Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

From: Ben Campbell <[email-masked]>
Date: Wed, 11 Mar 2020 16:21:29 -0500

Hi Everyone,

The proponents have gone through a few revisions of the proposed charter (below) based on list feedback. At this point, we’d like to call the questions on what to recommend to to the ART ADs. Please respond to the following questions:

1. Is the topic described suitable for a reasonably short-lived mini-working group, without requiring a separate BoF first?

2. Is the charter a good starting point from which to develop a final charter (through the usual charter review process for new working groups)

3. Would you participate in a working group with a charter substantially similar to this one?

Note that we have agenda time allocated for this on an upcoming virtual meeting (details TBD), but if we can close these questions via email, we can give that time back to other things.

Thanks!

Ben.

> On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) <sreenara=[email-masked]> wrote:
> 
> All,
> 
> Here are the revisions to the proposed charter of ASAP (Automatic SIP trunking And Peering) after incorporating the latest comments. Suggestions/comments are welcome.
> 
> 
> The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks is increasing at a rapid pace. Consequently, direct IP peering between enterprise and service provider networks is quickly replacing traditional methods of interconnection between enterprise and service provider networks.
> 
> Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often not clear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks resulting in a large number of support cases being opened with enterprise equipment manufacturers and SIP service providers. Subsequently, deployment times for SIP trunking between enterprise and service provider networks increase significantly.
> 
> This work would define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, provides the enterprise network with sufficient information to setup SIP trunking with the SIP service provider. Such a capability set would not only result in SIP trunking deployment times being drastically scaled down, but also would result in a significant decrease in interoperability issues between enterprise and service provider network. Over the long run, operational costs for service providers and enterprise equipment manufactures would likely decrease as a result of fewer support cases.
> 
> This work would make use of HTTPS based framework that allows a SIP service provider to offload a detailed capability set to the enterprise network. HTTPS is used in favor of SIP for the following reasons:
> 1. While there are extensions to baseline SIP that could potentially allow a capability set to be communicated from the service provider to the enterprise network, none of these extensions are readily usable to achieve the objective of this work.
> 2. Any modifications to existing SIP-based extensions to fit the objective of this work would require equipment manufacturers to upgrade their SIP stacks.
> 
> The scope of activity includes:
> 
> * Define a robust capability set which encapsulates sufficient information to ensure smooth IP peering between enterprise and service provider SIP networks.
> * Define a data model for the capability set.
> * Extensibility of the data model to allow proprietary parameters to be encoded.
> * A HTTPS-based transport mechanism using which the capability set is communicated from the service provider network to the enterprise network.
> * A mechanism to discover the capability server hosted in the SIP service provider network
> 
> The following is out of scope:
> * Extensions to SIP that enable an enterprise network to solicit and obtain a descriptive capability set from a SIP service provider.
> * A workflow/mechanism that allows service providers to directly configure devices in the enterprise network.
> 
> The group will produce
> * Requirements, Use Cases and Architecture draft.
> * Specification for SIP Auto Peer.
> 
> This group will co-ordinate with the SIP core workgroup and the SIPConnect efforts carried out by the SIP Forum.
> 
> Milestones:
> <Date TBD> Send protocol specification to IESG
> 
> _______________________________________________
> dispatch mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Mar 2020 15:14:28 -0500

Hi Again Everyone,

I know people have been more caught up in how we handle the cancelation of the IETF107 in-person meeting than in day to day DISPATCH email. One way we can handle that is to complete discussions on list rather than taking meeting time. This seems like a good candidate for that.

Thanks!

Ben.

> On Mar 11, 2020, at 4:21 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi Everyone,
> 
>> On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) <sreenara=[email-masked] <mailto:sreenara=[email-masked]>> wrote:
>> 
>> All,
>>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 19 Mar 2020 03:36:31 +0000

Hi Ben -

Responses inline…

On Mar 11, 2020, at 5:21 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Hi Everyone,

Yes, I think a short-lived WG would be ideal for this given the limited scope and milestone(s).

Yes. It seems appropriate to me as starting point.

Yes.

Thanks!

Ben.

Cheers,

Gonzalo

On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) <sreenara=[email-masked]<mailto:sreenara=[email-masked]>> wrote:

All,

The group will produce

Milestones:

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ben Campbell <[email-masked]>
Date: Sat, 21 Mar 2020 15:34:34 -0500

Hi Everyone,

Gonzalo S. wins the chair-appreciation award for being the first to respond to a chair request for input :-)

Anyone else? We will have a tight agenda on Monday; any chance we could close this topic prior to the meeting?

