RFC 9409

The 'sip-trunking-capability' Link Relation Type

📅 published July 2023, from ietf

okay bestie, this is an IETF doc (Internet Engineering Task Force) and it's the spec for a brand-new link relation type. Here's the title block so you know who's behind it:

  • Authors: K. Inamdar (Unaffiliated), S. Narayanan (Cisco), D. Engi (Cisco), G. Salgueiro (Cisco) 💅
  • Category: Informational 🦋
  • Date: July 2023 🌸
  • ISSN: 2070-1721
  • Obsoletes / Updates: none listed in its header ✨

Abstract 💖

so this Informational doc defines the 'sip-trunking-capability' link relation type 🔥. enterprise telephony networks that use Session Initiation Protocol (SIP) can use it to grab a SIP trunking capability set document. that document holds the capabilities and configuration requirements of an Internet Telephony Service Provider (ITSP) 🧚. the whole point is letting enterprise networks and the ITSP peer with each other smoothly, no drama 💅✨.

Status of This Memo 🌈

ngl this part is kind of a formality, but it's important: this document is not an Internet Standards Track specification. it's published for informational purposes only 📚.

it IS a product of the IETF, and it represents the consensus of the IETF community 🫶. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, though. see Section 2 of RFC 7841 for that 🙈.

if you want the latest status, any errata, or a way to give feedback, check out https://www.rfc-editor.org/info/rfc9409 💜.

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. read them carefully, bestie, because they explain your rights and restrictions for this doc. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Revised BSD License ⚖️🎀.

Table of Contents 📋

  • 1. Introduction
  • 2. The 'sip-trunking-capability' Link Relation Type
  • 3. Example Usage
  • 4. IANA Considerations
  • 5. Security Considerations
  • 6. References
    • 6.1. Normative References
    • 6.2. Informative References
  • Acknowledgements
  • Authors' Addresses

1. Introduction 🦋

okay so [RFC8288] is the one that defines how to show relationships between resources on the Web 🕸️. this doc specifies the 'sip-trunking-capability' link relation type following the rules of RFC 8288. links with this relation type can swap capability info between potential peer devices 💜. if systems need extra parameters and configuration to negotiate communication, a well-known URI can deliver the info to potential peers. that includes machine-readable instructions and the parameters needed for peering 🎀.

the 'sip-trunking-capability' link relation type may be used on web resources hosted by ITSPs. it gives them a structured, detailed capability set document ✨. the capability set document [SIP-AUTO-PEER] packs up a set of an ITSP's characteristics. when enterprise telephony network devices retrieve it, they can set up SIP [RFC3261] trunking between the two networks automatically 🤖💖. iconic.

the ITSP hosts a capability set document on web resources. there are two ways peers can find it. the ITSP can preconfigure a unique location and hand it to each peer 🍓. or there can be one centrally published resource that generates the capability set document on the fly, based on one or more Uniform Resource Identifiers (URIs) [RFC3986] that the peering device picks 🦋.

the capability set document describes the configuration parameters needed to successfully set up SIP trunking between an enterprise and an ITSP network 💅. it's made of structured, machine-readable parameters that can be turned into configuration data to meet the ITSP's communication requirements ✨. why does an enterprise telephony network need to grab this from an ITSP? it's all explained in "Automatic Peering for SIP Trunks" [SIP-AUTO-PEER] 📚.

3. Example Usage 🧚

this section shows one possible way to use the 'sip-trunking-capability' relation type 💜. the enterprise network device asks the well-known URI on the ITSP for the location of the capability set document, using the WebFinger protocol [RFC7033] 🔍. the examples have line breaks and indentation so they're easier to read 🎀.

GET /.well-known/webfinger?
   resource=acct%3Atrunkent1456%40example.com&
   rel=sip-trunking-capability
   HTTP/1.1
Host: ssp1.example.com

the location of the capability set document comes back in the "href" attribute 🫶.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
{
   "subject" : "acct:trunkent1456@example.com",
   "links" :
   [
      {
         "rel" : "sip-trunking-capability",
         "href" : "https://capserver.ssp1.example.com/capdoc.json"
      }
   ]
}

the ITSP can use an auth framework like OAuth 2.0 [RFC6749] to figure out who the enterprise telephony network is, so it can hand over the right capability set document 🔐👑.

4. IANA Considerations 👑

IANA registered the 'sip-trunking-capability' link relation in the "Link Relation Types" registry, like this 💅:

Relation Name:  sip-trunking-capability

Description:  Refers to a capability set document that defines
   parameters or configuration requirements for automated peering and
   communication-channel negotiation of the Session Initiation
   Protocol (SIP).

Reference:  RFC 9409

5. Security Considerations 🙈

⚠️ okay bestie, read this part carefully. it's serious.

the 'sip-trunking-capability' relation type is not known to introduce any new security issues beyond the ones already covered in RFC 8288 for generic web-linking mechanisms. still, it is recommended to exercise caution when publishing potentially sensitive capability information over unencrypted or unauthenticated channels 🚨. more security recommendations are laid out in the capability set document definition. for the full picture, see the Security Considerations section in "Automatic Peering for SIP Trunks" [SIP-AUTO-PEER] 💀🔒.

6. References 📚

6.1. Normative References 💜

[RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
           DOI 10.17487/RFC8288, October 2017,
           <https://www.rfc-editor.org/info/rfc8288>.

6.2. Informative 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,
           DOI 10.17487/RFC3261, June 2002,
           <https://www.rfc-editor.org/info/rfc3261>.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66,
           RFC 3986, DOI 10.17487/RFC3986, January 2005,
           <https://www.rfc-editor.org/info/rfc3986>.

[RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
           RFC 6749, DOI 10.17487/RFC6749, October 2012,
           <https://www.rfc-editor.org/info/rfc6749>.

[RFC7033]  Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
           "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
           2013, <https://www.rfc-editor.org/info/rfc7033>.

[SIP-AUTO-PEER]
           Inamdar, K., Narayanan, S., and C. F. Jennings, "Automatic
           Peering for SIP Trunks", Work in Progress, Internet-Draft,
           draft-ietf-asap-sip-auto-peer-07, 13 January 2023,
           <https://datatracker.ietf.org/doc/html/draft-ietf-asap-
           sip-auto-peer-07>.

Acknowledgements 🫶

this doc came out of the discussions in the ASAP Working Group, especially the super detailed, thoughtful comments from Paul Jones, Marc Petit-Huguenin, Mark Nottingham, Cullen Jennings, Jonathan Rosenberg, Jon Peterson, Chris Wendt, Jean Mahoney, and Murray Kucherawy 🌈. extra thanks to Joe Clarke, Tim Bray, Christopher Wood, Dan Romascanu, David Dong, Éric Vyncke, Robert Wilton, and Lars Eggert for reviewing it and sharing feedback 💖.

Authors' Addresses 💌

Kaustubh Inamdar
Unaffiliated
Email: kaustubh.ietf@gmail.com


Sreekanth Narayanan
Cisco
Email: sreenara@cisco.com


Derek Engi
Cisco
Ann Arbor, MI
United States of America
Phone: +1 919 392 7966
Email: deengi@cisco.com


Gonzalo Salgueiro
Cisco
7200-12 Kit Creek Rd.
Research Triangle Park, NC 27709
United States of America
Phone: +1 919 392 3266
Email: gsalguei@cisco.com
📦 where this page comes from