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

[Christer Holmberg <[e-mail]>]

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. 

>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 :)

---

>>> 2. OPTIONS could and in many cases today is used as a keep alive 
>>> mechanism between the enterprise and service provider network. Wouldn’t it be overkill to have the service provider
>>> embed the capability set document in every response? Unless, there is some way for the enterprise to indicate a
>>> keep alive OPTIONS request  and  a capability set soliciting OPTIONS request.
>>
>> I don't think it justifies to define a new capability indication mechanism just because people are misusing the current one.
>> 
>> However, if the community thinks OPTIONS is a good mechanism for keep-alives, I am sure it would be possible to define
>> some type of keep-alive indicator. But, what type of keep-alives are OPTIONS used for? Registration keep-alives? Session
>> keep-alives? Something else?
>
> Kaustubh: Registration keepalives are handled using the Expires header field value of the response to the REGISTER message(200 OK).
> By Session, I assume you mean calls…in which case session freshness is handled using the guidelines of RFC 4028. OPTIONS as it
> relates to keepalives on the other hand is used for target monitoring. In the sense that whether the target to which the OPTIONS is
> sent is capable of handling requests. For example,  SBC——SIP——Group of 3 Call Servers. The SBC would send OPTIONS at regular
> intervals to all three call servers. Depending on the response code or lack thereof, one, two or all three call servers can be
> as “up” - capable of handling further requests or “down” - not a viable destination to send requests to until it/they start responding
> to OPTIONS again. 

Thanks for clarifying. In this case I guess you could define a target keep-alive mode for OPTIONS, where it does not include the whole capability set in the response.

Alternatively, if you are only interested in getting *A* response from the target, you could send OPTIONS with Require:fake-option-tag, which should trigger a 4xx response :)

---

>>> 3. In most cases, SIP service providers would probably not respond to 
>>> OPTIONS unless a SIP trunk is registered to them. If a trunk is 
>>> registered, it explicitly means that the enterprise is ready to 
>>> incoming calls. To register a trunk, then get an OPTIONS response with the capability set and
>>> then configure the edge element(and perhaps other devices for features with an end-to-end bearing)
>>> would leave the enterprise network vulnerable to call failure/unexpected call handling for a certain lapse of time.
>>
>> If the service provider is going to respond to HTTPS GET requests, I would assume they could also response to pre-registration SIP OPTIONS requests?
>
> Kaustubh: This is highly unlikely. I don’t think service providers would respond to OPTIONS sourced from a trunk until the trunk
> is registered. In situations where the OPTIONS is sent prior to trunk registration, I think either the request is ignored (no response whatsoever) or
> responded to with a 403/5XX response without a message body.

Isn't this an SLA issue?

Because, I doubt a service provider would send its capabilities in a HTTPS GET response unless there is some kind of business agreement with the sender (enterprise network) of the GET request and the service provider.

>>> Also, to be able to send SIP OPTIONS, the enterprise ought to know the 
>>> transport address of the OPTIONS target. The transport address of the target is something that is included in the capability set document.
>>
>> The enterprise would have to know where to send the HTTPS GET too.
>
> Kaustubh: How would the enterprise network know which transport protocol to use for the OPTIONS request?
> Assuming it is TLS, would the request have to cycle through UDP, TCP and then TLS?

Well, you have the same question when you are sending a REGISTER, an initial INVITE or a MESSAGE, don't you? Again, I think this is an SLA issue.

> To summarise, deployment realities preclude the smooth use of a SIP based mechanism for obtaining the capability set. If we were talking about
> two simple SIP UAs, then OPTIONS is the best and easiest way of probing remote caps. However, in the context of SIP trunking, this doesn’t seem
> feasible and was one of the strongest reasons we chose to use HTTP.

In that case, I think you should describe that in the draft. Currently it doesn't even mention OPTIONS (unless I've missed it), which I think it is strange considering that it is *THE* SIP mechanism for querying capabilities :)

Regards,

Christer




 

On 19/09/19, 12:23 PM, "Christer Holmberg" <[e-mail]> wrote:

    Hi Kaustubh,
    
    > 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.
    
    ---
    
    > 2. OPTIONS could and in many cases today is used as a keep alive mechanism between the enterprise and service provider network. Wouldn’t it be overkill to have the service
    > provider embed the capability set document in every response? Unless, there is some way for the enterprise to indicate a keep alive OPTIONS request  and  a capability set soliciting OPTIONS request.
    
    I don't think it justifies to define a new capability indication mechanism just because people are misusing the current one.
    
    However, if the community thinks OPTIONS is a good mechanism for keep-alives, I am sure it would be possible to define some type of keep-alive indicator. But, what type of keep-alives are OPTIONS used for? Registration keep-alives? Session keep-alives? Something else?
    
    ---
    
    > 3. In most cases, SIP service providers would probably not respond to OPTIONS unless a SIP trunk is registered to them. If a trunk is registered, it explicitly
    > means that the enterprise is ready to incoming calls. To register a trunk, then get an OPTIONS response with the capability set and then configure the edge
    > element(and perhaps other devices for features with an end-to-end bearing) would leave the enterprise network vulnerable to call failure/unexpected call
    > handling for a certain lapse of time.
    
    If the service provider is going to respond to HTTPS GET requests, I would assume they could also response to pre-registration SIP OPTIONS requests?
    
    > Also, to be able to send SIP OPTIONS, the enterprise ought to know the transport address of the OPTIONS target. The transport address of the target is something
    > that is included in the capability set document.
    
    The enterprise would have to know where to send the HTTPS GET too.
    
    Regards,
    
    Christer