> On Mar 12, 2020, at 3:14 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi Again Everyone,
> 
>> On Mar 11, 2020, at 4:21 PM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Everyone,
>> 
> [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Mar 2020 00:33:50 +0000

Hi,

AFAIK, the authors of the proposed charter didn’t reply to my latest comments (which I sent twice). They may have tried to address them in the latest version of the proposed charter, but I think it would have been useful to have a discussion on the list.

I think my main issue was describing why the existing SIP capability exchange mechanisms cannot be used.

The proposed charter now says:

>1. While there are extensions to baseline SIP that could potentially allow a capability set to be communicated from the service provider to the enterprise network,
>none of these extensions are readily usable to achieve the objective of this work.

This doesn’t say much. It would be useful with some text on why none of the extensions are readily usable.

>2. Any modifications to existing SIP-based extensions to fit the objective of this work would require equipment manufacturers to upgrade their SIP stacks.

This would also need more justification, because doesn’t SIP extensions in general require upgrading of SIP stacks?

Regards,

Christer

From: dispatch <[email-masked]> on behalf of Ben Campbell <[email-masked]>
Date: Saturday, 21 March 2020 at 22.35
To: "[email-masked]" <[email-masked]>
Cc: "Sreekanth Narayanan (sreenara)" <sreenara=[email-masked]>, "Kaustubh Inamdar (kinamdar)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

Hi Everyone,

On Mar 12, 2020, at 3:14 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Hi Again Everyone,

Thanks!

Ben.

On Mar 11, 2020, at 4:21 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Hi Everyone,

Thanks!

Ben.

All,

The group will produce

Milestones:

---

From: "Sreekanth Narayanan (sreenara)" <[email-masked]>
Date: Sun, 22 Mar 2020 12:42:58 +0000

Hi Christer,

What are the SIP-based mechanisms you have in mind? If there are more than one, I assume the exchange of OPTIONS/200OK (with cap set in the body of the response) is one of them. Theoretically, while it is possible to leverage something like SIP OPTIONS, SIP trunking deployment realities between enterprise and service provider networks require the trunk to first be registered (SIP REGISTER/200OK) before any SIP traffic can be exchanged between the two networks, for example, an OPTIONS or even an INVITE to setup calls. To that end, for a SIP-based solution to work, the service provider ought to change this behaviour, why would that method be advocated when there is an alternative? While this entire framework attempts to ease SIP trunking between enterprise and service provider networks, why must the framework use SIP? Why not HTTPS? Is is purely because this framework is related to "SIP" trunking?

What are the advantages of using SIP over HTTPS in this specific scenario?
What is the barrier to deployment of a SIP-based method as opposed to a HTTPS based method? I suspect the former is more difficult.

Here are some of the advantages for HTTPS:

The service providers need only deploy HTTPS servers accessible over the Internet so that the enterprise can obtain a capability set. There is no change on the part of the service provider in terms of how they handle SIP.
There is also very little change required on part of enterprise SBC vendors. Almost all SBCs today support HTTPS, XML & YANG.
I would like to reiterate that using HTTPS in this context doesn't in any way mean that this is the new "normal" for soliciting and obtaining a remote SIP peers capability - the OPTIONS method was designed for that. This is A scenario for which HTTPS is conducive and has nothing to do with creating a new way of communicating capabilities.

Regards
Sreekanth

________________________________
From: Christer Holmberg <christer.holmberg=[email-masked]>
Sent: Sunday, March 22, 2020 6:03 AM
To: Ben Campbell <[email-masked]>; [email-masked] <[email-masked]>
Cc: Sreekanth Narayanan (sreenara) <[email-masked]>; Kaustubh Inamdar (kinamdar) <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

Hi,

Regards,

Christer

Hi Everyone,

Hi Again Everyone,

Thanks!

Ben.

Hi Everyone,

Thanks!

Ben.

All,

The group will produce

Milestones:

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Mar 2020 13:15:42 +0000

Hi,

>What are the SIP-based mechanisms you have in mind? If there are more than one, I assume the exchange of OPTIONS/200OK (with cap set in the body of the response) is one of them.

Yes. Most mechanisms can also be used with non-OPTION methods.

>Theoretically, while it is possible to leverage something like SIP OPTIONS, SIP trunking deployment realities between enterprise and service provider networks
>require the trunk to first be registered (SIP REGISTER/200OK) before any SIP traffic can be exchanged between the two networks, for example, an OPTIONS
>or even an INVITE to setup calls.

Having to exchange capabilities before the registration/session is established is a concrete justification. Please explain that in the proposed charter, because that would probably be one of the most important inputs for this work :)

>To that end, for a SIP-based solution to work, the service provider ought to change this behaviour, why would that method be advocated when there
>is an alternative? While this entire framework attempts to ease SIP trunking between enterprise and service provider networks, why must the framework
>use SIP? Why not HTTPS? Is is purely because this framework is related to "SIP" trunking?
>

I am not saying it must use SIP – I am asking for a justification why HTTPS would be more feasible than SIP. If we are going to use a non-SIP protocol for exchanging SIP capabilities I think it is important for people to know why we want to use a non-SIP protocol.

