Our two previous peering tutorials discussed the SPEERMINT Requirements and the SPEERMINT Architecture, both developed by the Session PEERing for Multimedia INTerconnect (SPEERMINT) working group within the Internet Engineering Task Force (IETF). In those articles, we discovered that the focus of this working group is on what they call Layer 5 (or Session) Peering, in which two service providers establish a peering relationship that utilizes the Session Initiation Protocol (SIP) call signaling procedures.
We also learned that the SPEERMINT Architecture draft document (see http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-02.txt) defines three functional layers:
- Location Function (LF): that develops call routing data (CRD), by discovering the Signaling Function (SF), and end user’s reachable host (IP address and port).
- Signaling Function (SF): that 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).
- Media Function (MF): that performs media related functions such as media transcoding and media security implementation between two SIP providers.
In order for that peering relationship to be established, the two networks must communicate with each other, indicating that a connection is desired. The Architecture document also includes a sequence of call procedures, describing how a call from an end user in the initiating peer establishes a call to an end user in the receiving peer:
- Analysis of a target address. Note that if the target address represents an intra-VSP (voice service provider—an entity that provides transport of SIP signaling to its customers) resource, we go directly to step 4.
- Discovery of the receiving peering point address
- Enforcement of authentication and other policy
- Discovery of end user address
- Routing of SIP messages
- Session establishment
- Transfer of media
- Session termination
The Architecture document discusses the Target Address Analysis (step 1, above) in section 5.1.1. This analysis is required to determine if the call should be terminated inside or outside of the network in question. If the target address is inside the network, then that network (through its own routing procedures) should be able to complete the call. If the target address is outside the network, then the call routing data is resolved by using the Location Function (LF), which might employ the ENUM (Electronic Numbering database), a routing table, or a SIP function, such as Domain Name Service (DNS) or Redirect, to resolve the address.
After the target address is analyzed (which is really an internal network issue, and beyond the scope of the inter-network-centric SPEERMINT work), the Message Flows draft document further elaborates on these call procedures by describing the message flow phases. Five phases of message flows are detailed in Section 7 of that document (see http://www.ietf.org/internet-drafts/draft-ietf-speermint-flows-01.txt). These five phases provide a high-level overview of the processes involved in setting up a call:
- Discovery Phase: queries the Location Function, which would typically implement a ENUM/DNS or redirect server, to determine the next phase in the message flow.
- Policy Exchange Phase: uses the SIP SUBSCRIBE command (described in RFC 3265, ftp://ftp.rfc-editor.org/in-notes/rfc3265.txt) to send a request to obtain the destination’s peering policy event package.
- Security Establishment Phase: after the originating proxy receives the policy event package, the security policy information is extracted, and its instructions followed, in order to satisfy the security requirements for this peering relationship.
- Signaling Exchange Phase: this phase follows standard SIP signaling procedures, such as the familiar INVITE, TRYING, RINGING, OK, ACK sequence that is typically used to establish a call.
- Media Exchange Phase: this phase is negotiated and established during the signaling exchange phase, and also follows standard SIP procedures. This element supports two-way communication, such as Real Time Protocol (RTP) media exchanges.
Once again, it should be pointed out these descriptions come from Internet Draft documents, which are just that—drafts—and as such, are subject to revision as they move through the IETF’s standardization process. Even with that disclaimer, however, it is clear that the SPEERMINT working group has made impressive progress toward the goal of defining standard procedures for the interconnection of peering networks. Our next tutorial will continue this investigation, and will dig deeper into the subject that was noted in the Discovery phase: address analysis or telephone-number-to-IP-address translation, which use ENUM and other procedures.
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.