Re: [dispatch] New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt - SIP OPTIONS?

[Cullen Jennings <[e-mail]>]

> On Sep 23, 2019, at 8:15 AM, Christer Holmberg <christer.holmberg=[e-mail]> wrote:
> 
> Hi Kaustubh,
> 
> Thank You for the reply! Please see inline.
> 
>>>> Constructs in SIP such as NOTIFY and OPTIONS may be used to achieve the end goal - which is to have the SIP service provider offload its set of capabilities.
>>>> However, with I see a couple of challenges with using OPTIONS…
>>>> 
>>>> 1. It is entirely plausible for the SIP service provider to offload 
>>>> different capability set documents to different enterprises or different sites within an enterprise. Accordingly, it would be a challenge to fine tune the OPTIONS response on a per enterprise/site basis.
>>> 
>>> I assume the service provider will have to know from which enterprise network the OPTIONS request comes from - similar to the HTTPS GET in the draft.
>> 
>> Kaustubh: The point of contention isn’t how the service provider determines “where” the OPTIONS request came in from. This can be done by examining SIP header fields or the source IP address of the >request. The point I was trying to make was two-fold:
>> 1.  Service providers would have to upgrade their SIP stacks to handle this new response type in the body of the OPTIONS response. 
>> 
>> 2.  I don’t know if it would be very simple to handle customised capability set responses based on enterprise identity at the SIP layer - even if it is, it is 
>> needlessly a lot of work for something that can be accomplished much more easily using an alternate mechanism.  
> 
> I don't understand how it would be "must more easily". In both cases the server is adding the capabilities in the response of a request (SIP OPTIONS or HTTP GET), and in both cases the server needs to implement the support for that. 

In many cases, the SP could just put a more or less static web page on existing server with a bit of DNS config. That sounds easier to me than waiting to deploy a new version of software on SBCs. I also don’t really know how to solve the chicken and egg problem of how to get the config for the SIP OPTIONS to get the config for the SIP. 

> 
>> While I completely get that SIP OPTIONS was designed for the purpose of probing a remote entity for its capabilities, the path of least disruption seems to be to use HTTPS.
> 
> One of the draft co-authors also co-authored the RIPP draft, which is kind of going in that direction (at least for a specific use-case). But, at least in the draft you are marketing this as a SIP feature :)
> 
> 

This is draft is a small trivial change to try and make it easier to set up a sip trunk, RIPP is, uh, something else. But whatever it is, it is not a small change.