>The service providers need only deploy HTTPS servers accessible over the Internet so that the enterprise can obtain a capability set.
>There is no change on the part of the service provider in terms of how they handle SIP..
>I would like to reiterate that using HTTPS in this context doesn't in any way mean that this is the new "normal" for soliciting and obtaining a remote SIP peers capability - the OPTIONS method >was designed for that. This is A scenario for which HTTPS is conducive and has nothing to do with creating a new way of communicating capabilities.

Regarding SBCs, one of the issues by using a non-SIP mechanism is that SBCs won’t be able to modify the capabilities – unless you intend to route the HTTPS traffic through the SBCs too.
Perhaps there won’t be any such intermediaries in the use-cases you have in mind, but we should discuss whether we are ok with that. My point is that, before we discuss protocol details, we should be clear about what functionality, and what use-cases, we want to support.

Thanks!

Regards,

Christer

Hi,

Regards,

Christer

Hi Everyone,

On Mar 12, 2020, at 3:14 PM, Ben Campbell <[email-masked]<mailto:ben@nostrum..com>> wrote:

Hi Again Everyone,

Thanks!

Ben.

On Mar 11, 2020, at 4:21 PM, Ben Campbell <[email-masked]<mailto:ben@nostrum..com>> wrote:

Hi Everyone,

Thanks!

Ben.

On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) <sreenara=40cisco.com@dmarc..ietf.org<mailto:sreenara=[email-masked]>> wrote:

All,

The group will produce

Milestones:

---

From: "Sreekanth Narayanan (sreenara)" <[email-masked]>
Date: Sun, 22 Mar 2020 16:04:38 +0000

Hi Christer,

>Having to exchange capabilities before the registration/session is established is a concrete justification. Please explain that in the proposed charter, because that would probably be one of the >most important inputs for this work :)

We can accommodate this in the charter.

> I am not saying it must use SIP – I am asking for a justification why HTTPS would be more feasible than SIP. If we are going to use a non-SIP protocol for exchanging SIP capabilities I think it is…

I think the text in the draft as well as the latest charter proposal covers this. We've mentioned a couple of points as to why HTTPs would be better than SIP.

> Perhaps there won’t be any such intermediaries in the use-cases you have in mind, but we should discuss whether we are ok with that. My point is that, before we discuss protocol details, we

> should be clear about what functionality, and what use-cases, we want to support.

The SBC isn’t required to modify the capability set - it simply sources the HTTPS GET and parses the response. In what scenario would the SBC require to modify the capabilities? The HTTPS GET, as per the draft, is always sourced from an “edge element” - the device that directly talks to the ITSP. In most cases this always going to be the SBC. If for some reason this isn’t the SBC, then that device sources the HTTPS GET and parses the response. The use case is simple - the edge element directly responsible for interworking signaling and media between the enterprise and service provider network, solicits a capability set and obtains the response. The reason it is required for the edge element to do so is because, deployment realities have demonstrated a concerted effort on the part of administrators to obtain and put in the correct configuration on these devices.

Since the HTTP request is sourced from the edge element (in most cases, the enterprise SBC), the only intermediaries are the HTTPS proxies that are located between the edge element and the service provider capability server. In all use-cases for this work, it is the edge element that will reach out with an HTTPS GET request.

Regards
Sreekanth

________________________________
From: Christer Holmberg <christer.holmberg=[email-masked]>
Sent: Sunday, March 22, 2020 6:45 PM
To: Sreekanth Narayanan (sreenara) <[email-masked]>; Ben Campbell <[email-masked]>; [email-masked] <[email-masked]>
Cc: Kaustubh Inamdar (kinamdar) <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

Hi,

Thanks!

Regards,

Christer

Hi,

Regards,

Christer

Hi Everyone,

Hi Again Everyone,

Thanks!

Ben.

Hi Everyone,

Thanks!

Ben.

All,

The group will produce

Milestones:

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Mar 2020 20:52:04 +0000

Hi,

>> Having to exchange capabilities before the registration/session is established is a concrete justification. Please explain that in the proposed charter,

>> because that would probably be one of the >most important inputs for this work :)
>

Thanks!

>The SBC isn’t required to modify the capability set - it simply sources the HTTPS GET and parses the response. In what scenario would the SBC require to modify the capabilities?

Assume you e.g., have some kind of transit network, which may limit the capabilities.

Regards,

Christer

Hi,

Thanks!

Regards,

Christer

Hi,

Regards,

Christer

Hi Everyone,

On Mar 12, 2020, at 3:14 PM, Ben Campbell <[email-masked]<mailto:ben@nostrum...com>> wrote:

Hi Again Everyone,

Thanks!

Ben.

On Mar 11, 2020, at 4:21 PM, Ben Campbell <[email-masked]<mailto:ben@nostrum...com>> wrote:

