One document matched: draft-rosenberg-sipping-siptrunk-00.txt
SIPPING J. Rosenberg
Internet-Draft Cisco
Intended status: Best Current February 15, 2008
Practice
Expires: August 18, 2008
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.
Copyright Notice
Copyright (C) The IETF Trust (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.
Rosenberg Expires August 18, 2008 [Page 1]
Internet-Draft SIP Trunk February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What is a SIP Trunk? . . . . . . . . . . . . . . . . . . . . . 3
2.1. Request Processing Behaviors . . . . . . . . . . . . . . . 4
2.2. Conditioned on a Contract . . . . . . . . . . . . . . . . 5
2.3. On a Server, not Between . . . . . . . . . . . . . . . . . 5
2.4. For Use by Servers . . . . . . . . . . . . . . . . . . . . 6
3. Identifying SIP Trunks . . . . . . . . . . . . . . . . . . . . 7
4. Best Practices for SIP Trunks . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Rosenberg Expires August 18, 2008 [Page 2]
Internet-Draft SIP Trunk February 2008
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] systems. A SIP trunk has been used to describe all of the
following:
o A service provided by service providers to enterprises, used for
the purpose of interconnection to the PSTN, as a replacement for
circuit based connectivity.
o 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.
o 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.
Rosenberg Expires August 18, 2008 [Page 3]
Internet-Draft SIP Trunk February 2008
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].
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] containing presence documents. Only a
certain set of presence document extensions are supported; in
particular, the documents need to comply with [RFC4480] but the
sphere element is not utilized and will be discarded silently if
Rosenberg Expires August 18, 2008 [Page 4]
Internet-Draft SIP Trunk February 2008
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]. 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 2.
Rosenberg Expires August 18, 2008 [Page 5]
Internet-Draft SIP Trunk February 2008
.
.
.
Trunk . +--------+
. | SIP |
| . | Server |
| . | |
| . +--------+
+--------+ | +--------+ . +--------+
| | V | | . +--------+ | SIP |
| Switch |-------| Switch | . | SIP | +-->o Server |
| | | | . | Server | | | |
+--------+ +--------+ . | | | +--------+
. +--------+ |
. |
. +--------+ |
. | SIP | |
. | Server | +-- SIP Trunk
. | |
. +--------+
.
TDM Model . SIP Model
.
Figure 2: Trunk Models
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.
Rosenberg Expires August 18, 2008 [Page 6]
Internet-Draft SIP Trunk February 2008
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].
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]. 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).
Rosenberg Expires August 18, 2008 [Page 7]
Internet-Draft SIP Trunk February 2008
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
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
Rosenberg Expires August 18, 2008 [Page 8]
Internet-Draft SIP Trunk February 2008
8.2. Informative References
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)", RFC 4480, July 2006.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
Author's Address
Jonathan Rosenberg
Cisco
Edison, NJ
US
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires August 18, 2008 [Page 9]
Internet-Draft SIP Trunk February 2008
Full Copyright Statement
Copyright (C) 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rosenberg Expires August 18, 2008 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 14:58:41 |