Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Roman's comments

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Jan 2018 16:37:15 +0000

Hi Roman,

Thanks for your comments! Please see inline.

>1. In https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-04#section-5.3 the document says:
>
>When the SIP proxy receives (or, in case the proxy is the SIP registrar, creates) a SIP request for a new 
>dialog (e.g., a SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE request) aimed for a 
>SIP UA, if the Request-URI of the request contains a pn-provider, a pn-prid and a pn-param (if required for 
>the specific PNS provider) SIP URI parameter, the proxy triggers a push request towards the PNS associated 
>with the PRID.  After that the proxy forwards the SIP request towards the UA using normal SIP procedures.
>
>Does this create a potential race condition? The push notification request can take a substantial time to get 
>delivered, so the NAT binding might still be absent and SIP message will not be delivered to the UA.
>
>Is this supposed to be handled by SIP Message re-transmit timers? In this case call setup will be significantly 
>delayed especially if push service takes more then 0.5 sec to deliver the notification which will cause first two
>SIP re-transmit message to be lost.
>
>Also, what happens when reliable transport protocol is used such as SIPS is used and  no re-transmit timers are there?
>Note that re-registration from the client might come from a new IP:port, especially in cases when new SIPS TCP connection 
>is established for this and SIP message destination address can change from previous registration.
>
>Our solution for the similar problem was to store the message and only transmit it when registration from the client was received.

Correct. And, that is described in the following paragraph :)

The reason for allowing the request to be forwarded before the REGISTER arrives is more an optimization, in case the connection between the UA and proxy is still available from a previous session.

>2. Does this document always require for a SIP Proxy to send regular timer based push messages to keep SIP Registrations 
>active? Such policy will result in additional load and cost for the SIP Service operator. In most cases client application can 
>be woken up on timer and does not need this, so this should be optional and controlled by pn-XXX parameter.

At least in the case of iOS, the application can NOT be woken up by an application timer, as far as I understand. Push (or user interaction) is the only way to wake the application :) 

(There used to be a "VoIP mode" in iOS, but it has been deprecated.)

But, in general, re-registrations are normally not that frequent, so I don't think it will cause too much load.

>3. Does the proxy strip the pn-XXX parameters when forwarding message to the client or are they kept? Does it strip 
>them when comparing contact registration URI? Without this, change in pn-XXX parameters will result in a new registration 
>instead of existing registration update.

There is no stripping of parameters. The pn- parameters will typically not change between UA device reboots. But, if they do, it does require a new registration.

Regards,

Christer

---

From: Liviu Chircu <[email-masked]>
Date: Wed, 31 Jan 2018 18:50:22 +0200

Hi all,

> There is no stripping of parameters. The pn- parameters will typically not change between UA device reboots. But, if they do, it does require a new registration.
Then what happens if a "pn-XXX" enabled INVITE R-URI from UA "a" to UA 
"b" traverses a chain of SIP proxies which are all "sip-push" aware? 
Will they not each perform the following:

     * launch PNS provider query
     * wait for re-REGISTER
     * forward INVITE to the next "sip-push" aware proxy

Thanks,
Liviu
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Jan 2018 17:42:39 +0000

Hi Liviu,

>>> 3. Does the proxy strip the pn-XXX parameters when forwarding message 
>>> to the client or are they kept? Does it strip them when comparing 
>>> contact registration URI? Without this, change in pn-XXX parameters will result in a new registration instead of existing registration update.
> Then what happens if a "pn-XXX" enabled INVITE R-URI from UA "a" to UA "b" traverses a chain of SIP proxies which are all "sip-push" aware? 

The R-URI will only traverse between the UA and its registrar.

My assumption has been that the operator configures the network in a way that there is only one SIP proxy doing the push.

However, if people think we can't make such assumption I guess one option would be that the proxy supporting the push would insert e.g., the sip.pns feature-capability indicator in the REGISTER request, in order to inform downstream proxies that they don't have to do it.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 31 Jan 2018 14:07:13 -0500

Hi Christer,

On Wed, Jan 31, 2018 at 11:37 AM, Christer Holmberg <
[email-masked]> wrote:

> >Our solution for the similar problem was to store the message and only
> transmit it when registration from the client was received.
>
> The reason for allowing the request to be forwarded before the REGISTER
> arrives is more an optimization, in case the connection between the UA and
> proxy is still available from a previous session.
>

