RFC 6050
A Session Initiation Protocol (SIP) Extension for the Identification of Services
RFC 6050: A Session Initiation Protocol (SIP) Extension for the Identification of Services 🎀
Okay bestie, here's the title block. This is RFC 6050, written by K. Drage at Alcatel-Lucent and published by the IETF in November 2010 under ISSN 2070-1721. Its category is Informational, so it's published for information and is not a standards-track spec 💅. The title block doesn't list anything it obsoletes or updates, so it stands on its own 🦋
Abstract ⭐
Okay so this doc is about private extensions to SIP (the Session Initiation Protocol 📞) that let a network of trusted SIP servers assert the service of an authenticated user 🫶. These extensions only work inside one administrative domain, where everyone has agreed on the rules for generating, transporting and using that info ahead of time. It does NOT offer a general service identification model for use between different trust domains or on the Internet at large 🙈
It also defines a URN that identifies both services and User Agent (UA) applications 💜. You can use that URN in the SIP header fields defined here to name services, and also in the caller preferences and callee capabilities framework to talk about services and apps between end UAs ✨
Status of This Memo 📜
This is not an Internet Standards Track specification. It's just published for information 🌸
It's a product of the Internet Engineering Task Force (IETF), so it reflects IETF community consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🧚
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6050 🔗
Copyright Notice 💖
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 👑
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the publication date. Please read them carefully, because they explain your rights and restrictions for this doc. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶
Table of Contents 🌈
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Syntax of the Header Fields . . . . . . . . . . . . . . . . . 6
4.1. The P-Asserted-Service Header . . . . . . . . . . . . . . 6
4.2. The P-Preferred-Service Header . . . . . . . . . . . . . . 7
4.3. Service and Application Definition . . . . . . . . . . . . 8
4.4. Registration Template . . . . . . . . . . . . . . . . . . 8
5. Usage of the P-Preferred-Service and P-Asserted-Service
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Requests . . . . . . . 10
5.1.1. Procedures at User Agent Clients (UAC) . . . . . . . . 10
5.1.2. Procedures at Intermediate Proxies . . . . . . . . . . 11
5.1.3. Procedures at User Agent Servers . . . . . . . . . . . 12
5.2. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Responses . . . . . . 12
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. P-Asserted-Service and P-Preferred-Service Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Definition of Service-ID Values . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 181. Introduction ✨
Okay, intro time 🦋 This section also describes private SIP extensions that let a network of trusted SIP servers assert a service, possibly only if the user is entitled to that service 💅. Same rule as before: it only applies inside one administrative domain with pre-agreed policies for generating, transporting and using the info. It does NOT offer a general service model for different trust domains or for the Internet at large 🙈
The idea of "service" in SIP has no hard and fast rules 🌸 RFC 5897 [RFC5897] gives general guidance on what counts as a service in SIP and what doesn't.
This doc also uses the terms "derived service identification" and "declarative service identification," as defined in RFC 5897 [RFC5897] 💜
Here's the spicy part: RFC 5897 [RFC5897] clearly says that declarative service identification is harmful 😭 That's the process where a user agent sticks a moniker into a message to define the desired service, separate from explicit, well-defined protocol mechanisms.
During session setup, proxies may need to know which service a request relates to, so they know which application server to contact or which other service logic to invoke 🧚 The SIP INVITE request has all the info needed to figure out the service. The catch is that working it out can be computationally and database intensive 💀 For example, a trust domain's definition of a service might include request authorization. And the analysis may require looking at the Session Description Protocol (SDP) 🔥
For example, an INVITE request with video SDP aimed at a video-on-demand Request-URI could be marked as an IPTV session 📺 An INVITE with push-to-talk over cellular (PoC) routes could be marked as a PoC session 🎀 An INVITE with a Require header field containing an option tag of "foogame" could be marked as a foogame session 🎮
NOTE: If the info inside the SIP INVITE request isn't enough to uniquely identify a service, the fix is to extend the SIP signaling to capture the missing element. RFC 5897 [RFC5897] has more explanation.
So here's the big idea 👑 You compute and store the results of the domain-specific service calculation, which is called derived service identification. That optimization lets one trusted proxy analyze the request and authorize the requestor's permission to ask for that service. The proxy can then include a service identifier, so other trusted proxies and trusted UAs don't have to repeat the same analysis for their own service identification 💖 On top of that, this extension lets user agent clients outside the trust domain give a hint about the service they want 🫶
This extension does NOT make the dialog or transaction get rejected if the service isn't supported end-to-end 🙈 SIP already has other tools for that, like the option-tag and the Require and Proxy-Require header fields, for when that behavior is actually needed. No service identification is signaled explicitly. The session just carries on under each node's own definition of the service, based on the SDP and the other SIP header fields 🌈
This mechanism is specifically for managing the information needs of intermediate routing devices between the calling user and the user in the Request-URI 🧚 To support it, a URN is defined to identify services. The URN is useful beyond this, too, since it can also identify services and terminal applications ✨ Between end users, caller preferences and callee capabilities from RFC 3840 [RFC3840] and RFC 3841 [RFC3841] are the right tool for signaling service and application identification. RFC 5688 [RFC5688] extended those mechanisms with more capabilities in this area 💅
The mechanism in this doc relies on a new header field called 'P-Asserted-Service' that contains a URN 🎀 It's backed up by another new header field, 'P-Preferred-Service', which also contains a URN and lets the UA express its preferences about the service decisions made inside the trust domain 🦋
Here's an example of the P-Asserted-Service header field 👇
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1A proxy server that handles a request can, after authenticating the originating user in some way (for example, digest authentication) to make sure the user is entitled to that service, insert a P-Asserted-Service header field into the request and forward it to other trusted proxies 🫶 And a proxy about to forward a request to a proxy server or UA it doesn't trust removes all the P-Asserted-Service header field values 🙈
This doc labels services with an informal URN 💜 That gives you a hierarchical structure for defining services and subservices, plus an address that can be resolved for various purposes outside this doc's scope, like getting info about the service it names 🌸
2. Applicability Statement ✨
okay bestie, so this doc is all about private extensions to SIP (see RFC 3261 [RFC3261]) 🎀 that let a network of trusted SIP servers assert the service of end users or end systems 💅. These extensions are only applicable inside a 'trust domain' as defined in "Short Term Requirements for Network Asserted Identity" (see RFC 3324 [RFC3324]) 🌸. Nodes in that trust domain are explicitly trusted by their users and end systems to publicly assert the service of each party, and they have common, agreed-upon definitions of services and homogeneous service offerings 🫶. How the network figures out which service to assert is outside the scope of this document (though it commonly involves some form of authentication) 🔐.
The way you set up a trust domain is by writing a set of specs called 'Spec(T)' and then saying you comply with that set 📜. Spec(T) MUST specify behavior as documented in RFC 3324 [RFC3324] 🧚.
This document is not a general service model for inter-domain use or for the Internet at large 🌍. Its assumptions about the trust relationship between the user and the network may not apply in many applications. For example, these extensions do not accommodate a model where end users can independently assert their service using the extensions defined here 🙈. End users assert their service by including the SIP and SDP parameters that correspond to the service they require. Furthermore, since the asserted services are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of RFC 3324 [RFC3324].
💀 okay this part is serious: the asserted services are not cryptographically certified, so anything that doesn't meet RFC 3324 [RFC3324] is open to forgery, replay, and falsification. Do not skip this one, bestie.
The asserted services also lack an indication of who specifically is asserting the service, so it must be assumed that a member of the trust domain is asserting it. Therefore, the information is only meaningful when securely received from a node known to be a member of the trust domain 🔥.
Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above and can accept the resulting limitations, which is why this mechanism is worth an informational publication 🦋.
3. Conventions 🌈
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 [RFC2119] 📖.
Throughout this document, requirements for or references to proxy servers or proxy behavior apply similarly to other intermediaries within a trust domain (for example, back-to-back user agents (B2BUAs)) 🍓.
The term trust domain in this document has the meaning defined in RFC 3324 [RFC3324] ✨.
4. Syntax of the Header Fields 💜
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234] 🧁.
4.1. The P-Asserted-Service Header
The P-Asserted-Service header field is used among trusted SIP entities (typically intermediaries) to carry the service information of the user sending a SIP message 🦢.
The P-Asserted-Service header field carries information that is derived service identification. While a declarative service identification can assist in deriving the value transferred in this header field, this should be in the form of streamlining the correct derived service identification 🫧.
PAssertedService = "P-Asserted-Service"
HCOLON PAssertedService-value
PAssertedService-value = Service-ID *(COMMA Service-ID)See Section 4.4 for the definition of Service-ID in ABNF 🔍.
Proxies can (and will) add and remove this header field 🫠.
Table 1 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification [RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in the reliability of provisional responses in SIP [RFC3262], Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for instant messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Asserted-Service R admr - - - o o - o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Asserted-Service - - - - o o o
Table 1Syntactically, there may be multiple P-Asserted-Service header fields in a request. The semantics of multiple P-Asserted-Service header fields appearing in the same request is not defined at this time. Implementations of this specification MUST provide only one P-Asserted-Service header field value 🎀.
4.2. The P-Preferred-Service Header
The P-Preferred-Service header field is used by a user agent sending the SIP request to give a trusted proxy a hint about the preferred service that the user wants used for the P-Asserted-Service field value that the trusted element will insert 💭.
The P-Preferred-Service header field carries information that is declarative service identification. Such information should only be used to assist in deriving a derived service identification at the recipient entity 🌷.
PPreferredService = "P-Preferred-Service"
HCOLON PPreferredService-value
PPreferredService-value = Service-ID *(COMMA Service-ID)See Section 4.4 for the definition of Service-ID in ABNF 🔍.
Table 2 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification [RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in Reliability of provisional responses in SIP [RFC3262], Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for Instant Messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Preferred-Service R dr - - - o o - o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Preferred-Service - - - - o o o
Table 2Syntactically, there may be multiple P-Preferred-Service header fields in a request. The semantics of multiple P-Preferred-Service header fields appearing in the same request is not defined at this time. Implementations of this specification MUST only provide one P-Preferred-Service header field value 🌸.
4.3. Service and Application Definition
Service definitions and characteristics are outside the scope of this document. Other standards organizations, vendors, and operators may define their own services and register them 🏳️🌈.
A hierarchical structure is defined, consisting of service identifiers or application identifiers, and subservice identifiers 🪜.
The service and subservice identifiers are as described in Section 1. The URN may also be used to identify a service or an application between end users for use within the context of RFC 3840 [RFC3840] and RFC 3841 [RFC3841] 💖.
IANA maintains a registry of service identifier values that have been assigned. This registry has been created by the actions of Section 8.2 of this document 📋.
subservice identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the subservices 🫶.
4.4. Registration Template 📝
okay so bestie, this is the URN registration form 💅 It follows RFC 3406 [RFC3406], and the URN scheme is treated as an informal Namespace ID (NID) ✨
Namespace ID: urn-7 🎀
Registration Information: Registration version: 1; registration date: 2009-03-22 🌸
Declared registrant of the namespace: 3GPP Specifications Manager (3gppContact@etsi.org) (+33 (0)492944200) 📞
Declaration of syntactic structure: okay the URN is a hierarchical service identifier or application identifier, built from a sequence of labels separated by periods 🦋 The leftmost label is the most significant one and gets called the 'top-level service identifier', and the names to its right are called 'subservices' or 'sub-applications'. The allowed characters are the same as for domain names (see RFC 1123 [RFC1123]), and it's a subset of the labels allowed in RFC 3958 [RFC3958]. Labels are case-insensitive and MUST be specified in all lowercase 🔥
Here's the vibe for removing labels 👀 For any given service identifier, you can remove labels right-to-left and the resulting URN is still valid, referring to a more generic service. The exceptions are the top-level service identifier and possibly the first subservice or sub-application identifier. You can't remove labels past a defined basic service. For example, the label w.x may define a service, but the label w may only define an assignment authority for assigning subsequent values and not define a service in its own right. In other words, if a service identifier 'w.x.y.z' exists, the URNs 'w.x' and 'w.x.y' are also valid service identifiers, but w may not be a valid service identifier if it merely defines who is responsible for defining x 💅✨
Service-ID = "urn:urn-7:" urn-service-id
urn-service-id = top-level *("." sub-service-id)
top-level = let-dig [ *26let-dig ]
sub-service-id = let-dig [ *let-dig ]
let-dig = ALPHA / DIGIT / "-"While the naming convention above says "service", all of these constructs apply just as well to identifying applications within the UA 🧚
Relevant ancillary documentation: None 🌈
Identifier uniqueness considerations: A service identifier identifies a service, and an application identifier identifies an application indicated in the service or application registration (see IANA Considerations (Section 8)). Uniqueness is guaranteed by the IANA registration 🔒
Identifier persistence considerations: The service or application identifier for the same service or application is expected to be persistent 💜 Although there naturally cannot be a guarantee that a particular service will continue to be available globally or at all times 🙈
Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (Section 8) 📋
Process for identifier resolution: There is no single global resolution service for service identifiers or application identifiers 🌍
Rules for lexical equivalence: 'service' identifiers are compared according to case-insensitive string equality 🍓
Conformance with URN syntax: The BNF in the 'Declaration of syntactic structure' above constrains the syntax for this URN scheme 🎀
Validation mechanism: Validation determines whether a given string is currently a validly assigned URN (see RFC 3406 [RFC3406]). Due to the distributed nature of usage, and since not all services are available everywhere, validation in this sense is not possible 😭
Scope: The scope for this URN can be local to a single domain, or it may be more widely used 🌸
5. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields 👑
5.1. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields in Requests 💌
5.1.1. Procedures at User Agent Clients (UAC) 🦋
The UAC MAY insert a P-Preferred-Service in a request that creates a dialog, or a request outside of a dialog. This information can assist the proxies in identifying appropriate service capabilities to apply to the call ✨ This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUST be present 🫶 So, for example, if a service requires a video component, then the SDP has to include the media line associated with that video component. It cannot be assumed from the P-Preferred-Service header field value 🎥 Similarly, if the service requires particular SIP functionality for which a SIP extension and a Require header field value is defined, then the request has to include that SIP signaling as well as the P-Preferred-Service header field value 💅
A UAC that is within the same trust domain as the proxy it sends a request to (e.g., a media gateway or application server) MAY insert a P-Asserted-Service header field in a request that creates a dialog, or a request outside of a dialog. This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUST be present 🔥
5.1.2. Procedures at Intermediate Proxies 🧚♀️
A proxy in a trust domain can receive a request from a node that it trusts, or from a node that it does not trust. When a proxy receives a request from a node it does not trust, and it wishes to add a P-Asserted-Service header field, the proxy MUST identify the service appropriate to the capabilities (e.g., SDP) in the request. It MAY authenticate the originator of the request (in order to determine whether the user is subscribed for that service) 🔐 Where the originator of the request is authenticated, the proxy MUST use the identity that results from this checking and authentication to insert a P-Asserted-Service header field into the request 🫶
When a proxy receives a request containing a P-Preferred-Service header field, the Proxy MAY use the contents of that header field to assist in determining the service to be included in a P-Asserted-Service header field. For instance, it could use it to prioritize the order of comparison of filter criteria for potential services that the request could match 🍓 The proxy MUST NOT use the contents of the P-Preferred-Service header field to identify the service without first checking against the capabilities (e.g., SDP) contained in the request. If the proxy inserts a P-Asserted-Service header field in the request, the proxy MUST remove the P-Preferred-Service header field before forwarding the request. Otherwise, the Proxy SHOULD include the P-Preferred-Service header field when forwarding the request 🌈
If the proxy receives a request from a node that it trusts, it can use the information in the P-Asserted-Service header field, if any, as if it had authenticated the user itself 👑
If there is no P-Asserted-Service header field present, or it is not possible to match the request to a specific service as identified by the service identifier, a proxy MAY add one containing it, using its own analysis of the information contained in the SIP request 🔍 If the proxy received the request from an element that it does not trust, and there is a P-Asserted-Service header present, the proxy MUST replace that header field's contents with a new analysis, or remove that header field 🧹
The analysis performed to identify such service identifiers is outside the scope of this document. However, it is perfectly valid for the analysis not to include any service identifier in the forwarded request, and thus not include a P-Asserted-Service header field 💖
If a proxy forwards a request to a node outside the proxy's trust domain, there MUST NOT be a P-Asserted-Service header field in the forwarded request 🔒
5.1.3. Procedures at User Agent Servers 🌸
For a User Agent Server (UAS) outside the trust domain, the P-Asserted-Service header is removed before it reaches this entity, so there are no procedures for such a device 🙅♀️
However, if a UAS receives a request from a previous element that it does not trust, it MUST NOT use the P-Asserted-Service header field in any way 🚫
If a UA is part of the trust domain from which it received a request containing a P-Asserted-Service header field, then it can use the value freely. But it MUST ensure that it does not forward the information to any element that is not part of the trust domain 🫶
5.2. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields in Responses 🦋
There is no usage of these header fields in responses 💀
6. Examples of Usage ✨
Okay bestie, the examples are where it all clicks 🦋 In this one, proxy.example.com builds a P-Asserted-Service header from three things: the user identity it found through SIP digest authentication, the list of services that fit that user, and the services matching the SDP info in the request. ngl F1 and F2 are all about figuring out who the user is, so they don't directly make up the capability this document is about 💅 The proxy then passes everything to a trusted proxy, which passes it on to a trusted gateway. Also, these are partial SIP messages. They only show the header fields that matter for the authenticated identity problem, so don't panic when stuff is missing 🙈
F1 useragent.example.com -> proxy.example.com
INVITE sip:+14085551212@example.com SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframesF2 proxy.example.com -> useragent.example.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123
To: <sip:+14085551212@example.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.example.com"F3 useragent.example.com -> proxy.example.com
INVITE sip:+14085551212@example.com SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Proxy-Authorization: realm="sip.example.com" user="fluffy"
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframesF4 proxy.example.com -> proxy.pstn.example (trusted)
INVITE sip:+14085551212@proxy. pstn.example SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframesF5 proxy.pstn.example -> gw.pstn.example (trusted)
INVITE sip:+14085551212@gw.pstn.example SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.example;branch=z9hG4bK-a1b2
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes7. Security Considerations 🔐
Okay, this one is serious, so listen up 🥹 The mechanism in this document only covers part of the service identification problem in SIP. For example, these mechanisms give end users NO way to securely share service information end-to-end unless there's a trusted service provider in the middle. That info is protected by transitive trust, and transitive trust is only as strong as the weakest link in the chain of trust. Yikes, no pressure 💀
The trust domain is a set of servers where the characteristics of the service get agreed for that service identifier value, and where the calling user is allowed to use that service. [RFC5897] explains the impact of letting these service identifier values "leak" outside the trust domain, including effects on fraud, interoperability, and stifling of service innovation. That's a whole mess 😭
8. IANA Considerations 📋
8.1. P-Asserted-Service and P-Preferred-Service Header Fields 🎀
This document creates two brand new SIP header fields: P-Asserted-Service and P-Preferred-Service. Their syntax is in Section 3. Both get listed in the header sub-registry under http://www.iana.org, using the info below 💖
Header Name compact Reference
----------------- ------- ---------
P-Asserted-Service RFC 6050
P-Preferred-Service RFC 60508.2. Definition of Service-ID Values 🧚
Top-level identifiers are labels managed by IANA, following the processes in [RFC5226], in a new registry called "Service-ID/Application-ID Labels". So if you want a new service at the top level, you need IANA action first 📝 The policy for adding service labels is 'specification required'. The following two identifiers are defined from the start:
3gpp-service
3gpp-applicationSubservice identifiers are NOT managed by IANA lol. It's the job of the organization that registered the service to manage its subservices 🫶
Application identifiers are also not managed by IANA. It's the responsibility of the organization that registered the service to manage the applicable applications 🌸
Entries in the registration table look like this 👑
Service/Application Description Reference
--------------------------------------------------------------------
3gpp-service Communication services defined by RFC 6050
3GPP for use by the IM CN subsystem
and its attached UAs. This value
in itself does not define a service
and requires subsequent labels to
define the service.
3gpp-application Applications defined by 3GPP for RFC 6050
use by UAs attached to the IM CN
subsystem. This value in itself
does not define a service and
requires subsequent labels to define
the service.Here, the IM CN subsystem means the IP Multimedia Core Network subsystem. Yes, that's the whole acronym 🙈
9. References 📚
9.1. Normative References
- [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
- [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.
- [RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
- [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
- [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
9.2. Informative References
- [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
- [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
- [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
- [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
- [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
- [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
- [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
- [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
- [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
- [RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", RFC 5688, January 2010.
- [RFC5897] Rosenberg, J., "Identification of Communications Services in the Session Initiation Protocol (SIP)", RFC 5897, June 2010.
Author's Address 🦋
Keith Drage Alcatel-Lucent Quadrant, Stonehill Green, Westlea Swindon, Wilts UK
EMail: drage@alcatel-lucent.com
📦 where this page comes from
- ietf: rfc6050 2010-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms