Re: [sipcore] sip-push Discussion Points - Adam's issue on proxies knowing what downstream proxies support

[Christer Holmberg <[e-mail]>]

Hi,

    >>>> I have already created threads for a couple of the issues listed by Ben.
    >>>> I will create separate threads for the other ones. This one covers 
    >>>> Adam's issue regarding proxies knowing what downstream proxies support.
    >>>> 
    >>>> -What is it about?
    >>>> 
    >>>> The text allows a proxy to forward a REGISTER request to another proxy, 
    >>>> if it "knows" that is supports a PNS supported by the UA.
    >>>> 
    >>>> Adam asked how a proxy would know.
    >>>> 
    >>>> -What do I think?
    >>>> 
    >>> > The knowledge is done by operator configuration, but I agree that is not
    >>> > clear in the text.
    >>> >
    >>> > -What do I suggest?
    >>> >
    >>> > Add text clarifying that the knowledge is based on operator configuration.
    >>>
    >>>Features that require configuration are burdensome and prone to error. A
    >>>mechanism that doesn't require it is preferred.
    >>>
    >>>Without going into detail, ISTM that a mechanism can be devised that
    >>>doesn't require this knowledge. But this first requires deciding who
    >>>should choose when multiple PNSs are supported by both client and 
    >>>proxies/registrar.
    >>>
    >>>One possibility is to use one round trip to discover what PNSs are 
    >>>supported by proxies on the path. Then the client can choose one, 
    >>>initialize just *that* PNS, and then another round trip to enable that 
    >>>choice.
    >> 
    >> This is basically how it already works. Note that the suggested change 
    >> applies to "query mode", where the UA does *not*  provide a PRID, so no 
    >> PNS will be "enabled".
    >
    > Ah! I didn't catch that point.
    >
    >> Then, when the UA wants to enable a PNS, it sends a *single* PRID, 
    >> associated with the PNS it wants to use - as currently specified.
    >
    > OK, that seems reasonable.
    >
    >> Now, I have no problem with allowing multiple proxies to indicate 
    >> support of one or more PNSs (or a single proxy indicating support of 
    >> multiple PNSs) in query mode, if people think that would be useful. That 
    >> would mean adding one Feature-Caps header field per supported PNS.
    >> 
    >> So, in query mode, a REGISTER 2xx response could look something like:
    >> 
    >> Feature-Caps: +apns
    >> Feature-Caps: +fcm
    >> Feature-Caps: +webpush, vapid
    >
    > And then the UA gets to choose. Sounds good.
    >
    >> However, I still want to allow a proxy to send 555, if it "knows" that 
    >> no downstream proxy will support any of the PNSs indicated by the UA. 
    >
    >While I have no problem with this if the proxy truly knows, I'm not 
    >inclined to trust a proxy's judgement on this point. It will be pretty 
    >tempting for implementations to simply *assume* they are the only one 
    >and always send the 555. Do we expect that there will be adequate 
    >motivation for proxies to do this right?

    I don't it will work based on the proxy's judgement - proxies will be configured whether to send 555 or not. We also say that the sending of 555 is based on local configuration.

    >> The reason is to avoid the REGISTER to reach the registrar and cause a 
    >> registration that won't be needed (since there is no common PNS 
    >> supported by the UA and any of the proxies).
    >
    > I understand the desire to optimize here, but it is likely to be an 
    > almost insignificant optimization. It will save *one* registration, but 
    > when using PUSH there will most likely be *many* subsequent 
    > push-triggered registrations. Is it worth the bother and complexity?

    It is not about the number of registration messages, but the fact that in some networks each registration consumes resources. And, if no proxy supports the UA PNS, there is no reason to create a registration for that UA, since it anyway won't be able to receive incoming calls.

   And, this is not new text - the option to either forward the request or send 555 has been there all the time.

    Regards,

    Christer