Hi Everyone,

Thanks!

Ben.

On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) <sreenara=40cisco.com@dmarc...ietf.org<mailto:sreenara=[email-masked]>> wrote:

All,

The group will produce

Milestones:

---

From: "Sreekanth Narayanan (sreenara)" <[email-masked]>
Date: Mon, 23 Mar 2020 04:23:43 +0000

Hi Christer,

>Assume you e.g., have some kind of transit network, which may limit the capabilities.

The capability set is provided by the ITSP that the enterprise trunk(s) registers to. Therefore, the ITSP that provided the capability set is expected to be the one that directly peers with the enterprise network. If however, in the event there is an intermediary, the ITSP that generates the capability set must include the caps of the network that directly peers with the enterprise, which in this case is the intermediary (after all, SIP trunk registration and call sending and receiving will be directly between the intermediary and the enterprise). This aspect will be discussed in the draft...

Regards
Sreekanth

Sent: Monday, March 23, 2020 2:22 AM

Hi,

Thanks!

Regards,

Christer

Hi,

Thanks!

Regards,

Christer

Hi,

Regards,

Christer

Hi Everyone,

Hi Again Everyone,

Thanks!

Ben.

Hi Everyone,

Thanks!

Ben.

All,

The group will produce

Milestones:

---

From: "Sreekanth Narayanan (sreenara)" <[email-masked]>
Date: Thu, 26 Mar 2020 04:06:43 +0000

All,

Here's the the updated version of the proposed charter of ASAP (Automatic SIP trunking And Peering) after addressing all concerns and comments so far. Further suggestions/comments are welcome.

The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks has been increasing gradually over the last few years. Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods of interconnection between enterprise and service provider networks.

Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often not clear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks resulting in a considerable number of support cases being opened with enterprise equipment manufacturers and SIP service providers. Subsequently, deployment times for SIP trunking between enterprise and service provider networks increase.

This work would define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, provides the enterprise network with sufficient information to setup SIP trunking with the SIP service provider. Such a capability set would not only result in SIP trunking deployment times being scaled down, but also would result in reduction of interoperability issues between enterprise and service provider network. Over the long run, operational costs for service providers and enterprise equipment manufactures would likely decrease as a result of fewer support cases.

  1.  Most SIP service providers require the enterprise network to first register a SIP trunk before any SIP traffic can be exchanged between the two networks. Accordingly, using a SIP-based method to obtain a detailed capability set from the SIP service provider (for example, SIP OPTIONS) would require the service provider to relax the requirement of enterprise networks first registering SIP trunks. This is a significant change and could serve as a barrier to adoption of the framework this work aims to produce.
  2.  Any modifications to existing SIP-based extensions to fit the objective of this work would require equipment manufacturers to upgrade their SIP stacks.

The group will produce

  *   Requirements, Use Cases and Architecture draft.
  *   Specification for SIP Auto Peer.
  *   This group will co-ordinate with the SIP core workgroup and the SIPConnect efforts carried out by the SIP Forum.

Milestones:

Regards
Sreekanth

________________________________
From: Sreekanth Narayanan (sreenara) <[email-masked]>
Sent: Monday, March 23, 2020 9:53 AM
To: Christer Holmberg <christer.holmberg=[email-masked]>; Ben Campbell <[email-masked]>; [email-masked] <[email-masked]>
Cc: Kaustubh Inamdar (kinamdar) <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

Hi Christer,

Regards
Sreekanth

Hi,

Thanks!

Regards,

Christer

Hi,

Thanks!

Regards,

Christer

Hi,

Regards,

Christer

Hi Everyone,

Hi Again Everyone,

Thanks!

Ben.

Hi Everyone,

Thanks!

Ben.

All,

The group will produce

Milestones:

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 26 Mar 2020 20:13:36 +0600

There is no mention about the RUNNING Code. I would like to see code
for proof of concept to be delivered as milestone before we send it to
IESG
ThanksSamir Srivastava

On 3/26/2020 at 9:37 AM, "Sreekanth Narayanan (sreenara)"  wrote:  P {
margin-top:0; margin-bottom:0; }    All,
  Here's the the updated version of the proposed charter of ASAP
(Automatic SIP trunking And Peering) after addressing all concerns and
comments so far. Further suggestions/comments are welcome.
  The deployment of a Session Initiation Protocol (SIP)-based
infrastructure in enterprise and service provider communication
networks has been increasing gradually over the last few years.
Consequently,  direct IP peering between enterprise and service
provider networks is replacing traditional methods of interconnection
between enterprise and service provider networks.
  Currently published standards provide a strong foundation over which
