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

["Kaustubh Inamdar (kinamdar)" <[e-mail]>]

Hi Christer,
Sorry for the delay, please find my responses below:


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.

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.  

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.
---

> 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. 

---

> 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.

> 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?

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.
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
    
    
    
    
    
    On 17/09/19, 9:55 PM, "Christer Holmberg" <[e-mail]> wrote:
    
        What about SIP OPTIONS?
        
        Regards,
        
        Christer
        
        -----Alkuperäinen viesti-----
        Lähettäjä: dispatch <[e-mail]> Puolesta Kaustubh Inamdar (kinamdar)
        Lähetetty: tiistai 17. syyskuuta 2019 4.32
        Vastaanottaja: [e-mail]
        Aihe: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt
        
        Hi All,
        The following draft has been posted to dispatch. The draft aims to simplify peering between enterprise and service provider SIP networks. Discussions/comments are welcome.
        
        -Kaustubh
        
        
        
        
        
            
            A new version of I-D, draft-kinamdar-dispatch-sip-auto-peer-00.txt
            has been successfully submitted by Cullen Jennings and posted to the
            IETF repository.
            
            Name:		draft-kinamdar-dispatch-sip-auto-peer
            Revision:	00
            Title:		Automatic Peering for SIP Trunks
            Document date:	2019-09-10
            Group:		Individual Submission
            Pages:		35
            URL:            https://www.ietf.org/internet-drafts/draft-kinamdar-dispatch-sip-auto-peer-00.txt
            Status:         https://datatracker.ietf.org/doc/draft-kinamdar-dispatch-sip-auto-peer/
            Htmlized:       https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-00
            Htmlized:       https://datatracker.ietf.org/doc/html/draft-kinamdar-dispatch-sip-auto-peer
        
            
            
            Abstract:
               This draft specifies a configuration workflow to enable enterprise
               Session Initiation Protocol (SIP) networks to solicit the capability
               set of a SIP service provider network.  The capability set can
               subsequently be used to configure features and services on the
               enterprise edge element, such as a Session Border Controller (SBC),
               to ensure smooth peering between enterprise and service provider
               networks.
            
                                                                                              
            
            
            Please note that it may take a couple of minutes from the time of submission
            until the htmlized version and diff are available at tools.ietf.org.
            
            The IETF Secretariat
            
            
        
        _______________________________________________
        dispatch mailing list
        [e-mail]
        https://www.ietf.org/mailman/listinfo/dispatch