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

[Christer Holmberg <[e-mail]>]

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