RFC 5486

Session Peering for Multimedia Interconnect (SPEERMINT) Terminology

📅 published March 2009, from ietf

RFC 5486: Session Peering for Multimedia Interconnect (SPEERMINT) Terminology 🎀

Okay bestie, this is RFC 5486 💅 Its title is Session Peering for Multimedia Interconnect (SPEERMINT) Terminology, and it came out of the Network Working Group in March 2009 ✨

The authors are D. Malas, Ed. from CableLabs and D. Meyer, Ed., whose line doesn't list an organization 🫶 The category is Informational, which means it's here to give info, not to be a standard. And it doesn't obsolete or update any other RFCs, since the header doesn't list any. 🦋

Status of This Memo ✨

This memo gives information to the Internet community. It is not an Internet standard of any kind 💜 It can be distributed freely, with no limits.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stand on the publication date of this document (http://trustee.ietf.org/license-info). Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🎀

This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who hold the copyright on some of that material may not have given the IETF Trust permission to allow changes to it outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸

Abstract 🦋

This document defines the terminology we use when we describe Session PEERing for Multimedia INTerconnect (SPEERMINT). It's the vocab list for the whole thing 📖✨

Table of Contents 🌈

   1. Introduction ....................................................2
   2. SPEERMINT Context ...............................................3
   3. General Definitions .............................................4
      3.1. Signaling Path Border Element ..............................4
      3.2. Data Path Border Element ...................................4
      3.3. Session Establishment Data .................................4
      3.4. Call Routing ...............................................5
      3.5. PSTN .......................................................5
      3.6. IP Path ....................................................5
      3.7. Peer Network ...............................................5
      3.8. Service Provider ...........................................5
      3.9. SIP Service Provider .......................................6
   4. Peering .........................................................6
      4.1. Layer 3 Peering ............................................6
      4.2. Layer 5 Peering ............................................6
           4.2.1. Direct Peering ......................................7
           4.2.2. Indirect Peering ....................................7
           4.2.3. On-Demand Peering ...................................7
           4.2.4. Static Peering ......................................7
      4.3. Functions ..................................................7
           4.3.1. Signaling Function ..................................7
           4.3.2. Media Function ......................................8
           4.3.3. Look-Up Function ....................................8
           4.3.4. Location Routing Function ...........................8
   5. Federations .....................................................8
   6. Security Considerations .........................................9
   7. Acknowledgments .................................................9
   8. Informative References .........................................10

1. Introduction ✨

Okay so, the phrase "Voice over IP Peering" (VoIP Peering) has been used for ages to describe a whole bunch of stuff about connecting service provider networks, and about delivering Session Initiation Protocol (SIP [2]) call termination across those connections 📞

It's gotten kinda messy, though, because "peering" gets used in different contexts to mean interconnection at different levels of a protocol stack 😭 Session Peering for Multimedia Interconnect is all about how to identify and route real-time sessions (like VoIP calls) at the session layer. It doesn't (necessarily) cover swapping packet-routing data or media sessions. So "layer 5 network" here means the link between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). From here on, "peering" just means a layer 5 interconnection 🫶

This document brings in standard terminology for describing real-time session peering. Heads up, though: even though it's mostly aimed at the VoIP peering case, the terms also work for service providers that peer using SIP signaling (these are defined as SIP Service Providers; see Section 3.9) for non-voice or quasi-real-time stuff like instant messaging 💬

Here's how the rest of the doc is laid out: Section 2 gives the general context for the Session PEERing for Multimedia INTerconnect working group (SPEERMINT). Section 3 gives the general definitions for real-time, SIP-based communication, focusing first on the VoIP peering case. Section 4 defines the terms for the different forms of peering. And finally, Section 5 introduces federations 🌈

2. SPEERMINT Context 💅

SPEERMINT gives us a peering framework built on the building blocks of existing IETF-defined protocols like SIP [2] and ENUM [4]. The SPEERMINT working group describes how those protocols get used in peering, but it doesn't redefine the input or output variables needed to create Session Establishment Data (SED), or how that data gets used during peering. Check Section 3.3 for more on SED and its main variables, like Uniform Resource Identifiers (URIs) [3] and E.164 telephone numbers [5] 🧚

For example, SPEERMINT isn't limited to telephone numbers, but an E.164 number can be used as a key in an E.164-to-URI mapping with ENUM. That mapping involves looking up Naming Authority Pointer (NAPTR) records in the DNS, and the result is a SIP URI. The process for deriving that info is already defined in [4], and SPEERMINT uses it as a building block for SPEERMINT SED, which the later call routing depends on 💖 Notably, the call-routing step doesn't depend on there being an E.164 number. The URI from an ENUM query might not even contain numbers of any type anymore! The SIP URI can also be advertised in other ways, like on a web page 🌸

Last thing: the word "call" is being used here in the most general sense, which means call routing and session routing are used interchangeably ✨

