Subject: [sipcore] sip-push Discussion Points

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Jan 2019 17:42:55 -0600

Hi,

I promised Christer that I would send a list of the technical points from the IESG ballots that I think require working group discussion. Here’s that list.

Thanks!

Ben.

---------------

From Adam's ballot DISCUSS points:

- Maintaining soft-state of dialogs.
- Privacy considerations of Contact-URI parameters available via RFC 3680 subscriptions
- Negotiating supported PNSs between UA and registrar. ( I see that discussion this one is already happening.)

From Adam's additional comments:

- Requirement for proxies to know what PNSs may be supported by downstream proxies.

- Discussion of response codes. This includes loosening the MUST requirements to send specific response codes. (I agree with Adam's suggestion, but the wg needs to vet it.). It also includes the discussion of the impact of response code choices (see Adam's comments on §6.2.3)

From Ekr's ballot:

-comment on §5.3.2: Discussion about whether the proxy should be allowed to race an incoming request with the push-notification generated re-registration.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Jan 2019 12:08:43 +0000

Hi,

I have already created threads for a couple of the issues listed by Ben. I will create separate threads for the other ones. This one covers Adam's soft state issue (DISCUSS).

-What is it about?

Adam indicated that the current solution does not allow negotiating push notifications for subscription refreshes and session-timer refreshes. Of course, one could use the same timer values as for the binding refresh, and send SUBSCRIBE and/or re-INVITE at the same time as REGISTER.

-What do I think?

I think that, as far as the base mechanism is concerned, if this functionality is needed one should use the binding refresh timer. I think that should work at least for subscription refreshes.

Regarding session-timers:

First, they are only sent within INVITE initiated dialog, and the assumption has been that the UA is awake during such dialogs.

Second, IF there is a long-lived INVITE initiated dialog, where the UA might go to sleep during the dialog, one could use the registration timer also for that.

(FWIW, I talked to some product people, and they had never heard about a need for using push for session-timers.)

-What do I suggest?

My suggestion is to keep the existing binding-associated push notification, and add text about how it can also be used for subscriptions and/or session-timers, if needed.

Then, once we get more deployment experience, IF we realize there is a need to negotiate explicit push notifications for subscriptions and/or session-timers we can define that in a separate draft.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Jan 2019 12:14:59 +0000

Hi,

I have already created threads for a couple of the issues listed by Ben. I will create separate threads for the other ones. This one covers Adam's response code issue.

-What is it about?

Adam indicated that the text is too strict (using MUST) regarding which error response codes to use (404 or 480). He suggested that the text can recommend usage of 404 or 480, and allow others. However, when sending an error response to a mid-dialog request, the proxy needs to take into consideration whether the response code only terminates the transaction, or the whole dialog usage.

-What do I think?

I have no problem with Adam's suggestion.

-What do I suggest?

Recommend usage of 404 or 480, but allow usage of others.

In the mid-dialog request section, add a reference to RFC 5057.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Jan 2019 12:20:44 +0000

Hi,

I have already created threads for a couple of the issues listed by Ben. I will create separate threads for the other ones. This one covers Adam's issue regarding proxies knowing what downstream proxies support.

-What is it about?

The text allows a proxy to forward a REGISTER request to another proxy, if it "knows" that is supports a PNS supported by the UA.

Adam asked how a proxy would know.

-What do I think?

The knowledge is done by operator configuration, but I agree that is not clear in the text.

-What do I suggest?

Add text clarifying that the knowledge is based on operator configuration.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Jan 2019 12:27:19 +0000

Hi,

I have already created threads for a couple of the issues listed by Ben. I will create separate threads for the other ones. This one covers Ekr's race issues (COMMENT).

-What is it about?

When a proxy receives a request, addressed towards the UA, the default behaviour is to request that a push notification is sent to the UA, wait for the REGISTER request AND the associated REGISTER 2xx response, and then forward the request.

As an optimization, the text allows the proxy to forward the request immediately, if it has "knowledge" that the UA is awake.

Ekr suggested that a proxy should always be allowed to forward the request at the same time as requesting the push notification, without having any knowledge about whether the UA is awake, and without waiting for the REGISTER request/response.

-What do I think?

I do NOT think we should make this change. The WG did discuss this, decided on the wait-for-the-REGISTER-2xx approach, and the draft explains the reasons.

