Subject: Re: [sipcore] SIP Push with SIP notifications: Way forward - The instance id approach

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Sep 2018 06:43:29 +0000

The text for the SIP UA section would be something like:

"When the UA sends a REGISTER request (initial request for a registration or a binding refresh requests), if the UA supports SIP dialogs where the UA due long durations between in-dialog requests might be suspended while a dialog is 
still ongoing, the UA MUST include a '+sip.instance' Contact header field parameter [RFC5626] in the REGISTER request."

"When the UA sends an initial request for a dialog, or a 2xx response to an initial request for a dialog, if the UA due long durations between in-dialog requests might be suspended, and if the UA has included a '+sip.instance' Contact header 
field parameter in its REGISTER requests, the UA MUST  include a '+sip.instance' Contact header field parameter in the initial request (or 2xx response) for the dialog."

(I will submit a proper pull request, including also procedure text for the push proxy, if people are ok moving forward with an instance id based approach.)

Regards,

Christer

On 03/09/18 07:25, "sipcore on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,
    
    >>>>> I don’t think the proxy needs to modify the Contact. The proxy can 
    >>>>> provide a local GRUU e.g., using a media feature tag. That is my 
    >>>>> idea for providing the “random value” (no matter whether it is a 
    >>>>> GRUU or not).
    >>>>
    >>>> Ok, we can define a new media feature tag that proxy can add to 
    >>>> response which will be used similar to permanent GRUU. The push 
    >>>> enabled UA will use value of this field as a contact for all dialog 
    >>>> creating requests it will send.
    >>>
    >>> Just be careful about calling it a gruu unless it actually has gruu properties.
    >> 
    >> Well, most likely it won't be possible to use the "GRUU" outside the dialog to reach the UA...
    >
    > Then it is most definitely not a GRUU!
    >
    >> Also, I had some discussions about usage of a local GRUU provided by the proxy, and people had concerns that 
    >> this would prevent the UA from generating a local GRUU by its own - whatever the use-case for that would be.
    >> 
    >> A suggestion was to instead use the instance id: the UA would provide the instance id in the REGISTER, and in 
    >> the initial request for the dialog. The push proxy would then map the instance id of the dialog to the registration/PRID, 
    >> and be able to request a push notification when it e.g., receives a NOTIFY.  I think that sounds like a good suggestion.
    >
    > This sounds better, modulo security concerns.
    
    I guess whatever normal security concerns associated with instance id apply.
    
    Regards,
    
    Christer
    
    _______________________________________________
    sipcore mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sipcore

---

From: Roman Shpount <[email-masked]>
Date: Mon, 3 Sep 2018 13:48:09 -0400

Hi Christer,

On Mon, Sep 3, 2018 at 2:43 AM, Christer Holmberg <
[email-masked]> wrote:

> "When the UA sends a REGISTER request (initial request for a registration
> or a binding refresh requests), if the UA supports SIP dialogs where the UA
> due long durations between in-dialog requests might be suspended while a
> dialog is
> still ongoing, the UA MUST include a '+sip.instance' Contact header field
> parameter [RFC5626] in the REGISTER request."
>
> "When the UA sends an initial request for a dialog, or a 2xx response to
> an initial request for a dialog, if the UA due long durations between
> in-dialog requests might be suspended, and if the UA has included a
> '+sip.instance' Contact header
> field parameter in its REGISTER requests, the UA MUST  include a
> '+sip.instance' Contact header field parameter in the initial request (or
> 2xx response) for the dialog."
>
> (I will submit a proper pull request, including also procedure text for
> the push proxy, if people are ok moving forward with an instance id based
> approach.)
>
>
I generally like this solution. One comment that I have, should reg-id
parameter be included in the contact as well for completeness? This way
there is a one-to-one mapping to registration.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Sep 2018 18:04:28 +0000

Hi,

>> "When the UA sends a REGISTER request (initial request for a registration or a binding refresh requests), 
>> if the UA supports SIP dialogs where the UA due long durations between in-dialog requests might be suspended 
>> while a dialog is still ongoing, the UA MUST include a '+sip.instance' Contact header field parameter [RFC5626] in 
>> the REGISTER request."
>>
>> "When the UA sends an initial request for a dialog, or a 2xx response to an initial request for a dialog, if the UA 
>> due long durations between in-dialog requests might be suspended, and if the UA has included a '+sip.instance' 
>> Contact header field parameter in its REGISTER requests, the UA MUST  include a '+sip.instance' Contact header 
>> field parameter in the initial request (or 2xx response) for the dialog."
>>
> I generally like this solution. One comment that I have, should reg-id parameter be included in the contact as well for 
> completeness? This way there is a one-to-one mapping to registration.

I was thinking about that, but I don't see what reg-id would bring from a SIP push perspective.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 3 Sep 2018 22:14:30 -0400