direct IP peering can be realized. However, given the sheer number of
these standards, it is often not clear which behavioural  subsets,
extensions to baseline protocols and operating principles ought to be
configured by the enterprise network administrator to ensure
successful peering with a SIP service provider network. This lack of
context often leads to interoperability issues  between enterprise and
service provider SIP networks resulting in a considerable number of
support cases being opened with enterprise equipment manufacturers and
SIP service providers. Subsequently, deployment times for SIP trunking
between enterprise and  service provider networks increase.
  This work would define a descriptive capability set, which is
populated by a SIP service provider, and which, when communicated to
an enterprise network, provides the enterprise network with sufficient
 information to setup SIP trunking with the SIP service provider. Such
a capability set would not only result in SIP trunking deployment
times being scaled down, but also would result in reduction of
interoperability issues between enterprise and service provider 
network. Over the long run, operational costs for service providers
and enterprise equipment manufactures would likely decrease as a
result of fewer support cases.
  This work would make use of HTTPS based framework that allows a SIP
service provider to offload a detailed capability set to the
enterprise network. HTTPS is used in favor of SIP for the following 
reasons:
    	*Most SIP service providers require the enterprise network to
first register a SIP trunk before any SIP traffic can be exchanged
between the two networks. Accordingly, using a SIP-based method to 
obtain a detailed capability set from the SIP service provider (for
example, SIP OPTIONS) would require the service provider to relax the
requirement of enterprise networks first registering SIP trunks. This
is a significant change and could serve as a barrier  to adoption of
the framework this work aims to produce.	*Any modifications to
existing SIP-based extensions to fit the objective of this work would
require equipment manufacturers to upgrade their SIP stacks. 
  The scope of activity includes:
 	*Define a robust capability set which encapsulates sufficient
information to ensure smooth IP peering between enterprise and service
provider SIP networks.	*Define a data model for the capability
set.	*Extensibility of the data model to allow proprietary parameters
to be encoded.	*A HTTPS-based transport mechanism using which the
capability set is communicated from the service provider network to
the enterprise network.	*A mechanism to discover the capability server
hosted in the SIP service provider network
   The following is out of scope:
 	*Extensions to SIP that enable an enterprise network to solicit and
obtain a descriptive capability set from a SIP service provider.	*A
workflow/mechanism that allows service providers to directly configure
devices in the enterprise network.
   The group will produce
 	*Requirements, Use Cases and Architecture draft.	*Specification for
SIP Auto Peer.	*This group will co-ordinate with the SIP core
workgroup and the SIPConnect efforts carried out by the SIP Forum.
  Milestones:
   Send protocol specification to IESG  
   Regards  Sreekanth
-------------------------
 From: Sreekanth Narayanan (sreenara) 
 Sent: Monday, March 23, 2020 9:53 AM
 To: Christer Holmberg ; Ben Campbell ; [email-masked] 
 Cc: Kaustubh Inamdar (kinamdar) ; [email-masked] 
 Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP
trunking And Peering)      Hi Christer,  
	 > >The SBC isn’t required to modify the capability set -  it
simply sources the HTTPS GET and parses the response. In what scenario
would the SBC require to modify the capabilities?  
	 >Assume you e.g., have some kind of transit network, which may limit
the capabilities. 
   The capability set is provided by the ITSP that the enterprise
trunk(s) registers to. Therefore, the ITSP that provided the
capability  set is expected to be the one that directly peers with the
enterprise network. If however, in the event there is an intermediary,
the ITSP that generates the capability set must include the caps of
the network that directly peers with the enterprise, which  in this
case is the intermediary (after all, SIP trunk registration and call
sending and receiving will be directly between the intermediary and
the enterprise). This aspect will be discussed in the draft...
   Regards  Sreekanth  
-------------------------
 From: Christer Holmberg 
 Sent: Monday, March 23, 2020 2:22 AM
 To: Sreekanth Narayanan (sreenara) ; Ben Campbell ; [email-masked]

 Cc: Kaustubh Inamdar (kinamdar) ; [email-masked] 
 Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP
trunking And Peering)      

	 Hi,  
	>> Having to exchange capabilities before the registration/session is
established is a concrete justification. Please explain that in the
proposed charter,  

	 Thanks!    
	>> Regarding SBCs, one of the issues by using a non-SIP mechanism is
that SBCs won’t be able to modify the capabilities – unless you
intend to route the HTTPS traffic  through the SBCs too. 

	>> Perhaps there won’t be any such intermediaries in the use-cases
you have in mind, but we should discuss whether we are ok with that.
My point is that, before we  discuss protocol details, we  

	 >The SBC isn’t required to modify the capability set - it simply
sources the HTTPS GET and parses the response. In what scenario would
the SBC require to modify the capabilities?  
	 Assume you e.g., have some kind of transit network, which may limit
the capabilities. 
	 Regards, 
	 Christer 
-------------------------
	 From: Christer Holmberg 
 Sent: Sunday, March 22, 2020 6:45 PM
 To: Sreekanth Narayanan (sreenara) ; Ben Campbell ; [email-masked]

 Cc: Kaustubh Inamdar (kinamdar) ; [email-masked] 
 Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP
trunking And Peering)   
	 Hi,   
	 >What are the SIP-based mechanisms you have in mind? If there are
more than one, I assume the exchange of OPTIONS/200OK (with cap set in
the body of the response) is one of them.  
	 Yes. Most mechanisms can also be used with non-OPTION methods. 
	 >Theoretically, while it is possible to leverage something like SIP
OPTIONS, SIP trunking deployment realities between enterprise and
service provider networks 

	 >require the trunk to first be registered (SIP REGISTER/200OK)
before any SIP traffic can be exchanged between the two networks, for
example, an OPTIONS 

	 >or even an INVITE to setup calls.  
	 Having to exchange capabilities before the registration/session is
established is a concrete justification. Please explain that in the
proposed charter, because that would probably be one of the most
important inputs for this work :) 
	 >To that end, for a SIP-based solution to work, the service provider
ought to change this behaviour, why would that method be advocated
when there 

	 >is an alternative? While this entire framework attempts to ease SIP
trunking between enterprise and service provider networks, why must
the framework 

	 > What is the barrier to deployment of a SIP-based method as opposed
to a HTTPS based method? I suspect the former is more difficult. 
	 I am not saying it must use SIP – I am asking for a justification
why HTTPS would be more feasible than SIP. If we are going to use a
non-SIP protocol for exchanging SIP capabilities I think it is
important for people to know why we want  to use a non-SIP protocol.  

	 >The service providers need only deploy HTTPS servers accessible
over the Internet so that the enterprise can obtain a capability set. 

	 >There is also very little change required on part of enterprise SBC
vendors. Almost all SBCs today support HTTPS, XML & YANG.  

	 >I would like to reiterate that using HTTPS in this context doesn't
in any way mean that this is the new "normal" for soliciting and
obtaining a remote SIP peers capability  - the OPTIONS method >was
designed for that.  This is A scenario for which HTTPS is conducive
and has nothing to do with creating a new way of communicating
capabilities.   
	 Regarding SBCs, one of the issues by using a non-SIP mechanism is
that SBCs won’t be able to modify the capabilities – unless you
intend to route the HTTPS traffic through the SBCs too. 

	 Perhaps there won’t be any such intermediaries in the use-cases
you have in mind, but we should discuss whether we are ok with that.
My point is that, before we discuss protocol details, we should be
clear about what functionality, and what  use-cases, we want to
support. 
	 Thanks! 
	 Regards, 
	 Christer 
-------------------------
	 From: Christer Holmberg 
 Sent: Sunday, March 22, 2020 6:03 AM
 To: Ben Campbell ; [email-masked] 
 Cc: Sreekanth Narayanan (sreenara) ; Kaustubh Inamdar (kinamdar) ;
[email-masked] 
 Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP
trunking And Peering)   
	 Hi, 
	 AFAIK, the authors of the proposed charter didn’t reply to my
latest comments (which I sent twice). They may have tried to address
them in the latest version of the proposed charter, but I think it
would have been useful to have a discussion  on the list. 
	 I think my main issue was describing why the existing SIP capability
exchange mechanisms cannot be used. 
	 The proposed charter now says: 
	 >1. While there are extensions to baseline SIP that could
potentially allow a capability set to be communicated from the service
provider to the enterprise network, 

	 >none of these extensions are readily usable to achieve the
objective of this work. 
	 This doesn’t say much. It would be useful with some text on why
none of the extensions are readily usable. 
	 >2. Any modifications to existing SIP-based extensions to fit the
objective of this work would require equipment manufacturers to
upgrade their SIP stacks. 
	 This would also need more justification, because doesn’t SIP
extensions in general require upgrading of SIP stacks? 
	 Regards, 
	 Christer 
	 From: dispatch  on behalf of Ben Campbell 
 Date: Saturday, 21 March 2020 at 22.35
 To: "[email-masked]" 
 Cc: "Sreekanth Narayanan (sreenara)" , "Kaustubh Inamdar (kinamdar)"
, "[email-masked]" 
 Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP
trunking And Peering)   
	 Hi Everyone,   
	 Gonzalo S. wins the chair-appreciation award for being the first to
respond to a chair request for input :-)    
	 Anyone else? We will have a tight agenda on Monday; any chance we
could close this topic prior to the meeting?  
	 On Mar 12, 2020, at 3:14 PM, Ben Campbell  wrote:  
	 Hi Again Everyone,   
	 I know people have been more caught up in how we handle the
cancelation of the IETF107 in-person meeting than in day to day
DISPATCH email. One way we can handle that is to complete discussions
on list rather than taking meeting time. This seems like a good 
candidate for that.   
	 Thanks!   
	 Ben.  
	 On Mar 11, 2020, at 4:21 PM, Ben Campbell  wrote:     
	 Hi Everyone,   
	 The proponents have gone through a few revisions of the proposed