-What do I suggest?

If something regarding the current approach is unclear I am happy to add clarification text, but other than that my suggestion is that we don't do anything regarding this issue.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Jan 2019 12:44:41 -0500

On 1/12/19 7:20 AM, Christer Holmberg wrote:
> Hi,
> 
> I have already created threads for a couple of the issues listed by Ben. 
> I will create separate threads for the other ones. This one covers 
> Adam's issue regarding proxies knowing what downstream proxies support.
> 
> -What is it about?
> 
> The text allows a proxy to forward a REGISTER request to another proxy, 
> if it "knows" that is supports a PNS supported by the UA.
> 

Features that require configuration are burdensome and prone to error. A 
mechanism that doesn't require it is preferred.

Without going into detail, ISTM that a mechanism can be devised that 
doesn't require this knowledge. But this first requires deciding who 
should choose when multiple PNSs are supported by both client and 
proxies/registrar.

One possibility is to use one round trip to discover what PNSs are 
supported by proxies on the path. Then the client can choose one, 
initialize just *that* PNS, and then another round trip to enable that 
choice. This way would be less efficient in initial setup because it 
would require two round trips, but it would be more efficient long term 
because the client would only have to enable the PNS that will be used, 
and we might be able to find a way to eliminate the unneeded push 
proxies from the path.

Another way would be for the client to indicate its preference among 
supported PNSs. During the request, the highest priority supported PNS 
can be identified. Then in the response, the proxy supporting that PNS 
can do the necessary setup. This only requires one round trip. But it 
requires the registrar to mirror something from the request to the 
response. It also requires the client to initialize all supported PNSs 
even though only one will be used.

Yet another way would be for client to indicate all supported PNSs. The 
first proxy that supports one of them becomes the push proxy, and 
removes the request for a push proxy before forwarding the request. Push 
proxies that don't support any of the PNSs just forward the request. If 
none of the PNSs are supported, the registration will complete without 
one. In that case the client will have to decide whether to cope with 
that or remove the registration and give up. This approach only takes 
one round trip (except in case of non-support). But the choice of which 
PNS to use is made based on the order of proxies, not on client 
preference. And again the client has to initialize all its supported PNSs.

In all of these, after the initial registration the client can optimize 
for the chosen PNS. It can close down sessions with other PNSs and only 
mention the chosen PNS in future registration requests.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Sat, 12 Jan 2019 17:28:28 -0500

On Sat, Jan 12, 2019 at 7:27 AM Christer Holmberg <
[email-masked]> wrote:

> -What is it about?
>
> When a proxy receives a request, addressed towards the UA, the default
> behaviour is to request that a push notification is sent to the UA, wait
> for the REGISTER request AND the associated REGISTER 2xx response, and then
> forward the request.
>
>
> As an optimization, the text allows the proxy to forward the request
> immediately, if it has "knowledge" that the UA is awake.
>
> Ekr suggested that a proxy should always be allowed to forward the request
> at the same time as requesting the push notification, without having any
> knowledge about whether the UA is awake, and without waiting for the
> REGISTER request/response.
>
> -What do I think?
>
> I do NOT think we should make this change. The WG did discuss this,
> decided on the wait-for-the-REGISTER-2xx approach, and the draft explains
> the reasons.
>

I agree. I do not think it is a good idea to always send request at the
same time as push notification. The optimization is there  when persistent
TLS connection from the client is used, which is required on most mobile
platforms. In this case proxy can determine that this connection is still
active (recent TCP keep-alive was received on this connection). If this
connection is active, proxy can send request immediately. If no connection
from the client is available, proxy needs to send the push notification
since there is no way to send the request to the client.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sat, 12 Jan 2019 17:29:41 -0500

On Sat, Jan 12, 2019 at 7:15 AM Christer Holmberg <
[email-masked]> wrote:

> -What is it about?
>
> Adam indicated that the text is too strict (using MUST) regarding which
> error response codes to use (404 or 480). He suggested that the text can
> recommend usage of 404 or 480, and allow others. However, when sending an
> error response to a mid-dialog request, the proxy needs to take into
> consideration whether the response code only terminates the transaction, or
> the whole dialog usage.
>
> -What do I think?
>
I agree. We should make usage of 404 or 480 a SHOULD, but allow proxy to
send other errors.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sat, 12 Jan 2019 17:36:16 -0500

