Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Roman's comments

From: [email-masked] (Dale R. Worley)
Date: Mon, 05 Feb 2018 23:54:07 -0500

Christer Holmberg <[email-masked]> writes:
>>>> 3. Does the proxy strip the pn-XXX parameters when forwarding message 
>>>> to the client or are they kept? Does it strip them when comparing 
>>>> contact registration URI? Without this, change in pn-XXX parameters will result in a new registration instead of existing registration update.
>>> There is no stripping of parameters. The pn- parameters will typically not change between UA device reboots. But, if they do, it does require a new registration.
>>>
>> Then what happens if a "pn-XXX" enabled INVITE R-URI from UA "a" to UA "b" traverses a chain of SIP proxies which are all "sip-push" aware? 
>> Will they not each perform the following:
>>
>>     * launch PNS provider query
>>     * wait for re-REGISTER
>>     * forward INVITE to the next "sip-push" aware proxy
>
> The R-URI will only traverse between the UA and its registrar.

Really, this is the reason that you want all the pn-* parameters to be
header field parameters rather than URI parameters -- they're only used
in specific messages.  It doesn't make any sense to use them in the UA's
"real URI", which is used as the Contact field of requests, etc.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 05:10:29 +0000

Hi,

>>>>> 3. Does the proxy strip the pn-XXX parameters when forwarding 
>>>>> message to the client or are they kept? Does it strip them when 
>>>>> comparing contact registration URI? Without this, change in pn-XXX parameters will result in a new registration instead of existing registration update.
> Really, this is the reason that you want all the pn-* parameters to be header field parameters rather than 
> URI parameters -- they're only used in specific messages.  It doesn't make any sense to use them in the 
> UA's "real URI", which is used as the Contact field of requests, etc.

As I have said before, using header field parameters would have impact on the registrar, as it would have to store those separately. In IMS that would have impact on the HSS and interfaces. It would take a long time to update those, and SIP Push is a feature that is needed now. 

Regards,

Christer