Subject: [sipcore] Comments regarding sip-push registration

From: [email-masked] (Dale R. Worley)
Date: Thu, 21 Dec 2017 06:49:09 -0500

* Design questions

- Reregistration

The discussion touches on the topic of registration maintenance
without discussing it thoroughly.  My expectation is that once a UA
obtains a registration, it will set itself a wakeup call for whatever
time it wants to perform a re-registration.  (For UAs I've worked on,
this was 1/3 of the registration time minus epsilon, so as to protect
against network instability.)

It seems that the draft envisions situations where the UA *can't* set
a wakeup call for a future time, and thus the proxy must wake it up
using the push notification service.  However, the mechanism to
control this isn't made clear -- What sets the time interval for the
wakeup?  And surely we don't need to have this be a mandatory feature
of all push-notification registrations.

- Put the responsibility on the Registrar

Formally, this mechanism should be described as behaviors of the
registrar and its dependent redirector for AORs, that is, the UAS of
the REGISTER requests.  Some of the work may be delegated to
intermediate proxies, but that is an implementation detail that isn't
visible to the UA.

Interestingly, if the proxy is willing to manipulate the registered
contact URIs (details upon request), it can implement
push-notification without modification of the register.  (See
Christer's comments and the next comment here.)

OTOH, the registrar/redirector can implement the push-notification
operations in an environment where the proxies are unaware of
push-notification.  (Details upon request.)

- Header field parameters

Really, the use of URI parameters for controlling push-notification
registration is a Bad Idea from the design point of view.  Header
parameters should be used.  (Note that ":" must be quoted in header
parameters.)

If you want to use a registrar that can't add another column to its
registrations table, the proxy should manipulate the REGISTER before
forwarding it to the registrar to stash the push-notification
information in the contact URI.  But we should design the message flow
between the UA and the proxy to be as clean as we can, and allow
implementors to devise clever ways to support that message flow.

- Examples

The examples are thin, and no responses to REGISTER messages are
shown.  For this example

     REGISTER sip:[email-masked] SIP/2.0
     Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
     Max-Forwards: 70
     To: Alice <sip:[email-masked]>
     From: Alice <sip:[email-masked]>;tag=456248
     Call-ID: 843817637684230@998sdasdh09
     CSeq: 1826 REGISTER
     Contact: sip:[email-masked];
       pn-type="acme:acme-param";
       pn-prid="ZTY4ZDJlMzODE1NmUgKi0K"
     Expires: 7200
     Content-Length: 0

the response would be

     SIP/2.0 200 OK
     Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
     To: Alice <sip:[email-masked]>;tag=eksofdk
     From: Alice <sip:[email-masked]>;tag=456248
     Call-ID: 843817637684230@998sdasdh09
     CSeq: 1826 REGISTER
     Contact: sip:[email-masked];
       pn-type="acme:acme-param"
     Expires: 7200
     Content-Length: 0

In addition, the presence of the pn-type header parameter in the
response is needed to show that the proxy understands
push-notification and can implement registrations using the
acme:acme-param service.  Otherwise, there's no way for the UA to
verify that the proxy understood its need for push-notification.

- Negotiation

Note that the document assumes that the UA knows which push service is
needed for registering with the proxy.  This means that the mechanism
works only if the push-notification configuration of the UA and the
proxy is made to match in advance.  Requiring configuration rather
than implementing negotiation makes systems less likely to work.

Let us define that if the pn-type is a *list* of values, then it is a
request for the proxy to tell which service it supports/prefers from
the list.  E.g.,

     REGISTER sip:[email-masked] SIP/2.0
     Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
     Max-Forwards: 70
     To: Alice <sip:[email-masked]>
     From: Alice <sip:[email-masked]>;tag=456248
     Call-ID: 843817637684230@998sdasdh09
     CSeq: 1826 REGISTER
     Contact: sip:[email-masked];
       pn-type="acme:acme-param/acme:other/-"
     Expires: 7200
     Content-Length: 0

This is a request to the proxy to identify which push service it
implements/prefers given that the UA prefers services in this order:
acme:acme-param, acme:other, and no push service (identified by "-").
The server can respond

     SIP/2.0 200 OK
     Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
     To: Alice <sip:[email-masked]>;tag=eksofdk
     From: Alice <sip:[email-masked]>;tag=456248
     Call-ID: 843817637684230@998sdasdh09
     CSeq: 1826 REGISTER
     Contact: <sip:[email-masked]>;
       pn-type="acme:acme-param";
       expires=0
     Expires: 7200
     Content-Length: 0

Since the server chose acme:acme-param, and that requires a pn-prid
value to implement, the server sent "expires=0" with the Contact.  But
the UA can then send the first REGISTER example above to obtain a
registration, now that it knows what push service to register with.

It seems that a use of this mechanism requires that expires is 0 --
since the UAC doesn't know which notification service the UAS will
choose, it can't send the correct pn-prid, and so a push registration
can't be created.

This requires defining a separator character that cannot appear in a
pn-type value.  Which leads to:

- Quoting

Be careful to define the procedures based on the *values* of parameter
fields, that is, the values after any quoting is removed.  E.g., the
effect of header parameters 'foo=bar', 'foo="bar"', and 'foo="b\ar"
should be exactly the same, the (semantic) value of the parameter is
the same regardless of how that value is represented.  If we don't
follow this rule, then it is impossible to define a generic parser for
SIP headers that reduces parameters to sets of name/value pairs.

- Require and option-tag

It would probably also be helpful to define an option-tag for this
feature, so that the UA can require the registrar to reject its
REGISTER in a way that is definitive that the registrar doesn't
support push registrations.  Perhaps use "pn" as the option-tag.

* Editorial things

The capitalization of the section titles is inconsistent.

   When the SIP proxy receives a SIP request for a new session, or a

s/session/dialog/

   the SIP proxy will send a push request to the push notification
   service used by the SIP UA, using the push resource ID associated
   with the registered contact of the SIP UA, in order to trigger a push
   notification towards the SIP UA.  The SIP proxy will then forward the
   SIP request towards the SIP UA using normal SIP routing procedures.
   Once the SIP UA receives the push notification, it will be to receive
   the SIP request, and to generate a SIP request (e.g., a SIP REGISTER)
   itself.

This description is incomplete, as it leaves out the step between the
first and second sentences, "the proxy waits to receive a
re-registration from the UA".  The other descriptions of the process
for sending requests to the UA need to be checked for this as well.

The abbreviation "pn-prid" is redundant, as it means "push
notification - push registration id".  Perhaps reduce it to "pn-rid"
or "pn-id".

   The format of the PRID may vary depending on the PNS provider.  The
   PRID may be part of a URI that can be used to retrieve the address
   and port of the PNS when sending push requests to the PNS.  The PRID
   may also be a token value, in which case the address and port of the
   PNS needs to be provided using other means.

It's not clear what "may be part of a URI" means, since just about any
string could be part of a URI.  In any case, the format of the PRID is
outside the scope of this document; from our point of view, it's an
opaque string.  The only real restriction is that it's a sequence of
Unicode characters and can be represented as a quoted-string (RFC 3261
section 25.1).

   If the SIP UA at some point wants to stop the SIP proxy from sending
   push requests, the SIP UA MUST send a SIP REGISTER request without
   the pn-prid and pn-type URI parameters.

It should be added, "or remove the registration".

   If the SIP UA expects to receive payload in the push notification,
   the SIP UA MAY add a pn-enckey and a pn-encsec Contact header field
   URI parameter, in order to allow encryption of the data using the
   mechanism in [I-D.ietf-webpush-encryption].  The pn-enckey URI
   parameter contains the public key, and the pn-encsec URI parameter
   contains the authentication secret [I-D.ietf-webpush-encryption].

Need to mention that the format and use of such a payload is outside
the scope of this document; all we're doing here is defining the
parameters that make such payloads possible.

   In some cases the push notification provider can be retrieved from
   the pn-prid URI parameter.  In other cases the pn-type URI parameter
   is used to identity the push notification provider.

Exactly how you retrieve Apple Corp. from the parameters is unclear; I
know of no media-type for Apple Corp.

I think you mean, "Together, the pn-prid and pn-type parameters
suffice to identify which push notification provider is to be used and
how to direct it to notify the UA."

   If the proxy is not able to contact the push notification provider,
   or even determine which push notification provider to contact, it
   SHOULD reject the SIP request.

This sentence conflates two situations that should be handled
differently.  If the redirector is unable to contact the push
notification provider, it must necessarily reject the request.  (Do we
need to define a 4xx code to indicate that?)  If the redirector is
unable to determine the push notification provider, it is able to
detect that during registration, and the REGISTER should have been
rejected.

    It is currently suggested (see pull request in other e-mail) that
    a proxy that receives a SIP REGISTER request with pn- parameters
    for a PNS provider it does not support sends a 501 (Not
    Implemented) response code.

    The question is whether it would be useful to define a
    PNS-specific response code for this? E.g., 514 (Push Notification
    Service Not Supported). In addition, we could define a feature
    capability indicator that could be added to the response and list
    the PNS providers supported by the proxy.

And also,

    I have updated the pull request by adding a new SIP response code,
    555 (Push Notification Service Not Supported).

Defining 514/555 like this doesn't really help, because the baseline
incompatibility case is when the registrar/redirector doesn't
understand the push notification mechanism at all, and happily
provides an ordinary registration when the UA wanted a
push-notification registration.  See comments about an option-tag
above.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Dec 2017 12:47:08 +0000

Hi,

>of all push-notification registrations.

The interval will be based on the registration expiration.

And, similar to the UA wakeup behaviour you mention, the push notification
should be triggered prior to the actual registration expiration.

>push-notification.  (Details upon request.)

The mechanism does not have to be part of the registrar. It for sure can
be.

>implementors to devise clever ways to support that message flow.

The usage of URI parameters will make the deployment easier as it does not
mandate updating the registrars (unless the push notification triggering
will be done by the registrar, of course). Also, unlike some of the
proprietary ideas I have seen, it does not mandate intermediaries to
modify the REGISTER and/or the contact, etc.

In some environments ³adding another table² can be a very big task.

As the schedule for deploying this is very tight in many cases, there is a
strong wish from the industry to be able to deploy this without having to
update the registrar.

>verify that the proxy understood its need for push-notification.

In the latest pull request, a feature-capability indicator is defined for
this. The proxy will insert that in the REGISTER 200 OK response, in order
to inform the SIP UA that push-notification is supported.

>SIP headers that reduces parameters to sets of name/value pairs.

It was requested to use separate parameters, to be able to avoid
separators, and to minimise the need to potentially have to escape
characters.

And, in reality, clients will only support one push notification mechanism
(and it will be part of the OS). One of the main reasons for using push to
begin with is having to maintain only a single connection
(the connection between the device and the push notification server), in
order to save battery etc.

Having said that, the feature-capability indicator (defined in the pull
request) can be used to negotiate and query the network, should there be a
need for that.

>support push registrations.  Perhaps use "pn" as the option-tag.

If there push notifications are handled by an intermediary, there is no
need to mandate support in the registrar.

I will look at and address your editorial comments later.

Regards,

Christer

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Dec 2017 09:39:40 -0500

> strong wish from the industry to be able to deploy this without having to

Why does using header field parameters rather than uri parameters impact 
the choice of proxy or registrar to implement this feature? The proxy 
can observe header field parameters, and a registrar will ignore header 
field parameters it doesn't understand.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Dec 2017 15:33:51 +0000

Hi Paul,

Maybe I was unclear and/or I misunderstood your question. I did not mean to say that it would impact the choice.

Using URI parameters in the REGISTER request, they will automatically be copied into the INVITE request using normal SIP registrar procedures. There is no need to update the registrar, or having intermediaries modifying the REGISTER, contact etc.

Using header parameters, you would need to update the SIP registrar to insert them in the INVITE request.

Regards,

Christer

Sent from my iPhone

On 21 Dec 2017, at 16.40, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

Why does using header field parameters rather than uri parameters impact the choice of proxy or registrar to implement this feature? The proxy can observe header field parameters, and a registrar will ignore header field parameters it doesn't understand.

   Thanks,
   Paul

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Dec 2017 14:47:18 -0500

On 12/21/17 10:33 AM, Christer Holmberg wrote:
> Using URI parameters in the REGISTER request, they will automatically be 
> copied into the INVITE request using normal SIP registrar procedures. 
> There is no need to update the registrar, or having intermediaries 
> modifying the REGISTER, contact etc.
> 

Ahh, I missed that.

OK, I acknowledge that this will allow you to get by without modifying 
the registrar.

	Thanks,
	Paul

>> Why does using header field parameters rather than uri parameters 
>> impact the choice of proxy or registrar to implement this feature? The 
>> proxy can observe header field parameters, and a registrar will ignore 
>> header field parameters it doesn't understand.
>>
>>    Thanks,
>>    Paul
>>
>> [email-masked] <mailto:[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Sat, 23 Dec 2017 08:07:06 -0500

> should be triggered prior to the actual registration expiration.

You need to explain this behavior completely.  It seems that the UA is
likely to depend on it, but in order for the UA to do that, it has to
have a clear specification as to how the registrar will perform these
wake-ups, and precisely *when* they will happen.

> In some environments 'adding another table' can be a very big task.
>

OK, but you don't have to muddy the documented wire protocol to support
unmodified registrars, because the proxy can compensate for that.  And
you're already expecting to modify the proxy.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Dec 2017 19:27:00 +0000

Hi,

>> And, similar to the UA wakeup behaviour you mention, the push 
>> notification should be triggered prior to the actual registration expiration.
>
> You need to explain this behavior completely.  It seems that the UA is likely to depend on it, but
> in order for the UA to do that, it has to have a clear specification as to how the registrar will perform 
> these wake-ups, and precisely *when* they will happen.

I don't think we need to mandate how the wake-ups are triggered, because there are different ways of doing that. If the proxy triggering the push notifications is not part of the registrar, there needs to be A way for it to know when to trigger the push notifications.

I can add text pointing out that the push notifications triggering the re-registrations need to be triggered before the registration expires (eventhough a UA sending re-register before registration expiration as such that is normal SIP behavior).

>>> The usage of URI parameters will make the deployment easier as it does 
>>> not mandate updating the registrars (unless the push notification 
>> triggering will be done by the registrar, of course). Also, unlike 
>> some of the proprietary ideas I have seen, it does not mandate 
>> intermediaries to modify the REGISTER and/or the contact, etc.
>>
>> As the schedule for deploying this is very tight in many cases, there 
>> is a strong wish from the industry to be able to deploy this without 
>> having to update the registrar.
>
> OK, but you don't have to muddy the documented wire protocol to support unmodified registrars, because the proxy can 
> compensate for that.  And you're already expecting to modify the proxy.

A proxy processing URI parameters (triggering the push notifications etc) is much less impact than the registrar having to be able to store new header parameters: in 3GPP networks that would most likely impact the HSS, the interface between to the HSS etc - thing would require much more standardization.

In addition to being a standardized solution (in addition to different proprietary solutions people are looking at), the solution has been sold as easy to implement, as it does not impact the registrar, user databases etc. I really hope we can keep it that way.

Regards,

Christer