On Sat, Jan 12, 2019 at 7:08 AM Christer Holmberg <
[email-masked]> wrote:

> -What is it about?
>
> Adam indicated that the current solution does not allow negotiating push
> notifications for subscription refreshes and session-timer refreshes. Of
> course, one could use the same timer values as for the binding refresh, and
> send SUBSCRIBE and/or re-INVITE at the same time as REGISTER.
>
> -What do I think?
>
> I think that, as far as the base mechanism is concerned, if this
> functionality is needed one should use the binding refresh timer. I think
> that should work at least for subscription refreshes.
>
> First, they are only sent within INVITE initiated dialog, and the
> assumption has been that the UA is awake during such dialogs.
>
> Second, IF there is a long-lived INVITE initiated dialog, where the UA
> might go to sleep during the dialog, one could use the registration timer
> also for that.
>
> My suggestion is to keep the existing binding-associated push
> notification, and add text about how it can also be used for subscriptions
> and/or session-timers, if needed.
>
> Then, once we get more deployment experience, IF we realize there is a
> need to negotiate explicit push notifications for subscriptions and/or
> session-timers we can define that in a separate draft.
>

During our implementation we have bound SUBSCRIBE intervals to Registration
refresh intervals, so subscriptions were always refreshed at the same time
as registrations. Registration refresh was initiated by the push
notification. NOTIFY messages during subscription, such as MWI would cause
a push notification which would wake up the client and make it issue
Registration/Subscription which would cause the NOTIFY messages with
subscription state.

Session-timers during calls were trivial since client was awake and could
use regular timers.

We had no experience with long duration INVITE dialogs.

I do not think anything needs to change in the current specification except
for potentially additional explanation text.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 13 Jan 2019 13:33:55 +0000

Hi Roman,

The suggestion is to use RECOMMENDED for 404 and 480, but whatever the community decides...

Regards,

Christer

________________________________
From: Roman Shpount <[email-masked]>
Sent: Sunday, January 13, 2019 12:29 AM
To: Christer Holmberg
Cc: Ben Campbell; [email-masked]; [email-masked]
Subject: Re: [sipcore] sip-push Discussion Points - Adam's response code issue

On Sat, Jan 12, 2019 at 7:15 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

-What is it about?

-What do I think?

-What do I suggest?

I agree. We should make usage of 404 or 480 a SHOULD, but allow proxy to send other errors.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 13 Jan 2019 13:41:37 +0000

Hi,

Perhaps adding something like:

"If a SIP UA needs to wake up for other usages than those described in this document (e.g., for sending a subscription refresh SUBSCRIBE request [RFC6665]), this document does not define a mechanism to negotiate push notifications explicitly for such usages. However, by using the same refresh interval that is used for the binding-refreshes, the UA can perform actions associated with such usages (in addition to sending a binding-refresh REGISTER request) whenever it receives a push notification."

Regards,

Christer

________________________________
From: Roman Shpount <[email-masked]>
Sent: Sunday, January 13, 2019 12:36 AM
To: Christer Holmberg
Cc: Ben Campbell; [email-masked]; [email-masked]
Subject: Re: [sipcore] sip-push Discussion Points - Adam's soft state issue

On Sat, Jan 12, 2019 at 7:08 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

-What is it about?

-What do I think?

-What do I suggest?

During our implementation we have bound SUBSCRIBE intervals to Registration refresh intervals, so subscriptions were always refreshed at the same time as registrations. Registration refresh was initiated by the push notification. NOTIFY messages during subscription, such as MWI would cause a push notification which would wake up the client and make it issue Registration/Subscription which would cause the NOTIFY messages with subscription state.

Session-timers during calls were trivial since client was awake and could use regular timers.

I do not think anything needs to change in the current specification except for potentially additional explanation text.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 13 Jan 2019 14:07:59 +0000

Hi,

>choice.

This is basically how it already works. Note that the suggested change applies to "query mode", where the UA does *not*  provide a PRID, so no PNS will be "enabled".

Then, when the UA wants to enable a PNS, it sends a *single* PRID, associated with the PNS it wants to use - as currently specified.

Now, I have no problem with allowing multiple proxies to indicate support of one or more PNSs (or a single proxy indicating support of multiple PNSs) in query mode, if people think that would be useful. That would mean adding one Feature-Caps header field per supported PNS.

