Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Feb 2018 19:26:09 +0000

Hi Roman,

>> That said I think it can be allowable for the proxy or registrar to use the pn-provider parameter to 
>> decide whether or not to prompt re-registrations for a particular UA. Practically the pn-provider 
>> will often map to a certain class of UAs allowing the network operator to provide this function 
>> where required and optimize it out where it's not. This also avoids the need for extra flows or 
>> parameters. I read section 5.2 as allowing this already but it could be worth an extra sentence to clarify.
>
> I have suggested in another thread that proxy should return minimum interval after which it expects to
> trigger a push notification for registration (something like pn-refresh SIP URL parameter in Contact registration
> response). Based on this SIP UA can try to schedule the re-registration. If SIP UA successfully re-register before 
> proxy triggers push notification, then push notification will be avoided. If UA does not re-register either due to 
> mobile OS limitations or OS scheduling failure, proxy will trigger the push notification to wake the client and trigger
> the re-registration.

I have added text to the pull request which covers the UA-using-timer-to-re-register case. The text says:

          "NOTE: If the proxy does not request a push notification towards the UA, but still receives a re-registration
          REGISTER request, it means that the UA has awaken using some non-push mechanism (e.g., using a timer). If the
          REGISTER request updates the registration expiration value, the proxy does not need to request a push notification
          until the next time the registration is about to expire (in which case it might again receive a REGISTER request
          before requesting the push notification ). This allows the UA to use timers for sending re-registration REGISTER 
          requests, but to use push notification to awaken the UA when a SIP request addressed towards the UA arrives (in 
          which case the proxy will request a push notification using the procedures in <xref target="section.proxy.req.oth">."

So, there is no need for new parameters etc. The proxy simply follows  when the registration expiration is about to expire.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 14 Feb 2018 22:25:59 -0500

>>> That said I think it can be allowable for the proxy or registrar to
>>> use the pn-provider parameter to decide whether or not to prompt
>>> re-registrations for a particular UA. Practically the pn-provider
>>> will often map to a certain class of UAs allowing the network
>>> operator to provide this function where required and optimize it out
>>> where it's not. This also avoids the need for extra flows or

I would argue strongly against this.  "the pn-provider will often map to
a certain class of UAs" is precisely the sort of lock-in that we want to
avoid -- building into the *networks* presumptions about which UAs can
use which features.

>> I have suggested in another thread that proxy should return minimum
>> interval after which it expects to trigger a push notification for
>> registration (something like pn-refresh SIP URL parameter in Contact
>> registration response). Based on this SIP UA can try to schedule the
>> re-registration. If SIP UA successfully re-register before proxy
>> triggers push notification, then push notification will be
>> avoided. If UA does not re-register either due to mobile OS
>> limitations or OS scheduling failure, proxy will trigger the push
>> notification to wake the client and trigger the re-registration.

Perhaps also a parameter which is the UAs request for how long before
registration expriation it will need a wake-up in order to ensure that
it can re-register.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Wed, 14 Feb 2018 22:31:25 -0500

> registration expriation it will need a wake-up in order to ensure that

I have been asking for the same thing in my comments, but it still was not
added.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Feb 2018 06:55:05 +0000

Hi,

Or, we could change the text:

"It is RECOMMENDED that the proxy requests the push notification at least 10 seconds before the registration expires."

to:

“The proxy SHOULD NOT request a push notification earlier than 10 seconds before the registration expires, in case the UA is able to awake using a non-push mechanism in order to send a re-registration REGISTER.”

That means the UA can send it’s re-registration REGISTER whenever it wants, as long as it does it earlier than 10 seconds before the registration expires. We could make the number a little larger, though, e.g., 60 seconds.

But, if people want a way for the proxy to explicitly indicate the min value to the UA, we can for sure add e.g., a feature-capability indicator for that.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Thursday 15 February 2018 at 05:31
To: Dale Worley <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Mickey Arnold <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests

On Wed, Feb 14, 2018 at 10:25 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps also a parameter which is the UAs request for how long before
registration expriation it will need a wake-up in order to ensure that
it can re-register.

I have been asking for the same thing in my comments, but it still was not added.
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 15 Feb 2018 21:09:52 -0500

Christer Holmberg <[email-masked]> writes:
> That means the UA can send it's re-registration REGISTER whenever it
> wants, as long as it does it earlier than 10 seconds before the
> registration expires. We could make the number a little larger,
> though, e.g., 60 seconds.

Clearly, we need input from people who are directly involved in the
engineering of these systems to learn a good default value.

> But, if people want a way for the proxy to explicitly indicate the min
> value to the UA, we can for sure add e.g., a feature-capability
> indicator for that.

I would expect it to be one of the pn-* parameters.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Feb 2018 06:35:01 +0000

Hi,

> Clearly, we need input from people who are directly involved in the engineering of these systems to learn a good default value.

What I meant was that people will know what values to use when they deploy their networks.

> I would expect it to be one of the pn-* parameters.

If the UA decides what the value shall be, then we could use a pn- parameter. But, the proxy should not modify the pn- parameters, as it would mess up the URI matching.

Regards,

Christer