Network Working Group M. Garcia Internet-Draft Ericsson Expires: December 22, 2002 E. Henrikson Lucent D. Mills Vodafone June 23, 2002 Private Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) draft-garcia-sipping-3gpp-p-headers-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 22, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a set of private SIP extensions used by the 3rd-Generation Partnership Project (3GPP). Garcia, et al. Expires December 22, 2002 [Page 1] Internet-Draft 3GPP SIP Extensions June 2002 Table of Contents 1. Overall Applicability . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Private Headers . . . . . . . . . . . . . . . . . . . . . 4 4.1 The P-Associated-URI header . . . . . . . . . . . . . . . 4 4.1.1 Applicability statement . . . . . . . . . . . . . . . . . 5 4.1.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . 6 4.1.2.2 Procedures at the registrar . . . . . . . . . . . . . . . 6 4.1.2.3 Procedures at the proxy . . . . . . . . . . . . . . . . . 6 4.2 The P-Called-Party-ID header . . . . . . . . . . . . . . . 6 4.2.1 Applicability statement . . . . . . . . . . . . . . . . . 10 4.2.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . 10 4.2.2.2 Procedures at the proxy . . . . . . . . . . . . . . . . . 10 4.3 The P-Visited-Network-ID header . . . . . . . . . . . . . 11 4.3.1 Applicability statement . . . . . . . . . . . . . . . . . 11 4.3.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.2.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . 13 4.3.2.2 Procedures at the registrar and proxy . . . . . . . . . . 13 4.4 The P-Access-Network-Info header . . . . . . . . . . . . . 14 4.4.1 Applicability Statement . . . . . . . . . . . . . . . . . 15 4.4.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.2.1 UAC behavior . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.2.2 Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 16 4.5 The P-Charging-Function-Addresses and P-Charging-Vector headers . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5.1 Applicability Statement . . . . . . . . . . . . . . . . . 18 4.5.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5.2.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . 19 4.5.2.2 Procedures at the Proxy . . . . . . . . . . . . . . . . . 19 4.5.2.3 Procedures at the Back to Back UA . . . . . . . . . . . . 19 4.5.2.4 Examples of Usage . . . . . . . . . . . . . . . . . . . . 20 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 21 5.1 The P-Associated-URI header . . . . . . . . . . . . . . . 21 5.2 P-Called-Party-ID syntax . . . . . . . . . . . . . . . . . 21 5.3 P-Visited-Network-ID syntax . . . . . . . . . . . . . . . 21 5.4 P-Access-Network-Info syntax . . . . . . . . . . . . . . . 22 5.5 The P-Charging-Function-Addresses header . . . . . . . . . 23 5.6 The P-Charging-Vector header . . . . . . . . . . . . . . . 24 5.7 Table of new headers . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . 25 6.1 P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 25 6.2 P-Called-Party-ID . . . . . . . . . . . . . . . . . . . . 26 6.3 P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 26 6.4 P-Access-Network-Info . . . . . . . . . . . . . . . . . . 26 Garcia, et al. Expires December 22, 2002 [Page 2] Internet-Draft 3GPP SIP Extensions June 2002 6.5 P-Charging-Function-Addresses and P-Charging-Vector . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 28 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 29 Normative References . . . . . . . . . . . . . . . . . . . 30 Informational References . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31 Full Copyright Statement . . . . . . . . . . . . . . . . . 32 Garcia, et al. Expires December 22, 2002 [Page 3] Internet-Draft 3GPP SIP Extensions June 2002 1. Overall Applicability The SIP [1] extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. The mechanisms specified here were designed to satisfy the requirements specified in [6] for which either no general purpose solution was planned, where insufficient operational experience was available to understand if a general solution is needed, or where a more general solution is not yet mature. For more details about the assumptions made about these extensions, consult the Applicability subsection for each extension. 2. 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 RFC-2119 [2]. 3. Overview Third Generation Partnership Project (3GPP) has selected SIP as the protocol used to establish and tear down multimedia sessions in the context of its IP Multimedia Subsystem (IMS). (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [15] and 3GPP TS 24.229 [5]. 3GPP notified the SIP WG that existing SIP documents provided almost all the functionality needed to satisfy the requirements of the IMS, but that they required some additional functionality in order to use SIP for this purpose. These requirements [6] are documented in an Internet Draft which was submitted to the SIPPING Working Group. Some of these requirements are satisfied by chartered extensions, while other requirements were applicable to SIP, but not sufficiently general for the SIP Working Group to adopt. This document describes private extensions to address those requirements. Each extension, or set of related extensions is desribed in its own section below. 4. Private Headers 4.1 The P-Associated-URI header This extension allows a registrar to return a set of associated URIs for a registered address- of-record. We define the P-Associated-URI header field, used in the 200 OK response to a REGISTER request. The P-Associated-URI header field transports the set of Associated URIs to the registered address- of-record. Garcia, et al. Expires December 22, 2002 [Page 4] Internet-Draft 3GPP SIP Extensions June 2002 An associated URI is a URI that the service provider has allocated to a user for his own usage. A registrar contains information that allows an address-of-record URI to be associated with zero or more URIs. Usually, all these URIs (the address-of-record URI and the associated URIs) are allocated for the usage of a particular user. The extension to SIP we define in this document allows the UAC to know, upon a successful authenticated registration, which other URIs, if any, the service provider has associated to an address-of-record URI. Note that, generally speaking, the registrar does not register the associated URIs on behalf of the user. Only the address-of-record in the Request-URI of the REGISTER is registered and bound to the contact address. The only information conveyed is that the registrar is aware of other URIs to be used by the same user. It may be possible, however, that an application server (even the registrar itself) registers any of the associated URIs on behalf of the user by means of a third party registration. However, this third party registration is out of the scope of this document. A UAC MUST NOT assume that the associated URIs are registered. If a UAC wants to check whether any of the associated URIs is registered, it can do so by mechanisms specified outside this document, e.g., the UA may send a REGISTER request with the To header field value set to any of the associated URIs. If the associated URI is not registered, the UA MAY register it prior to its utilization. 4.1.1 Applicability statement This specification is applicable in SIP networks where the SIP provider is allocating the set of identities that a user can claim (in headers like the From field) in requests that it generates. It furthermore assumes that the provider knows the entire set of identities that a user can legitimately claim, and that the user is willing to restrict its claimed identities to that set. This is in contrast to normal SIP usage, where the From field is explicitly an end-user specified field. 4.1.2 Usage The registrar inserts the P-Associated-URI header field into the 200 OK response to a REGISTER request. The header field value is populated with a list containing zero or more URIs that are associated to the address-of-record. If the registrar supports the P-Associated-URI header field, and there are URIs to populate in it, the registrar always inserts the P- Garcia, et al. Expires December 22, 2002 [Page 5] Internet-Draft 3GPP SIP Extensions June 2002 Associated-URI header field in a 200 OK response to a REGISTER request, regardless of whether the REGISTER was an initial registration, re-registration, or de-registration and regardless of whether there are zero or more associated URIs. 4.1.2.1 Procedures at the UA A UAC may receive a P-Associated-URI header field in the 200 OK response for a REGISTER. The presence of the header field in the 200 OK response for a REGISTER request implies that the extension is supported at the registrar. The header value contains a list of zero or more associated URIs to the address-of-record URI. The UAC MAY use any of the associated URIs to populate the From header value, or any other SIP header value that provides information of the identity of the calling party, in a subsequent request. The UAC MAY check whether the associated URI is registered or not. This check can be done, e.g., by populating the To header value in a REGISTER sent to the registrar. As described in SIP, the 200 OK response may contain a Contact header field with zero or more values (zero meaning the address-of-record is not registered). 4.1.2.2 Procedures at the registrar A registrar that receives and authorizes a REGISTER request, may associate zero or more URIs with the address-of-record. A registrar that supports this specification MUST include a P- Associated-URI header field in the 200 OK response to a REGISTER request. In case the address-of-record under registration does not have any other SIP or SIPS URIs associated, the registrar MUST include an empty P-Associated-URI header value. In case the address-of-record under registration has one or more SIP or SIPS URIs associated, the registrar MUST include a comma separated list of URIs in the P-Associated-URI header value. 4.1.2.3 Procedures at the proxy This memo does not define any procedures at the proxy. 4.2 The P-Called-Party-ID header This header is inserted by a proxy server, typically in an INVITE, Garcia, et al. Expires December 22, 2002 [Page 6] Internet-Draft 3GPP SIP Extensions June 2002 en-route to its destination. The header is populated with the Request-URI received by the proxy in the request. The UAS identifies which ID out of several IDs the invitation was sent to (for example, the user may be using simultaneously a personal and a business SIP URI to receive invitation to sessions). The UAS may use the information to render different distinctive audiovisual alerting tones, depending on the ID used to receive the invitation to the session. Users in the 3GPP IP Multimedia Subsystem (IMS) may get one or several SIP URIs to identify the user. For instance, a user may get a business SIP URI and a personal one. As an example of utilization, the user may make available the business SIP URI to co-workers and may make available the personal SIP URI to members of the family. At a certain point in time, both the business SIP URI and the personal SIP URI are registered to the network, so both URIs can receive invitations to new sessions. When the user receives an invitation to join a session, he/she should be aware of which of the several registered SIP URIs this session was sent to. This requirement is stated in section 6.10.3 of the 3GPP requirements [6]. A problem arises during the terminating side of a session establishment, when the SIP server that is serving a user gets an INVITE, and the SIP sever retargets the SIP URI in the Request-URI field and replaces it by the SIP URI published by the user in the Contact header field of the REGISTER message at registration time. When the UAS receives the SIP request, it cannot determine which identity the request was sent towards. One can argue that the To header field conveys the semantics of the called user, and therefore, this extension is not needed. Although the To header field in SIP may convey the called party ID in most situations, there are two particular cases when the above assumption is not correct: 1. The session has been forwarded, redirected, etc. by previous SIP entities, before arriving to the called user's proxy. 2. The UAC builds an INVITE request and the To header field is not the same as the Request-URI. The problem of using the To header field is that this field is populated by the UAC and not modified by proxies in the path. If the UAC, for any reason, did not populate the To header field with the SIP URI of the destination user, then the destination user is not Garcia, et al. Expires December 22, 2002 [Page 7] Internet-Draft 3GPP SIP Extensions June 2002 able to distinguish which ID the session is intended to be received. Another possible solution to the problem is built upon the differentiation of the Contact header value between different URIs at registration time. The UA can differentiate each identity it registers by assigning a different Contact header value. For instance, when the UA registers sip:id1, the Contact value can be sip:id1@ua1; the registration of sip:id2 can be bound to the Contact value sip:id2@ua2. The solution described above assumes that the UA explicitly registers each of his address-of-record URIs, and therefore, it has full control over the contact address values assigned to each registration. However, in the case the UA does not have full control of his address- of-record URIs registered, because of, e.g., a 3rd party registration, the solution does not work. This is the case of the 3GPP registration, where the UA may have previously indicated to the network, by means outside SIP, that some other address-of-record URIs may be automatically registered when the UA registers a particular address- of-record URI. The requirement is covered in section 6.10.2.2 of the 3GPP requirements [6]. In the next paragraphs we show an example of the problem, in the case there has been some sort of call forwarding in the session, so that the UAC is not aware of the intended destination URI in the current INVITE. Example of the current behavior: a user registers his business URI to his/her registrar. F1 Register UA -> P1 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: sip:user1-business@example.com From: sip:user1-business@example.com;tag=456248 Call-ID: 843817637684230998sdasdh09 CSeq: 1826 REGISTER Contact: The user also registers his personal URI to his/her registrar. Garcia, et al. Expires December 22, 2002 [Page 8] Internet-Draft 3GPP SIP Extensions June 2002 F2 Register UA -> P1 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8 To: sip:user1-personal@example.com From: sip:user1-personal@example.com;tag=346249 Call-ID: 2Q3817637684230998sdasdh10 CSeq: 1827 REGISTER Contact: Later, the proxy/registrar receives an INVITE destined to the user's business SIP URI. We assume that this SIP INVITE has undergone some sort of forwarding in the past, and as such, the To header field is not populated with the SIP URI of the user. In this case, we assume that the session was initiated to sip:other-user@othernetwork.com, who has forwarded this session to sip:user1-business@example.com F3 INVITE P2 -> P1 INVITE sip:user1-business@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1 To: sip:other-user@othernetwork.com From: sip:another-user@anothernetwork.com;tag=938s0 Call-ID: 843817637684230998sdasdh09 CSeq: 101 INVITE The proxy P1 retargets the user and replaces the Request-URI by the SIP URI published during registration time in the Contact header value. F4 INVITE P1 -> UA INVITE sip:user1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128 Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1 To: sip:other-user@othernetwork.com From: sip:another-user@anothernetwork.com;tag=938s0 Call-ID: 843817637684230998sdasdh09 CSeq: 101 INVITE When the UAS receives the INVITE, it cannot determine whether it got the session invitation due to his registration of the business or the personal ID. Neither the UAS, nor proxies or application servers can provide this user a service based on the destination of the session. We solve this problem by allowing the proxy that is responsible for the home domain (as defined in SIP) of the user to insert a P-Called- Party-ID header that identifies the URI to which this session is destined. Garcia, et al. Expires December 22, 2002 [Page 9] Internet-Draft 3GPP SIP Extensions June 2002 4.2.1 Applicability statement The P-Called-Party-ID is applicable when the UAS needs to be aware of the intended address-of-record in the request, before the proxy retargeted to the contact address. The UAS may be interested in applying different audiovisual alerting effects or other filtering services, depending on the intended destination of the request. It is specially valuable when the UAS has registered several address-of- record URIs to his registrar, and therefore, is not aware of the address-of-record that hit his proxy/registrar unless this extension is used. Requirements for a more general solution are proposed in [14], but have not been adopted by SIP. 4.2.2 Usage The P-Called-Party-ID header field provides the UAS with the URI the request was addressed to, before a proxy retargeted the request. This information is intended to be used by subsequent proxies in the path or by the destination UAS. Typically, a SIP proxy, inserts the P-Called-Party-ID header field when it retargets the user by replacing the Request-URI with the contact address. The P-Called-Party-ID header value is populated with the contents of the Request-URI in the request. This extension MUST NOT be used in REGISTER request. 4.2.2.1 Procedures at the UA A UAC SHOULD NOT insert a P-Called-Party-ID header field in any SIP request or response. A UAS may receive a P-Called-Party-ID header field. The header is populated with the URI that the request was intended for. The UAS may use the value in the P-Called-Party-ID header field to provide services based on the destination of the called party, such as filtering of calls depending on the date and time, distinctive presentation services, distinctive alerting tones, etc. 4.2.2.2 Procedures at the proxy A proxy that has authoritative information about the user, may insert a P-Called-Party-ID header field in an INVITE, any other request that initiates a dialog or any other standalone request outside a dialog (such as OPTIONS) except REGISTER. The header is typically populated Garcia, et al. Expires December 22, 2002 [Page 10] Internet-Draft 3GPP SIP Extensions June 2002 with the contents of the Request-URI in the SIP request that the proxy received. It is necessary that the proxy which inserts the P-Called-Party-ID header have information about the user, in order to prevent a wrong delivery of the called party ID. This information may have been learnt through a registration process, for instance. A proxy or application server that receives a request containing a P- Called-Party-ID header may use the contents of the header to provide a service to the user based on the URI of that header value. 4.3 The P-Visited-Network-ID header 3GPP networks are composed of a collection of so called home networks, visited networks and subscribers. A particular home network may have roaming agreements with one or more visited networks. This has the effect that when a mobile terminal is roaming, it can use resources provided by the visited network in a transparent fashion. One of the conditions for a home network to accept a mobile roaming to a particular visited network is the presence of a roaming agreement between the home and the visited network. There is a need to indicate to the home network which is the visited network that the terminal is using. 3GPP terminals always register to the home network. The REGISTER request is proxied by the visited network to the home network. In the sake of a simple approach, it seems sensible that the visited network includes an identification that is known at the home network. This identification takes the form of a quoted text string or a token. The home network may use this identification to verify the existence of a roaming agreement with the visited network, and to authorize the registration through that visited network. 4.3.1 Applicability statement The P-Visited-Network-ID is applicable whenever the following circumstances are met: 1. There is transitive trust in intermediate proxies between the UA and the home network proxy via established relationships between the home network and the visited network, and generally supported by the use of standard security mechanisms, e.g. IPsec, AKA, or TLS. 2. An endpoint is using resources provided by one or more visited Garcia, et al. Expires December 22, 2002 [Page 11] Internet-Draft 3GPP SIP Extensions June 2002 networks (a network to which the user does not have a direct business relationship). 3. A proxy that is located in one of the visited networks wants to be identified at the user's home network. 4. There is no requirement that every visited network needs to be identified at the home network. Those networks that want to be identified make use of the extension defined in this document. Those networks that do not want to be identified do nothing. 5. A commonly pre-agreed text string or token identifies the visited network at the home network. 6. The UAC sends a REGISTER or dialog initiating request (e.g., INVITE) or a standalone request outside a dialog (e.g., OPTIONS) to a proxy in a visited network. 7. The request traverses, en route to its destination, a proxy in the home network, or its destination is the registrar in the home network. 8. The registrar or home proxy verifies and authorizes the usage of resources (e.g., proxies) in the visited network. 4.3.2 Usage The P-Visited-Network-ID header field is used to convey to the registrar or home proxy in the home network the identifier of a visited network. The identifier is a text string or token that is known by both the registrar or the home proxy at the home network and the proxies in the visited network. Typically, the home network authorizes the UA to roam to a particular visited network. This action requires an existing roaming agreement between the home and the visited network. The Visited Network Identifier header is populated with a quoted text string or token that identifies the proxy network at the home network. While it is possible for a home network to identify one or more visited networks by inspecting the domain name in the Via header fields, this approach has a heavy dependency on DNS. It is an option for a proxy to populate the via header with an IP address, for example, and in the absence of a reverse DNS entry, the IP address will not convey the desired information. Garcia, et al. Expires December 22, 2002 [Page 12] Internet-Draft 3GPP SIP Extensions June 2002 Any SIP proxy that receives a REGISTER request, a standalone request outside a dialog (e.g., OPTIONS), or a request that initiates a dialog, MAY insert a P-Visited-Network-ID header when it forwards the request. In case a REGISTER or other request is traversing different administrative domains (e.g., different visited networks), a SIP proxy may insert a new P-Visited-Network-ID header if the request does not contain a P-Visited-Network-ID header with the same network identifier as its own network identifier (e.g., if the request has traversed other different administrative domains). Note also that, there is not requirement for the header to be readable in the proxies. Therefore, a first proxy may insert an encrypted header that only the registrar can decrypt. If the request traverses another proxy (e.g., a second proxy) located in the same administrative domain as the first proxy, the second proxy will not be able to read the contents of the P-Visited-Network-ID header. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header, and therefore, it will insert a new P-Visited-Network-ID header value (hopefully with the same visited network identifier). When the request arrives at the registrar, it will notice that the header value is repeated (both the first and the second proxy inserted it). The decrypted values should be the same, because both proxies where part of the same administrative domain. While this situation is not desirable, it does not create any harm at the registrar. The P-Visited-Network-ID is normally used at registration. However, this extension does not preclude other usages. For instance, a proxy in a visited network that does not maintain registration state may insert a P-Visited-Network-ID header into any standalone request outside a dialog or a request that creates a dialog. At the time of writing this document, the only requests that create dialogs are INVITE, SUBSCRIBE [8] and REFER [13]. 4.3.2.1 Procedures at the UA This memo does not define any procedure at the UA. The UA MUST NOT insert the P-Visited-Network-ID header. 4.3.2.2 Procedures at the registrar and proxy A proxy that is located in a visited network MAY insert a P-Visited- Network-ID header field in any of the requests indicated in the Table 1. The header is populated with the contents of a text string or a token that identifies the administrative domain of the network where the proxy is operating at the user's home network. The home proxy or registrar in the home network may use the contents Garcia, et al. Expires December 22, 2002 [Page 13] Internet-Draft 3GPP SIP Extensions June 2002 of the P-Visited-Network-ID as an identifier of one or more visited networks that the request traversed. The home proxy or registrar may take local policy driven actions based on the existence or not of a roaming agreement between the home and the visited networks. This means, for instance, authorize the actions of the request based on the contents of the P-Visited-Network-ID header. A home proxy MUST delete this header when forwarding the message outside the home network administrative domain, in order to retain the user's privacy. A home proxy SHOULD delete this header, even when the request is not forwarded outside the home network administrative domain, when the home proxy has used the contents of the header or the request is routed based on the called party. 4.4 The P-Access-Network-Info header This section defines the private SIP extension header P-Access- Network-Info. This mechanism is useful in SIP-based networks that also provide layer 2/layer 3 connectivity through different access technologies. SIP User Agents may use this header to relay information about the access technology to serving proxies in their home network. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP terminal uses this header to pass information about the access network such as radio access technology and cell ID to its home service provider. There are many cases where a user is accessing their home network services via a particular access network. An example is a 3GPP wireless terminal that accesses a SIP server via the UMTS Radio Access Network. In this document we define an access network as the network providing the layer 2/layer 3 IP connectivity which in turn provides a user with access to the SIP capabilities or services provided by the home network of that user. In some cases, the home network may wish to know information about the type of access network that the UA is currently using. Some services are more suitable or less suitable depending on the access type, and some services are of more value to subscribers if the access network details are known in the home network. In other cases, the home network may simply wish to know crude location information in order to provide certain services to the user. For example, many of the location based services available in wireless networks today require the home network to know the identity Garcia, et al. Expires December 22, 2002 [Page 14] Internet-Draft 3GPP SIP Extensions June 2002 of the cell the user is being served by. Some regulatory requirements exist mandating that for cellular radio systems, the identity of the cell where an emergency call is established is made available to the emergency authorities. The home network may desire knowledge about the access network. This is achieved by defining a new private SIP extension header , P- Access-Network-Info. This header carries information relating to the access network between the UAC and its serving proxy in the home network. 4.4.1 Applicability Statement This mechanism is appropriate in environments where SIP services are dependent on SIP elements knowing details about the IP and lower layer technologies used by a UA to connect to the SIP network. Specifically, the extension requires that the UA know the access technology it is using, and that a proxy desires such information to provide services. Generally, SIP is built on the "Everything over IP and IP over everything" principle, where the access technology is not relevant for the operation of SIP. Since SIP systems generally should not care or even know about the access technology, this draft is not for general SIP usage. The information revealed in the P-Access-Network-Info header is potentially very sensitive. Proper protection of this information depends on the existence of specific business and security relationships amongst the proxies that will see messages containing this header. It also depends on explicit knowledge of the UA of the existence of those relationships. Therefore, this mechanism is only suitable in environments where the appropriate relationships are in place, and the UA has explicit knowledge that they exist. 4.4.2 Usage When a user agent generates a SIP request or response which it knows is going to be securely sent to its home network, it inserts a P- Access-Network-Info header into the message. This header contains information on the access network that the UA is using to get IP connectivity. The header is ignored by intermediate proxies between the UA and the home proxy. The home proxy can inspect the header and make use of the information contained there to provide services. Before proxying the request onwards, the home proxy strips the header from the message. Garcia, et al. Expires December 22, 2002 [Page 15] Internet-Draft 3GPP SIP Extensions June 2002 4.4.2.1 UAC behavior A UAC that supports this extension and is willing to disclose the related parameters MAY insert the P-Access-Network-Info header in any SIP message request. The UAC inserting this information MUST trust the home network proxy to protect its privacy by deleting the header before forwarding the message outside of the home proxy's domain. In order to do this it must also have transitive trust in intermediate proxies between it and the home network proxy. This trust is established by business agreements between the home network and the access network, and generally supported by the use of standard security mechanisms, e.g. IPsec, AKA, and TLS. This document does not define either the nature of the information or the messages where the P-Access-Network-Info needs to be inserted. Some systems may require that the P-Access-Network-Info header is only sent by the UAC when a secure connection to the proxy in the home network is present. For example, in 3GPP systems, the UAC MUST NOT send this header in the initial unauthenticated REGISTER request. 4.4.2.2 Proxy behavior A proxy MUST NOT insert or modify the P-Access-Network-Info header. The proxy in the home network may act upon any information in the P- Access-Network-Info header if it is present, to provide a different service depending on the network through which the UA is accessing the server. For example, for cellular radio access networks the home network may use the cell ID to provide basic localised services. A proxy, typically located in the home network, and therefore trusted, MUST delete the header when the SIP signaling is forwarded to a SIP server located in a non-trusted administrative network domain. The access network information is used by a home network and is of no interest to the destination network. 4.5 The P-Charging-Function-Addresses and P-Charging-Vector headers The P-Charging-Function-Addresses header is used to pass the addresses of entities that provide a charging function. The P- Charging-Vector header is used to pass charging correlation information. The affected UAs and proxies associated with a dialog or standalone transaction need to know the identities or addresses of the appropriate charging entities. They also need to pass correlation information so that the records generated and sent to the Garcia, et al. Expires December 22, 2002 [Page 16] Internet-Draft 3GPP SIP Extensions June 2002 charging entities may be properly associated for a coordinated billing effort. 3GPP has defined a distributed architecture that results in multiple network entities becoming involved in providing access and service. Operators need the ability and flexibility to charge for the access and services as they see fit. This requires coordination among the network entities, which includes correlating charging records generated from different entities that are related to the same session. There is a need to inform each network entity involved about common charging functions to receive the generated records. The solution provided by 3GPP is to define two types of charging functions: Charging Collection Function (CCF) and Event Charging Function (ECF). CCF is used for off-line charging and ECF is used for on-line charging. There may be a primary and secondary CCF and ECF, for redundancy purposes. The CCF and ECF addresses may be passed during the establishment of a dialog or standalone transaction. The details are specified in the 3GPP documents, see 3GPP TS 32.200 [4]. Additionally, a charging vector is defined that may be filled in during the establishment of a dialog or standalone transaction. The information inside the charging vector may be filled in by multiple network entities and retrieved by multiple network entities. There are three types of correlation information to be passed: IMS Charging ID (ICID), Inter Operator Identifiers (IOI) and access network charging information. ICID is a globally unique value that may be used to correlate charging records. There may an IOI generated from each side of the dialog to identify the network associated with each side. There is also expected to be access network charging information, which consists of network specific identifiers for the access level (e.g. 3GPP radio access network or IEEE 802.11b). The details of the information for each type of network are not described in this memo. The provided mechanism uses private headers "P-Charging-Function- Addresses" and "P-Charging-Vector" in either the initial request or subsequent response for a dialog or standalone transaction. Only one instance of each header is allowed in a particular request or response. The mechanisms by which an entity determines which values to populate in the P-Charging-Function-Addresses and P-Charging-Vector headers are specific to the local implementation and outside the scope of this document. Garcia, et al. Expires December 22, 2002 [Page 17] Internet-Draft 3GPP SIP Extensions June 2002 4.5.1 Applicability Statement The P-Charging-Function-Addresses and P-Charging-Vector headers are applicable within a single private network where coordination of charging is required. For example, according to the architecture specified in 3GPP TS 32.200 [4]. The P-Charging-Vector header is also applicable between private networks with a trust relationship. The P-Charging-Function-Addresses header is not sent outside of a private network. The P-Charging-Vector header is not sent to another network if there is no trust relationship. Neither header is applicable if the private network does not provide a charging function or manages charging in a way that does not require correlation of records from multiple network entities. The P-Charging-Function-Addresses header is applicable whenever the following circumstances are met: 1. A UAC sends a REGISTER or dialog initiating request (e.g., INVITE) or a standalone transaction request to a proxy in a private network. 2. A registrar, proxy or B2BUA that is located in the private network wants to generate charging records. 3. A registrar, proxy or B2BUA that is located in the private network has access to the addresses of the charging function entities for that network. The P-Charging-Vector header is applicable whenever the following circumstances are met: 1. A UAC sends a REGISTER or dialog initiating request (e.g., INVITE) or a standalone transaction request to a proxy in a private network. 2. A registrar, proxy or B2BUA that is located in the private network wants to generate charging records. 3. A proxy or B2BUA that is located in the private network has access to the charging correlation information for that network. 4. Optionally, a registrar, proxy or B2BUA that is part of the dialog or standalone transaction and is located in another private network wants to generate charging records and correlate the records with the other private network. Garcia, et al. Expires December 22, 2002 [Page 18] Internet-Draft 3GPP SIP Extensions June 2002 4.5.2 Usage 4.5.2.1 Procedures at the UA The UAC and UAS (originating and terminating UA) behave as usual. They are not required to understand the P-Charging-Function- Addresses header, but MAY retrieve the information if received. The UAC and UAS (originating and terminating UA) behave as usual. They are not required to understand the P-Charging-Vector header, but MAY retrieve the information if received. 4.5.2.2 Procedures at the Proxy The P-Charging-Function-Addresses and P-Charging-Vector headers are treated like any other unknown header by intermediate proxies. They simply forward it on towards the destination. If a proxy that supports this extension receives a request or response without the P-Charging-Function-Addresses or P-Charging- Vector header, it MAY insert a P-Charging-Function-Addresses or P- Charging-Vector header prior to forwarding the message. If a proxy that supports this extension receives a request or response with the P-Charging-Function-Addresses or P-Charging- Vector header, it MAY retrieve the information from the header to use with application specific logic, i.e. charging. The proxy SHOULD retain the P-Charging-Function-Addresses and P-Charging- Vector header in the outbound message. Per local application specific logic, the proxy MAY modify the contents of the P- Charging-Vector header prior to sending the message. If the next hop for the message is outside the closed network of the proxy, then the proxy MUST remove the P- Charging-Function-Addresses header and MAY remove the P-Charging- Vector header from the message. 4.5.2.3 Procedures at the Back to Back UA If a B2BUA that supports this extension receives a request or response without the P-Charging-Function-Addresses or P-Charging- Vector header, it MAY insert a P-Charging-Function-Addresses or P- Charging-Vector header prior to forwarding the message. If a B2BUA that supports this extension receives a request/response with the P-Charging-Function-Addresses or P-Charging-Vector header, the B2BUA SHOULD copy the headers from the receiving side UA to the sending side UA. Per local application specific logic, the B2BUA MAY modify the contents of the P-Charging-Vector header prior to sending the message. Garcia, et al. Expires December 22, 2002 [Page 19] Internet-Draft 3GPP SIP Extensions June 2002 4.5.2.4 Examples of Usage We present example in the context of the scenario presented in the Background section earlier in this document. The network diagram is replicated below: Scenario UA1----P1-----P2-----UA2 This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case P1 also inserts charging information. P1 then routes the call via P2 to UA2. Message sequence for INVITE using P-Charging-Function-Addresses and P-Charging-Vector: F1 INVITE UA1 -> P1 INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: . . . F2 INVITE P1 -> P2 INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: P-Charging-Function-Addresses: ccf1=135.18.232.565; ccf2=135.18.232.766 P-Charging-Vector: icid=1234bc9876e;orig-ioi=ACCESSDOMAIN . . . Garcia, et al. Expires December 22, 2002 [Page 20] Internet-Draft 3GPP SIP Extensions June 2002 5. Formal Syntax All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC- 2234 [3]. Further, several BNF definitions are inherited from SIP and are not repeated here. Implementers need to be familiar with the notation and contens of SIP and RFC 2234 to understand this document. 5.1 The P-Associated-URI header The syntax of the P-Associated-URI header is: P-Associated-URI = "P-Associated-URI" HCOLON (addr-spec *(COMMA addr-spec)) A registrar supporting this extension MUST insert a P-Associated-URI header field into a 200 OK response for a REGISTER request. If the address-of-record in the REGISTER does not have any associated URIs, the registrar still inserts the header field, although without any value in it. 5.2 P-Called-Party-ID syntax The P-Called-Party-ID header is defined as follows: P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec called-pty-id-spec = addr-spec This extension MUST NOT be used in REGISTER request. 5.3 P-Visited-Network-ID syntax The syntax of the P-Visited-Network-ID header is described as follows: P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON vnetwork *(COMMA vnetwork) vnetwork = (token / quoted-string) *(SEMI vnetwork-param) vnetwork-param = generic-param Example: P-Visited-Network-ID = "Network number 1", Other-Network Any SIP proxy that receives a REGISTER request, a standalone request outside a dialog (e.g., OPTIONS), or a request that initiates a dialog, MAY insert a P-Visited-Network-ID header when it forwards the request. In case a REGISTER or other request is traversing different Garcia, et al. Expires December 22, 2002 [Page 21] Internet-Draft 3GPP SIP Extensions June 2002 administrative domains (e.g., different visited networks), a SIP proxy may insert a new P-Visited-Network-ID header if the request does not contain a P-Visited-Network-ID header with the same network identifier as its own network identifier (e.g., if the request has traversed other different administrative domains). Note also that, there is not requirement for the header to be readable in the proxies. Therefore, a first proxy may insert an encrypted header that only the registrar can decrypt. If the request traverses another proxy (e.g., a second proxy) located in the same administrative domain as the first proxy, the second proxy will not be able to read the contents of the P-Visited-Network-ID header. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header, and therefore, it will insert a new P-Visited-Network-ID header value (hopefully with the same visited network identifier). When the request arrives at the registrar, it will notice that the header value is repeated (both the first and the second proxy inserted it). The decrypted values should be the same, because both proxies where part of the same administrative domain. While this situation is not desirable, it does not create any harm at the registrar. The P-Visited-Network-ID is normally used at registration. However, this extension does not preclude other usages. For instance, a proxy in a visited network that does not maintain registration state may insert a P-Visited-Network-ID header into any standalone request outside a dialog or a request that creates a dialog. 5.4 P-Access-Network-Info syntax The P-Access-Network-Info header is used to transport a set of parameters associated with the access characteristics of a particular network. The information in the P-Access-Network-Info is privacy sensitive. It is intended for use between the UA and proxies in the home network. The P-Access-Network-Info header is described as follows: Garcia, et al. Expires December 22, 2002 [Page 22] Internet-Draft 3GPP SIP Extensions June 2002 P-Access-Network-Info ="P-Access-Network-Info" HCOLON access-network-information access-network-information = access-type *(SEMI access-info] access-type ="IEEE-802.11a" / "IEEE-802.11b" / "3GPP-GERAN" / "3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" / "3GPP-CDMA2000" / token access-info = cgi-3gpp / utran-cell-id-3gpp / extension-access-info extension-access-info = gen-value cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string) utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL (token / quoted string) Access-info could contain additional information relating to the access network. The values for "cgi-3gpp" and "utran-cell-id-3gpp" are defined in 3GPP TS 24.229 [5]. 5.5 The P-Charging-Function-Addresses header The syntax for the P-Charging-Function-Addresses header is: p-charging-addr = "P-Charging-Function-Addresses" HCOLON charge-addr-params *(SEMI charge-addr-params) charge-addr-params = ccf1 / ccf2 / ecf1 / ecf2 / generic-param ccf1 = "ccf1" EQUAL gen-value ccf2 = "ccf2" EQUAL gen-value ecf1 = "ecf1" EQUAL gen-value ecf2 = "ecf2" EQUAL gen-value Example: P-Charging-Function-Addresses: ccf1=135.18.232.565; ccf2=135.18.232.766 Garcia, et al. Expires December 22, 2002 [Page 23] Internet-Draft 3GPP SIP Extensions June 2002 5.6 The P-Charging-Vector header The syntax for the P-Charging-Vector header is: p-charging-vector = "P-Charging-Vector" HCOLON charge-params *(SEMI charge-params) charge-params = icid / orig-ioi / term-ioi / generic-param icid = "icid" EQUAL gen-value orig-ioi = "orig-ioi" EQUAL gen-value term-ioi = "term-ioi" EQUAL gen-value Example: P-Charging-Vector: icid=1234bc9876e;orig-ioi=ACCESSDOMAIN A P-Charging-Vector header may be inserted into a request or response by any SIP node traversed by that message. However, there may only be one instance of a P-Charging-Vector in a SIP message. Further, a particular instance of P-Charging-Vector will always contain the icid parameter and may contain one instance of each of the other parameters: orig-ioi and term-ioi. Finally, it is expected that there will be network specific information included in the extension parameter generic-param. 5.7 Table of new headers Table 1 extends the headers defined in this document to Table 2 in SIP [1], section 4.1 of the SIP-specific event notification [8], tables 1 and 2 in the SIP INFO method [10], tables 1 and 2 in Reliability of provisional responses in SIP [9], tables 1 and 2 in the SIP UPDATE method [11], tables 1 and 2 in the SIP extension for Instant Messaging [12], and table 1 in the SIP REFER method [13]: Garcia, et al. Expires December 22, 2002 [Page 24] Internet-Draft 3GPP SIP Extensions June 2002 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ P-Associated-URI 2xx - - - - - o P-Called-Party-ID R amr - - - o o - P-Visited-Network-ID R ad - - - o o o P-Access-Network-Info dr - o - o o o P-Charging-Vector dr - o - o o o P-Charging-Function- dr - o - o o o Addresses Header field SUB NOT PRA INF UPD MSG REF ___________________________________________________________ P-Associated-URI - - - - - - - P-Called-Party-ID o - - - - o o P-Visited-Network-ID o - - - - o o P-Access-Network-Info o o o o o o o P-Charging-Vector o o o o o o o P-Charging-Function- o o o o o o o Addresses Table 1: Header field support 6. Security Considerations 6.1 P-Associated-URI The information returned in the P-Associated-URI header is not viewed as particularly sensitive. Rather, it is simply informational in nature, providing openness to the UAC with regard to the automatic association performed by the registrar. If end-to-end protection is not used at the SIP layer, it is possible for proxies between the registrar and the UA to modify the contents of the header value. This attack, while potentially annoying, should not have significant impacts. The lack of encryption, either end-to-end or hop-by-hop, may lead to leak some privacy regarding the list of authorized identities. For instance, a user who registers an address-of-record of sip:user1@example.com may get another SIP URI associated as sip:first.last@example.com returned in the P-Associated-URI header value. An eavesdropper could collect this information. If the user does not want to disclose the associated URIs, the eavesdropper could have gain access to private URIs. Therefore it is RECOMMENDED that this extension is used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop. Garcia, et al. Expires December 22, 2002 [Page 25] Internet-Draft 3GPP SIP Extensions June 2002 6.2 P-Called-Party-ID Due to the nature of the P-Called-Party-ID header, this extension does not introduce any significant security concern. It is possible for an attacker to modify the contents of the header. However, this modification will not cause any harm to the session establishment. An eavesdropper may collect the list identities a user is registered. This may have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop- by- hop. 6.3 P-Visited-Network-ID The P-Visited-Network-ID header assumes that there is trust relationship between a home network and one or more transited visited networks. It is possible for other proxies between the proxy in the visited network that inserts the header, and the registrar or the home proxy, to modify the value of P-Visited-Network-ID header. Therefore intermediaries participating in this mechanism MUST apply a hop-by-hop integrity protection mechanism such us IPsec or other available mechanisms in order to prevent such attacks. 6.4 P-Access-Network-Info This extension assumes that the access network is trusted by the UA (because the UA's home network has a trust relationship with the access network), as described earlier in this document. This extension assumes that the information added to the header by the UAC should be sent only to trusted entities and should not be used outside of the trusted administrative network domain. The home network uses the information contained in this header to provide additional services and UAs are expected to provide correct information. However, there are no security problems resulting from a UAC inserting incorrect information. Networks providing services based on the information carried in the P-access-network-info header will therefore need to trust the UAC sending the information. A rogue UAC sending false access network information will do no more harm than to restrict the user from using certain services. The mechanism provided in this document is designed primarily for private systems like 3GPP. Most security requirements are met by way of private standardised solutions. For instance, 3GPP will use the P-Access-Network-Info header to carry Garcia, et al. Expires December 22, 2002 [Page 26] Internet-Draft 3GPP SIP Extensions June 2002 relatively sensitive information like the cell ID. Therefore the information MUST NOT be sent outside of the 3GPP domain. The UAC is aware - if it is a 3GPP UAC - that it is operating within a trusted domain. The 3GPP UAC is aware of whether or not a secure connection to the home network domain for transporting SIP signalling, is currently available, and as such the sensitive information carried in the P- Access-Network-Info header should not be sent in any initial unauthenticated and unprotected requests (e.g. REGISTER). Any UAC that is using this extension and is not part of a private trusted domain should not consider the mechanism as secure and as such SHOULD NOT send sensitive information in the P-Access-Network- Info header. Any proxy that is operating in a private trust domain where the P- Access-Network-Info header is supported is required to delete the header, if it is present, from any message prior to forwarding it outside of the trusted domain. This is stated in section 8.2. Therefore, a home network that requires its UACs to send information in the P-access-network-info header must ensure that either that information is not of a sensitive nature or that the information is not sent outside of the trust domain. A proxy receiving a message containing the P-Access-Network-Info header from a non-trusted entity is not able to guarantee the validity of the contents. 6.5 P-Charging-Function-Addresses and P-Charging-Vector It is expected as normal behavior that proxies and B2BUAs within a closed network will modify the values of P-Charging-Function- Addresses and P-Charging-Vector and to insert these headers into a request for a dialog, e.g. INVITE request (or other requests or responses). However, these proxies and B2BUAs that share this information MUST have a trust relationship. If an untrusted entity were inserted between trusted entities, it could potentially interfere with the charging correlation mechanism or substitute a different charging function address. Therefore, an integrity protection mechanism such as IPsec or other available mechanisms MUST be applied in order to prevent such attacks. Since each trusted proxy or B2BUA may need to view or modify the values in the P-Charging-Function-Addresses and P-Charging-Vector headers, the protection should be applied on a hop-by-hop basis. Garcia, et al. Expires December 22, 2002 [Page 27] Internet-Draft 3GPP SIP Extensions June 2002 7. IANA Considerations This document defines several private SIP extension header fields (beginning with the prefix "P-" ). These extension headers should be included in the registry of SIP header fields defined in SIP [1]. As required by the SIP change process [7] the SIP extension header field name without the "P-" prefix should also be registered in association with these extensions. Expert review as required for this process was provided by the SIP Working Group. The following extensions are registered as private extension header fields: RFC Number: This document Header Field Name: P-Associated-URI Compact Form: none RFC Number: This document Header Field Name: P-Called-Party-ID Compact Form: none RFC Number: This document Header Field Name: P-Visisted-Network-ID Compact Form: none RFC Number: This document Header Field Name: P-Access-Network-Info Compact Form: none RFC Number: This document Header Field Name: P-Charging-Function-Addresses Compact Form: none RFC Number: This document Header Field Name: P-Charging-Vector Compact Form: none RFC Number: This document Header Field Name: P-Service-Route Compact Form: none RFC Number: This document Header Field Name: P-Original-Dialog-ID Compact Form: none The following extensions header names are reserved in case future standardization is warranted. They MUST NOT be used unless further documented by a standards-track RFC. Garcia, et al. Expires December 22, 2002 [Page 28] Internet-Draft 3GPP SIP Extensions June 2002 RFC Number: This document Header Field Name: Associated-URI Compact Form: none RFC Number: This document Header Field Name: Called-Party-ID Compact Form: none RFC Number: This document Header Field Name: Visisted-Network-ID Compact Form: none RFC Number: This document Header Field Name: Access-Network-Info Compact Form: none RFC Number: This document Header Field Name: Charging-Function-Addresses Compact Form: none RFC Number: This document Header Field Name: Charging-Vector Compact Form: none RFC Number: This document Header Field Name: Service-Route Compact Form: none RFC Number: This document Header Field Name: Original-Dialog-ID Compact Form: none 8. Contributors The extensions described in this document were originally specified in several documents. Miguel Garcia authored the P-Associated-URI, P-Called-Party-ID, and P-Visited-Network-ID headers. Duncan Mills authored the P-Access-Network-Info header. Eric Henrikson authored the P-Charging-Function-Addresses and P-Charging-Vector headers. Rohan Mahy assisted in the incorporation of these extensions into a single document. 9. Acknowledgments The authors would like to thank Andrew Allen, Gabor Bajko, Gonzalo Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Jonathan Rosenberg, Ya-Ching Tan and the 3GPP CN1 WG members for Garcia, et al. Expires December 22, 2002 [Page 29] Internet-Draft 3GPP SIP Extensions June 2002 their comments on this document. Normative References [1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), February 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] 3GPP, "TS 32.200, Version 5: Telecommunication Management; Charging management; Charging principles", June 2002. [5] 3GPP, "TS 24.229: IP Multimedia Subsystem (IMS) (Stage 3) - Release 5", June 2002. Informational References [6] Garcia, M., "3GPP requirements on SIP", draft-garcia-sipping- 3gpp-reqs-03 (work in progress), March 2002. [7] Bradner, S., Mankin, A. and R. Mahy, "Change Process for the Session Initiation Protocol (SIP)", draft-tsvarea-sipchange-02 (work in progress), May 2002. [8] Roach, A., "SIP-Specific Event Notification", draft-ietf-sip- events-05 (work in progress), March 2002. [9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in SIP", draft-ietf-sip-100rel-06 (work in progress), February 2002. [10] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [11] Rosenberg, J., "The Session Initiation Protocol UPDATE Method", draft-ietf-sip-update-02 (work in progress), May 2002. [12] Rosenberg, J. and B. Campbell, "Session Initiation Protocol Extension for Instant Messaging", draft-ietf-sip-message-04 (work in progress), May 2002. [13] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-05 (work in progress), June 2002. Garcia, et al. Expires December 22, 2002 [Page 30] Internet-Draft 3GPP SIP Extensions June 2002 [14] Barnes, M., Watson, M., Peterson, J. and C. Jennings, "Generic Request History Capability - Requirements", draft-watson- sipping-req-history-01 (work in progress), April 2002. [15] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2) - Release 5", June 2002. Authors' Addresses Miguel Garcia Ericsson Jorvas FIN-02420 Finland EMail: miguel.a.garcia@ericsson.com Eric Henrikson Lucent 11601 Willows Rd, Suite 100 Redmond, WA 98052 USA EMail: ehenrikson@lucent.com Duncan Mills Vodafone The Courtyard, 2-4 London Road Newbury, Berkshire RG14 1JX UK EMail: duncan.mills@vf.vodafone.co.uk Garcia, et al. Expires December 22, 2002 [Page 31] Internet-Draft 3GPP SIP Extensions June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis 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. Garcia, et al. Expires December 22, 2002 [Page 32]