RFC 6432

RFC 6432: Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses 🦋

okay bestie, let's get into RFC 6432 💅 Here's the title block tea ✨:

• Number: RFC 6432, from the Internet Engineering Task Force (IETF) 🌸
• Authors: R. Jesske and L. Liess, both at Deutsche Telekom 💖
• Category: Standards Track, which means it's a real protocol spec 👑
• ISSN: 2070-1721
• Date: November 2011 🍓
• Obsoletes / Updates: the header doesn't list any, so it doesn't obsolete or update any other RFCs 🧚

---

Abstract ✨

okay so SIP (Session Initiation Protocol) has a Reason header field that's allowed in responses 🎀 RFC 3326 talks about it in general, but it never says which response codes it's for 🙈 Meanwhile, people were already putting failure-related Q.850 [Q.850] cause codes in that header on SIP responses to INVITE requests that got gatewayed to Public Switched Telephone Network (PSTN) systems 📞 This document is the official, normative spec for doing that properly 💜

Status of This Memo

This is an Internet Standards Track document 👑

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ More info on Internet Standards lives in Section 2 of RFC 5741 📚

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6432 🔥

Copyright Notice

Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙏 Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚠️

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Without 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, except to format it for publication as an RFC or to translate it into languages other than English 💅

Table of Contents 🗂️

1. Overview ........................................................2
2. Terminology .....................................................2
3. Applicability ...................................................3
4. Security Considerations .........................................3
5. Acknowledgments .................................................3
6. Normative References ............................................3

1. Overview 🌸

okay so the Reason header field in SIP responses is covered in general by RFC 3326 [RFC3326], but no particular response code gets its own rules 🙈 Still, existing deployments were already carrying failure-related Q.850 [Q.850] cause codes in SIP responses to INVITE requests that got gatewayed to PSTN systems 📞 This document normatively describes using the Reason header field in SIP responses to carry Q.850 [Q.850] cause codes 💖

2. Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] ✨

This document uses terms from [RFC3261] 🧚

3. Applicability 🦋

okay so this is where the rules get real 💅 This document lets SIP responses carry Reason header fields like this:

Any SIP Response message, with the exception of a 100 (Trying), MAY contain a Reason header field with a Q.850 [Q.850] cause code. 🔥

The Reason header field isn't needed in 100 (Trying) responses, since those get sent hop by hop, not end to end 🫶 SIP responses with Reason header fields carrying values other than Q.850 [Q.850] cause codes are outside the scope of this document 🙈

4. Security Considerations 🔐

This spec allows the Reason header field containing Q.850 [Q.850] cause codes in responses 💜 Having that header in a response doesn't change how the response gets treated 🫢 But wrong info could be a real problem: a bad Q.850 [Q.850] cause code could, for example, make an announcement system play the wrong message 💀 To avoid that kind of chaos, it is RECOMMENDED that this header field be protected by a suitable integrity mechanism 🚨 Transport- or network-layer hop-by-hop security mechanisms, like Transport Layer Security (TLS) or IPsec with appropriate cipher suites, can meet this requirement 🔒

5. Acknowledgments 🫶

Huge thanks to Gonzalo Camarillo and Mary Barnes for the detailed review of this document 👑

Thanks also to Paul Kyzivat, Mary Barnes, John Elwell, Keith Drage, and Thomas Belling, who gave helpful comments, feedback, and suggestions 💖

6. Normative References 📚

[Q.850]    "Usage of cause and location in the Digital Subscriber
           Signalling System No. 1 and the Signalling System No. 7
           ISDN User Part", ITU Recommendation Q.850, May 1998.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[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.

[RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
           Header Field for the Session Initiation Protocol (SIP)",
           RFC 3326, December 2002.

Authors' Addresses 💌

Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt  64307
Germany

Phone: +4961515812766
EMail: r.jesske@telekom.de


Laura Liess
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt  64307
Germany

Phone: +4961515812761
EMail: L.Liess@telekom.de