charter (below) based on list feedback. At this point, we’d like to
call the questions on what to recommend to to the ART ADs. Please
respond to the following questions:   
	 1. Is the topic described suitable for a reasonably short-lived
mini-working group, without requiring a separate BoF first?   
	 2. Is the charter a good starting point from which to develop a
final charter (through the usual charter review process for new
working groups)   
	 3. Would you participate in a working group with a charter
substantially similar to this one?   
	 Note that we have agenda time allocated for this on an upcoming
virtual meeting (details TBD), but if we can close these questions via
email, we can give that time back to other things.   
	 Thanks!   
	 Ben.    
	 On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara)  wrote:
 
	 All,   
	 Here are the revisions to the proposed charter of ASAP (Automatic
SIP trunking And Peering) after incorporating the latest comments.
Suggestions/comments are welcome.   
	 The deployment of a Session Initiation Protocol (SIP)-based
infrastructure in enterprise and service provider communication
networks is increasing at a rapid pace. Consequently, direct IP
peering between enterprise  and service provider networks is quickly
replacing traditional methods of interconnection between enterprise
and service provider networks.   
	 Currently published standards provide a strong foundation over which
direct IP peering can be realized. However, given the sheer number of
these standards, it is often not clear which behavioural subsets,
extensions  to baseline protocols and operating principles ought to be
configured by the enterprise network administrator to ensure
successful peering with a SIP service provider network. This lack of
context often leads to interoperability issues between enterprise and 
service provider SIP networks resulting in a large number of support
cases being opened with enterprise equipment manufacturers and SIP
service providers. Subsequently, deployment times for SIP trunking
between enterprise and service provider networks increase 
significantly.   
	 This work would define a descriptive capability set, which is
populated by a SIP service provider, and which, when communicated to
an enterprise network, provides the enterprise network with sufficient
information  to setup SIP trunking with the SIP service provider. Such
a capability set would not only result in SIP trunking deployment
times being drastically scaled down, but also would result in a
significant decrease in interoperability issues between enterprise and
 service provider network. Over the long run, operational costs for
service providers and enterprise equipment manufactures would likely
decrease as a result of fewer support cases.   
	 This work would make use of HTTPS based framework that allows a SIP
service provider to offload a detailed capability set to the
enterprise network. HTTPS is used in favor of SIP for the following
reasons:   

	 1. While there are extensions to baseline SIP that could potentially
allow a capability set to be communicated from the service provider to
the enterprise network, none of these extensions are readily usable to
achieve  the objective of this work.   

	 2. Any modifications to existing SIP-based extensions to fit the
objective of this work would require equipment manufacturers to
upgrade their SIP stacks.   
	 The scope of activity includes:   
	 * Define a robust capability set which encapsulates sufficient
information to ensure smooth IP peering between enterprise and service
provider SIP networks.   

	 * Extensibility of the data model to allow proprietary parameters to
be encoded.   

	 * A HTTPS-based transport mechanism using which the capability set
is communicated from the service provider network to the enterprise
network.   

	 * A mechanism to discover the capability server hosted in the SIP
service provider network   
	 The following is out of scope:   

	 * Extensions to SIP that enable an enterprise network to solicit and
obtain a descriptive capability set from a SIP service provider.   

	 * A workflow/mechanism that allows service providers to directly
configure devices in the enterprise network.   
	 The group will produce   

	 * Specification for SIP Auto Peer.   
	 This group will co-ordinate with the SIP core workgroup and the
SIPConnect efforts carried out by the SIP Forum.   
	 Milestones:   

	  Send protocol specification to IESG  
	 _______________________________________________
 dispatch mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/dispatch    
	 _______________________________________________
 dispatch mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Mar 2020 16:00:01 -0700

One nit, which can be handled anywhere in the process (i.e., it's not a
blocker):

On Wed, Mar 25, 2020 at 9:07 PM Sreekanth Narayanan (sreenara) <sreenara=
[email-masked]> wrote:

> The group will produce
>
>    - Requirements, Use Cases and Architecture draft.
>    - Specification for SIP Auto Peer.
>    - This group will co-ordinate with the SIP core workgroup and the
That last bullet isn't a deliverable, so it should be outside of this
list.  But I'm glad it's being mentioned explicitly.

-MSK

---

From: Mary Barnes <[email-masked]>
Date: Thu, 26 Mar 2020 18:20:02 -0500

Indeed, it would be a good think to coordinate with the SIP Connect
efforts. I did find it interesting that there have been no messages about
this new work being posted on the SIP Forum mailing list.   I think at a
minimum an email announcing this group should go to the SIP Forum Tech WG
mailing list.   While the majority of those folks are likely on the SIPCORE
WG mailing list, when I checked at one time, I was surprised that not all
the folks I might expect were on the DISPATCH WG mailing list when I looked
a while back.

