RFC 3603
Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
RFC 3603 🎀 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
Okay bestie, here's the paperwork tea ☕
- Series: Network Working Group
- Number: Request for Comments: 3603
- Authors: W. Marshall, Ed. (AT&T) and F. Andreasen, Ed. (Cisco)
- Category: Informational
- Date: October 2003
- Obsoletes/Updates: The title block doesn't list anything this one obsoletes or updates 💅
Status of this Memo ✨
This memo gives information to the Internet community. It is not a standard of any kind, and it doesn't specify an Internet standard. Distribution is unlimited 🦋
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract 🌈
Okay so, the goal is to offer residential phone service at a huge scale across different domains 📞. For that to work, trusted elements owned by different service providers have to swap trusted info that carries customer-specific details and expectations about the people on the call. This doc describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) that let trusted entities in the PacketCable Distributed Call Signaling Architecture exchange customer and billing info. These extensions give us mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The extensions only apply within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordinating charging and other functions is required. That's the vibe, no cap 🫶
Table of Contents 📜
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Trust Boundary. . . . . . . . . . . . . . . . . . . . . . . . 5
4. Conventions used in this document . . . . . . . . . . . . . . 6
5. P-DCS-TRACE-PARTY-ID. . . . . . . . . . . . . . . . . . . . . 6
5.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures at an Untrusted User Agent Client (UAC). . . 7
5.3. Procedures at a Trusted User Agent Client (UAC) . . . . 7
5.4. Procedures at an Untrusted User Agent Server (UAS). . . 7
5.5. Procedures at a Trusted User Agent Server (UAS) . . . . 7
5.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 8
5.6.1. Procedures at Originating Proxy . . . . . . . . 8
5.6.2. Procedures at Terminating Proxy . . . . . . . . 8
6. P-DCS-OSPS. . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Procedures at an Untrusted User Agent Client (UAC). . . 9
6.3. Procedures at a Trusted User Agent Client (UAC). . . . . 10
6.4. Procedures at an Untrusted User Agent Server (UAS). . . 10
6.5. Procedures at a Trusted User Agent Server (UAS). . . . . 11
6.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 11
7. P-DCS-BILLING-INFO. . . . . . . . . . . . . . . . . . . . . . 11
7.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Procedures at an Untrusted User Agent Client (UAC). . . 14
7.3. Procedures at a Trusted User Agent Client (UAC). . . . . 14
7.4. Procedures at an Untrusted User Agent Server (UAS). . . 15
7.5. Procedures at a Trusted User Agent Server (UAS). . . . . 15
7.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 16
7.6.1. Procedures at Originating Proxy . . . . . . . . 16
7.6.2. Procedures at Terminating Proxy . . . . . . . . 17
7.6.3. Procedures at Tandem Proxy. . . . . . . . . . . 18
8. P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 18
8.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Procedures at an Untrusted User Agent Client (UAC). . . 20
8.3. Procedures at a Trusted User Agent Client (UAC). . . . . 20
8.4. Procedures at an Untrusted User Agent Server (UAS). . . 21
8.5. Procedures at a Trusted User Agent Server (UAS). . . . . 21
8.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 21
8.6.1. Procedures at Originating Proxy . . . . . . . . 22
8.6.2. Procedures at Terminating Proxy . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Intellectual Property Rights Notice . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References. . . . . . . . . . . . . . . . . . 25
12.2. Informative References. . . . . . . . . . . . . . . . . 26
13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 26
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 281. Applicability Statement 🌸
Heads up, these SIP extensions make some big assumptions about network topology, how SIP links to the lower layers, and whether trust is transitive 🧐. Those assumptions generally don't hold across the Internet as a whole. The headers are only meant for closed administrative domains, or federations of administrative domains with previously agreed-upon policies where coordinating charging and other functions is required, like in the architecture described in [6]. Using them outside of that setup could leak sensitive or private info, so be careful 🙈. Users are strongly encouraged to consent to the privacy implications of the policies in [6] inside those domains too.
Also, even though RFC 2119 language shows up in this doc, the normative language only covers this doc's area of applicability. Like the technology itself, it does not reach the general Internet 💅
2. Introduction 💖
Okay so, to launch a SIP-based [2] residential phone service at a massive scale across different domains, trusted elements owned by different service providers need to trade trusted info. That info covers billing details and expectations about the people on the call 📱
There are tons of billing models that bring in revenue from phone services today ✨ Charging for phone service is tightly tied to using network resources. Going through all of these different methods is out of scope for this doc, so we're skipping that drama.
A key principle behind the DCS architecture in [6] is that network service providers need to be able to control and monitor network resources 🔥 Revenue can come from using those resources, and also from delivering enhanced services like telephony. The DCS architecture also gets that call signaling and resource management need to coordinate. That coordination makes sure users are authenticated and authorized before they get access to network resources and billable enhanced services 🫶
DCS Proxies, as defined in [6], can see subscriber info and act as policy decision points and trusted intermediaries along the call signaling path 👑 Edge routers handle network connectivity and enforce resource policy. They also capture and report connectivity and resource usage info. Edge routers need billing info they can log with Record Keeping or Billing servers 🧾 The DCS Proxy is the central point where call signaling and resource management meet, so it can provide that info based on the authenticated identity of the calling and called parties. Since DCS Proxies trust each other, they can be relied on to exchange trusted billing info about the parties in a call. See [6] for the trust boundary and the trusted versus untrusted entities 🦋
So, it makes sense to think about defining SIP header extensions that let DCS Proxies swap info during call setup 💜 The extensions would only show up on trusted network segments. They should be inserted when entering a trusted network region, and removed before leaving trusted network segments.
An originating DCS Proxy gets a LOT of info while handling a connection setup request from a user agent 😭 That includes location info about the subscriber (essential for emergency services calls), billing info, and station info (like, a coin operated phone). Plus, while translating the destination number, it picks up info like the local-number-portability office code, and every other proxy handling the call will need that too 🍓
For Usage Accounting records, we need an identifier that can be tied to all the event records made for the call 📊 The SIP Call-ID header field can't do that job. The originating user agent picks it, and it may not be unique across past and current calls. Since the service provider is the one using this identifier, it should be picked in a way and format that meets the provider's needs 🌈
Billing info isn't always unique to each user. Picture a bunch of calls from an office all billed to the same account 🏢 It also may not be the same for every call one user makes. Think prepaid calls, credit card calls, collect calls, and so on 💀 That's why billing info has to be carried separately from the calling and called party identification. On top of that, some billing models use split-charging, where multiple entities get billed for parts of the call 💅
Adding a SIP General Header Field lets us capture billing info and billing identification for the whole duration of the call ⭐
The billing extensions also only show up on trusted network segments. A DCS Proxy MAY insert them in INVITE and REFER requests and INVITE responses on a trusted network segment, and they get removed before leaving trusted network segments 🧚
Besides billing, residential phone service also needs customer originated trace for harassing or obscene calls 📞 It needs operator services like busy line verification and emergency interrupt, which an operator starts from an Operator Services Position System (OSPS) 🎀 It needs emergency services too, like 9-1-1 calls to a Public Service Access Point (PSAP) and the call handling that follows. And it needs support for Electronic Surveillance and Law Enforcement access, as required by applicable legislation and court orders ⚖️ In all of these cases, more info about the call and the subscribers on it has to get exchanged between the proxies. Lowkey a lot, but that's the job 🌸
3. Trust Boundary ✨
okay so the DCS architecture [6] draws a trust boundary 🛡️ around all the systems and servers that the service provider owns, runs, and/or controls. the trusted side includes the proxies plus servers like bridge servers, voicemail servers, announcement servers, etc. 💅 everything outside that boundary is the customer premises equipment, plus application and media servers run by third-party service providers.
some subscriber info, like billing and accounting details, stays inside the boundary 🔒. other subscriber info, like endpoint identity, may get shown to untrusted endpoints, or may get held back depending on the subscriber profile 🎀.
the User Agent (UA) can be inside the trust boundary OR outside it, and it depends on exactly what function is being done and exactly how it's being done 🦋. so the procedures a User Agent follows are different depending on which side it's on. obsessed with how this makes sense once you see it 😭.
that's why the User Agent sections below are split into trusted user agents and untrusted user agents 🧚.
4. 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 BCP 14, RFC 2119 [1]. 🌈
okay now the private-URL 🕵️♀️. this is a term used in this document for a SIP URI that a proxy generates. it has a "hostport" that identifies the proxy, plus a "userinfo" string that the proxy generated too. the "userinfo" usually has (or points to) stuff that must not leave the trusted proxy domain, like billing account numbers, electronic surveillance indication, electronic surveillance parameters, and call redirection information 🙈.
so that info is either stored locally by the proxy, or it's encrypted with a private key that only the proxy knows, then encoded as a character string in the "userinfo" part of the URL. a checksum is included in the "userinfo" data so tampering can be detected 🔍.
how a proxy recognizes a "userinfo" as a private-URL, then decodes and recovers the original info, is local to that proxy and is not standardized. 🤫 a couple of possible implementations are an initial magic cookie (e.g., z9hG4Bk followed by the pointer/information), or using a reserved "user" name (e.g., "private") with the optional "password" holding the pointer/information 💖.
5. P-DCS-TRACE-PARTY-ID 📞
in the telephone network, calling identity info supports regulatory stuff like the Customer Originated Trace service 🚨. that service lets the called party report obscene or harassing phone calls to law enforcement. it works separately from caller-id, and it works even if the caller asked for anonymity 🙈. the calling party here is the station that originated the call.
for this service to be dependable, the called party has to be able to trust that the calling identity info being shown is valid ✅. one way to get there is described in [10] ✨.
to start a customer-originated-trace from an untrusted UAC, there's an extra header defined for the INVITE request 💌. it's called P-DCS-Trace-Party-ID, and it doesn't show up in any other request or response. the entity the Request-URI points to does the service-provider-specific stuff: recording and reporting the caller identity in the P-DCS-Trace-Party-ID for law enforcement action 👮♀️. then it forwards the call to either an announcement server or the service-provider's business office, to collect more info about the complaint. 🎀 a trusted UAC doesn't use this header, since it starts the action locally.
5.1. Syntax 📝
the ABNF for this header is below (some terms used in this ABNF are defined in [2]) 💅:
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON
name-addrthis document adds the following entry to Table 2 of [2] 🧾:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -the addr-spec inside name-addr holds a URL that identifies the remote endpoint 🌸. it's usually a tel: URL or a SIP URI giving the identity of the remote endpoint, as provided in the signaling messages that set up the session being traced 🎯.
5.2. Procedures at an Untrusted User Agent Client (UAC) 🌍
the UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request 🚨. the UAC MUST also use a SIP URI in the Request-URI, with userinfo set to "call-trace" and hostport identifying the call tracing entity for the untrusted UA 🫶.
5.3. Procedures at a Trusted User Agent Client (UAC) 🔐
a trusted UAC does the customer-originated-trace in a way that's similar to the trusted UAS, described below 🦋. a trusted UAC MUST NOT include this header in any request 🙅♀️.
5.4. Procedures at an Untrusted User Agent Server (UAS) 🚫
this header MUST NOT appear in any response sent by a UAS 💀.
5.5. Procedures at a Trusted User Agent Server (UAS) 👑
if the P-DCS-Trace-Party-ID header is in the initial INVITE request from a UAC, and the Request-URI of the INVITE has userinfo set to "call-trace" and hostport set to the UAS, then the UAS MUST do the service-provider-specific stuff: record and report the caller identity for law enforcement action 🚔. the UAS then MUST redirect the call, using a 3xx response, to either an announcement server or the service-provider's business office, to collect further info about the complaint 💁♀️.
this header MUST NOT appear in any response sent by a UAS 🙅♀️.
5.6. Procedures at Proxy 🔀
there are two sets of proxy procedures defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy 🧩. the originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
the terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint 📤.
a proxy that both receives the INVITE request from an untrusted endpoint AND sends the INVITE request to an untrusted endpoint performs both sets of procedures 🔁.
5.6.1. Procedures at Originating Proxy 🛎️
if the P-DCS-Trace-Party-ID header is in the initial INVITE request from the UAC, and the Request-URI of the INVITE has userinfo other than "call-trace", and hostport is set to something other than a potentially provisioned call tracing entity, then the Proxy MAY reject the request, or MAY remove the P-DCS-Trace-Party-ID header from the request 🤔. if the header is in a valid request and holds a private-URL that identifies the Proxy in the hostport, then the Originating Proxy SHOULD replace the private-URL with its original contents (i.e., the verified identity of the caller of the session that is being traced) ✨.
5.6.2. Procedures at Terminating Proxy 🛑
this header MUST NOT appear in any request or response sent by a terminating proxy to an untrusted endpoint 🙅♀️.
6. P-DCS-OSPS 🎀
some calls have special call processing needs that normal user agent call processing might not satisfy 🌟. for example, when a user is already on a call and another call comes in, that call might get rejected with a busy indication 📵. but some PSTN operator services need special call processing. in particular, the Busy Line Verification (BLV) and Emergency Interrupt (EI) services, started by an operator from an Operator Services Position System (OSPS) on the PSTN network, have that need 👩💼. similarly, emergency calls to a 9-1-1 Public Service Access Point (PSAP) may cause trunk signaling that leads to operator ringback, using a howling tone or sustained ring on the originating line (country-specific variations may exist) 🚨.
to tell the SIP user agent that a call should get special treatment, we use a new P-DCS-OSPS header field 💫. it can be set to a value that says when a special type of call processing is requested. three values are defined in this header: "BLV" for busy line verification, "EI" for emergency interrupt, and "RING" for operator ringback (e.g., howling/sustained tone ring in the US) 🔔.
if the user agent decides to honor such a request, its response to an INVITE with either "BLV" or "EI" will not be a busy indication 🙌. since "EI" and "RING" only happen on established dialogs, they may also show up in UPDATE requests 🧚♀️.
6.1. Syntax 📝
the ABNF for the P-DCS-OSPS header is below (some terms used in this ABNF are defined in [2]) 💅:
P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag
OSPS-Tag = "BLV" / "EI" / "RING" / tokenthis document adds the following entry to Table 2 of [2] 🧾:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - o -the OSPS-Tag value of "token" is defined for extensibility, and it's reserved for future use 🔮.
6.2. Procedures at an Untrusted User Agent Client (UAC) 🚫
the P-DCS-OSPS header MUST NOT be sent in a request from an untrusted UAC 🙅♀️.
6.3. Procedures at a Trusted User Agent Client (UAC) 🏛️
this header is usually only inserted by a Media Gateway Controller [6] that controls a Media Gateway with special trunks to a PSTN OSPS system or PSAP 🌉. that trunk group is often called a BLV-trunk group, and it uses special signaling procedures that prevent accidental use 🛡️. calls starting at the PSTN OSPS system get sent over this trunk group, and they result in an INVITE request with the P-DCS-OSPS header 📞.
this header MAY be sent in an INVITE request, and it MUST NOT appear in any message other than the ones listed below 🎯.
the OSPS-Tag value "BLV" MUST NOT appear in any request or response other than an initial INVITE request that sets up a new dialog 🙅♀️.
the OSPS-Tag value "EI" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog that was established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a pre-existing dialog that was established with the OSPS-Tag value of "BLV" 🔁.
the OSPS-Tag value "RING" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog that a UAC established to an operator or PSAP, or (2) an UPDATE request within a pre-existing dialog that a UAC established to an operator or PSAP 🔔.
6.4. Procedures at an Untrusted User Agent Server (UAS) 💅
okay so if the UAS gets an INVITE with an OSPS-Tag of "BLV", and the dialog identification matches an existing dialog, but that existing call was NOT set up with the OSPS-Tag, it MUST reject the request with a 403-Forbidden error code. no exceptions bestie 🙅♀️
if the UAS gets an INVITE/UPDATE with an OSPS-Tag of "EI" or "RING" and the dialog identification does NOT match an existing dialog, it MUST reject it with a 403-Forbidden response code 💀
if an INVITE has an OSPS-Tag of "BLV" and the UAS isn't willing to help offer this service, it MUST reject the request with a 403-Forbidden response code. boundaries are everything 🫶
now the vibes for "BLV". the UAS SHOULD NOT reject a BLV INVITE just because it's busy 📞. the UAS MUST NOT send a 3xx-Redirect response code to a BLV INVITE, no redirecting, no drama 🙅♀️. and the UAS SHOULD NOT alert the user about the incoming call attempt if the BLV OSPS-Tag is in the INVITE. shhh 🤫
if a BLV INVITE gets accepted (like it meets all the QoS pre-conditions, etc.), the UAS MUST send an audio stream on this connection to the address and port listed in the SDP of the INVITE 🎧. the UAS MAY mix the two ends of an existing active call together and send that resulting media stream to the address and port listed. or, alternatively, the UAS MAY send a copy of the local voice stream and, if there's no activity on the local voice stream, send a copy of the received voice stream of an existing call. mixing options, so cute 🎀. if the UAS is idle, the UAS SHOULD send a stream of silence packets to OSPS 🤍. if the UAS is ringing or in ringback, the UAS SHOULD send a ringback stream to OSPS 🔔.
if an INVITE/UPDATE with an OSPS-Tag of "EI" gets accepted, the UAS MUST enable communication between the UAC and the local user 🗣️✨. the UAS MAY put any existing call on hold, or start an ad-hoc conference. main character energy 👑.
if an INVITE/UPDATE with an OSPS-Tag of "RING" gets accepted, the UAS MUST perform operator ringback following local procedures. for example, it can generate a 3-second howling tone or a sustained ring, depending on what state the user equipment is in 🔔🌸.
6.5. Procedures at a Trusted User Agent Server (UAS) 🫶
the procedures at a trusted UAS MUST be identical to the ones in 6.4. same rules, no notes 📜✨.
6.6. Procedures at Proxy 🧚
in the DCS architecture, the OSPS counts as a trusted UAC 🤝. if a proxy gets a P-DCS-OSPS header in a request from an untrusted source, it MUST either remove the header or reject the request with a 403-Forbidden response 🚫. no sneaky headers allowed bestie 😤.
a proxy that runs a call-forwarding service MUST NOT respond to an INVITE request with a 3xx response if the request had the P-DCS-OSPS header in it 🙈. redirects are off the table here 💅.
7. P-DCS-BILLING-INFO 💸
okay billing time 🍓. there are SO many billing models out there for making money off telephony services, and charging is super tightly linked to how network resources get used. the details of all these different methods are outside the scope of this document, so we're skipping them 🙃.
proxies have access to subscriber info and act as policy decision points and trusted middlemen along the call signaling path 🕵️♀️. edge routers provide the network connection and enforce resource policy, and they also capture and report connection and resource usage info 🛜. edge routers need billing info they can log with Record Keeping or Billing servers 📒. the proxy is the central coordinator between call signaling and resource management, so it can provide this info based on the authenticated identity of the calling and called parties 🪪. since proxies trust each other, they can be relied on to exchange trusted billing info about the parties in a call 🤝💖.
for Usage Accounting records, you need an identifier that can be linked to ALL the event records made for a call 🔗. the SIP Call-ID header field can't do this job, because the originating user agent picks it, and it might not be unique across past and current calls 🙅♀️. also, since the service provider is the one using this identifier, it should be chosen in a manner and format that meets the service provider's needs 💼.
billing info isn't always unique per user, like calls from an office that all get billed to the same account 🏢. and billing info isn't always the same for every call one user makes, like prepaid calls, credit card calls, collect calls, and so on 💳. so billing info has to be carried separately from the calling and called party identification 🧠. and some billing models do split-charging, where multiple entities get billed for different portions of the call ✂️.
adding a SIP General Header Field lets you capture billing info and billing identification for the whole duration of the call 🎯.
the billing extensions are only meant to show up on trusted network segments. they MAY be inserted by a proxy or a trusted UA in INVITE requests on a trusted network segment, and removed before they leave the trusted network segments 🛡️. the P-DCS-Billing-Info header extension is only used on requests and responses between proxies and trusted User Agents. it is NEVER sent to, or sent by, an untrusted UA 🚫✨.
7.1. Syntax 📝
the DCS-Billing-Info header is defined by the following ABNF (some terms used in this ABNF are defined in [2]) 🧾:
P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON
Billing-Correlation-ID "/" FEID
*(SEMI Billing-Info-param)
Billing-Correlation-ID = 1*48(HEXDIG)
FEID = 1*16(HEXDIG) "@" host
Billing-Info-param = RKS-Group-ID-param / Charge-param /
Calling-param / Called-param /
Routing-param / Loc-Routing-param /
generic-param
RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID
RKS-Group-ID = token
Charge-param = "charge" EQUAL Acct-Charge-URI
Acct-Charge-URI = LDQUOT addr-spec RDQUOT
Calling-param = "calling" EQUAL Acct-Calling-URI
Acct-Calling-URI = LDQUOT addr-spec RDQUOT
Called-param = "called" EQUAL Acct-Called-URI
Acct-Called-URI = LDQUOT addr-spec RDQUOT
Routing-param = "routing" EQUAL Acct-Routing-URI
Acct-Routing-URI = LDQUOT addr-spec RDQUOT
Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI
Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOTthis doc adds the following entry to Table 2 of [2] 📊:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Billing-Info admr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -the P-DCS-Billing-Info extension holds an identifier that an event recorder can use to link multiple usage records, possibly from different sources, to a billable account 🔑. it also has the subscriber account info and other info needed for accurate billing of the service 💰. this header is only used between proxies and trusted User Agents 🤍.
the Billing-Correlation-ID is specified in [9] as a 24-byte binary structure. it has 4 bytes of NTP timestamp, 8 bytes for the unique identifier of the network element that made the ID, 8 bytes for the time zone, and 4 bytes of monotonically increasing sequence number at that network element 🧮. this identifier is picked to be globally unique within the system for a window of several months 🌍. it MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 48 characters. leading zeroes MAY be suppressed 🫧.
the Financial-Entity-ID (FEID) is specified in [9] as an 8-byte structure. it has the financial identifier for that domain, followed by a domain name 🏦. an FEID can be associated with a type of service, and it could be assigned to multiple domains by the same provider 🎟️. a domain could contain multiple assigned FEIDs too 🌈. this 8-byte structure MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 16 characters. trailing zeroes MAY be suppressed. "Host" holds the domain name 🌐.
the RKS-Group-ID points to a record keeping server (or a group of cooperating servers) for event messages about this call 📚. it's used to control certain optimizations of procedures when multiple event message streams are being sent to the same Record Keeping Server ⚡.
the extra parameters carry the info needed to generate event message records 📋. Acct-Charge-URI, Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and Acct-Location-Routing-URI are each defined as URLs. they SHOULD all contain tel: URLs with E.164 formatted addresses. (lowercase "should" here, it's a soft suggestion 🥰.) these fields are further defined in [9] under the element identifiers "Charge_Number" (element ID 16), "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element ID 5), "Routing Number" (element ID 25), and "Location_Routing_Number" (element ID 22) 🔢.
7.2. Procedures at an Untrusted User Agent Client (UAC) 🙅♀️
this header is never sent to an untrusted UAC, and it's never sent by an untrusted UAC either 🔒.
7.3. Procedures at a Trusted User Agent Client (UAC) 🎀
the UAC MUST generate the Billing-Correlation-ID for the call and put it into the P-DCS-Billing-Info header in the initial INVITE sent to the terminating proxy, along with the charging info for the call 💖. the UAC MUST include its FEID and the RKS-Group-ID for the Record-Keeping-Server it's using. if the UAC did a Local Number Portability (LNP) query, it MUST include the Routing Number and Location Routing Number that the query returned 📞.
if the response to the initial INVITE is a 3xx-Redirect, the UAC generates a new initial INVITE request to the destination in the Contact: header, just like standard SIP 🔁. if a UAC gets a 3xx-Redirect response to an initial INVITE, the new INVITE it generates MUST contain the P-DCS-Billing-Info header from that 3xx-Redirect response 🫶. if the UAC is acting as a B2BUA, it MAY generate a private-URL instead of a new INVITE and place it in the Contact header of a 3xx-Redirect response sent to the originating endpoint 🦋. this private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which shows the charging arrangement for the new call, and it MUST have an expiration time very shortly in the future. that way the originator can't reuse this private-URL for multiple calls ⏳🙈.
a UAC that includes a Refer-to header in a REFER request MUST include a P-DCS-Billing-Info header in the Refer-to's URL 🔗. this P-DCS-Billing-Info header MUST include the accounting info of the REFER initiator 🧾✨.
7.4. Procedures at an Untrusted User Agent Server (UAS) 🔐
this header is never sent to an untrusted UAS, and it's never sent by an untrusted UAS either 🫧💜.
7.5. Procedures at a Trusted User Agent Server (UAS) 💅✨
Okay bestie, the trusted UAS has the biggest job in the call 🫶. It MUST put a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message 🎀. That header MUST carry the Billing-Correlation-ID the UAS generated, the FEID of the UAS, and the RKS-Group-ID of the Record-Keeping-Server it's using 🦋.
The UAS MAY change Acct-Charge-URI if it wants to override the billing info that came in the INVITE, like for a toll-free call 📞. But whether it does that, and what the new Acct-Charge-URI says, MUST be decided by the service provider policy provisioned in the UAS 👑. And if the UAS did an LNP query, it MUST include the Routing Number and Location Routing Number that the query returned 💖.
The UAS MUST also add a P-DCS-Billing-Info header to a 3xx-redirect response to an initial INVITE 🌸. That header gives the accounting info for the call forwarder, covering the call segment from the destination to the forwarded-to destination. Iconic 💅.
7.6. Procedures at Proxy 🧚
There are three sets of proxy procedures: (1) the originating proxy, (2) the terminating proxy, and (3) the tandem proxy 🌈.
An originating proxy is the one that receives the INVITE request from a non-trusted endpoint ✨.
A terminating proxy is the one that sends the INVITE request to a non-trusted endpoint 🦋.
Any proxy that is neither of those is a tandem proxy 🍓.
For mid-call changes, like call transfers, the proxy that gets the request from a non-trusted endpoint is called the initiating proxy 📲. The proxy that sends the request to a non-trusted endpoint is called the recipient proxy 💜. The initiating proxy's procedures are grouped with the originating proxy ones, and the recipient proxy's procedures are grouped with the terminating ones 🫶.
A proxy that both receives the INVITE request from an untrusted endpoint and sends the INVITE request to a non-trusted endpoint does both sets of procedures. Main character energy 👑.
7.6.1. Procedures at Originating Proxy 🎀
The originating proxy MUST generate the Billing-Correlation-ID for the call and insert it into the P-DCS-Billing-Info header in the initial INVITE message it sends to the terminating proxy, along with the charging info for the call 💖. It MUST include its FEID and the RKS-Group-ID of the Record-Keeping-Server it's using. If it did an LNP query, it MUST include the Routing Number and Location Routing Number that the query returned. And any P-DCS-Billing-Info header that came from an untrusted UA MUST be removed 🗑️.
If the Request-URI contains a private-URL, and the decoded username contains billing information, the originating proxy MUST generate a P-DCS-Billing-Info header with that decrypted information 🔐. Otherwise, the originating proxy MUST work out the accounting info for the call originator and insert a P-DCS-Billing-Info header with that info 💅.
If the response to the initial INVITE is a 3xx-Redirect that arrives before a 18x, the originating proxy generates a new initial INVITE request to the destination listed in the Contact: header, just like standard SIP 🦋. If an originating proxy gets a 3xx-Redirect response to an initial INVITE before any 18x response, the INVITE it generates MUST contain the P-DCS-Billing-Info header from that 3xx-Redirect response 🌸.
If the response to the initial INVITE is a 3xx-Redirect that arrives after a 18x, the originating proxy generates a private-URL and puts it in the Contact header of a 3xx-Redirect response sent to the originating endpoint 🧚. That private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which shows the charging arrangement for the new call. It also needs an expiration time very shortly in the future, so the originator can't reuse it for multiple calls ⏳.
An originating proxy that processes a REFER request from an untrusted UA MUST include a P-DCS-Billing-Info header in the Refer-to's URL 🔗. That header MUST include the accounting info of the initiator 💜.
7.6.2. Procedures at Terminating Proxy 🌈
The terminating proxy MUST NOT send the P-DCS-Billing-Info header to an untrusted destination 🙅♀️.
The terminating proxy MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message 🎀. That header MUST include the Billing-Correlation-ID the terminating proxy generated, its FEID, and the RKS-Group-ID of the Record-Keeping-Server it's using 💖. It MAY change Acct-Charge-URI if it wants to override the billing info that was in the INVITE, like for a toll-free call ☎️. Whether it does that, and what the resulting P-DCS-Billing-Info header contains, MUST be determined by the service provider policy provisioned in the terminating proxy 👑. If it did an LNP query, it MUST include the Routing Number and Location Routing Number that the query returned 🦋.
The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx-redirect response to an initial INVITE 🌸. Those give the accounting info for the call forwarder, for the call segment from the destination to the forwarded-to destination 📞.
When a proxy gets a mid-call REFER request that includes a Refer-to header, it generates a private-URL and puts it in the Refer-to header sent to the endpoint 🔗. That private-URL MUST contain the P-DCS-Billing-Info value, which shows the charging arrangement for the new call. It also needs an expiration time very shortly in the future, so the endpoint can't reuse it for multiple calls 😭.
7.6.3. Procedures at Tandem Proxy 🍓
If the tandem proxy did an LNP query, it MUST insert the Routing Number and Location Routing Number returned by the query into the P-DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 100) response 💅.
8. P-DCS-LAES and P-DCS-REDIRECT 🕵️
NOTE: According to RFC 2804 [5], the IETF supports documenting lawful intercept technology if it's needed to develop it 📚. The next section provides that documentation. The RFC 2119 language, as stated above, describes the requirements of the specification only if it's implemented, and strictly within the applicability domain described above. See RFC 2804 for the privacy, security, and complexity issues around this tech 🔒.
The P-DCS-LAES extension holds the info needed to support Lawfully Authorized Electronic Surveillance 🕵️♀️. This header has the address and port of an Electronic Surveillance Delivery Function, which receives a duplicate stream of event messages related to this call. It may also have an extra address and port for delivering call content. Security key info is included so pairs of Delivery Functions can securely exchange surveillance information 🔐. This header is only used between proxies and trusted User Agents 💜.
The P-DCS-Redirect extension holds call-identifying info needed to support Lawfully Authorized Electronic Surveillance of redirected calls 🦋. This header is only used between proxies and trusted User Agents 🫶.
Use of P-DCS-LAES and P-DCS-Redirect is controlled by a mix of legislation, regulation, and court orders, and those MUST be followed ⚖️. In some cases these headers are mandated, so they MUST be present in the requests and responses indicated. In other cases they're forbidden, so they MUST NOT be present in the requests and responses indicated. In the sub-sections that follow, "SHOULD" is used to cover these conflicting situations. For example, a P-DCS-LAES header SHOULD be included in an initial INVITE means either that it MUST be included or that it MUST NOT be included, depending on the applicable court orders 🌈.
8.1. Syntax 📝
The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by the following ABNF (some terms used in this ABNF are defined in [2] and [3]) 🧁:
P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig
*(SEMI Laes-param)
Laes-sig = hostport
Laes-param = Laes-content / Laes-key / generic-param
Laes-content = "content" EQUAL hostport
Laes-key = "key" EQUAL token
P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID
*(redir-params)
Called-ID = LDQUOT addr-spec RDQUOT
redir-params = redir-uri-param / redir-count-param /
generic-param
redir-uri-param = "redirector-uri" EQUAL Redirector
Redirector = LDQUOT addr-spec RDQUOT
redir-count-param = "count" EQUAL Redir-count
Redir-count = 1*DIGITThis document adds the following entry to Table 2 of [2] 🎀:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - -
P-DCS-Redirect adr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
- - - - - -The values of Laes-sig and Laes-content are addresses of the Electronic Surveillance Delivery Function. They're used as the destination address for call-identifying info and call content, respectively 🎯. Laes-key is a string the proxy generates, which the Delivery Function uses to securely transfer info between them [8] 🔑.
The P-DCS-Redirect header holds redirection info 🔀. The redir-uri-param shows the original destination the user asked for (like the dialed number), the Redirector shows the new destination, and the Redir-count shows how many redirections have happened so far 🔢.
8.2. Procedures at an Untrusted User Agent Client (UAC) 🙅♀️
This header MUST NOT be sent to an untrusted UAC, and it MUST NOT be sent by an untrusted UAC either 💖.
8.3. Procedures at a Trusted User Agent Client (UAC) 🎀
okay so the trusted UAC is the one that checks whether the originating subscriber has an outstanding lawfully authorized surveillance order 👀. If there is one, it puts that info into the Authorization for Quality of Service [7] or signals it to the device doing the intercept (like a Media Gateway) 🎧
If the first reliable 1xx (except 100), 2xx, or 3xx response has a P-DCS-LAES header in it, that means surveillance is needed on the terminating subscriber, but the terminating equipment can't do it itself 😭. In that case the UAC MUST include this info in the Authorization for Quality of Service, or MUST signal it to the device performing the intercept (e.g., a Media Gateway) 🫶
Now the redirect situation 🦋. If a 3xx-Redirect response comes back to the initial INVITE request, and that 3xx response has a P-DCS-LAES header, the UAC SHOULD keep that header exactly as it is when it reissues the INVITE. The UAC SHOULD also add a P-DCS-Redirect header with the original dialed number, the new destination number, and how many redirections have happened so far 🧚 Now, it's technically possible for the originating equipment to do this surveillance (or add to its existing surveillance of the call), but the surveillance system is designed so the terminating equipment handles all the intermediate forwardings 💅
Next, a UAC that puts a Refer-to header in a REFER request should SHOULD include a P-DCS-LAES header attached to the Refer-to, but only when the originating subscriber has an outstanding lawfully authorized surveillance order 🌸 That header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages. It SHOULD also include the address and port of that same kind of Delivery Function for a copy of the call content, if the call content is being intercepted. And it SHOULD include a random string to use as a security key between the Delivery Functions 🔐
Last but DEFINITELY not least 🚫: the trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity 💜
8.4. Procedures at an Untrusted User Agent Server (UAS) 🙈
this one is short and sweet 🍓 This header MUST NOT be sent to an untrusted UAS, and MUST NOT be sent by an untrusted UAS 🛑
8.5. Procedures at a Trusted User Agent Server (UAS) 🧁
the trusted UAS checks for an outstanding lawfully authorized surveillance order for the terminating subscriber. It also checks whether the P-DCS-LAES header is in the INVITE request. If either of those is there, the UAS puts this info into the authorization for Quality of Service [7] ✨
If the terminating equipment can't perform the required surveillance (say the destination is a voicemail server 📼), the UAS SHOULD include a P-DCS-LAES header in the first reliable non-100 response. That header asks the originating proxy to do the surveillance 🙏 It SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages. It SHOULD include the address and port of that same kind of Delivery Function for a copy of call content, if call content is to be intercepted. And it SHOULD include a random string for use as a security key between the Delivery Functions 🗝️
If the response to the initial INVITE request is a 3xx-Redirect response, and there's an outstanding lawfully authorized surveillance order for the terminating subscriber, the UAS SHOULD include a P-DCS-LAES header in the 3xx-Redirect response. Its contents are the same as described above 🌈
The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity ⚠️
8.6. Procedures at Proxy 🧚♀️
there are two sets of proxy procedures here 💖 (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is the proxy that got the INVITE request from a non-trusted endpoint. The terminating proxy is the proxy that sends the INVITE request to a non-trusted endpoint 🦋
For mid-call changes, like call transfers 🔁, the proxy that gets the request from a non-trusted endpoint counts as the initiating proxy. The proxy that sends the request to a non-trusted endpoint counts as the recipient proxy. The initiating proxy's procedures are included with the originating proxy ones, and the recipient proxy's procedures are included with the terminating proxy ones 💅
A proxy that BOTH receives the INVITE request from an untrusted endpoint AND sends the INVITE request to a non-trusted endpoint MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers 🚫
A proxy that's neither an originating proxy nor a terminating proxy SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers along in requests and responses 🫶
8.6.1. Procedures at Originating Proxy 👑
The Originating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or untrusted UA 🧹
The originating proxy checks for an outstanding lawfully authorized surveillance order for the originating subscriber. If there is one, it puts this info into the Authorization for Quality of Service [7] or signals it to the device doing the intercept (like a Media Gateway) 🎧
If the first reliable 1xx (except 100), 2xx, or 3xx response has a P-DCS-LAES header, that means surveillance is needed on the terminating subscriber, but the terminating equipment can't do it 😩 In that case the originating proxy MUST include this info in the Authorization for Quality of Service, or MUST signal it to the device performing the intercept (e.g., a Media Gateway) ✨
If the Request-URI in an initial INVITE request has a private-URL, the originating proxy MUST decrypt the userinfo to find the real destination for the call, plus any other special processing info 🔓 If the decrypted userinfo has electronic surveillance info in it, the originating proxy SHOULD generate a P-DCS-LAES header with that surveillance info 🕵️♀️
If a 3xx-Redirect response comes back to the initial INVITE request before an 18x, and that 3xx response has a P-DCS-LAES header, the originating proxy SHOULD keep that header unchanged when it reissues the INVITE. It SHOULD also add a P-DCS-Redirect header with the original dialed number, the new destination number, and how many redirections have happened 🔁
If a 3xx-Redirect response comes back to the initial INVITE request after an 18x, the originating proxy generates a private-URL and puts it in the Contact header of a 3xx-Redirect response sent to the originating endpoint 🎀 If a P-DCS-LAES header is in the 3xx response, this private-URL MUST contain (1) the electronic surveillance info from the 3xx-Redirect response, (2) the original destination number, (3) the identity of the redirecting party, and (4) the number of redirections for this call 🧩
An originating proxy that handles a REFER request [4] from an untrusted UA becomes a B2BUA for that request, but only when the originating subscriber has an outstanding lawfully authorized surveillance order 🦄 It SHOULD reissue the request with a P-DCS-LAES header added to the Refer-to's URL. That header SHOULD include (1) the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, (2) the address and port of that same kind of Delivery Function for a copy of call content if call content is to be intercepted, and (3) a random string to use as a security key between the Delivery Functions 🗝️
An initiating proxy that sends a mid-call REFER request with a Refer-to header, when the initiating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header in the Refer-to's URL 🌸
The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity 💜
8.6.2. Procedures at Terminating Proxy 🌙
The Terminating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or UA 🧹
The terminating proxy checks for an outstanding lawfully authorized surveillance order for the terminating subscriber. If there is one, the terminating proxy puts this info into the authorization for Quality of Service [7] ✨
The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity. That goes for headers in the request or response, and for headers attached to URIs in the request or response 🙅♀️
If the terminating equipment can't do the required surveillance (say the destination is a voicemail server 📼), the terminating proxy SHOULD include a P-DCS-LAES header in the first reliable 1xx/2xx/3xx (except 100) response. That asks the originating proxy to do the surveillance 🙏 The header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages. It SHOULD include the address and port of that same kind of Delivery Function for a copy of call content, if call content is to be intercepted. And it SHOULD include a random string to use as a security key between the Delivery Functions 🔐
If the response to the initial INVITE request is a 3xx-Redirect response, and there's an outstanding lawfully authorized surveillance order for the terminating subscriber, the terminating proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect response. Its contents are the same as described above 🌈
A proxy that gets a mid-call REFER request [4] with a Refer-to header that has a P-DCS-LAES header attached becomes a B2BUA for this request 🦋 It MUST generate a private-URL and put it in the Refer-to header sent to the endpoint. This private-URL MUST contain the P-DCS-LAES info from the attached header 💖
9. Security Considerations 🔐⚠️
okay this one is SERIOUS bestie, no jokes 😭 QoS gate coordination, billing information, and electronic surveillance information are all sensitive. They MUST be protected from eavesdropping, and they furthermore require integrity checking 🛡️ So the trusted UAs and proxies NEED to take precautions to protect this info from eavesdropping and tampering. Use of IPsec or TLS between Proxies is REQUIRED 🔒 A minimum mandatory-to-implement IPsec configuration for the DCS architecture is given by [8] 📚 Also REQUIRED is mutual authentication (1) between Proxies and (2) between trusted UAs and Proxies. Either of these MAY be implemented with administratively pre-shared keys, or through consultation with another trusted third party 🤝 If IPsec is going to be used, the specification of the security policies and procedures of the administrative domain where these headers apply (and all connections between administrative domains in the federation) MUST define an interoperable set of options 🌸
10. IANA Considerations ✨
okay so this doc adds a bunch of new SIP extension headers 🎀 and they get added to the registry of SIP headers from [2]. here's the registration info for each one 💅
Header Field Name: P-DCS-Trace-Party-ID
RFC Number: 3603
Compact Form: none
Header Field Name: P-DCS-OSPS
RFC Number: 3603
Compact Form: none
Header Field Name: P-DCS-Billing-Info
RFC Number: 3603
Compact Form: none
Header Field Name: P-DCS-LAES
RFC Number: 3603
Compact Form: none
Header Field Name: P-DCS-Redirect
RFC Number: 3603
Compact Form: none11. Intellectual Property Rights Notice 🦋
the IETF has heard that some intellectual property rights are claimed over some or all of the spec in this document 👀 if you want the details, go check the online list of claimed rights.
12. References
12.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
- [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] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 🧩
- [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. ↪️
- [5] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. 🕵️♀️
12.2. Informative References
- [6] DCS Group, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", Work in Progress. 🚧
- [7] PacketCable Dynamic Quality of Service Specification, pkt-sp-dqos-i07-030815, August 2003. 📦
- [8] PacketCable Security Specification, pkt-sp-sec-i09-030728, July 2003. 🔐
- [9] PacketCable Event Message Specification, pkt-sp-em-i07-030815, August 2003. 🗂️
- [10] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. 🪪
13. Acknowledgements 🫶
the Distributed Call Signaling work in the PacketCable project was done by a huge crew from loads of different companies, and the authors wanted to thank these people for helping out: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 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. 💖
earlier versions also credited a bunch of people as co-authors for writing the text of this document 🌸 they are:
Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan (kkrama@research.att.com), AT&T; Ed Miller (edward.miller@terayon.com), Terayon; Glenn Russell (G.Russell@Cablelabs.com), CableLabs; Burcak Beser (burcak@juniper.net) Juniper Networks, Mike Mannette (Michael_Mannette@3com.com) and Kurt Steinbrenner (Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens (jpickens@com21.com), Com21; Poornima Lalwaney (poornima.lalwaney@nokia.com), Nokia; Jon Fellows (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans (n7dr@arrisi.com) Arris, and Keith Kelly (keith@netspeak.com), NetSpeak.
14. Editors' Addresses 📮
Bill Marshall
AT&T
Florham Park, NJ 07932
EMail: wtm@research.att.comFlemming Andreasen
Cisco
Edison, NJ
EMail: fandreas@cisco.com15. Full Copyright Statement 🌈
Copyright (C) The Internet Society (2003). All Rights Reserved.
you're allowed to copy and share this document, and to make derivative works that comment on it, explain it, or help people implement it, and publish and distribute those in whole or in part with no real restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work 📄 the document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. the one exceptions are for developing Internet standards, where the copyright procedures in the Internet Standards process have to be followed, or translating it into languages other than English 🌍
these permissions are perpetual and the Internet Society or its successors or assigns will never revoke them 💜
this document and the info 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: rfc3603 2003-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms