From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6050.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc6050.txt (limited to 'doc/rfc/rfc6050.txt') diff --git a/doc/rfc/rfc6050.txt b/doc/rfc/rfc6050.txt new file mode 100644 index 0000000..2561612 --- /dev/null +++ b/doc/rfc/rfc6050.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Drage +Request for Comments: 6050 Alcatel-Lucent +Category: Informational November 2010 +ISSN: 2070-1721 + + + A Session Initiation Protocol (SIP) Extension + for the Identification of Services + +Abstract + + This document describes private extensions to the Session Initiation + Protocol (SIP) that enable a network of trusted SIP servers to assert + the service of authenticated users. The use of these extensions is + only applicable inside an administrative domain with previously + agreed-upon policies for generation, transport, and usage of such + information. This document does NOT offer a general service + identification model suitable for use between different trust domains + or for use in the Internet at large. + + The document also defines a URN to identify both services and User + Agent (UA) applications. This URN can be used within the SIP header + fields defined in this document to identify services, and also within + the framework defined for caller preferences and callee capabilities + to identify usage of both services and applications between end UAs. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6050. + + + + + + + + + + +Drage Informational [Page 1] + +RFC 6050 SIP Service Identification November 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without 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 . . . . . . . . . . . . . . . . . . 18 + + + + + + + + +Drage Informational [Page 2] + +RFC 6050 SIP Service Identification November 2010 + + +1. Introduction + + This document describes private extensions to the Session Initiation + Protocol (SIP) that enable a network of trusted SIP servers to assert + the service, possibly subject to the user being entitled to that + service. The use of these extensions is only applicable inside an + administrative domain with previously agreed-upon policies for + generation, transport, and usage of such information. This document + does NOT offer a general service model suitable for use between + different trust domains or for use in the Internet at large. + + The concept of "service" within SIP has no hard and fast rules. RFC + 5897 [RFC5897] provides general guidance on what constitutes a + service within SIP and what does not. + + This document also makes use of the terms "derived service + identification" and "declarative service identification" as defined + in RFC 5897 [RFC5897]. + + It should be noted that RFC 5897 [RFC5897] clearly states that + declarative service identification -- the process by which a user + agent inserts a moniker into a message that defines the desired + service, separate from explicit and well-defined protocol mechanisms + -- is harmful. + + During a session setup, proxies may need to understand what service + the request is related to in order to know what application server to + contact or other service logic to invoke. The SIP INVITE request + contains all of the information necessary to determine the service. + However, the calculation of the service may be computational and + database intensive. For example, a given trust domain's definition + of a service might include request authorization. Moreover, the + analysis may require examination of the Session Description Protocol + (SDP). + + For example, an INVITE request with video SDP directed to a video-on- + demand Request-URI could be marked as an IPTV session. An INVITE + request with push-to-talk over cellular (PoC) routes could be marked + as a PoC session. An INVITE request with a Require header field + containing an option tag of "foogame" could be marked as a foogame + session. + + NOTE: If the information contained within the SIP INVITE request is + not sufficient to uniquely identify a service, the remedy is to + extend the SIP signaling to capture the missing element. RFC 5897 + [RFC5897] provides further explanation. + + + + + +Drage Informational [Page 3] + +RFC 6050 SIP Service Identification November 2010 + + + By providing a mechanism to compute and store the results of the + domain-specific service calculation, i.e., the derived service + identification, this optimization allows a single trusted proxy to + perform an analysis of the request and authorize the requestor's + permission to request such a service. The proxy may then include a + service identifier that relieves other trusted proxies and trusted + UAs from performing further duplicate analysis of the request for + their service identification purposes. In addition, this extension + allows user agent clients outside the trust domain to provide a hint + of the requested service. + + This extension does not provide for the dialog or transaction to be + rejected if the service is not supported end-to-end. SIP provides + other mechanisms, such as the option-tag and use of the Require and + Proxy-Require header fields, where such functionality is required. + No explicitly signaled service identification exists, and the session + proceeds for each node's definition of the service in use, on the + basis of information contained in the SDP and in other SIP header + fields. + + This mechanism is specifically for managing the information needs of + intermediate routing devices between the calling user and the user + represented by the Request-URI. In support of this mechanism, a URN + is defined to identify the services. This URN has wider + applicability to additionally identify services and terminal + applications. Between end users, caller preferences and callee + capabilities as specified in RFC 3840 [RFC3840] and RFC 3841 + [RFC3841] provide an appropriate mechanism for indicating such + service and application identification. These mechanisms have been + extended by RFC 5688 [RFC5688] to provide further capabilities in + this area. + + The mechanism proposed in this document relies on a new header field + called 'P-Asserted-Service' that contains a URN. This is supported + by a further new header field called 'P-Preferred-Service' that also + contains a URN and that allows the UA to express preferences + regarding the decisions made on service within the trust domain. + + An example of the P-Asserted-Service header field is: + + P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1 + + A proxy server that handles a request can, after authenticating the + originating user in some way (for example: digest authentication) to + ensure that the user is entitled to that service, insert such a + P-Asserted-Service header field into the request and forward it to + + + + + +Drage Informational [Page 4] + +RFC 6050 SIP Service Identification November 2010 + + + other trusted proxies. A proxy that is about to forward a request to + a proxy server or UA that it does not trust removes all the + P-Asserted-Service header field values. + + This document labels services by means of an informal URN. This + provides a hierarchical structure for defining services and + subservices, and provides an address that can be resolvable for + various purposes outside the scope of this document, e.g., to obtain + information about the service so described. + +2. Applicability Statement + + This document describes private extensions to SIP (see RFC 3261 + [RFC3261]) that enable a network of trusted SIP servers to assert the + service of end users or end systems. The use of these extensions is + only applicable inside a 'trust domain' as defined in "Short Term + Requirements for Network Asserted Identity" (see RFC 3324 [RFC3324]). + Nodes in such a trust domain are explicitly trusted by its users and + end systems to publicly assert the service of each party, and that + they have common and agreed-upon definitions of services and + homogeneous service offerings. The means by which the network + determines the service to assert is outside the scope of this + document (though it commonly entails some form of authentication). + + The mechanism for defining a trust domain is to provide a certain set + of specifications known as 'Spec(T)', and then specify compliance to + that set of specifications. Spec(T) MUST specify behavior as + documented in RFC 3324 [RFC3324]. + + This document does NOT offer a general service model suitable for + inter-domain use or use in 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 whereby end users can independently assert their + service by use of 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]. + + The asserted services also lack an indication of who specifically is + asserting the service, and so it must be assumed that a member of the + trust domain is asserting the service. Therefore, the information is + only meaningful when securely received from a node known to be a + member of the trust domain. + + + + + +Drage Informational [Page 5] + +RFC 6050 SIP Service Identification November 2010 + + + Despite these limitations, there are sufficiently useful specialized + deployments, that meet the assumptions described above and can accept + the limitations that result, to warrant informational publication of + this mechanism. + +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 as 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. + + + + + + +Drage Informational [Page 6] + +RFC 6050 SIP Service Identification November 2010 + + + 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 1 + + Syntactically, 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 provide a hint to a trusted proxy of the preferred + service that the user wishes to be 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], + + + +Drage Informational [Page 7] + +RFC 6050 SIP Service Identification November 2010 + + + 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 2 + + Syntactically, 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 + + Below, we include the registration template for the URN scheme + according to RFC 3406 [RFC3406]. The URN scheme is defined as an + informal Namespace ID (NID). + + + +Drage Informational [Page 8] + +RFC 6050 SIP Service Identification November 2010 + + + 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: The URN consists of a + hierarchical service identifier or application identifier, with a + sequence of labels separated by periods. The leftmost label is + the most significant one and is called 'top-level service + identifier', while names to the right are called 'subservices' or + 'sub-applications'. The set of allowable characters is the same + as that for domain names (see RFC 1123 [RFC1123]) and a subset of + the labels allowed in RFC 3958 [RFC3958]. Labels are case- + insensitive and MUST be specified in all lowercase. For any given + service identifier, labels can be removed right-to-left and the + resulting URN is still valid, referring a more generic service, + with the exception of the top-level service identifier and + possibly the first subservice or sub-application identifier. + Labels cannot be removed beyond 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 uses the term "service", all the + constructs are equally applicable to identifying applications + within the UA. + + Relevant ancillary documentation: None + + Identifier uniqueness considerations: A service identifier + identifies a service, and an application identifier an application + indicated in the service or application registration (see IANA + Considerations (Section 8)). Uniqueness is guaranteed by the IANA + registration. + + + + +Drage Informational [Page 9] + +RFC 6050 SIP Service Identification November 2010 + + + 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 + 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. Thus, 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 + + + + + +Drage Informational [Page 10] + +RFC 6050 SIP Service Identification November 2010 + + + 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 to which it + sends a request (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 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, 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, 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 + + + +Drage Informational [Page 11] + +RFC 6050 SIP Service Identification November 2010 + + + 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 + as a result of 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; + therefore, 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 + + In this example, proxy.example.com creates a P-Asserted-Service + header field from the user identity it discovered from SIP digest + authentication, the list of services appropriate to that user, and + the services that correspond to the SDP information included in the + request. Note that F1 and F2 are about identifying the user and do + not directly form part of the capability provided in this document. + It forwards this information to a trusted proxy that forwards it to a + trusted gateway. Note that these examples consist of partial SIP + messages that illustrate only those header fields relevant to the + authenticated identity problem. + + + + + +Drage Informational [Page 12] + +RFC 6050 SIP Service Identification November 2010 + + + * 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: + From: "Anonymous" ;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; maxframes + + + * F2 proxy.example.com -> useragent.example.com + + SIP/2.0 407 Proxy Authorization + Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123 + To: ;tag=123456 + From: "Anonymous" ;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: + From: "Anonymous" ;tag=9802748 + Call-ID: 245780247857024504 + CSeq: 2 INVITE + Max-Forwards: 70 + Proxy-Authorization: realm="sip.example.com" user="fluffy" + + + + +Drage Informational [Page 13] + +RFC 6050 SIP Service Identification November 2010 + + + 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; maxframes + + + * F4 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: + From: "Anonymous" ;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; maxframes + + + + + + + + + +Drage Informational [Page 14] + +RFC 6050 SIP Service Identification November 2010 + + + * F5 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: + From: "Anonymous" ;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; maxframes + +7. Security Considerations + + The mechanism provided in this document is a partial consideration of + the problem of service identification in SIP. For example, these + mechanisms provide no means by which end users can securely share + service information end-to-end without a trusted service provider. + This information is secured by transitive trust, which is only as + reliable as the weakest link in the chain of trust. + + The trust domain provides a set of servers where the characteristics + of the service are agreed for that service identifier value, and + where the calling user is entitled to use that service. RFC 5897 + [RFC5897] identifies the impact of allowing such service identifier + values to "leak" outside of the trust domain, including implications + on fraud, interoperability, and stifling of service innovation. + + + + + + + + +Drage Informational [Page 15] + +RFC 6050 SIP Service Identification November 2010 + + +8. IANA Considerations + +8.1. P-Asserted-Service and P-Preferred-Service Header Fields + + This document specifies two new SIP header fields: P-Asserted-Service + and P-Preferred-Service. Their syntax is given in Section 3. These + header fields are defined by the following information, which has + been added to the header sub-registry under http://www.iana.org. + + Header Name compact Reference + ----------------- ------- --------- + P-Asserted-Service RFC 6050 + P-Preferred-Service RFC 6050 + +8.2. Definition of Service-ID Values + + Top-level identifiers are identified by labels managed by IANA, + according to the processes outlined in RFC 5226 [RFC5226], in a new + registry called "Service-ID/Application-ID Labels". Thus, creating a + new service at the top-level requires IANA action. The policy for + adding service labels is 'specification required'. The following two + identifiers are initially defined: + + 3gpp-service + + 3gpp-application + + subservice identifiers are not managed by IANA. It is the + responsibility of the organization that registered the service to + manage the subservices. + + Application identifiers are not managed by IANA. It is the + responsibility of the organization that registered the service to + manage the applicable applications. + + + + + + + + + + + + + + + + + +Drage Informational [Page 16] + +RFC 6050 SIP Service Identification November 2010 + + + Entries in the registration table have the following format: + + 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 stands for the IP Multimedia Core Network + subsystem. + +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. + + + + + +Drage Informational [Page 17] + +RFC 6050 SIP Service Identification November 2010 + + + [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. + + + + +Drage Informational [Page 18] + +RFC 6050 SIP Service Identification November 2010 + + +Author's Address + + Keith Drage + Alcatel-Lucent + Quadrant, Stonehill Green, Westlea + Swindon, Wilts + UK + + EMail: drage@alcatel-lucent.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Drage Informational [Page 19] + -- cgit v1.2.3