On Mon, Sep 3, 2018 at 2:04 PM, Christer Holmberg <
[email-masked]> wrote:

> parameter be included in the contact as well for

Technically the same UA can register multiple times through the same
proxies and registrars with different contacts for different AOR and
provide different pn- values. UA will use the same sip.instance parameter
in the contact but different ref-id. If reg-id is provided with contact in
the dialog creating request (or 2XX response to it), it is possible to
determine the specific registration which corresponds to this contact.
Otherwise proxy will need to pull information for all registrations from
the UA and potentially send multiple push notifications.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Sep 2018 06:41:31 +0000

Hi,

> Technically the same UA can register multiple times through the same proxies and registrars with different contacts for different AOR 
> and provide different pn- values. UA will use the same sip.instance parameter in the contact but different ref-id. If reg-id is provided with 
> contact in the dialog creating request (or 2XX response to it), it is possible to determine the specific registration which corresponds to this 
> contact. Otherwise proxy will need to pull information for all registrations from the UA and potentially send multiple push notifications.

I think we should leave that for the future outbound-support work. In reality I think UAs will use a single push notification subscription, which means that they need to send re-REGISTER for all bindings.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 4 Sep 2018 09:24:11 -0400

On Tue, Sep 4, 2018 at 2:41 AM, Christer Holmberg <
[email-masked]> wrote:

> proxies and registrars with different contacts for different AOR
> > and provide different pn- values. UA will use the same sip.instance
> parameter in the contact but different ref-id. If reg-id is provided with
> > contact in the dialog creating request (or 2XX response to it), it is
> possible to determine the specific registration which corresponds to this
> > contact. Otherwise proxy will need to pull information for all
> registrations from the UA and potentially send multiple push notifications.
>
> I think we should leave that for the future outbound-support work. In
> reality I think UAs will use a single push notification subscription, which
> means that they need to send re-REGISTER for all bindings.
>
>
Does the draft specify that UA must use the same push notification
subscription for all registrations? it might not be possible if UA actually
registers with two different services.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Sep 2018 14:25:02 +0000

Hi,

> Does the draft specify that UA must use the same push notification subscription for all registrations? it might not be possible if UA actually registers with two different services.

Even if we use reg-id, there is no guarantee that two services would use different values. 

The only way to associate registration(s) with a specific push notification subscription is using the PRID.

So, perhaps we anyway should include the PRID in the initial request/response for a dialog (e.g., SUBSCRIBE). It could be included as a feature tag, which means the push proxy can remove it without being a B2BUA, and the value would not be sent to the remote network (read: no privacy issues).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 5 Sep 2018 12:16:43 -0400

> So, perhaps we anyway should include the PRID in the initial request/response for a dialog (e.g., SUBSCRIBE). It could be included as a feature tag, which means the push proxy can remove it without…

This only works if the UA *knows* that there is a middlebox that will 
remove this. If there doesn't happen to be one then the PRID will leak 
to the UAS.

I've lost track of the details of the environment where this case 
arises, so I don't know if this is a reasonable assumption.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Sep 2018 17:59:19 +0000

Hi,

>> So, perhaps we anyway should include the PRID in the initial request/response for a dialog (e.g., SUBSCRIBE). It could 
>> be included as a feature tag, which means the push proxy can remove it without being a B2BUA, and the value would 
>> not be sent to the remote network (read: no privacy issues).
>
> This only works if the UA *knows* that there is a middlebox that will remove this. If there doesn't happen to be one then the PRID will leak to the UAS.

The idea is that we would specify that the push proxy MUST remove it, if included in the request. 

The UA will find out during registration whether SIP push will be used.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 5 Sep 2018 15:57:03 -0400

> The UA will find out during registration whether SIP push will be used.

Does the agreement during registration guarantee that a push proxy will 
be on the path for dialogs? I think that then needs to be a normative 
requirement, along with the requirement to remove the PRID.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Sep 2018 20:05:02 +0000

Hi,

>>>> So, perhaps we anyway should include the PRID in the initial 
>>>> request/response for a dialog (e.g., SUBSCRIBE). It could be 
>>>> included as a feature tag, which means the push proxy can remove it without being a B2BUA, and 
>>>> the value would not be sent to the remote network (read: no privacy issues).
>>>
> Does the agreement during registration guarantee that a push proxy will be on the path for dialogs? 
>I think that then needs to be a normative requirement,

That is the assumption, because otherwise the proxy won't be able to request a push notification towards the UA if it receives a mid-dialog request and the UA is suspended - which is the reason we'd include the PRID in the initial request/response of the dialog to begin with.

But, I can add text making it a normative requirement. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 5 Sep 2018 18:09:56 -0400

> That is the assumption, because otherwise the proxy won't be able to request a push notification towards the UA if it receives a mid-dialog request and the UA is suspended - which is the reason we'…

