Subject: Re: [sipcore] SIP Push with SIP notifications: Way forward - The text using PURK - Pull request

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Sep 2018 11:37:49 +0000

Pull request created:

https://github.com/cdh4u/draft-sip-push/pull/23

I call the new parameter PURK (Proxy Unique Registration Key), but let me know if you have a better suggestion :)

Regards,

Christer

On 18/09/18 03:29, "Paul Kyzivat" <[email-masked]> wrote:

    On 9/17/18 3:58 PM, Christer Holmberg wrote:
    > Hi,
    > 
    >>>>> I have put together initial text to support mid-dialog NOTIFY request.
    >>>>>
    >>>>> I put everything in a dedicated section.
    >>>>>
    >>>>> If people are ok with the approach, I will create a proper pull request.
    >>>>
    >>>> I have one concern about this:
    >>>>
    >>>> The doc says that the PRID must be unique. But it doesn't state the
    >>>> scope of uniqueness. It looks to me that until now the PRID only had
    >>>> to be unique among PRID values issued by the same PNS. (At least if
    >>>> we assume that a given UA only uses one PNS.) But the new text for
    >>>> subscription dialogs expands the requirement. Now the PRID must be unique
    >>>> among all dialogs managed by the push proxy. These might involve multiple PNSs.
    >>>>
    >>>> It is hard to ensure uniqueness of PRID values across multiple PNSs
    >>>> since the format is left entirely up to the PNS. I think this needs more consideration.
    >>>
    >>> We can include more information in the SUBSCRIBE, if needed.
    >>
    >> Certainly more info there is needed. But I also think more needs to be said up front and first specification of PRID,
    >> that global uniqueness is required, across *all* PNSs. But beyond that, I don't see how it can be left to each individual
    >> PNS to specify how it is going to guarantee that its values are unique from those of other PNSs. Seems like each PNS needs
    >> to have a distinct namespace somehow.
    > 
    > Even though I think that PRIDs will be globally unique in reality, we can't mandate in the speciation. But, for normal push cases that is not a problem, since there are additional pn- parameters.
    > 
    > Anyway, if people are ok with Roman's suggestion of the proxy generating a random value (not a gruu) I think that would probably be a better solution.
    
    Yes, I agree it is a better solution.
    
    	Thanks,
    	Paul

---

From: Robert Sparks <[email-masked]>
Date: Tue, 18 Sep 2018 10:16:43 -0500

I'm having (minor) difficulty reading the current document (with this pr 
applied) because I think there's still unnecessary specialization of 
behavior.

Let me summarize what I think the document is currently saying. Correct 
me where I have this wrong:

1) There is a token that is used to allow a push server to wake a UA if 
an out-of-dialog request arrives when the UA is asleep. That token 
becomes known first to the registration system (which either generates 
it, or has access to something outside our architectural model that 
generates it). We assume that the SIP domain using this extension is 
constructed in such a way that some proxy in the path of an inbound 
request can put that token into the inbound request. It is passed in the 
REGISTER response so that that proxy, and the push proxy, can learn the 
value of the token (and remember it is associated with this registration 
flow).

2) There is a token that is used to allow a push server to wake a UA if 
an in-dialog NOTIFY arrives when the UA is asleep. Again, that token 
becomes known first to the registration system (which generates it, or 
gets it through some outside magic as above). The push proxy gets to see 
it in the REGISTER response, and associate it with the registration 
flow. It gets used as the Local-Target when the UA sets up a 
subscription dialog.

If that's correct, I have two questions:

1) Why are there two tokens? It seems one would do.

2) Why make SUBSCRIBE special this way? Even if current wireless 
networks would never use it with INVITE (since there are keepalives and 
all sorts of other things that would never let the UA sleep anyhow), or 
with SUBSCRIBE requests the UA receives, I don't see the harm in 
simplifying the specification to just use this in all dialogs. Any 
dialog initiating/refreshing request could behave like the way you have 
SUBSCRIBE specified in the draft. Existing wireless deployments would 
never end up using it outside the SUBSCRIBE case the draft is talking 
about, and that's fine. But this would cover the behavior for all of 
SIP. (For instance, some system that used MSRP might well have an INVITE 
dialog that lives a long time, with infrequent use of the media path, 
and an endpoint there could quite reasonably sleep). Then the text in 
this spec (and I think the code in any implementation) would become much 
simpler.

