What is a Session Initiation Protocol (SIP) Trunk Anyway?
draft-rosenberg-sipping-siptrunk-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 18, 2008.

Abstract

The term "Session Initiation Protocol (SIP) Trunk" has become almost commonplace amongst vendors and SIP providers. Even though the notion of a 'trunk' has a well defined meaning in circuit switched systems, it has never been defined for SIP. This document provides a formal definition for a SIP trunk, discusses its scope and applications, and establishes best practices for identification and security of SIP trunks.

Table of Contents

1.  Introduction
2.  What is a SIP Trunk?
    2.1.  Request Processing Behaviors
    2.2.  Conditioned on a Contract
    2.3.  On a Server, not Between
    2.4.  For Use by Servers
3.  Identifying SIP Trunks
4.  Best Practices for SIP Trunks
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The term "trunk" has been used within circuit switched telephony systems for many years. Wikipedia defines a trunk as:

    A circuit between telephone switchboards or other switching
    equipment, as distinguished from local loop circuits which
    extend from telephone exchange switching equipment to
    individual telephones or information origination/termination
    equipment.

Despite its reference to a physical circuit, the term "trunk" has been used in conjunction with Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) systems. A SIP trunk has been used to describe all of the following:

• A service provided by service providers to enterprises, used for the purpose of interconnection to the PSTN, as a replacement for circuit based connectivity.
• A SIP port on an enterprise server, for the purposes of interconnection to other server-based systems, such as voicemail servers, call centers, and application servers.
• A SIP-based interconnection between IP-PBXs, for the purposes of replacing traditional TDM tie lines.

This document provides a formal definition of a "SIP trunk", and discusses its scope and applications, and establishes best practices for identification and security of SIP trunks.

2.  What is a SIP Trunk?

We propose the following definition:

A SIP trunk is a virtual sip entity on a server (UAS, UAC or proxy) constrained by a predefined set of polices and rules that determine how to process requests.

The behavior of the trunk is conditioned on a contract - an agreement between the client and the server, that so long as requests are formatted based on the nature of the contract, the request will receive the specified treatment.

There are several key parts of this definition that are important.

2.1.  Request Processing Behaviors

SIP allows a server wide latitude in the processing it applies to an incoming SIP request. How the call is routed, how it is authenticated, whether it connects to the PSTN, whether headers are added or removed, whether it is terminated, and so on - are all at the discretion of the server. A SIP trunk is defined as a particular set of request processing logic - a specific authentication mechanism, specific routing logic, specific header addition and removal, and so on.

For example, the following are examples of SIP trunks that can be defined on a SIP server:

PSTN Interconnect Trunk:

This is a SIP trunk that would be used by enterprises connecting to a service provider. The trunk utilizes mutual TLS authentication to ascertain the identity of the requesting enterprise. Requests are accepted only if the resulting identity matches a pre-provisioned enterprise user; all others cause immediate closure of the TLS connection. Inbound requests are accepted for termination towards the PSTN. The request URI has to contain a phone number in the user part, and the domain part contains the domain of the provider. Numbers must be in E.164 format. The server will use locally configured routing tables to send the INVITE to a PSTN gateway based on the dialed number.

Filtering Trunk:

This is a SIP trunk that might be provided by a session border controller or other perimeter server. This SIP trunk runs over TCP and is not secured with TLS. The Request-URI can be anything; the domain part represents the destination of the request - not the server itself. The server will examine the SIP request and compare the headers in it, against a pre-configured set of allowed headers. Headers not on the list are removed by the server before the request is forwarded.

Voicemail Trunk:

This is a SIP trunk that might be provided by a voicemail server. It runs over TCP and is secured with TLS; clients must present certificates from an allowed set. The Request URI must be formatted based on the conventions of [RFC4458] (Jennings, C., Audet, F., and J. Elwell, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.).

Publication Trunk:

This is a SIP trunk might exit on a presence server. It supports TLS over TCP only, and is used explicitly for PUBLISH requests [RFC3903] (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) containing presence documents. Only a certain set of presence document extensions are supported; in particular, the documents need to comply with [RFC4480] (Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF),” July 2006.) but the sphere element is not utilized and will be discarded silently if present.

2.2.  Conditioned on a Contract

A server can have an almost arbitrarily large number of SIP trunks, each providing specific functionality to clients whose requests are processed using that logic. Clients which send requests to a specific SIP trunk can expect certain behaviors to be exhibited by the server, and those behaviors are based on pre-defined agreements between the provider of the client and the provider of the server. In order to receive that specified treatment, the request must conform to some agreed-upon structures which may include constraints beyond those in RFC 3261.

For example, if a voicemail server exposes a SIP trunk for voicemail services, the processing applied to requests on that trunk (namely, various voicemail services, such as voicemail deposit or retrieval), is conditioned on those requests being formatted based on the constraints of [RFC4458] (Jennings, C., Audet, F., and J. Elwell, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.). And therein lies the contract - IF the client formats the requests in that way, THEN it will apply voicemail processing to those requests.