OK, this makes sense.

>2. Does this document always require for a SIP Proxy to send regular timer
> based push messages to keep SIP Registrations
> >active? Such policy will result in additional load and cost for the SIP
> Service operator. In most cases client application can
> At least in the case of iOS, the application can NOT be woken up by an
> application timer, as far as I understand. Push (or user interaction) is
> the only way to wake the application :)
>

I think in case of Android you can setup a wake up timer. Depending on the
number of registered users vs number of concurrent calls SIP Registrations
can create quite a significant portion of the load. Having an option not to
trigger the push notification when client can send a new registration would
be useful.

Another way to approach is for the push enabled proxy to specify the
interval after which it intends to refresh the registration. This way SIP
client can send a registration refresh slightly earlier and avoid the push
notification.

> >3. Does the proxy strip the pn-XXX parameters when forwarding message to
> the client or are they kept? Does it strip
> >them when comparing contact registration URI? Without this, change in
> pn-XXX parameters will result in a new registration
> There is no stripping of parameters. The pn- parameters will typically not
> change between UA device reboots. But, if they do, it does require a new
> registration.
>
>
This makes sense. I think sip.instance with reg-id can be used to maintain
the same registration and change the pn-xxx parameters at the same time.

Regards,
______________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Jan 2018 21:27:41 +0000

Hi,

>>The reason for allowing the request to be forwarded before the REGISTER arrives is more an optimization, in case the 
>>connection between the UA and proxy is still available from a previous session.
>
>OK, this makes sense. 

However, Mickey commented that one should wait for the REGISTER response before forwarding the request.

---

>>At least in the case of iOS, the application can NOT be woken up by an application timer, as far as I understand. Push (or user interaction) is the only way to wake the >>application :)
>>
>I think in case of Android you can setup a wake up timer. Depending on the number of registered users vs number of concurrent calls SIP Registrations can create quite a >significant portion of the load. Having an option not to trigger the push notification when client can send a new registration would be useful.
>
>Another way to approach is for the push enabled proxy to specify the interval after which it intends to refresh the registration. This way SIP client can send a registration >refresh slightly earlier and avoid the push notification.
 
Not sure I follow. If the UA can use a timer to wake up, and send periodic re-registrations (or whatever messages) for keeping the connection alive, why does the UA have to use SIP push to begin with?

Regards,

Christer

 
This makes sense. I think sip.instance with reg-id can be used to maintain the same registration and change the pn-xxx parameters at the same time.

Regards,
______________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 31 Jan 2018 16:54:56 -0500

On Wed, Jan 31, 2018 at 4:27 PM, Christer Holmberg <
[email-masked]> wrote:

> arrives is more an optimization, in case the

Agreed. Registration would have to be properly verified and SIP message
should only be sent if 200 OK response is sent to the Registration message.

> >>>2. Does this document always require for a SIP Proxy to send regular
> timer based push messages to keep SIP Registrations
> the only way to wake the >>application :)
> >>
> >I think in case of Android you can setup a wake up timer. Depending on
> the number of registered users vs number of concurrent calls SIP
> Registrations can create quite a >significant portion of the load. Having
> an option not to trigger the push notification when client can send a new
> registration would be useful.
> >
> client can send a registration >refresh slightly earlier and avoid the push
> notification.
>
> Not sure I follow. If the UA can use a timer to wake up, and send periodic
> re-registrations (or whatever messages) for keeping the connection alive,
> why does the UA have to use SIP push to begin with?
>
>
Imagine an Android phone behind NAT. Without Push notification support it
will need to wake up often enough to maintain NAT binding (every 30 sec or
so creating huge load on both the client and the server). With push
notifications it only needs to wake up often enough to maintain
Registration (about once very hour). At the same time, if client can wake
up on its own and send a registration, then push enabled proxy does not
need to generate a push request -- less load on the proxy and fewer things
to break.

In general, I think it would be useful for the client to get some sort of
indication that it should expect a registration refreshing push
notification no sooner then in x seconds. So, in the registration response
client will get indication that registration will expire in y seconds
(expires URI parameter in contact or SIP header) and that push notification
will be send no sooner then in x seconds (x < y). This additional value can
be provided in something like pn-refresh Contact URL parameter. This way
client can prevent the push notification by proactively sending
registration. This value can also be extremely useful for debugging.

Regards,
_____________
Roman Shpount