Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-01.txt

From: [email-masked]
Date: Tue, 19 Dec 2017 01:07:11 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core WG of the IETF.

        Title           : Push Notification with the Session Initiation Protocol (SIP)
        Author          : Christer Holmberg
	Filename        : draft-ietf-sipcore-sip-push-01.txt
	Pages           : 13
	Date            : 2017-12-19

Abstract:
   This document describes how push notification mechanisms can be used
   to wake up suspended Session Initiation Protocol (SIP) User Agents
   (UAs), in order to be able to receive and generate SIP requests.  The
   document defines new SIP URI parameters, that can be used in a SIP
   REGISTER request to provide push notification information from the
   SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in
   this document) that will send a push request to the push server in
   order to trigger a push notification towards the SIP UA.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-01
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Dec 2017 11:21:26 -0500

Hi Christer,

A few comments on this version:

Section 5.3 says:

    If the proxy is aware of another proxy that
    supports the PNS provider, the proxy MAY redirect the SIP request
    (using a SIP 3xx response code) to that proxy.

I think this needs to be more specific. I guess you have in mind to use 
305 (Use Proxy), since no other response seems suitable. Unfortunately 
AFAIK the details of how to use 305 have never been specified. In 
particular, suppose you sent the prior request with a Route header 
containing one or more URIs. How should the Contact URI in the 305 
influence how the request is updated? Does that URI replace all the URIs 
in the Route, does it replace the first or the last, or does it get 
added to the front or the back of the list in the Route?

I'm not suggesting that the this document fix that. Instead, if the 
proxy knows of another proxy that can support the PNS provider, why not 
simply forward the request to it?

I also have a question about the mechanics of this. There could be 
multiple proxies in the path to the registrar. Potentially more than one 
of them might support this feature. If a proxy returns 555 it is in 
effect saying that it knows that neither it, nor any proxy further along 
the route to the registrar, supports this PNS. I think the implications 
of that should be discussed.

Later in the section is the following:

    If the SIP proxy is able to assume that the SIP UA is awake, and that
    the UA is able to receive the SIP request, the proxy MAY choose to
    not trigger a push notification request before trying to forward the
    SIP request towards the UA.  The proxy can make such assumption e.g.,
    if a TLS connection previously established by the UA is still open.

Is this a valid assumption? The timeout for a TCP/TLS connection is 
quite long. Unless the UA overtly tears it down before sleeping then it 
might still be up even though the device is sleeping.

Also a nit in this section: s/receival/receipt/

	Thanks,
	Paul

On 12/19/17 4:07 AM, [email-masked] wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Dec 2017 19:22:43 +0000

Hi Paul,

> 305 (Use Proxy), since no other response seems suitable. Unfortunately AFAIK the details of how to use 305 have never been specified. 
> In particular, suppose you sent the > prior request with a Route header containing one or more URIs. How should the Contact URI in the
> 305 influence how the request is updated? Does that URI replace all the URIs in the Route, does it replace the first or the last, or does it
> get added to the front or the back of the list in the Route?
>
> I'm not suggesting that the this document fix that. Instead, if the proxy knows of another proxy that can support the PNS provider, 
> why not simply forward the request to it?

Works for me.

We can fix 305 once we're done with the session-timer fix :)

> I also have a question about the mechanics of this. There could be multiple proxies in the path to the registrar. 
> Potentially more than one of them might support this feature. If a proxy returns 555 it is in effect saying that it 
> knows that neither it, nor any proxy further along the route to the registrar, supports this PNS. I think the implications 

The draft could allow forwarding the request, based on configuration. People deploying this can then do what works best for them.

> Is this a valid assumption? The timeout for a TCP/TLS connection is quite long. Unless the UA overtly tears it down
> before sleeping then it might still be up even though the device is sleeping.

Sure, the text about TCP/TLS was just to give an example where the proxy might try to forward the request before triggering the push notification. 

But, I can either remove it, or add text clarifying that a TLS connection does not guarantee that the request will reach the UA.

> Also a nit in this section: s/receival/receipt/

Will be fixed in the next version.

Thanks!

Regards,

Christer

On 12/19/17 4:07 AM, [email-masked] wrote:
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Dec 2017 11:14:17 +0000

Hi,

I updated the feature-tag pull request based on Paul¹s comments:

https://github.com/cdh4u/draft-sip-push/pull/5

I intend to submit a new version of the draft at the end of the week, so
please take a look.

Regards,

Christer

On 19/12/17 21:22, "sipcore on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>>AFAIK the details of how to use 305 have never been specified.
>> In particular, suppose you sent the > prior request with a Route header
>>containing one or more URIs. How should the Contact URI in the
>> 305 influence how the request is updated? Does that URI replace all the
>>URIs in the Route, does it replace the first or the last, or does it
>>proxy knows of another proxy that can support the PNS provider,
>>multiple proxies in the path to the registrar.
>> Potentially more than one of them might support this feature. If a
>>proxy returns 555 it is in effect saying that it
>> knows that neither it, nor any proxy further along the route to the
>>registrar, supports this PNS. I think the implications
>The draft could allow forwarding the request, based on configuration.
>People deploying this can then do what works best for them.
>
>>quite long. Unless the UA overtly tears it down
>Sure, the text about TCP/TLS was just to give an example where the proxy
>might try to forward the request before triggering the push notification.
>
>But, I can either remove it, or add text clarifying that a TLS connection
>does not guarantee that the request will reach the UA.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Dec 2017 10:32:00 -0500

> https://github.com/cdh4u/draft-sip-push/pull/5

Looks good.