Subject: Re: [sipcore] Draft new version: sip-push-13

From: Brian Rosen <[email-masked]>
Date: Fri, 4 May 2018 09:33:33 -0400

Are everyone’s issues resolved?  

Should we progress this draft to IESG?

Brian

> On Apr 11, 2018, at 9:00 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> I have merged the PR based on Martin’s comments, and submitted a new version (-13) of SIP Push.
> 
> The biggest change is the addition of the possibility to perform a registration and query the network push capabilities, without actually triggering push notifications. This allows a UA to e.g., retrieve the VAPID information before registering to the PNS.
> 
> Regards,
> 
> Christer
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 May 2018 01:14:49 +0000

Datatracker only shows -11.  Am I missing something? I don't want to review
an old draft.

> The biggest change is the addition of the possibility to perform a
registration and query the network push capabilities, without actually
triggering push notifications. This allows a UA to e.g., retrieve the VAPID
information before registering to the PNS.

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 06 May 2018 22:07:05 -0400

Brian Rosen <[email-masked]> writes:
> Are everyone's issues resolved?  
>

I'm behind on the sip-push worki, and I probably would prefer some
changes.  But my concerns have certainly been considered enough by the
authors.  Let it progress, whatever my opinions ...

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 May 2018 04:45:14 +0000

Hi,

Version -11, that was submitted about a month ago, is the latest version.

Sorry for the confusion.

Regards,

Christer

Sent from my iPhone

On 7 May 2018, at 4.15, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

Datatracker only shows -11.  Am I missing something? I don't want to review
an old draft.
On Fri, May 4, 2018 at 11:33 PM Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Brian