So, in query mode, a REGISTER 2xx response could look something like:

Feature-Caps: +apns
Feature-Caps: +fcm
Feature-Caps: +webpush, vapid

However, I still want to allow a proxy to send 555, if it "knows" that no downstream proxy will support any of the PNSs indicated by the UA. The reason is to avoid the REGISTER to reach the registrar and cause a registration that won't be needed (since there is no common PNS supported by the UA and any of the proxies).

Regards,

Christer

 This way would be less efficient in initial setup because it

        Thanks,
        Paul

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore
sipcore Info Page - IETF<https://www.ietf.org/mailman/listinfo/sipcore>
www.ietf.org
Your email address: Your name (optional): You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your ...

---

From: Roman Shpount <[email-masked]>
Date: Sun, 13 Jan 2019 15:43:17 -0500

On Sun, Jan 13, 2019 at 8:41 AM Christer Holmberg <
[email-masked]> wrote:

> "If a SIP UA needs to wake up for other usages than those described in
> this document (e.g., for sending a subscription refresh SUBSCRIBE request
> [RFC6665]), this document does not define a mechanism to negotiate push
> notifications explicitly for such usages. However, by using the same
> refresh interval that is used for the binding-refreshes, the UA can perform
> actions associated with such usages (in addition to sending a
> binding-refresh REGISTER request) whenever it receives a push notification."
>
>
>
This looks good to me.

Thank You,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sun, 13 Jan 2019 15:44:30 -0500

> The suggestion is to use RECOMMENDED for 404 and 480, but whatever the
RECOMMENDED also works for me.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2019 12:14:15 -0500

On 1/13/19 9:07 AM, Christer Holmberg wrote:
> This is basically how it already works. Note that the suggested change 
> applies to "query mode", where the UA does *not*  provide a PRID, so no 
> PNS will be "enabled".

Ah! I didn't catch that point.

> Then, when the UA wants to enable a PNS, it sends a *single* PRID, 
> associated with the PNS it wants to use - as currently specified.

OK, that seems reasonable.

> Now, I have no problem with allowing multiple proxies to indicate 
> support of one or more PNSs (or a single proxy indicating support of 
> multiple PNSs) in query mode, if people think that would be useful. That 
> would mean adding one Feature-Caps header field per supported PNS.
> 

And then the UA gets to choose. Sounds good.

> However, I still want to allow a proxy to send 555, if it "knows" that 
> no downstream proxy will support any of the PNSs indicated by the UA. 

While I have no problem with this if the proxy truly knows, I'm not 
inclined to trust a proxy's judgement on this point. It will be pretty 
tempting for implementations to simply *assume* they are the only one 
and always send the 555. Do we expect that there will be adequate 
motivation for proxies to do this right?

> The reason is to avoid the REGISTER to reach the registrar and cause a 
> registration that won't be needed (since there is no common PNS 
> supported by the UA and any of the proxies).

I understand the desire to optimize here, but it is likely to be an 
almost insignificant optimization. It will save *one* registration, but 
when using PUSH there will most likely be *many* subsequent 
push-triggered registrations. Is it worth the bother and complexity?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Jan 2019 18:27:17 +0000

Hi,

    >motivation for proxies to do this right?

    I don't it will work based on the proxy's judgement - proxies will be configured whether to send 555 or not. We also say that the sending of 555 is based on local configuration.

    > push-triggered registrations. Is it worth the bother and complexity?

    It is not about the number of registration messages, but the fact that in some networks each registration consumes resources. And, if no proxy supports the UA PNS, there is no reason to create a registration for that UA, since it anyway won't be able to receive incoming calls.

   And, this is not new text - the option to either forward the request or send 555 has been there all the time.

    Regards,

    Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jan 2019 16:50:05 -0500

>      I don't it will work based on the proxy's judgement - proxies will be configured whether to send 555 or not. We also say that the sending of 555 is based on local configuration.

At least the ones you are affiliated with will be.
I have less confidence in any others.
But I'm not going to fight this.

>      It is not about the number of registration messages, but the fact that in some networks each registration consumes resources. And, if no proxy supports the UA PNS, there is no reason to create…

OK, that is a more convincing argument.

I will be satisfied once multiple PNSs can be handled in query mode.

	Thanks,
	Paul