It seems like there are two cases:

- those that only require a notification for re-registration and 
out-of-dialog requests;

- those that also require notification in the midst of *certain* long 
dialogs.

Only for the 2nd case is a push proxy required on the dialog path. At 
the time of registration, it seems to be necessary to declare or 
negotiate with case this is.

Things would be simpler if we could exclude one of those cases. Either 
by stating that the second case is not being addressed at all, or by 
stating that the machinery to support the second case must be present 
whether the UA needs it or not.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Sep 2018 07:02:46 +0000

Hi,
 
    >> That is the assumption, because otherwise the proxy won't be able to request a push notification towards the UA if it receives a mid-dialog request and 
    >>the UA is suspended - which is the reason we'd include the PRID in the initial request/response of the dialog to begin with.
    >

    There are two ways:

     1) The UA indicates whether it needs the machinery for a given dialog, by including the feature tag in the initial request for the dialog
     2) The UA always includes the feature tag, and the proxy decides whether the machinery is needed for a given dialog

     The logic for making the decision whether the machinery is needed for a dialog would be based on configuration, but I assume in most cases it would be used for SUB/NOT dialogs.

    Regards,

    Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 6 Sep 2018 11:24:50 -0400

>       The logic for making the decision whether the machinery is needed for a dialog would be based on configuration, but I assume in most cases it would be used for SUB/NOT dialogs.

Are you proposing that there be a separate feature tag for requesting 
in-dialog support?

This is sounding like a use case for either Require'ing an option tag or 
a caller-pref. Since the UA probably can't function without this the 
option tag seems preferred.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Sep 2018 16:28:35 +0000

Hi,

>>       The logic for making the decision whether the machinery is needed for a dialog would be based on configuration, but I assume 
>>       in most cases it would be used for SUB/NOT dialogs.
>
> Are you proposing that there be a separate feature tag for requesting in-dialog support?
>
> This is sounding like a use case for either Require'ing an option tag or a caller-pref. Since the UA probably can't function without
> this the option tag seems preferred.

I think the easiest solution is to simply say that, for subscription usage dialogs, the push proxy must insert itself in the dialog path, and the UA must provide (using a feature tag) the PRID in the initial request/response for the dialog. Then, whenever the push proxy receives an inbound mid-dialog request (e.g., NOTIFY), it requests a push notification towards the UA (unless it has other, unspecified, means to determine that the UA is awake).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 8 Sep 2018 12:45:26 -0400

> I think the easiest solution is to simply say that, for subscription usage dialogs, the push proxy must insert itself in the dialog path, and the UA must provide (using a feature tag) the PRID in t…

Currently there are two kinds of dialog usages: INVITE and SUBSCRIBE. In 
the discussion here there seems to be good use cases for needing push 
notifications for SUBSCRIBE usages. There was some suggestion of use 
cases in INVITE usages, perhaps not as compelling. In the case of 
SUBSCRIBE usages, the need may vary. Some (such as REFER) might be brief 
and not require push. It is the UAC that knows for sure.

Are you proposing that whenever there is a push proxy on the 
out-of-dialog case that it decide on its own whether it will be needed 
for push support each time a dialog is established and use that as part 
of the decision whether to record-route? (And that this decision perhaps 
be based on subscribe vs invite?)

Seems like it would be better for the need to be signaled to the push 
proxy by the UAC. Perhaps the presence of the PRID could be considered 
the signal.

In any case, this needs some normative text to ensure that the PRID 
doesn't leak downstream of the push proxy.