RjS

On 9/18/18 6:37 AM, Christer Holmberg wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Sep 2018 18:56:45 +0000

Hi,

>applied) because I think there's still unnecessary specialization of behavior.
>
>Let me summarize what I think the document is currently saying. Correct me where I have this wrong:
>
> 1) There is a token that is used to allow a push server to wake a UA if an out-of-dialog request arrives when the UA is asleep. 
> That token becomes known first to the registration system (which either generates it, or has access to something outside our 
> architectural model that generates it). We assume that the SIP domain using this extension is constructed in such a way that 
> some proxy in the path of an inbound request can put that token into the inbound request. It is passed in the REGISTER response 
> so that that proxy, and the push proxy, can learn the value of the token (and remember it is associated with this registration flow).
>
>2) There is a token that is used to allow a push server to wake a UA if an in-dialog NOTIFY arrives when the UA is asleep. Again, that token becomes known first to the >registration system (which generates it, or gets it through some outside magic as above). The push proxy gets to see it in the REGISTER response, and associate it with the >registration flow. It gets used as the Local-Target when the UA sets up a subscription dialog.

The token is generated by the push proxy, and is provided to the UA in the REGISTER 2xx response.

The UA then includes the token in the Contact URI of the SUBSCRIBE request, so that it will be present in the mid-dialog NOTIFY requests. The push proxy will then be able to find the associated push information.

>1) Why are there two tokens? It seems one would do.

There is only one token, but two ways to carry it: feature-capability indicator in the REGISTER response and SIP URI parameter in the SUBSCRIBE and NOTIFY requests.

>2) Why make SUBSCRIBE special this way? Even if current wireless networks would never use it with INVITE (since there are keepalives and all sorts of other things that >would never let the UA sleep anyhow), or with SUBSCRIBE requests the UA receives, I don't see the harm in simplifying the specification to just use this in all dialogs. Any >dialog initiating/refreshing request could behave like the way you have SUBSCRIBE specified in the draft. Existing wireless deployments would never end up using it outside >the SUBSCRIBE case the draft is talking about, and that's fine. But this would cover the behavior for all of SIP. (For instance, some system that used MSRP might well have an >INVITE dialog that lives a long time, with infrequent use of the media path, and an endpoint there could quite reasonably sleep). Then the text in this spec (and I think the >code in any implementation) would become much simpler.

We can for sure allow this also in INVITE dialogs.

However, in VoIP sessions it is not needed, as the UA will be awake during the session, so I don't think we shall mandate it.

Regards,

Christer

On 9/18/18 6:37 AM, Christer Holmberg wrote:
> I call the new parameter PURK (Proxy Unique Registration Key), but let 
> me know if you have a better suggestion :)
>
> Regards,
>
> Christer
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Sep 2018 10:41:53 +0000

Hi,
    
>> 2) Why make SUBSCRIBE special this way? Even if current wireless networks would never use it with INVITE (since there are keepalives and all sorts of other things that 
>> would never let the UA sleep anyhow), or with SUBSCRIBE requests the UA receives, I don't see the harm in simplifying the specification to just use this in all dialogs. Any 
>> dialog initiating/refreshing request could behave like the way you have SUBSCRIBE specified in the draft. Existing wireless deployments would never end up using it outside 
>> the SUBSCRIBE case the draft is talking about, and that's fine. But this would cover the behavior for all of SIP. (For instance, some system that used MSRP might well have an 
>> INVITE dialog that lives a long time, with infrequent use of the media path, and an endpoint there could quite reasonably sleep). Then the text in this spec (and I think the 
>> code in any implementation) would become much simpler.
>    

One thing to keep in mind is that, for incoming sessions towards the UA, the push proxy needs to make a decision whether to add a Record-Route before it gets any indication from the UA.

Now, the UA could still indicate in the 2xx response that it does not want to receive mid-dialog push requests, but the proxy cannot "undo" the Record-Route.

Regards,

Christer