A more subtle example is the filtering trunk. There, the contract states that IF the request arrives over TCP - THEN it will remove headers from the request based on the pre-configured set. Here, there are very few constraints on the request beyond RFC 3261 - just usage of TCP. The bulk of the contract is in the THEN part - what processing the server will apply to the request.

2.3.  On a Server, not Between

In the proposed definition, the SIP trunk exists on a single server. It represents functionality provided on that server, possibly to a large number of other clients that connect. This is in contrast to the traditional definition of a trunk, which referred specifically to the interconnection between two switches. This is shown in Figure 1 (Trunk Models).

                                 .
                                 .
                                 .
              Trunk              .    +--------+
                                 .    |   SIP  |
                |                .    | Server |
                |                .    |        |
                |                .    +--------+
   +--------+   |   +--------+   .                     +--------+
   |        |   V   |        |   .    +--------+       |   SIP  |
   | Switch |-------| Switch |   .    |   SIP  |   +-->o Server |
   |        |       |        |   .    | Server |   |   |        |
   +--------+       +--------+   .    |        |   |   +--------+
                                 .    +--------+   |
                                 .                 |
                                 .    +--------+   |
                                 .    |   SIP  |   |
                                 .    | Server |   +-- SIP Trunk
                                 .    |        |
                                 .    +--------+
                                 .
            TDM Model            .              SIP Model
                                 .

The difference is due to the nature of IP; IP allows any number of clients to connect to the trunk. In a TDM world, there is a distinct physical circuit that is bound to a specific upstreadm switch.

The definition posits that, in the TDM world, the important part of the concept of a trunk was the policies, features and functionality that were bound to it - not the fact that it was a physical connection to another switch. For this reason, a SIP trunk is defined entirely by a set of policies, features and functionality that are invoked when SIP requests are sent to that trunk.

2.4.  For Use by Servers

The last key part of the definition is that the SIP trunk is meant to be used by other servers. That is, the entities on the other side of the TCP or UDP connection to the SIP trunk would be another server, not an end user client. This definition is fuzzy, but it is largely a consequence of the contract. The contract requires that the entity sending the request meet the constraints of the contract when sending the request. This typically involves a level of trust and pre-configured agreement that are difficult to put in place for an end-user client.

3.  Identifying SIP Trunks

We propose that SIP trunks be identified by a SIP URI. Furthermore, when requests are sent to a SIP trunk, the SIP trunk URI appear in the Route header field of the request. This rule applies only to requests outside the scope of a dialog. Mid-dialog requests utilize Route headers as defined in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).

The usage of a SIP URI for identifying SIP trunks is natural. The SIP URI provides enough information to connect to the trunk - based on existing procedures in [RFC3263] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.). The user part of the SIP URI provides an infinitely large namespace - allowing a server to have as many trunks as it wishes, and utilize whatever manner of structure it likes for the user part to facilitate request processing. One server might construct the user part as an integer that maps into a database which contains the policies for that trunk. Another server might take the policy definition, represent it in some language, encrypt the result, and place that as the user part of the SIP URI.

Because the user part of the SIP URI provides an infinitely large namespace, a SIP server can have many SIP trunks, while listening for SIP requests on a single UDP or TCP port.

When a server provides a SIP trunk service, the administrator of that server hands out the SIP URI to use for connecting to that trunk. The SIP trunk URI goes hand in hand with the trunk contract. A requestor that send a request using the SIP trunk URI in the Route header, and formatting the request based on the nature of the contract, will receive the agreed-upon processing.

As an example, if provider example.com is offering a SIP trunk for connection to the PSTN, based on the contract described above, and it uses the SIP URI sip:pstn@example.com for its trunk URI, a request sent to that trunk would look like, in part:

INVITE sip:+19739525000@example.com
Route: sip:pstn@example.com
To: sip:+19739525000@example.com

Usage of the Route header field allows for complete separation of the intended target of the request (present in the Request-URI) from the intermediate logic that is to be applied to the request before arriving at that target (identified by the topmost Route URI).

4.  Best Practices for SIP Trunks

Since SIP trunks are meant for interconnection between servers, they SHOULD run over TCP. Authentication SHOULD be done using mutual TLS authentication, with both sides of the trunk providing a TLS certificate.

TODO: might be interesting to recommend some practices for usage of phone numbers, but this might be out of scope here.

5.  Security Considerations

Servers providing SIP trunks will need to authenticate and authorize access to those trunk services. This specification recommends usage of the practices defined and required in RFC 3261 - mutual TLS authentication - for this purpose.

In some cases, the requests sent on SIP trunks can require confidentiality and message integrity. In such cases, usage of mutual authenticated TLS is RECOMMENDED.

6.  IANA Considerations

There are no IANA considerations associated with this specification.

7.  Acknowledgements

I'd like to thank Mohammad Al-Taraireh for his comments on this document.

8.  References

8.1. Normative References

8.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.