(This *almost* seems like a use case for Proxy-Require, but that would 
only work if the push proxy is always the first proxy on the path, and I 
don't think we can assume that.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Sep 2018 19:01:32 +0000

Hi,

>>>>> - those that also require notification in the midst of *certain* 
>>>>> long dialogs.
>>>>>
>>>>> Only for the 2nd case is a push proxy required on the dialog path. 
>>>>> At the time of registration, it seems to be necessary to declare or 
>>>>> Things would be simpler if we could exclude one of those cases. 
>>>>> Either by stating that the second case is not being addressed at 
>>>>> all, or by stating that the machinery to support the second case 
>>>>> must be present whether the UA needs it or not.
>>>>
>>>>       There are two ways:
>>>>
>>> This is sounding like a use case for either Require'ing an option tag 
>>> or a caller-pref. Since the UA probably can't function without this the option tag seems preferred.
>> 
>> I think the easiest solution is to simply say that, for subscription usage dialogs, the push proxy must insert 
>> itself in the dialog path, and the UA must provide (using a feature tag) the PRID in the initial request/response 
>> for the dialog. Then, whenever the push proxy receives an inbound mid-dialog request (e.g., NOTIFY), it requests 
>> a push notification towards the UA (unless it has other, unspecified, means to determine that the UA is awake).
>>
>> Currently there are two kinds of dialog usages: INVITE and SUBSCRIBE. In the discussion here there seems to be good 
>> use cases for needing push notifications for SUBSCRIBE usages. There was some suggestion of use cases in INVITE usages, 
>> perhaps not as compelling. In the case of SUBSCRIBE usages, the need may vary. Some (such as REFER) might be brief and 
>> not require push. It is the UAC that knows for sure.
>
> Are you proposing that whenever there is a push proxy on the out-of-dialog case that it decide on its own whether it will be 
> needed for push support each time a dialog is established and use that as part of the decision whether to record-route? (And 
> that this decision perhaps be based on subscribe vs invite?)

Yes.

In the deployments I am aware of, the push proxy will anyway insert itself in the dialog path, but one can of course not guarantee that will always be the case.

> Seems like it would be better for the need to be signaled to the push proxy by the UAC. Perhaps the presence of the PRID could be considered the signal.

That would work in cases where the UA sends the SUBSCRIBE request.

But, in case where a SUBSCRIBE is sent towards the UA, the UA will send the PRID in the response - but the proxy needs to make the decision whether to insert itself in the dialog before that.

>In any case, this needs some normative text to ensure that the PRID doesn't leak downstream of the push proxy.

There needs to be text saying that the proxy MUST remove the PRID.

>(This *almost* seems like a use case for Proxy-Require, but that would only work if the push proxy is always the first 
>proxy on the path, and I don't think we can assume that.)

No. There are cases where the push proxy will be co-located with the home proxy, which means there will be may be other proxies between.

Obviously, the push proxy will now need to store the pn- parameters, and associate the subscribe usage dialog with them, so that it can request the push notification whenever it receives the mid-dialog NOTIFY. And, it needs to monitor the lifetime of the registration, so it knows when it can discard the parameters.

For initial requests sent towards the UA, the push proxy does not need to store anything, as the pn- parameters will be present in the R-URI (inserted by the home proxy).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 8 Sep 2018 17:01:47 -0400

> But, in case where a SUBSCRIBE is sent towards the UA, the UA will send the PRID in the response - but the proxy needs to make the decision whether to insert itself in the dialog before that.

This is theoretically an issue, but is it so in practice? When would a 
device that needs push notifications be the UAS of a long lived SUBSCRIBE?

Perhaps this might be the case for an INVITE. (E.g. in a 3pcc case.) 
That might need more consideration.

> There needs to be text saying that the proxy MUST remove the PRID.

And text saying that it MUST record-route when is sees a PRID in the 
dialog initiating request.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 9 Sep 2018 15:27:11 +0000

Hi,

>>>>>>> At the time of registration, it seems to be necessary to declare 
>>>>>>> or negotiate with case this is.
>>>>>>>
>>>>> This is sounding like a use case for either Require'ing an option 
>>>>> tag or a caller-pref. Since the UA probably can't function without this the option tag seems preferred.
>>>>
>>>> I think the easiest solution is to simply say that, for subscription 
>>>> usage dialogs, the push proxy must insert itself in the dialog path, 
>>>> and the UA must provide (using a feature tag) the PRID in the 
>>>> initial request/response for the dialog. Then, whenever the push proxy receives an 
>>>> inbound mid-dialog request (e.g., NOTIFY), it requests a push notification towards the 
>>>> UA (unless it has other, unspecified, means to determine that the UA is awake).
>>>>
>>>> Currently there are two kinds of dialog usages: INVITE and 
>>>> SUBSCRIBE. In the discussion here there seems to be good use cases 
>>>> for needing push notifications for SUBSCRIBE usages. There was some 
>>>> suggestion of use cases in INVITE usages, perhaps not as compelling. In the case 
>>>> of SUBSCRIBE usages, the need may vary. Some (such as REFER) might be brief and 
>>> out-of-dialog case that it decide on its own whether it will be 
>>> needed for push support each time a dialog is established and use 
>>> that as part of the decision whether to record-route? (And that this 
>>> decision perhaps be based on subscribe vs invite?)
>> 
>> Yes.
>> 
>> In the deployments I am aware of, the push proxy will anyway insert itself in the dialog path, but 
>> one can of course not guarantee that will always be the case.
>> 
>> But, in case where a SUBSCRIBE is sent towards the UA, the UA will send the PRID in the response - but 
>> the proxy needs to make the decision whether to insert itself in the dialog before that.
>
> This is theoretically an issue, but is it so in practice? When would a device that needs push 
> notifications be the UAS of a long lived SUBSCRIBE?

In my opinion, never, and I'd be happy to say that use-case is not supported by the draft.

>Perhaps this might be the case for an INVITE. (E.g. in a 3pcc case.) That might need more consideration.
>
> And text saying that it MUST record-route when is sees a PRID in the dialog initiating request.

Correct.

Regards,

Christer