3. General Definitions 🎀

3.1. Signaling Path Border Element 💜

A signaling path border element (SBE) sits on the administrative border of a domain, and that's where inter-domain session layer messages flow through. It usually handles signaling functions like protocol inter-working (for example, H.323 to SIP), identity and topology hiding, and Session Admission Control for a domain 🔥

3.2. Data Path Border Element 🦋

A data path border element (DBE) sits on the administrative border of a domain, and that's where the media for an inter-domain session flows through. It usually handles media-related stuff like deep packet inspection and modification, media relay, and firewall-traversal support. The SBE can control the DBE 👑

3.3. Session Establishment Data 💅

Session Establishment Data, or SED, is the data used to route a call to the next hop linked to the called domain's ingress point. A domain's ingress point might be, for example, the location derived from different types of DNS records (NAPTR, SRV, or A record) [1] that came from resolving the SIP URI 🫶

More specifically, SED is the set of parameters the outgoing SBEs need to finish the call, and it may include:

  • A destination SIP URI
  • A SIP proxy or ingress SBE to send the INVITE to, including:
    • Fully Qualified Domain Name (FQDN)
    • Port
    • Transport Protocol (UDP [8], TCP [9], and TLS [7])
  • Security parameters, including:
    • TLS certificate to use
    • TLS certificate to expect
    • TLS certificate verification setting
  • Optional resource control parameters such as:
    • Limits on the total number of call initiations to a peer
    • Limits on SIP transactions per second

3.4. Call Routing 🌈

Call routing is the set of processes and rules used to route a call, plus any mid-dialog SIP requests that come after, to their proper (SIP) destination. More broadly, you can think of call routing as the set of processes and rules used to route a real-time session to where it terminates ⭐

3.5. PSTN 📞

PSTN stands for the Public Switched Telephone Network. More specifically, it's the collection of interconnected, circuit-switched, voice-oriented public telephone networks, both commercial and government-owned 🍓 Generally, PSTN terminals are addressed with E.164 numbers, but some dial-plans (like emergency services dial-plans) might not use E.164 numbers directly 🙈

3.6. IP Path 💖

For this document, an IP path is defined as a sequence of zero or more IP router hops. Yes, zero counts! 🧚

3.7. Peer Network 🌸

This document defines a peer network as the set of SIP user agents (UAs) (customers) that belong to a single administrative domain and can be reached over some IP path. Such a peer network may also include end-users located on the PSTN (and so may be interconnected with the PSTN too), as long as they're also reachable over some IP path 🫶

3.8. Service Provider ✨

A Service Provider (SP) is defined as an entity that provides layer 3 (IP) transport of SIP signaling and media packets. Example services include, but aren't limited to, Ethernet Private Line (EPL), Frame Relay, and IP Virtual Private Network (VPN). An Internet Service Provider (ISP) is one example 💅

3.9. SIP Service Provider 👑

A SIP Service Provider (SSP) is an entity that provides session services using SIP signaling to its customers. If the SSP is also a function of the SP, it may also provide media streams to its customers. An SSP like this can additionally be peered with other SSPs, and it may also interconnect with the PSTN 🔥 An SSP may also be called an Internet Telephony Service Provider (ITSP). ITSP and SSP get used interchangeably a lot, but this document and other subsequent SIP peering-related documents should use the term SSP, because SSP more accurately shows that SIP is the underlying layer 5 signaling protocol 🎀

4. Peering ✨

okay so "peering" is one of those terms everyone argues about lol 💅 but the general vibe is that two operationally independent service providers agree to interconnect with each other. It can be settlement-free or not, and either way they're working out reciprocal arrangements 🤝

this doc splits peering into two flavors, layer 3 peering and layer 5 peering. let's get into it 🦋

4.1. Layer 3 Peering

layer 3 peering is when two providers' networks connect so they can swap IP packets that are headed for one (or both) of the peer's networks. it's pretty much agnostic to the IP payload 🎀 and it's usually done with a routing protocol like the Border Gateway Protocol (BGP) [6] to trade the routing info they need.

there's also a more operational take: the peers exchange only customer routes, so any traffic between them ends up on one of the peers' networks or on the peer's customer's network 🌸

4.2. Layer 5 Peering

layer 5 (session) peering is when two SSPs connect to route real-time (or quasi-real-time) call signaling between their customers, using SIP methods. it can be direct or indirect (see Section 4.2.1 and Section 4.2.2 below). fyi the media streams tied to this signaling (if there are any) are not locked into following the same set of IP paths 🦋

4.2.1. Direct Peering

direct peering is when two SSPs peer without using an intervening layer 5 network 💜

4.2.2. Indirect Peering

indirect (or transit) peering is when a signaling and media path, or just a signaling path, gets set up through one (or more) layer 5 transit network(s) 🛤️ in this case it's generally required that a trust relationship is established between the originating SSP and the transit SSP on one side, and between the transit SSP and the termination SSP on the other side 🤝

