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

From: [email-masked] (Dale R. Worley)
Date: Thu, 08 Mar 2018 22:14:07 -0500

I wrote a long message, trying to work out which components of the SIP
system know which elements of the entire reregistration delay when a UA
using sip-push needs to wake up to reregister.  Unfortunately, given
that the re-REGISTER may easily be rejected with a 401, requiring the UA
to send another REGISTER, the process is messy enough there's no way to
come up with a neat formula that lets the UA register optimally just
before its registration expires.

So I'm abandoning that attempt, and suggesting that we specify that the
system should always allow "enough" time for the UA to reregister.  I
believe that the value of 120 seconds has been recommended, and that
seems sufficient to me.

My assumption is that registrations will be for as long as 1 hour, as in
wired SIP systems.  OTOH, Roman mentions registrations as short as 90
seconds, which makes handling reregistrations more difficult.  I'd like
to hear more about that case.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Mar 2018 22:21:13 -0500

Dale,

All I said that for the sip PUSH to work, a reasonable minimal Registration
duration is required. I wrote that most likely you would not be able to
implement re-registrations triggering using push notifications if
registration expiration is less then 90 seconds.

My suggestion was:

1. If push notifications are used, minimal Registration expiration of 90
seconds (can be longer) is enforced.
2. Push notification is sent either 30 seconds or 1/3 of the registration
expiration interval before registration expiration, whichever is longer
3. If client want's to re-Register on its own, it needs to send
re-registration after 1/2 of the expiration period.

Finally, I know that push notification content is not currently used for
anything, but it would be really beneficial to at least be able to send a
new nonce value, which will allow to avoid 401 and Registration
re-transmission.

Regards,

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Mar 2018 07:31:40 +0000

Hi,

>All I said that for the sip PUSH to work, a reasonable minimal Registration duration is required. I wrote that most likely you would not be able to implement re-registrations triggering using push notifications if registration expiration is less then 90 seconds.
>
>My suggestion was:
>
>1. If push notifications are used, minimal Registration expiration of 90 seconds (can be longer) is enforced.
>2. Push notification is sent either 30 seconds or 1/3 of the registration expiration interval before registration expiration, whichever is longer
>3. If client want's to re-Register on its own, it needs to send re-registration after 1/2 of the expiration period.
>
>Finally, I know that push notification content is not currently used for anything, but it would be really beneficial to at least be able to send a new nonce value, which will allow to avoid 401 and Registration re-transmission.

We decided early that we are not going to send “SIP information” in the push notifications. I would NOT like to change that at this point. Also, I have received off-line questions regarding sending other kind of SIP information in push notifications too, so we could easily open a Pandora’s box.

Having said that, if someone thinks that using push notifications for transporting SIP information he/she can write a draft about that, which considers the type of information, the encoding, the privacy/security considerations etc etc.

Regards,

Christer

On Thu, Mar 8, 2018 at 10:14 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 14 Mar 2018 22:18:40 -0400

> re-registration after 1/2 of the expiration period.

OK, that makes sense to me.

> new nonce value, which will allow to avoid 401 and Registration

As Christer says, it's probably best not to include that in this draft,
but describe it as an extension to make systems more efficient.

Dale