Subject: [sipcore] SIP Push: PNS-specific SIP response code?

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Dec 2017 07:57:21 +0000

Hi,

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.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Dec 2017 06:34:54 -0500

Christer Holmberg <[email-masked]> writes:
> 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.

I took a quick look at the draft, and I might have missed it, but how
does the UA verify that the registrar (the UAS receiving its REGISTER
request) supports the push notifications that it expects?  Or rather,
how does it register so that the response tells it whether this
proxy/registrar implements push in one or another way vs. whether it's
an ordinary proxy registrar?  These upward-compatibility procedures need
to be laid out carefully.

Also, as a general design question, it seems to me that these pn-
parameters would do better as header parameters than URI parameters.
E.g.:

     REGISTER sip:[email-masked] SIP/2.0
     ...
     Contact: <sip:[email-masked]>;
       pn-type=acme:acme-param;
       pn-prid="ZTY4ZDJlMzODE1NmUgKi0K"

Because the pn- parameters are more *properties of* the contact that is
being registered than intrinsic *parts of* the contact.

There's also this oddity in the text:

   When a SIP UA registers to a push service, it will receive a unique
   Push Resource ID (PRID) associated to that registration.  The SIP UA
   will provide the PRID to the SIP network in a SIP REGISTER request.
   A SIP proxy (e.g., the SIP registrar) will store a mapping between
   the registered contact and the PRID.

The first sentence suggests that the PRID is assigned by the registrar
and supplied in the REGISTER response, whereas the second sentence
suggests the PRID is presumably assigned by the UA and supplied in the
REGISTER *request*.  Do you mean "The SIP UA will provide the PRID to
the SIP network in the subsequent SIP REGISTER requests of the same
registration pseudo-dialog."?

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Dec 2017 11:42:08 +0000

Hi Dale,

>to be laid out carefully.

We could use a feature capability tag for that.

>being registered than intrinsic *parts of* the contact.

The reason they are defined as URI parameters is because the SIP registrar
will add them to the SIP INVITE/MESSAGE request using normal registrar
procedures. 

>registration pseudo-dialog."?

The SIP UA registers to the push service using a non-SIP protocol. Perhaps
that could be more clear.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Dec 2017 10:35:28 -0500

> We could use a feature capability tag for that.

IMO the sip options mechanism is appropriate here. The UA would include 
a Require:push in the REGISTER, and the registrar, if it supports push, 
will include Supported:push in the response.

It gets a bit more subtle regarding the particular push mechanism. 
Suppose that the registrar supports the push mechanism for some PNS 
providers but not the requested one. There is a temptation to indicate 
this by returning Unsupported:push. But this would be a distortion. It 
is probably better to find a different way to indicate this. Using some 
error code, and perhaps also a Reason code, is a possibility.

	Thanks,
	Paul

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Dec 2017 19:27:29 +0000

Hi,

>>> proxy/registrar implements push in one or another way vs. whether 
>>> it's an ordinary proxy registrar?  These upward-compatibility 
>>> procedures need to be laid out carefully.
>> 
> IMO the sip options mechanism is appropriate here. The UA would include a Require:push in 
> the REGISTER, and the registrar, if it supports push, will include Supported:push in the response.

The push functionality may not necessarily be supported by the registrar - it may be handled by an intermediary SIP proxy.

>Suppose that the registrar supports the push mechanism for some PNS providers but not the requested one. There is a temptation to indicate this by returning >Unsupported:push. But this would be a distortion. It is probably better to find a different way to indicate this. Using some error code, and perhaps also a Reason code, is a >possibility.

I think a new error code would be justified for this.

Regards,

Christer

>> Because the pn- parameters are more *properties of* the contact that 
>> is being registered than intrinsic *parts of* the contact.
> 
> The reason they are defined as URI parameters is because the SIP 
> registrar will add them to the SIP INVITE/MESSAGE request using normal 
> registrar procedures.
> 
>> The first sentence suggests that the PRID is assigned by the 
>> registrar and supplied in the REGISTER response, whereas the second 
>> sentence suggests the PRID is presumably assigned by the UA and 
>> supplied in the REGISTER *request*.  Do you mean "The SIP UA will 
>> provide the PRID to the SIP network in the subsequent SIP REGISTER 
>> requests of the same registration pseudo-dialog."?
> 
> The SIP UA registers to the push service using a non-SIP protocol. 
> Perhaps that could be more clear.
> 
> Regards,
> 
> Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Dec 2017 16:54:39 -0500

> The push functionality may not necessarily be supported by the registrar - it may be handled by an intermediary SIP proxy.

Hmm. In that case piggybacking everything on the REGISTER at least seems 
a bit sleazy. In that case it might be better for the proxy to use a 
feature-capability-indicator to supply the URI where the UA can register 
for the push service.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Dec 2017 07:38:49 +0000

Hi,

>> The push functionality may not necessarily be supported by the
>>registrar - it may be handled by an intermediary SIP proxy.
>

The idea is that the proxy itself could send the error response.

Also, I don¹t think we need a URI. The URI, and other credentials, is
normally part of the device iOS, and at least in the case of iOS and
Android you can¹t register with any other push service.

Regards,

Christer

>>>this by returning >Unsupported:push. But this would be a distortion. It
>>>error code, and perhaps also a Reason code, is a >possibility.
>>