4.2.3. On-Demand Peering

SSPs are said to peer on-demand when they can exchange SIP traffic with no pre-association at all before a real-time transaction (like a SIP message) goes between the domains 🚀 any info that needs to be shared for peering can be learned through a dynamic protocol mechanism. on-demand peering can happen as direct or indirect.

4.2.4. Static Peering

SSPs are said to peer statically when pre-association between the providers is required before any real-time transaction (like a SIP message) can start 🔒 static peering can happen as direct or indirect. an example is a federation 👑 each of the peers in the federation has to first agree on a common set of rules and guidelines for peering, so they pre-associate with each other before initiating session requests.

4.3. Functions

the following are terms for the functions needed for peering 🧚

4.3.1. Signaling Function

the Signaling Function (SF) does the routing of SIP requests for establishing and maintaining calls, and helps with discovering or exchanging the parameters the Media Function (MF) will use 📞 the SF is a capability of SIP processing elements like SIP proxies, SBEs, and user agents.

4.3.2. Media Function

the Media Function (MF) handles media-related stuff like media transcoding and media security implementation between two SSPs 🎧 the MF is a capability of SIP-session-associated media end-points like DBEs and user agents.

4.3.3. Look-Up Function

the Look-Up Function (LUF) figures out, for a given request, the target domain it should be routed to 🔍 examples of a LUF are an ENUM [4] look-up, or a SIP INVITE request to a SIP proxy that gives redirect responses for peers.

in some cases, some entity (usually a 3rd party or federation) helps the originating SSP out by providing this function 🫶 the assisting entity may give info about direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary.

4.3.4. Location Routing Function

the Location Routing Function (LRF) works out, for the target domain of a given request, where the SF is located in that domain, and optionally develops other SED needed to route the request to that domain 🗺️ an example of the LRF may be applied to either example in Section 4.3.3. once the ENUM response or SIP 302 redirect comes back with the destination's SIP URI, the LRF must derive the destination peer's SF from the FQDN in the domain portion of the URI ✨

in some cases, some entity (usually a 3rd party or federation) provides peering assistance to the originating SSP by providing this function 🌈 the assisting entity may give info about direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary.

5. Federations 👑

a federation is a group of SSPs that agree to exchange calls with each other via SIP. they also agree on a set of administrative rules for those calls (settlement, abuse-handling, etc.) and on specific rules for the technical details of the peering 💅

the following gives examples of rules that the peers of a federation may agree to and enforce on all participants:

  • Common domain for all federation peers (e.g., bob@peer1.federation.example.com)
  • Codec rules (e.g., all peers must use the ITU-T G.711 codec [10])
  • Authentication preference (e.g., all peers must use TLS when requesting to establish sessions with other peers)
  • Transport protocol (e.g., all peers must use TCP)
  • SIP address resolution mechanisms (e.g., all peers must use ENUM for resolving telephone numbers to SIP URIs)

finally, note that an SSP can be a member of:

  • No federation (e.g., the SSP has only bilateral peering agreements)
  • A single federation
  • Multiple federations

also, an SSP can have any combination of bilateral and multilateral (i.e., federated) peers 🦋

6. Security Considerations 🚨

this document introduces no new security considerations. however, it is important to note that session peering, as described in this document, has a wide variety of security issues that should be considered in documents addressing both protocol and use-case analysis. this is a big deal, bestie, so please don't skip it 😭

7. Acknowledgments 🫶

many of the definitions were gleaned from detailed discussions on the SPEERMINT, ENUM, and SIPPING mailing lists. Scott Brim, John Elwell, Mike Hammer, Eli Katz, Gaurav Kulshreshtha, Otmar Lendl, Jason Livingood, Alexander Mayrhofer, Jean-Francois Mule, Jonathan Rosenberg, David Schwartz, Richard Shockey, Henry Sinnreich, Richard Stastny, Hannes Tschofenig, Adam Uzelac, and Dan Wing all made valuable contributions to early versions of this document 💖 Patrik Faltstrom also made many insightful comments to early versions of this document 👑

8. Informative References 📚

  • [1] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [2] 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.
  • [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
  • [4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
  • [5] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, February 2005.
  • [6] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
  • [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [8] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
  • [9] Postel, J., "DoD standard Transmission Control Protocol", RFC 761, January 1980.
  • [10] ITU Recommendation G.711 (11/88) - Pulse code modulation (PCM) of voice frequencies.

Authors' Addresses 💌

Daryl Malas (editor)
CableLabs
858 Coal Creek Circle
Louisville, CO  80027
USA
EMail: d.malas@cablelabs.com

David Meyer (editor)
EMail: dmm@1-4-5.net

that's the whole thing, bestie 🌈💜✨

📦 where this page comes from