Our previous tutorial investigated the work that the IETF has undertaken to support the transmission of real time information over Internet Protocol (IP)-based internetworks, including the worldwide Internet. We discovered that this work falls within the Real-Time Applications and Infrastructure research Area. A working group within that Area, called SPEERMINT (which stands for Session PEERing for Multimedia INTerconnect), is investigating the concepts of IP network peering in general, and peering of networks that use the Session Initiation Protocol (SIP) in particular (see http://www.ietf.org/html.charters/speermint-charter.html). This working group has produced a number of Internet Draft documents that describe their work, including one that defines the SPEERMINT Peering Architecture, which we will examine in this tutorial (see http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-02.txt). (As before, it should be noted that Internet Drafts are works in progress, and are subject to revision, until such time that they are approved by the Working Group and other IETF authorities as Request for Comments or RFC documents.)
To begin, let's look at what this architecture is designed to accomplish. To quote from the SPEERMINT working group charter:
SPEERMINT focuses architectures to identify, signal, and route delay-sensitive (real-time) communication sessions. These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks. Where these domains peer, or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations. Note that the term "peering" is used here to refer to the interconnection between application layer entities such as SIP servers, as opposed to interconnection at the IP network layer.
In other words, the SPEERMINT work goes beyond the mere interconnection of networks, and extends into higher layer (i.e., OSI Layers 57) functions, including signaling, trust (or authentication), and security. Note that these issues are perhaps not so great a concern for users of the Public Switched Telephone Network (PSTN), as signaling, authentication, and security are functions that the network has dealt with for many decades. But for those enterprises that are moving out from under the PSTN "security blanket," new ways must be found to provide these necessary functions.
In addition, the SPEERMINT architecture identifies a number of possible peering scenarios:
- Enterprise to enterprise across the public Internet
- Enterprise to service provider across the public Internet
- Service provider to service provider across the public Internet
- Enterprise to enterprise across a private Layer 3 network
- Enterprise to service provider across a private Layer 3 network
- Service provider to service provider across a private Layer 3 network
The architecture itself defines three layers, a Location Function (LF), a Signaling Function (SF) and a Media Function (MF). Recall from our previous tutorial that the SPEERMINT work is focused on what is called Layer 5 (Session) peering, in which the SIP methods are employed. This being the case, we can make the assumption that the lower layer functions (e.g., OSI Layer 14) are handled by other network processes, and that the focus of the SPEERMINT architecture and functionality is at OSI Layers 57, as also noted above. These architectural functions are described as follows:
The Location Function (LF) develops call routing data (CRD) by discovering the Signaling Function (SF), and end user's reachable host (IP address and port). Before this process occurs, however, the provider that is initiating the call determines if the target (destination) address is one that can be completed without going outside that provider's network (or the provider's federation, if a multilateral peering relationship has been established). If that provider determines that an extra-network call is required, then the LF function is employed to determine the call routing data. Examples of this function include ENUM (Electronic Numbers), routing tables, SIP Domain Name Service (SIP DNS), and the SIP Redirect Server. We will explore some of these functions in greater detail in future tutorials.
The Signaling Function (SF) performs routing of SIP messages, optionally performs termination and re-initiation of calls, also optionally implements security and policies on SIP messages, and assists in discovery/exchange of parameters to be used by the Media Function (MF). The routing of SIP messages is performed by SIP proxies. The optional termination and re-initiation of calls is performed by Back to Back User Agents (B2BUAs), that are described in RFC 3261, section 6 (see ftp://ftp.rfc-editor.org/in-notes/rfc3261.txt). The SF may also perform additional functions such as Session Admission Control, SIP denial of service (DoS) protection, SIP topology hiding, SIP header normalization, and SIP security, privacy, and encryption.
The Media Function (MF) performs media related functions such as media transcoding and media security implementation between two SIP providers. An example of this function would be the transformation of a voice payload from one encoding, such as G.711, to another, such as EvRC (Enhanced variable rate codec, which is used with CDMA wireless networks).
With this foundation insight into a peering architecture, our next tutorial will dig deeper, and examine the actual messages that are exchanged between these layers in order to complete the end-to-end connection.
Copyright Acknowledgement: © 2006 DigiNet ® Corporation, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.