Subject: [sipcore] SIP Push: Problem with pn-provider carrying multiple values

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jan 2019 15:00:20 +0000

Hi,

I realized that the ABNF for SIP URI parameters don’t allow a list of values, meaning that it is not possible to have a pn-provider parameter with a list of supported PNS.

So, the question is whether we could live with the original restriction, indicating a single value? A UA could always perform multiple queries, each with a different pn-provider value, if it wants.

Note that this does not affect proxies. They use feature-capability indicators to indicate the supported PNSs, so a list of values is ok.

Alternatively, we could define a sip.pns media feature tag, that a UA can use for queries - IF we think multiple values is needed.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jan 2019 14:13:59 -0500

On 1/16/19 10:00 AM, Christer Holmberg wrote:
> Hi,
> 
> I realized that the ABNF for SIP URI parameters don’t allow a list of 
> values, meaning that it is not possible to have a pn-provider parameter 
> with a list of supported PNS.
> 
> So, the question is whether we could live with the original restriction, 
> indicating a single value? A UA could always perform multiple queries, 
> each with a different pn-provider value, if it wants.
> 
> Note that this does not affect proxies. They use feature-capability 
> indicators to indicate the supported PNSs, so a list of values is ok.
> 
> Alternatively, we could define a sip.pns media feature tag, that a UA 
> can use for queries - IF we think multiple values is needed.

I only see query mentioned in section 4.2, and it only discusses the 
UA's behavior, not proxies or the registrar. What is the proxy supposed 
to do with a query? I guess that if it doesn't support the PNS mentioned 
in the query then you would have it respond with a 555 if it knows there 
are no subsequent push proxies. What if it *does* support the PNS, or 
doesn't know if there are more push proxies? In that case, won't the 
registration succeed without push notification being enabled? Did you 
want that to happen?

Perhaps it would be better to support query via OPTIONS. Then the 
request could go all the way to the registrar, passing any push proxies, 
without establishing a registration. Ideally the response would report 
all supported PNSs.

In any case, it would be very helpful to have the document discuss the 
issue of clients that support multiple PNSs and how query is used for this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Jan 2019 22:07:59 +0000

Hi,

>UA's behavior, not proxies or the registrar.

Query is also described for the proxy. But, it is not very clear, so I am going to also place the proxy query procedures into a separate sub-section.

>What is the proxy supposed to do with a query?
>
>I guess that if it doesn't support the PNS mentioned
>are no subsequent push proxies.

Correct.

>What if it *does* support the PNS, or doesn't know if there are more push proxies? In that case,
>won't the registration succeed without push notification being enabled? Did you
>want that to happen?

If it does support the PNS, it will insert a feature-cap to indicate that. In this case it is ok if the registration succeed, as it will be used (sure, the UA will have to send a subsequent REGISTER to actually enable push, but that's ok).

If the REGISTER reaches the registrar without any proxy indicating support for the PNS, then an "unnecessary" registration will be created. That is what I want to avoid - which is the reason I want to allow a proxy to send 555.
But, if it the registration is created, the UA will have to delete it.

>without establishing a registration. Ideally the response would report

I think that in many networks you will have to register before you send OPTIONS.

>issue of clients that support multiple PNSs and how query is used for this.

Yes. But, as I said in my initial e-mail: currently it is not possible for a UA to indicate support for multiple PNSs, and we can't even extend the pn-provider SIP URI parameter in order to enable that.

So, my question was: can we live without the UA being able to indicate support of multiple PNSs?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jan 2019 18:57:55 -0500

On 1/16/19 5:07 PM, Christer Holmberg wrote:

> Yes. But, as I said in my initial e-mail: currently it is not possible 
> for a UA to indicate support for multiple PNSs, and we can't even extend 
> the pn-provider SIP URI parameter in order to enable that.
> 

I understood your point. But a client can still *support* multiple PNSs 
even if it can't *indicate* such support. So I'm asking for the document 
to address this case, and recommend how such a client can discover which 
of the PNSs it supports are supported by the network and enroll with a 
push proxy for one - preferably its preferred one.

Whether we can live without being able to indicate multiple PNSs may 
depend on how ugly it is to live without doing so.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Jan 2019 10:18:49 +0000

Hi,

>    depend on how ugly it is to live without doing so.
  
We could e.g., allow a UA to send an "empty" pn-provider, and the network would then inform the UA about all PNSs that are supported - no matter if the UA supports them or not.

Then the UA can choose one that it supports.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jan 2019 12:44:58 -0500

> Then the UA can choose one that it supports.

WFM.