Subject: [sipcore] WGLC: draft-ietf-sipcore-sip-push

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 25 Jan 2018 14:35:21 -0600

Hi all,

Working Group Last Call starts today for draft-ietf-sipcore-sip-push.

https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/

Please provide any feedback to the sipcore mailing list by Friday, 
February 9th.

Thanks!

Jean

---

From: Roman Shpount <[email-masked]>
Date: Wed, 31 Jan 2018 10:18:09 -0500

Hi All,

I have reviewed this document. I have following comments:

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.

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.

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.

Regards,

_____________
Roman Shpount

On Thu, Jan 25, 2018 at 3:35 PM, A. Jean Mahoney <[email-masked]>
wrote:

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

---

From: Mickey Arnold <[email-masked]>
Date: Wed, 31 Jan 2018 16:55:55 +0000

Hi Christer,

I've a few comments, the first of which I believe requires a change to the draft.

-- Major comment --
Section 1:
   The proxy can use the
   receipt of the REGISTER request as a trigger to forward SIP request
   towards the UA, using normal SIP routing procedures.

Section  4:
   If the SIP proxy triggered
   the push notification because it wants to forward a SIP request
   towards the UA, the receipt of the REGISTER request can be used by
   the proxy as a trigger to forward the request.

Section 5.3:
   As the push notification will trigger the SIP UA to perform a re-
   registration, the SIP proxy can use the receipt of the SIP REGISTER
   request as a trigger to forward SIP request towards the UA.

The SIP proxy should only be allowed to use the received (or generated if the Proxy contains the registrar functionality) 200 OK response to the REGISTER as a trigger to send on the queued message. Otherwise the proxy will be re-routing based on a unconfirmed REGISTER request. If the reregister fails then the proxy has forwarded the INVITE or OOD request on to a contact URI that is not stored in the registrar. This would likely cause the call to fail but also raises security concerns where a well-timed re-register with incorrect SIP authentication by a 3rd party could "steal" a SIP message.

-- Minor comments --
Typo in Section 1. I think
"Some are based on there standardized mechanism..."
Should be
"Some are based on the standardized mechanism..."

Section 1
Consider adding a mention of the feature capabilities indicator.

Section 3
Consider clarifying that PRID need only be unique per PNS. Also consider clarifying that this mechanism is only appropriate for notification systems that provide such a token.

I hope that's useful feedback, please let me know if you have any follow-up questions.

Regards, Mickey

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of A. Jean Mahoney
Sent: 25 January 2018 20:35
To: SIPCORE <[email-masked]>
Subject: [sipcore] WGLC: draft-ietf-sipcore-sip-push

Hi all,

Please provide any feedback to the sipcore mailing list by Friday, February 9th.

Thanks!

Jean

---

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

Hi,

I spotted some minor nuisances:

Section 7.1 - typo

  "555 (Push Notficiation Service Not Supported)"

Section 7.2 - inconsistency (possibly due to an old iteration)

The BNF grammar defines a series of "pn-*" params, yet the last sentence 
references a couple of undefined "pns-*" params:

"The format and semantics of pns-param is specific to a given 
pns-provider value."

Best regards,
Liviu

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Feb 2018 11:28:24 +1100

> Please provide any feedback to the sipcore mailing list by Friday, February

This document should not be published without significant changes.

This document addresses a serious shortcoming.  For a long time, we
have had SIP UAs on mobile devices that are privileged by virtue of
being developed and installed by the device vendor, but the nature of
these platforms makes developing an alternative UA impossible.

But it swaps one type of vendor lock-in for another.  This is a rare
case of a (intended for) proposed standard document enshrining
proprietary protocols into the RFC series.  And only proprietary
protocols.  No definition is added for RFC 8030, despite that having a
well-documented (and deployed) protocol.

The two proprietary protocols (for APNS and FCM) are not documented
here, nor does the document normatively reference specifications for
those protocols.  Given that there are only two registered values for
pn-provider, I don't see how this specification could be implemented
by a proxy without information that is not normatively referenced.

This document should discuss its relationship with RFC 5626 (outbound)
and the existing mechanisms used to keep connections and NAT bindings
between UA and proxy alive.  My expectation is that if the parameters
were supported connections would be allowed to drop and the push
notification channel would be preferred.

I don't understand why the terminology established in RFC 8030 wasn't
used.  It's well-defined and clear.

The discussion about what is sent in the push notification message
isn't actionable.  It says that the payload is undefined.  I think
that is unwise.  Either say that the payload is empty (which is
possible) or it isn't.  That raises the question of whether you care
about authentication of the message.

I don't think that it is as simple as saying that authentication isn't
important - you need to explain why.  RFC 8030 talks about the
measures that it puts in place to ensure that user agents don't
receive unwanted push messages, but now you have a whole spectrum of
potential proprietary protocols and systems that could be used here,
with unknown properties.

Section 12.4 doesn't define the registration policy for the new registry.