On Apr 11, 2018, at 9:00 AM, Christer Holmberg <
[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I have merged the PR based on Martin’s comments, and submitted a new
version (-13) of SIP Push.

Regards,

Christer
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 May 2018 11:35:47 +1000

I took another look.

I'm still not getting any clarity from the doc about the relationship
between reachability of the UA (as determined by NAT binding timers, for
instance), and the lifetime of the registration.  All this takes is saying
that the registration might last longer than NAT bindings and that push can
be used to ensure reachability for the entire duration of the registration.

sip.pnsreg overloads two concepts:

The first (the one I think that is important to signal) is that is signals
that a UA can maintain its subscriptions.  However, I would question the
choice of not making this the default - given that this is the assumption
in SIP.  A signal to the proxy/registrar that a push is needed to ensure
that registrations can be refreshed before expiration would be much closer
to existing SIP semantics (as I understand them).

The second is maintaining the timing for refreshing subscriptions.  This is
questionable.  Isn't there already a way of a proxy/registrar signaling its
knowledge of NAT binding timers?  The odd part is that this is relative to
the end of the subscription, requiring calculations from both parties.  If
the intent is to ensure that NAT bindings don't time out, I think that you
want a separate parameter that indicates how often the registration needs
to be refreshed - if there isn't one already.
On Wed, Apr 11, 2018 at 11:01 PM Christer Holmberg <

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 May 2018 07:16:36 +0000

Hi,

>be used to ensure reachability for the entire duration of the

Not sure I follow. Do you want to use push as a way to trigger NAT
keep-alives while the UA is active?

While the UA is active, there are other mechanisms no negotiate
keep-alives.

>to existing SIP semantics (as I understand them).

I would prefer the be default to be that the UA informs that it isn¹t able
to do anything without push notifications, and then signal exceptions.

>to be refreshed - if there isn't one already.

The SIP REGISTER request/response contains a parameter that indicates when
the registration expires.

The purpose of sip.pnsreq is to indicate how long, prior the expiration,
the UA will have to send the re-registratation request.

Regards,

Christer

>> I have merged the PR based on Martin¹s comments, and submitted a new

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 May 2018 08:27:38 +1000

> keep-alives while the UA is active?

I'm looking for the document to be clearer.

> to do anything without push notifications, and then signal exceptions.

The primary mechanism in this document is an augmentation of UA contact
details.  If you think of it that way, the lack of reachability is the
exceptional condition.

> the UA will have to send the re-registratation request.

I understand that this is how you have defined it.  I just don't think that
it makes a lot of sense when framed that way.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 May 2018 06:35:37 +0000

Hi,

>>> between reachability of the UA (as determined by NAT binding timers, 
>>> for instance), and the lifetime of the registration.  All this takes 
>>> is saying that the registration might last longer than NAT bindings and that 
>>> push can be used to ensure reachability for the entire duration of 
>>> the registration.
>>

The text currently says:

   "Because of the restrictions above, Session Initiation Protocol (SIP)
   User Agents (UAs) [RFC3261] can not be awoken, in order to send re-
   registration SIP REGISTER requests and to receive incoming SIP
   requests, without using a PNS to awake the UA in order to perform
   those functions.

   Also, without being able to use internal timers in order to awake
   applications, a UA will not be able to maintain connections e.g.,
   using the SIP Outbound Mechanism [RFC5626], as it requires the UA to
   send periodic keep-alive messages."

I suggest to remove the second paragraph, talking about maintaining connections with keep-alives. Will that make things more clear?

---

>>>The first (the one I think that is important to signal) is that is
>>> signals that a UA can maintain its subscriptions.  However, I would question 
>>> the choice of not making this the default - given that this is the 
>>> assumption in SIP.  A signal to the proxy/registrar that a push is 
>>> needed to ensure that registrations can be refreshed before 
>>> expiration would be much closer to existing SIP semantics (as I understand them).
>>>
>>> I would prefer the be default to be that the UA informs that it isn¹t 
>>> able to do anything without push notifications, and then signal exceptions.
>>
>> The primary mechanism in this document is an augmentation of UA contact details.  
>> If you think of it that way, the lack of reachability is the exceptional condition.

The primary mechanism is to wake up suspended UAs, in order to maintain registrations and provide reachability. That was the original use-case that triggered the whole document.

The possibility to indicate that a UA is able to maintain registrations, but still want to receive push notifications for incoming calls, was added later.

---

>>> The second is maintaining the timing for refreshing subscriptions.  
>>> This is questionable.  Isn't there already a way of a proxy/registrar 
>>> signaling its knowledge of NAT binding timers?  The odd part is that 
>>> this is relative to the end of the subscription, requiring calculations from both parties.
>>> If the intent is to ensure that NAT bindings don't time out, I think that
>>> you want a separate parameter that indicates how often the registration 
>>> needs to be refreshed - if there isn't one already.
>>
>> The SIP REGISTER request/response contains a parameter that indicates 
>> when the registration expires.
>>
>> The purpose of sip.pnsreq is to indicate how long, prior the 
>> expiration, the UA will have to send the re-registratation request.
>
> I understand that this is how you have defined it. I just don't think that it makes a lot of sense when framed that way.

The purpose is that, if the UA has indicated that it is able to maintain the registration, but for whatever reason does not send a re-registration, the proxy can still trigger a push notification prior to registration expiration.

Do you want to remove that feature, and assume that UAs that have indicated that they are able to maintain the registration will actually do it (and, if they don't, the registration will expire)?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 May 2018 10:13:31 +1000

On Sat, May 19, 2018 at 4:35 PM Christer Holmberg <
[email-masked]> wrote:
> I suggest to remove the second paragraph, talking about maintaining
connections with keep-alives. Will that make things more clear?

Maybe I should state this differently.  You have an ample problem
statement, but what you don't have is a *solution* statement.  That is, an
explanation of the model you are using to address that problem.

> The primary mechanism is to wake up suspended UAs, in order to maintain
registrations and provide reachability. That was the original use-case that
triggered the whole document.

> The possibility to indicate that a UA is able to maintain registrations,
but still want to receive push notifications for incoming calls, was added
later.

How the document got to where it is doesn't matter so much as where it is
now.

> The purpose is that, if the UA has indicated that it is able to maintain
the registration, but for whatever reason does not send a re-registration,
the proxy can still trigger a push notification prior to registration
expiration.

Yes, that is clear.

> Do you want to remove that feature, and assume that UAs that have
indicated that they are able to maintain the registration will actually do
it (and, if they don't, the registration will expire)?

I'm suggesting that - when framed as a mechanism to ensure continuous
reachability, it is better to make the time relative to the time of
registration rather than relative to the end of registration.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 May 2018 07:01:42 +0000

Hi,

> Maybe I should state this differently.  You have an ample problem statement, but what you don't 
> have is a *solution* statement.  That is, an explanation of the model you are using to address that problem.

Doesn't the 4th paragraph of the Introduction address that?

>>>> The primary mechanism in this document is an augmentation of UA
>>>> contact details. If you think of it that way, the lack of reachability is the
>>>> exceptional condition.
>>> The primary mechanism is to wake up suspended UAs, in order to 
>>> maintain registrations and provide reachability. That was the original use-case that 
>> but still want to receive push notifications for incoming calls, was added later.
>
> How the document got to where it is doesn't matter so much as where it is now.

In my opinion it is still the main use-case, and I think we shall keep it that way: the default is that the UA can not awake , and any exception can then be explicitly signalled. 

>> The purpose is that, if the UA has indicated that it is able to maintain the registration, but for whatever reason 
>> does not send a re-registration, the proxy can still trigger a push notification prior to registration expiration.
>
> Yes, that is clear.
>
>> Do you want to remove that feature, and assume that UAs that have indicated that they are able to maintain the 
>> registration will actually do it (and, if they don't, the registration will expire)?
>
> I'm suggesting that - when framed as a mechanism to ensure continuous reachability, it is better to make the 
> time relative to the time of registration rather than relative to the end of registration.

So, what do you suggest? 

Regards,

Christer