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

[Christer Holmberg <[e-mail]>]

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

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.

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

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 <christer.holmberg=[e-mail]>
Sent: Sunday, March 22, 2020 6:03 AM
To: Ben Campbell <[e-mail]>; [e-mail] <[e-mail]>
Cc: Sreekanth Narayanan (sreenara) <[e-mail]>; Kaustubh Inamdar (kinamdar) <[e-mail]>; [e-mail] <[e-mail]>
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 <[e-mail]> on behalf of Ben Campbell <[e-mail]>
Date: Saturday, 21 March 2020 at 22.35
To: "[e-mail]" <[e-mail]>
Cc: "Sreekanth Narayanan (sreenara)" <sreenara=[e-mail]>, "Kaustubh Inamdar (kinamdar)" <[e-mail]>, "[e-mail]" <[e-mail]>
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 <[e-mail]<mailto:ben@nostrum..com>> 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 <[e-mail]<mailto:ben@nostrum..com>> 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) <sreenara=40cisco.com@dmarc..ietf.org<mailto:sreenara=[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dispatch







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