Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the DISCUSS issue

[Christer Holmberg <[e-mail]>]

Hi,

Can you draft an e-mail to the list with all the issues you think need to be discussed there?

I am fine to discuss Adam’s issue, but I am not sure which of Ekr’s issues you are thinking of. Are you referring to his comment on re-writing the text?

Regards,

Christer


From: Ben Campbell <[e-mail]>
Sent: Wednesday, January 09, 2019 9:53 PM
To: Christer Holmberg <[e-mail]>
Cc: Adam Roach <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Brian Rosen <[e-mail]>
Subject: Re: Adam Roach's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the DISCUSS issue

Hi Christer, Adam, and SIPCORE chairsl:

I think this point needs to go back to the work group for discussion. There may well be some edge conditions we have not thought through, and it’s probably not wise to try to do that in the context of a telechat ballot discussion. Further, I think this may be true for some of Adam’s other DISCUSS points as well as some of Ekr’s points.

Thanks,

Ben.



On Jan 9, 2019, at 8:42 AM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:

Hi Adam,

Thank You for the review! In this reply I will address the DISCUSS issue. Please see inline.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

>Thanks to everyone who is put work into defining this mechanism. I think it will
>be very useful to have a solution for integrating push mechanisms into SIP
>networks. I've identified three issues that I think need to be addressed in the
>current document before it can move forward, and a fourth serious flaw that I
>call out in my comments below.
>
>---------------------------------------------------------------------------
>
>It's nice that this document has considered the impact of inbound mid-dialog
>messages in long-lived dialogs. However, it appears to have a major hole in it:
>handing of outbound messages for the purpose of maintaining soft-state in those
>dialogs isn't handled correctly.
>
>In particular: networks that deploy this mechanism will cause SUBSCRIBE
>dialogs to time out and be destroyed while they are still in use.
>Additionally, if RFC 4028 (session timers) is negotiated, then INVITE dialogs
>will suffer the same fate.
>
>I can think of a couple of ways for these situations to be handled, but they
>need explicit text in the document.
>
>One approach would be to specify that the User Agent selects its requested
>"Expires" value in its registration to be the smallest value before its set of
>subscriptions and session timers needs to be refreshed. This would cause a push
>notification to happen to prevent registration timeout, and the client could
>refresh the other soft state at that time. Complications arise if the registrar
>responds with a 483 (Interval too Brief), and we'd need to find a solution for
>that.
>
>Another approach would be for the clients to refresh all soft state whenever
>they send a registration, and set the timeout for that soft state to be equal to
>or greater than the registration timeout. A complication could arise if the
>notifier or the peer in an invite dialog shortens the requested time, and we'd
>need to find a solution for that.
>
>A third approach would be getting the proxy involved in some way -- either by
>requiring it to observe subscription and session timer timeouts and requiring it
>to send push notifications prior to their expiration, or by an explicit
>communication between the UA and the proxy that indicates when the next push
>notification should be scheduled. If the latter approach is taken, I would
>suggest that it needs to be taken for REGISTER messages as well.
>
>I really don't think this mechanism is feasibly deployable without a solution to
>this problem.
Based on what I’ve heard, the first approach (using the registration expiration timer also for soft states) would work with subscription refreshes. When the subscription dialog is crated, if the notifier reduces the refresh value, the UA can always send a new REGISTER with that reduced value.
Regarding session timers, as they are only used within INVITE initiated dialogs, the assumption has been that the UA is awake during those sessions, and I am not aware of any case where that would not apply. But, of course, nothing prevent from using the first approach also for session timers.
So, my suggestion would be to go for the first approach. At least from what I’ve heard, that would work for current use-cases.
Then, once we get more deployment experience, if we realize it doesn’t work we can always define new pn- parameters to explicitly negotiate push frequencies for different soft states etc. But I wouldn’t want to do it in this draft.
Regards,
Christer