RFC 3313
Private Session Initiation Protocol (SIP) Extensions for Media Authorization
Private Session Initiation Protocol (SIP) Extensions for Media Authorization 🎀
Okay bestie, this is RFC 3313 and it's giving networking nerd realness 🤓💖. It was written by W. Marshall, listed as the editor (Ed.), from AT&T. It's in the Informational category, so it's sharing info for the Internet community, not a formal Internet standard 🦋. It's dated January 2003. The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own ✨.
Status of This Memo 📝
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸.
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved 💜.
Abstract 🦋
Okay so the abstract is the big picture 👀. This document explains why we need Quality of Service (QoS) and media authorization, and it defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks 🛡️. Here's the tea: the extension only works in administrative domains, or among federations of administrative domains with previously agreed-upon policies. On top of that, both the SIP proxy authorizing the QoS and the policy control of the underlying network providing the QoS have to belong to that same administrative domain or federation of domains 🔐. No cap, it's very specific.
Table of Contents 📋
1. Scope of Applicability......................................... 2
2. Conventions Used in this Document.............................. 3
3. Background and Motivation...................................... 3
4. Overview....................................................... 4
5. Changes to SIP to Support Media Authorization.................. 4
5.1 SIP Header Extension....................................... 5
5.2 SIP Procedures............................................. 5
5.2.1 User Agent Client (UAC)................................ 6
5.2.2 User Agent Server (UAS)................................ 6
5.2.3 Originating Proxy (OP)................................. 7
5.2.4 Destination Proxy (DP)................................. 7
6. Examples....................................................... 8
6.1 Requesting Bandwidth via RSVP Messaging.................... 8
6.1.1 User Agent Client Side................................. 8
6.1.2 User Agent Server Side................................. 10
7. Advantages of the Proposed Approach............................ 12
8. Security Considerations........................................ 13
9. IANA Considerations............................................ 13
10. Notice Regarding Intellectual Property Rights................. 13
11. Normative References.......................................... 14
12. Informative References........................................ 14
13. Contributors.................................................. 15
14. Acknowledgments............................................... 15
15. Editor's Address.............................................. 15
16. Full Copyright Statement...................................... 161. Scope of Applicability 🌍
Okay so this section is about where this thing actually works 💅. This document defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. It's only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS and the policy control of the underlying network providing the QoS belong to that administrative domain or federation of domains. Furthermore, the mechanism is generally incompatible with end-to-end encryption of message bodies that describe media sessions 🙈. Hard pass on encrypting those bodies, sadly.
This is kind of the opposite of general Internet principles, which separate data transport from applications 😭. So the solution in this document is not applicable to the Internet at large. Despite these limitations, there are specialized deployments that meet the assumptions above and can accept the resulting limitations, and those are useful enough to warrant informational publication of this mechanism ✨. An example would be a closed network that emulates a traditional circuit switched telephone network 📞. This document specifies a private header to make it easier to use in these specialized configurations 🧚.
2. Conventions Used in this Document 🎀
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 RFC 2119 [2] 📚.
3. Background and Motivation 🌈
Okay, real talk, current IP telephony systems kind of assume a perfect world 🥹. They assume there's either an unlimited amount of bandwidth, or that network layer Quality of Service (QoS) is provided without any kind of policy control. But the reality is that end-to-end bandwidth is not unlimited, and uncontrolled access to QoS is, in general, unlikely 😬. The main reason is that QoS gives preferential treatment to one flow at the expense of another. So it's important to have policy control over whether a given flow should have access to QoS 🚦. This will not only enable fairness in general, but can also prevent denial of service attacks 🛡️.
In this document, we're focused on providing QoS for media streams established via the Session Initiation Protocol (SIP) [3] 📞. We assume an architecture that integrates call signaling with media authorization, as shown in the figure below. The solid lines (A and B) show interfaces, and the dotted line (C) shows the QoS enabled media flow 🦋.
+---------+
| Proxy |
+--------->| |
| +---------+
| ^
A)| B) |
| { }
| |
| v
v +------+
+------+ C) | Edge |
| UA |........|router|......
+------+ +------+
Figure 1 - Basic ArchitectureIn this architecture, we assume a SIP UA connected to a QoS enabled network, with an edge router acting as a Policy Enforcement Point (PEP) [6] 🚪. We also assume that a SIP UA that wants QoS starts sessions through a proxy that can interface with the QoS policy control for the data network being used 💌. We'll call that proxy a QoS enabled proxy 👑. The SIP UA needs to present an authorization token to the network in order to get Quality of Service (C) 🎟️. The SIP UA gets this token via SIP (A) from the QoS enabled proxy, using an extension SIP header defined in this document 🧚. The proxy, in turn, talks either directly to the edge router or to a Policy Decision Point (PDP - not shown) [6] to get a suitable authorization token for the UA 🫶.
Examples of access data networks where a QoS enabled proxy could be used include DOCSIS based cable networks and 3rd generation (3G) wireless networks 📶.
4. Overview 🗺️
Here's the step-by-step for a session that needs QoS for its media streams, following the basic architecture above 💅.
The SIP UA sends an INVITE to the QoS enabled proxy. For each resulting dialog, the proxy includes one or more media authorization tokens in all unreliable provisional responses (except 100), in the first reliable 1xx or 2xx response, and in all retransmissions of that reliable response for the dialog 🎫. When the UA requests QoS, it includes the media authorization tokens with the resource reservation 🙌.
A SIP UA may also receive an INVITE from its QoS enabled proxy that includes one or more media authorization tokens 💌. In that case, when the UA requests QoS, it includes the media authorization tokens with the resource reservation too ✨. The resource reservation mechanism is not part of SIP and isn't described within the scope of this document 🤷♀️.
5. Changes to SIP to Support Media Authorization 🛠️
This document defines a private SIP header extension to support a media authorization scheme 🔧. In this architecture, a QoS enabled SIP proxy gives the UA one or more authorization tokens to use in QoS requests 🎟️. The extension lets the QoS enabled SIP proxy authorize network QoS resources 👑.
5.1 SIP Header Extension 💖
A new P-Media-Authorization general header field is defined 🎀. The P-Media-Authorization header field contains one or more media authorization tokens that are to be included in later resource reservations for the media flows associated with the session. In other words, they get passed to an independent resource reservation mechanism, which isn't specified here 🧚. These tokens are used to authorize QoS for the media stream(s) 🔐. The P-Media-Authorization header field is described by the following ABNF [4] 📐:
P-Media-Authorization = "P-Media-Authorization" HCOLON
P-Media-Authorization-Token
*(COMMA P-Media-Authorization-Token)
P-Media-Authorization-Token = 1*HEXDIGTable 1 below extends tables 2 and 3 in [3] for the new header field defined here 📊. For informational purposes, it also includes the relevant entries for standards track extension methods that were published when this document came out 🌸. The INFO, PRACK, UPDATE, and SUBSCRIBE and NOTIFY methods are defined in [11], [9], [12], and [10], respectively 📚.
Where proxy ACK BYE CAN INV OPT REG
P-Media-Authorization R ad o - - o - -
P-Media-Authorization 2xx ad - - - o - -
P-Media-Authorization 101-199 ad - - - o - -
Where proxy INF PRA UPD SUB NOT
P-Media-Authorization R ad - o o - -
P-Media-Authorization 2xx ad - o o - -
Table 1: Summary of header fields.The P-Media-Authorization header field can only be used in SIP requests or responses that can carry a SIP offer or answer 🙅♀️. This naturally keeps the scope of this header field narrow 🥰.
5.2 SIP Procedures 🦋
Okay, this is where the SIP procedures start 👀. This section defines SIP [3] procedures for use in media authorization compatible systems, from the point of view of the authorizing QoS. We're about to get into the details, so stay tuned bestie 💜.
5.2.1 User Agent Client (UAC)
Okay bestie, the initial SIP INVITE, mid-call messages that change network QoS resources, and mid-call changes in call destination all need to get authorized ✨. These messages get sent through the QoS-enabled proxies so they can actually receive that authorization 🔐. To authorize QoS, the QoS-enabled SIP proxy MAY need to peek inside the message bodies that describe the media streams (like SDP) 👀. So it is recommended (where it makes sense for the applicability scope in Section 1 of this document) that those message bodies not be encrypted end-to-end 🫶.
Next, the P-Media-Authorization-Token lives in the P-Media-Authorization header 🎀. The proxy sends it to the UAC for each dialog in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and every retransmission of that reliable response for the dialog 💌.
The UAC should use all the P-Media-Authorization-Tokens from the most recent request/response that had the P-Media-Authorization header when it asks for QoS for the associated media stream(s). This goes for both the initial reservation messages and the refresh ones (like in an RSVP-based reservation system) 🔄. A reservation function in the UAC should turn each string of hex digits into binary and use each result as a Policy-Element, as defined in RFC 2750 [5] (leaving out Length, but keeping P-Type, which is in each token) 🧩. These Policy-Elements would typically hold the authorizing entity and credentials, and they get used in an RSVP request for media data stream QoS resources 💅.
5.2.2 User Agent Server (UAS)
The User Agent Server gets the P-Media-Authorization-Token in an INVITE (or other) message from the QoS-enabled SIP proxy 📨. If the response has a message body describing media streams the UA wants QoS for, it is recommended (where it makes sense for the applicability scope in Section 1 of this document) that this message body not be encrypted end-to-end 🔒.
The UAS should use all the P-Media-Authorization-Tokens from the most recent request/response that had the P-Media-Authorization header when it asks for QoS for the associated media stream(s). This applies to both initial and refresh reservation messages (like in an RSVP-based reservation system) ✨. A reservation function in the UAS should turn each string of hex digits into binary and use each result as a Policy-Element, as defined in RFC 2750 [5] (leaving out Length, but keeping P-Type, which is in each token) 🌸. These Policy-Elements would typically hold the authorizing entity and credentials, and they get used in an RSVP request for media data stream QoS resources 👑.
5.2.3 Originating Proxy (OP)
When the originating QoS-enabled proxy (OP) gets an INVITE (or other) message from the UAC, it authenticates the caller and checks that the caller is allowed to get QoS 🕵️♀️.
Working together with an originating Policy Decision Point (PDP-o), the OP gets and/or makes one or more media authorization tokens 🧚. These hold enough info for the UAC to get the authorized QoS for the media streams 💖. Each media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (leaving out Length, but keeping P-Type, which is in each token), and then turned into a string of hex digits to form a P-Media-Authorization-Token 🎀. The proxy's resource management function may look at the message bodies that describe the media streams (like SDP), in both requests and responses, to decide what QoS to authorize 👀.
For each dialog that comes out of the INVITE (or other) message from the UAC, the originating proxy must add a P-Media-Authorization header with the P-Media-Authorization-Token in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response it sends to the UAC, if that response may cause network QoS changes 🦋. A response with an SDP may cause those changes 🔥.
5.2.4 Destination Proxy (DP)
The Destination QoS-Enabled Proxy (DP) checks that the called party is allowed to get QoS 🌈.
Working together with a terminating Policy Decision Point (PDP-t), the DP gets and/or makes a media authorization token that holds enough info for the UAS to get the authorized QoS for the media streams 💜. The media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (leaving out Length, but keeping P-Type, which is in each token), and then turned into a string of hex digits to form a P-Media-Authorization-Token 🍓. The proxy's resource management function may look at the message bodies that describe the media streams (like SDP), in both requests and responses, to decide what QoS to authorize 🧐.
The Destination Proxy must add the P-Media-Authorization header with the P-Media-Authorization-Token in the INVITE (or other) request it sends to the UAS if that message may cause network QoS changes 💅. A message with an SDP body may cause those changes ✨.
6. Examples 🎀
6.1. Requesting Bandwidth via RSVP Messaging
Here's an example of how the P-Media-Authorization header field can be used together with the Resource Reservation Protocol (RSVP) [7] 🌊. It assumes that an offer shows up in the initial INVITE and an answer shows up in a reliable provisional response [9], which has an SDP description of the media flow 💌.
6.1.1. User Agent Client Side
Figure 2 gives a high-level look at a basic call flow with media authorization from the UAC's point of view 🦋. Some policy interactions were left out to keep it short 🙈.
When a user goes off-hook and dials a phone number, the UAC collects the dialed digits and sends the initial (1)INVITE message to the originating SIP proxy 📞.
The originating SIP proxy (OP) authenticates the user/UAC and forwards the (2)INVITE message to the proper SIP proxy 🫶.
If the call isn't forwarded, the terminating end-point sends a (3)18x response to the initial INVITE via OP 💫. This response includes the negotiated bandwidth requirement for the connection (in the form of an SDP description [8]) 📊.
When OP gets the (3)18x, it has enough info about the end-points, bandwidth, and characteristics of the media exchange 🧠. It starts a Policy-Setup message to PDP-o, (4)AuthProfile 💅.
PDP-o stores the authorized media description in its local store, makes an authorization token that points to this description, and returns the authorization token to OP, (5)AuthToken 🔑.
UAC ER-o PDP-o OP
|(1)INVITE | | | Client Authentication
|------------------------------------------->| and Call Authoriz.
| | | | (2)INVITE
| | | |-------------->
| | | | (3)18x
| | |(4)AuthProfile |<--------------
| | |<--------------|
| | |(5)AuthToken |
| | |-------------->| Auth. Token put into
| | | (6)18x | P-Media-Authorization
|<-------------------------------------------| header extension.
|---(7)PRACK-------------------------------->|
| |--(8)PRACK---->
| |<-(9)200 (PRACK)
|<--(10)200 (PRACK)--------------------------|
| | | |
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(11)RSVP-PATH | |
|----------->| (12)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (13)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(14)RSVP-PATH
| |------------------------------------------------>
| | | |(15)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(16)RSVP-RESV | |
|----------->| (17)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (18)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(19)RSVP-RESV
| |--------------------------------------------------->
| | | |(20)RSVP-RESV
|<----------------------------------------------------------------
| | | |
Figure 2 - Media Authorization with RSVP (UAC)OP puts the authorization token in the P-Media-Authorization header extension of the (6)18x message 🎀.
When the UAC gets the (6)18x message, it stores the media authorization token from the P-Media-Authorization header 💾. Then the UAC acknowledges the 18x message by sending a (7)PRACK message, which gets answered with (10) 200 🙌.
Before sending any media, the UAC asks for QoS by sending an (11)RSVP-PATH message, which includes the P-Media-Authorization-Token it stored earlier as a Policy-Element 🚀.
ER-o, once it gets the (11)RSVP-PATH message, checks the authorization through a PDP-o COPS message exchange, (12)REQ. PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it gave to OP 🧾. If the authorization works out, PDP-o returns an "install" Decision, (13)DEC ✅.
ER-o checks whether the request is admissible, and if admission succeeds, it forwards the (14)RSVP-PATH message 🌸.
Once the UAC gets the (15)RSVP-PATH message from the UAS, it sends the (16)RSVP-RESV message to reserve the network resources 🥰.
ER-o, after it gets the (16)RSVP-RESV message, checks the authorization through a PDP-o COPS message exchange, (17)REQ. PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it gave to OP 🔍. If the authorization works out, PDP-o returns an "install" Decision, (18)DEC 💖.
ER-o checks whether the request is admissible, and if admission succeeds, it forwards the (19)RSVP-RESV message 🦋.
Once the (20)RSVP-RESV message arrives, network resources have been reserved in both directions 🎉👑 no cap, we did it!
6.1.2 User Agent Server Side ✨
okay so Figure 3 gives you the big picture of the call flow from the UAS's side 🎀 It skips a few policy steps to keep things short, so don't panic if something's missing 🙈
UAS ER-t PDP-t DP
| | | | (1)INVITE
| | | |<--------------
| | | | Proxy Authentication
| | | (2)AuthProfile| and Call Authoriz.
| | |<--------------|
| | | (3)AuthToken |
| | |-------------->| Auth. Token put into
| | | (4)INVITE | P-Media-Authorization
|<------------------------------------------| header extension
| (5)18x | | |
|------------------------------------------>| (6)18x
|Copies the RSVP policy object |-------------->
|from the P-Media-Authorization |
|(7)RSVP-PATH | |
|---------->| (8)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (9)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(10)RSVP-PATH
| |-------------------------------------------------->
| | | |(11)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
| (12)RSVP-RESV | |
|---------->| | |
| | (13)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (14)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(15)RSVP-RESV
| |--------------------------------------------------->
| | | |(16)RSVP-RESV
|<---------------------------------------------------------------
| | | |<-(17)PRACK---------
|<--(18)PRACK ------------------------------|
|---(19)200 (PRACK) ----------------------->|
| | | |--(20)200 (PRACK)-->
| | | |Figure 3 - Media Authorization with RSVP (UAS)
Here's the vibe: the destination SIP proxy (DP) already knows the endpoints, the bandwidth, and what the media exchange looks like, so the second it gets the (1)INVITE, it sends a Policy-Setup message over to the terminating Policy Decision Point (PDP-t) 💅
PDP-t stores the authorized media description in its local store 🗂️ It then makes an authorization token that points back to that description and sends the token back to DP. The token gets slipped into the (4)INVITE and forwarded on to the UAS 🦋
Assuming the call isn't forwarded, the UAS sends a (5)18x response to the initial INVITE, and that gets passed back to the UAC. At the same time, the UAS sends a (7)RSVP-PATH message, and this one carries the P-Media-Authorization-Token (the one stored earlier) as a Policy-Element 🎀
Now ER-t gets the (7)RSVP-PATH and double-checks the authorization with a COPS message exchange with PDP-t. PDP-t checks things against the stored authorized media description that's linked to the token it gave DP. If the authorization works out, PDP-t sends back an "install" Decision, the (9)DEC 🔥
ER-t then checks admissibility for the request. If admission succeeds, it forwards the (10)RSVP-PATH message 🌈
Once the UAS gets the (11)RSVP-PATH message, it sends the (12)RSVP-RESV message to reserve the network resources 💖
When ER-t gets the (12)RSVP-RESV, it runs the same kind of check: another COPS exchange with PDP-t, which compares things against the stored media description tied to the token it returned to DP. If that passes, PDP-t sends back an "install" Decision, the (14)DEC ✨
ER-t checks admissibility again, and if it succeeds, it forwards the (15)RSVP-RESV message 🧚
Once the (16)RSVP-RESV message shows up, network resources are reserved in both directions. Iconic! 👑
For completeness, the diagram also shows the (17)PRACK message for the (5) 18x response, plus the (19) 200 response that acknowledges the PRACK 🫶
7. Advantages of the Proposed Approach ✨
Media authorization lets you control how network resources get used, and honestly that's a whole mood 💅 It makes IP Telephony way more robust against denial of service attacks and all kinds of service fraud 🛡️ By using the authorization capability, you can keep track of how many flows there are and how many resources get reserved, so the IP Telephony system stays dependable even when resources are scarce 🌸
8. Security Considerations 💀
Okay, this section is serious, so grab your snack and pay attention 😭
In order to control access to QoS, a QoS enabled proxy should authenticate the UA before giving it a media authorization token. The method and policy for that authentication are outside the scope of this document. It could, for example, be done with standard SIP authentication mechanisms, as described in [3].
Media authorization tokens sent in the P-Media-Authorization header from a QoS enabled proxy to a UA MUST be protected from eavesdropping and tampering. This can, for example, be done through a mechanism such as IPSec or TLS. However, this only gives you hop-by-hop security. If there are one or more intermediaries (for example, proxies) between the UA and the QoS enabled proxy, those intermediaries can see the P-Media-Authorization header field value, which compromises confidentiality and integrity. This enables both theft-of-service and denial-of-service attacks against the UA 😱 So the P-Media-Authorization header field MUST NOT be available to any untrusted intermediary in the clear or without integrity protection. Right now SIP doesn't define a mechanism that satisfies these requirements. Until one exists, proxies MUST NOT send P-Media-Authorization headers through untrusted intermediaries, since those intermediaries might reveal or modify what's in the header. (Quick note: S/MIME-based encryption in SIP isn't available to proxy servers, because proxies aren't allowed to add message bodies.) 🙈
QoS enabled proxies may need to look inside message bodies that describe media streams (SDP, for example). So those message bodies should not be encrypted. The downside is that this stops end-to-end confidentiality of those message bodies, which lowers the overall security you can get 🥺
9. IANA Considerations 🍓
This document defines a new private SIP header for media authorization, P-Media-Authorization. The IANA registered it in the SIP header registry, and the reference is the RFC number of this document 🌈
10. Notice Regarding Intellectual Property Rights 📜
The IETF has been told about intellectual property rights that someone claims apply to some or all of the specification in this document. For more info, check the online list of claimed rights 🔗
11. Normative References 📚
- [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] 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.
- [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
12. Informative References 📖
- [6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
- [7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
- [8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
- [10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
- [11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
- [12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.
13. Contributors 🫶
The following people contributed significantly and were co-authors on earlier versions of this document, so huge thanks to them 💜
Bill Marshall (AT&T), K. K. Ramakrishnan (AT&T), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Juniper Networks), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (Arris), and Keith Kelly (NetSpeak).
14. Acknowledgments 🌷
The Distributed Call Signaling work in the PacketCable project is the work of a large number of people from many different companies 🌍 The contributors want to recognize and thank the following for their help: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications. Dean Willis and Rohan Mahy gave valuable feedback as well 💖
15. Editor's Address 💌
Bill Marshall
AT&T
Florham Park, NJ 07932
EMail: wtm@research.att.com16. Full Copyright Statement 💅✨
Okay bestie, the legal stuff matters too. 🎀 The copyright line says: Copyright (C) The Internet Society (2003). All Rights Reserved.
Here's the gist. You're allowed to copy this document and share it, translated or not. You can also write derivative works that comment on or explain it, or that help people implement it, and you can publish and distribute those too, in whole or in part, with no real restrictions. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work. 🦋
You can't modify this document itself, though. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you're developing Internet standards, where the copyright procedures in the Internet Standards process must be followed, or when you're translating it into a language other than English. 🌸
These permissions are perpetual, so the Internet Society and its successors or assigns won't revoke them. 💜
The document and everything in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Acknowledgement ✨
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶👑
📦 where this page comes from
- ietf: rfc3313 2003-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms