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

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Tue, 17 Sep 2019 01:31:30 +0000

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 17 Sep 2019 11:37:39 -0400

I gave this draft a quick skim, and it seems sensible.  I'm not an expert
in the configuration / setup of SIP trunks, but I do love automating manual
processes (cf. ACME), and this draft seems like a plausible approach to
automating things about SIP trunk configuration that are currently manual.

Couple of things that jumped out to me on a quick skim, in no particular
order:

1. It would be good to have a tighter requirement for HTTPS in here.  For
example, on the one hand, you have "it is required to secure HTTP using
Transport Layer Security", but on the other hand, "MUST support the use of
the https uri scheme" (not MUST use).  There is no reason to support
unencrypted HTTP.  You can probably borrow some language from RFC 8555
https://tools.ietf.org/html/rfc8555#section-6

2. "Capability set documents MUST be formatted in XML or JSON" -- Why do
you need both?

3. OAuth2 seems like overkill for this application.  OAuth2 is designed for
a 3-party flow where authorization is being delegated; there are only two
entities here.  It would be much simpler to just use some point-to-point
authentication technique, such as TLS client certificates or even HTTP/SIP
Digest authentication.

4. The WebFinger utilization here also seems like overkill.  Once you take
out the OAuth2, you're just discovering a single URL -- at which point you
might as well configure that directly!  In general, this document needs to
specify (1) what configuration the client is presumed to start out with,
and (2) how that information is used to auto-configure the trunk.  Cf. in
ACME, "Each function is listed in a directory along with its corresponding
URL, so clients only need to be configured with the directory URL."  It
seems like all you really need here is a capability server URL and a
certificate / password.

5. The relation types defined using "https://sipserviceprovider/" need to
be changed to something else.  While that's syntactically a URL, it isn't
actually.  If you need a URI that isn't dereferenceable, please provide
some URNs here.

--RLB

On Mon, Sep 16, 2019 at 9:31 PM Kaustubh Inamdar (kinamdar) <
[email-masked]> wrote:

> 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
>
>
>
> 
>
>
>     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:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Sep 2019 16:24:58 +0000

What about SIP OPTIONS?

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: dispatch <[email-masked]> Puolesta Kaustubh Inamdar (kinamdar)
Lähetetty: tiistai 17. syyskuuta 2019 4.32
Vastaanottaja: [email-masked]
Aihe: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

Hi All,

-Kaustubh

    

    Abstract:

    
    
    The IETF Secretariat

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 17 Sep 2019 16:29:35 +0000

How does this fit with SIP CONNECT?

Martin C. Dolly
Lead Member of Technical Staff
Government & Services Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Sep 17, 2019, at 11:38 AM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

I gave this draft a quick skim, and it seems sensible..  I'm not an expert in the configuration / setup of SIP trunks, but I do love automating manual processes (cf. ACME), and this draft seems like a plausible approach to automating things about SIP trunk configuration that are currently manual.

Couple of things that jumped out to me on a quick skim, in no particular order:

1. It would be good to have a tighter requirement for HTTPS in here..  For example, on the one hand, you have "it is required to secure HTTP using Transport Layer Security", but on the other hand, "MUST support the use of the https uri scheme" (not MUST use).  There is no reason to support unencrypted HTTP.  You can probably borrow some language from RFC 8555 https://tools.ietf.org/html/rfc8555#section-6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8555-23section-2D6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=XpLJRHudftgf9TYF395MAR923aZyfVyPb3j2gK8qDZ4&e=>

2. "Capability set documents MUST be formatted in XML or JSON" -- Why do you need both?

3. OAuth2 seems like overkill for this application.  OAuth2 is designed for a 3-party flow where authorization is being delegated; there are only two entities here.  It would be much simpler to just use some point-to-point authentication technique, such as TLS client certificates or even HTTP/SIP Digest authentication.

4. The WebFinger utilization here also seems like overkill.  Once you take out the OAuth2, you're just discovering a single URL -- at which point you might as well configure that directly!  In general, this document needs to specify (1) what configuration the client is presumed to start out with, and (2) how that information is used to auto-configure the trunk.  Cf. in ACME, "Each function is listed in a directory along with its corresponding URL, so clients only need to be configured with the directory URL."  It seems like all you really need here is a capability server URL and a certificate / password.

5. The relation types defined using "https://sipserviceprovider/<https://urldefense.proofpoint.com/v2/url?u=https-3A__sipserviceprovider_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Nh0orXmFGB5EP87BbYzaB8LyrcQTu6_dDxUhpmpjSPA&e=>" need to be changed to something else.  While that's syntactically a URL, it isn't actually.  If you need a URI that isn't dereferenceable, please provide some URNs here.

--RLB

On Mon, Sep 16, 2019 at 9:31 PM Kaustubh Inamdar (kinamdar) <[email-masked]<mailto:[email-masked]>> wrote:
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

    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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Q2zoz-rVzYoAPa1kAMOGqftJUWccXmkX8DAjNHO9MJQ&e=>
    Status:         https://datatracker.ietf.org/doc/draft-kinamdar-dispatch-sip-auto-peer/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=fcIx3co5agjP22REJR49X4c1pZoZgJEkbg3jjwt8eL0&e=>
    Htmlized:       https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Tuzvwn9LD2APXpkJVHbzlTI7iXO3efPuikuGMp7Zabg&e=>
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-kinamdar-dispatch-sip-auto-peer<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=JGyQBNt1jPbfCcoLY9whz90UF1FEstsr-O3Cre3qCBQ&e=>

    Abstract:

    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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=hxxdnH1hOeFSij1s6a3ZjWpMO8A18PTrzUiyAbfVP0M&e=>.

    The IETF Secretariat

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dispatch&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=zAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU&e=>
_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dispatch&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=zAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU&e=

---

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Thu, 19 Sep 2019 01:07:33 +0000

Hi Christer,

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.

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.

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.

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.

Thanks,
Kaustubh 

On 17/09/19, 9:55 PM, "Christer Holmberg" <[email-masked]> wrote:

    What about SIP OPTIONS?
    
    Regards,
    
    Christer
    
    -----Alkuperäinen viesti-----
    Lähettäjä: dispatch <[email-masked]> Puolesta Kaustubh Inamdar (kinamdar)
    Lähetetty: tiistai 17. syyskuuta 2019 4.32
    Vastaanottaja: [email-masked]
    Aihe: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt
    
    Hi All,
    
    -Kaustubh

        

        
        Abstract:

        
        
        The IETF Secretariat

---

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Thu, 19 Sep 2019 01:08:27 +0000

Hi Martin,

This draft aims to enable an enterprise to discover the SIP service provider capability set. Both of these efforts are geared towards making calls work between enterprise and service provider networks, and as such are complementary.

Thanks,

Kaustubh

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tuesday, 17 September 2019 at 10:05 PM
To: Richard Barnes <[email-masked]>
Cc: Kaustubh Inamdar <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

Martin C. Dolly

--RLB

-Kaustubh

    Abstract:

    The IETF Secretariat

---

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Thu, 19 Sep 2019 01:14:03 +0000

Hi Richard,

Thanks for going over the draft, please find my responses inline:

From: Richard Barnes <[email-masked]>
Date: Tuesday, 17 September 2019 at 9:08 PM
To: Kaustubh Inamdar <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

I gave this draft a quick skim, and it seems sensible.  I'm not an expert in the configuration / setup of SIP trunks, but I do love automating manual processes (cf. ACME), and this draft seems like a plausible approach to automating things about SIP trunk configuration that are currently manual.

1. It would be good to have a tighter requirement for HTTPS in here.  For example, on the one hand, you have "it is required to secure HTTP using Transport Layer Security", but on the other hand, "MUST support the use of the https uri scheme" (not MUST use).  There is no reason to support unencrypted HTTP.  You can probably borrow some language from RFC 8555 https://tools.ietf.org/html/rfc8555#section-6

Kaustubh: Noted, will go over that section and make the appropriate changes.

Kaustubh:  JSON and XML were included to provide flexibility. If however, the larger group favours the use of a single format, we are okay to make the appropriate changes.

Kaustubh: Digest authentication is certainly the easiest client authentication technique. There is/has been little evidence of SIP service providers using client certificates for authentication. The main reason OAuth was chosen was to allow client authentication to be in line with what modern cloud based platforms use.

Kaustubh: Each enterprise network or site within an enterprise is assumed to start off with one of two possible scenarios -

1. The enterprise is provided with the URL of the capability server hosted in the service provider network - this information could be provided by the service provider along with other relevant trunking information such as the username and password combination to use be used while constructing SIP digest responses for 401/407 responses.

2. The enterprise is required to discover the URL of the capability server hosted in the service provider domain. In terms of discovery, the options considered were U-NAPTR and WebFinger. Given the significant deployment trail of WebFinger, it seems to be the best option. Not sure, if there is discovery mechanism embedded in RFC 8555.

In essence, the draft also requires the enterprise to have two fundamental information units to set this framework into motion:

 1. The URL of the capability server

 2. A mechanism for the ITSP to authenticate the enterprise (if at all).

5. The relation types defined using "https://sipserviceprovider/" need to be changed to something else.  While that's syntactically a URL, it isn't actually.  If you need a URI that isn't dereferenceable, please provide some URNs here.

Kaustubh: Will look into this one…

--RLB

-Kaustubh

    Abstract:

    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<http://tools.ietf.org>.

    The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2019 06:53:00 +0000

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

    What about SIP OPTIONS?
    
    Regards,
    
    Christer
    
    -----Alkuperäinen viesti-----
    Lähettäjä: dispatch <[email-masked]> Puolesta Kaustubh Inamdar (kinamdar)
    Lähetetty: tiistai 17. syyskuuta 2019 4.32
    Vastaanottaja: [email-masked]
    Aihe: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt
    
    Hi All,
    
    -Kaustubh

        

        
        Abstract:

        
        
        The IETF Secretariat

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 19 Sep 2019 11:42:05 +0000

And what if there is an intermediate (transit) carrier between them?

From: Kaustubh Inamdar (kinamdar) <[email-masked]>
Sent: Wednesday, September 18, 2019 9:08 PM
To: DOLLY, MARTIN C <[email-masked]>; Richard Barnes <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

Hi Martin,

Thanks,

Kaustubh

From: "DOLLY, MARTIN C" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 17 September 2019 at 10:05 PM
To: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Cc: Kaustubh Inamdar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

Martin C. Dolly

--RLB

-Kaustubh

    Abstract:

    The IETF Secretariat

---

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Sun, 22 Sep 2019 16:12:20 +0000

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

Hi Kaustubh,

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

 

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. 

---

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.

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" <[email-masked]> wrote:

    Hi Kaustubh,

    
    ---

    
    
    ---

    

    Regards,
    
    Christer

    
        What about SIP OPTIONS?
        
        Regards,
        
        Christer
        
        -----Alkuperäinen viesti-----
        Lähettäjä: dispatch <[email-masked]> Puolesta Kaustubh Inamdar (kinamdar)
        Lähetetty: tiistai 17. syyskuuta 2019 4.32
        Vastaanottaja: [email-masked]
        Aihe: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt
        
        Hi All,
        
        -Kaustubh

            

            
            Abstract:

            
            
            The IETF Secretariat

---

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Sun, 22 Sep 2019 16:17:31 +0000

Hi Martin,

Sorry for the delayed revert…

The capability set ought to be populated by the carrier/ITSP that handles and terminates trunk REGISTRATION. If that that happens to be an intermediary carrier, values that are local to the intermediary carrier such as the transport, registrar, callControl, OutboundProxy etc. may be populated without any challenges. Values that are dynamic, such as the set of audio media formats, faxing method etc. may be populated conservatively or via prior inter-carrier agreement. Perhaps carriers too could use something similar to the construct outlined in this draft to discover peer capabilities? The SBCs in the intermediary perhaps already take care of any mismatches in the signalling and media planes between the intermediary and end provider.

Thanks,
Kaustubh

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thursday, 19 September 2019 at 5:12 PM
To: Kaustubh Inamdar <[email-masked]>, Richard Barnes <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

Hi Martin,

Thanks,

Kaustubh

Martin C. Dolly

--RLB

-Kaustubh

    Abstract:

    The IETF Secretariat

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Sep 2019 13:49:54 +0200

It seems like this should work well with SIP Connect. Is there anything that would help align it with that ? 

> On Sep 17, 2019, at 6:29 PM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Cell: +1.609.903.3360
> Email: [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Sep 2019 13:52:39 +0200

> On Sep 19, 2019, at 3:14 AM, Kaustubh Inamdar (kinamdar) <[email-masked]> wrote:
> 

I could live with either but just to pick a starting point, I typically prefer JSON but I think in this case, XML would be better. The support for a strong schema language that really restricts the values of fields seem like it would help in this case. 

So +1 for just one, and a mild preference for XML.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Sep 2019 14:19:15 +0000

Hi Kaustubh,

The intermediary carrier might have it’s own set of supported capabilities and/or restrictions, that the service provider is not aware of. Using SIP OPTIONS, the intermediary carrier is able to (e.g., using the SBCs you mention) make sure that is reflected in the SIP OPTIONS request and response.

Regards,

Christer

From: dispatch <[email-masked]> on behalf of "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Sunday, 22 September 2019 at 19.18
To: MARTIN DOLLY <[email-masked]>, Richard Barnes <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

Hi Martin,

Thanks,
Kaustubh

Hi Martin,

Thanks,

Kaustubh

Martin C. Dolly

1. It would be good to have a tighter requirement for HTTPS in here..  For example, on the one hand, you have "it is required to secure HTTP using Transport Layer Security", but on the other hand, "MUST support the use of the https uri scheme" (not MUST use).  There is no reason to support unencrypted HTTP.  You can probably borrow some language from RFC 8555 https://tools.ietf.org/html/rfc8555#section-6<https://protect2.fireeye.com/url?k=f8869f2a-a40c4a2f-f886dfb1-861010bc36ff-05e6b7f3601b02b6&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_rfc8555-23section-2D6%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DXpLJRHudftgf9TYF395MAR923aZyfVyPb3j2gK8qDZ4%26e%3D>

5. The relation types defined using "https://sipserviceprovider/<https://protect2.fireeye.com/url?k=59debafa-05546fff-59defa61-861010bc36ff-9bd9adf9057a3d68&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__sipserviceprovider_%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DNh0orXmFGB5EP87BbYzaB8LyrcQTu6_dDxUhpmpjSPA%26e%3D>" need to be changed to something else.  While that's syntactically a URL, it isn't actually.  If you need a URI that isn't dereferenceable, please provide some URNs here.

--RLB

-Kaustubh

    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<https://protect2.fireeye.com/url?k=6449d555-38c30050-644995ce-861010bc36ff-0312aeeb5f01095a&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_internet-2Ddrafts_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer-2D00.txt%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DQ2zoz-rVzYoAPa1kAMOGqftJUWccXmkX8DAjNHO9MJQ%26e%3D>
    Status:         https://datatracker.ietf.org/doc/draft-kinamdar-dispatch-sip-auto-peer/<https://protect2.fireeye.com/url?k=7aacdd5f-2626085a-7aac9dc4-861010bc36ff-fb7e45b04af4dd13&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer_%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DfcIx3co5agjP22REJR49X4c1pZoZgJEkbg3jjwt8eL0%26e%3D>
    Htmlized:       https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-00<https://protect2.fireeye.com/url?k=34df3eb9-6855ebbc-34df7e22-861010bc36ff-21ca9741a62c22bc&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer-2D00%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DTuzvwn9LD2APXpkJVHbzlTI7iXO3efPuikuGMp7Zabg%26e%3D>
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-kinamdar-dispatch-sip-auto-peer<https://protect2.fireeye.com/url?k=b8418c35-e4cb5930-b841ccae-861010bc36ff-c0cc00b25d9a157d&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DJGyQBNt1jPbfCcoLY9whz90UF1FEstsr-O3Cre3qCBQ%26e%3D>

    Abstract:

    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<https://protect2.fireeye.com/url?k=7f659d46-23ef4843-7f65dddd-861010bc36ff-3eaeb291f220cdfb&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__tools.ietf.org%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DhxxdnH1hOeFSij1s6a3ZjWpMO8A18PTrzUiyAbfVP0M%26e%3D>.

    The IETF Secretariat

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch<https://protect2.fireeye.com/url?k=252249a0-79a89ca5-2522093b-861010bc36ff-adff9738f6e3658f&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_dispatch%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DzAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU%26e%3D>
_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dispatch&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=zAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU&e=<https://protect2.fireeye.com/url?k=80a75822-dc2d8d27-80a718b9-861010bc36ff-2c78e3612cd4cff2&q=1&u=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_dispatch%26d%3DDwICAg%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3DG9v8uCSSQhCmpw7ItG0r2g%26m%3DxEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ%26s%3DzAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU%26e%3D>