Regards,
Mary.

On Thu, Mar 26, 2020 at 6:00 PM Murray S. Kucherawy <[email-masked]>
wrote:

>>    SIPConnect efforts carried out by the SIP Forum..
>>
>>

---

From: Andy Hutton <[email-masked]>
Date: Fri, 27 Mar 2020 18:05:36 +0000

Hi Ben / All,

I think a short-lived WG for this would be good the charter looks like
a good start and likely I would participate.

Regards
Andy

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Mar 2020 20:43:15 +0000

Hi,

I am ok with the latest version of the proposed charter text. Thanks!

Regards,

Christer

From: "Sreekanth Narayanan (sreenara)" <sreenara=[email-masked]>
Date: Thursday, 26 March 2020 at 6.07
To: Christer Holmberg <[email-masked]>, Ben Campbell <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Kaustubh Inamdar (kinamdar)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

All,

The group will produce

Milestones:

Regards
Sreekanth

Hi Christer,

Regards
Sreekanth

Hi,

Thanks!

Regards,

Christer

Hi,

Thanks!

Regards,

Christer

Hi,

Regards,

Christer

Hi Everyone,

On Mar 12, 2020, at 3:14 PM, Ben Campbell <[email-masked]<mailto:ben@nostrum....com>> wrote:

Hi Again Everyone,

Thanks!

Ben.

On Mar 11, 2020, at 4:21 PM, Ben Campbell <[email-masked]<mailto:ben@nostrum....com>> wrote:

Hi Everyone,

Thanks!

Ben.

On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) <sreenara=40cisco.com@dmarc....ietf.org<mailto:sreenara=[email-masked]>> wrote:

All,

The group will produce

Milestones:

---

From: Richard Shockey <[email-masked]>
Date: Fri, 27 Mar 2020 17:18:03 -0400

+1 agreed. 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: dispatch <[email-masked]> on behalf of Mary Barnes <[email-masked]>
Date: Thursday, March 26, 2020 at 7:20 PM
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

Indeed, it would be a good think to coordinate with the SIP Connect efforts. I did find it interesting that there have been no messages about this new work being posted on the SIP Forum mailing list.   I think at a minimum an email announcing this group should go to the SIP Forum Tech WG mailing list.   While the majority of those folks are likely on the SIPCORE WG mailing list, when I checked at one time, I was surprised that not all the folks I might expect were on the DISPATCH WG mailing list when I looked a while back. 

Regards,

Mary. 

On Thu, Mar 26, 2020 at 6:00 PM Murray S. Kucherawy <[email-masked]> wrote:

One nit, which can be handled anywhere in the process (i.e., it's not a blocker):

On Wed, Mar 25, 2020 at 9:07 PM Sreekanth Narayanan (sreenara) <sreenara=[email-masked]> wrote:

The group will produce

Requirements, Use Cases and Architecture draft.
Specification for SIP Auto Peer.
This group will co-ordinate with the SIP core workgroup and the SIPConnect efforts carried out by the SIP Forum...

That last bullet isn't a deliverable, so it should be outside of this list.  But I'm glad it's being mentioned explicitly.

-MSK

_______________________________________________ dispatch mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Sun, 29 Mar 2020 13:34:50 +0000

Why is there a need to have the PoC delivered as a milestone?This framework uses a HTTPS request/response transaction to solicit and obtain a capability set from a SIP service provider, such that the capability set is encoded in XML or JSON (eventually, it would be only XML or JSON and not both). HTTPS is ubiquitous and therefore, a demonstration of this transaction seems unnecessary.
Demonstration/Implementation of the ability of an edge element to obtain a capability set and translate that into configuration blocks is out of scope as different equipment vendors have different command sets to enable functionality.

--Kaustubh

From: Samir Srivastava <[email-masked]>
Date: Thursday, 26 March 2020 at 19:54
To: "Sreekanth Narayanan (sreenara)" <sreenara=[email-masked]>, Christer Holmberg <christer.holmberg=[email-masked]>, Ben Campbell <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Kaustubh Inamdar <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

There is no mention about the RUNNING Code. I would like to see code for proof of concept to be delivered as milestone before we send it to IESG

Thanks
Samir Srivastava

On 3/26/2020 at 9:37 AM, "Sreekanth Narayanan (sreenara)" <sreenara=[email-masked]> wrote:
All,

The group will produce

Milestones:

Regards
Sreekanth

Hi Christer,

Regards
Sreekanth

Hi,

Thanks!

Regards,

Christer

Hi,

Thanks!

Regards,

Christer

Hi,

Regards,

Christer

Hi Everyone,

Hi Again Everyone,

Thanks!

Ben.

Hi Everyone,

Thanks!

Ben.

On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) <sreenara=40cisco.com@dmarc....ietf.org> wrote:

All,

The group will produce

Milestones: