Automatic SIP trunking And Peering (asap) Proposed WG
|WG||Name||Automatic SIP trunking And Peering|
|Area||Applications and Real-Time Area (art)|
|Charter||charter-ietf-asap-00-01 Start Chartering/Rechartering (Internal Steering Group/IAB Review)|
|Dependencies||Document dependency graph (SVG)|
|Jabber chat||Room address||xmpp:email@example.com?join|
Charter for proposed Working Group
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 behavioral 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 working group and the SIPConnect efforts carried out by the SIP Forum.
<Date TBD> Send protocol specification to IESG