SIPPING Working Group A. Allen Internet-Draft Research in Motion Expires: May 18, 2005 J. Holm Ericsson T. Hallin Motorola November 17, 2004 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the Open Mobile Alliance (OMA) Push to talk over Cellular (PoC) draft-allen-sipping-poc-p-headers-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 May 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the Open Mobile Alliance Allen, et al. Expires May 18, 2005 [Page 1] Internet-Draft PoC P-Headers November 2004 (OMA),For Push to talk over Cellular (PoC) along with their applicability, which is limited to the OMA PoC application. The P-headers are used for requesting and indicating the alerting mode of the handset which is particular to the PoC application. Table of Contents 1. Overall Applicability . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SIP Private Headers . . . . . . . . . . . . . . . . . . . . . 5 4.1 The P-Alerting-Mode header . . . . . . . . . . . . . . . . 5 4.1.1 Applicability statement for the P-Alerting-Mode header . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2 Usage of the P-Alerting-Mode header . . . . . . . . . 5 4.2 The P-Answer-State header . . . . . . . . . . . . . . . . 7 4.2.1 Applicability statement for the P-Answer-State header . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2 Usage of the P-Answer-State header . . . . . . . . . . 8 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 P-Alerting-Mode header syntax . . . . . . . . . . . . . . 11 5.2 P-Answer-State header syntax . . . . . . . . . . . . . . . 11 5.3 Table of new headers . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.1 P-Alerting-Mode . . . . . . . . . . . . . . . . . . . . . 12 6.2 P-Answer-State . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 9.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Allen, et al. Expires May 18, 2005 [Page 2] Internet-Draft PoC P-Headers November 2004 1. Overall Applicability The SIP extensions specified in this document make certain assumptions regarding network topology, 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 by the Open Mobile Alliance for Push-to-talk over cellular for which either no general-purpose solution was found, 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 BCP 14, RFC 2119 [2]. 3. Overview The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is specifying the Push-to-talk Over Cellular (PoC) service where SIP is the protocol used to establish half duplex media sessions across different participants. This document describes private extensions to address specific requirements of the PoC service and may not be applicable to the general Internet. The PoC service allows a SIP UA (PoC terminal) to establish a session To one or more SIP UAs simultaneously, usually initiated by the initiating user pushing a button. OMA has defined a collection of very stringent requirements in support of the PoC service. In order to provide the user with a satisfactory experience the initial session establishment from the time the user presses the button to the time they get an indication to speak must be minimized. The PoC terminal may support such hardware capabilities as a speaker phone and/or headset and software that provide the capability for the user to configure the PoC terminal to accept the session initiations immediately and play out the media as soon as it is received without requiring the intervention of the called user. This mode of operation is known as Automatic Answer mode. The user may alternatively configure the PoC terminal to first alert the user and require the user to manually accept the session invitation before media is accepted. This mode of operation is known as Manual Answer Allen, et al. Expires May 18, 2005 [Page 3] Internet-Draft PoC P-Headers November 2004 mode. The PoC terminal may support both or only one of these modes of operation. The user may change the Answer Mode (AM) configuration of the PoC terminal frequently based on their current circumstances and preference,(perhaps because the user is busy, or in a public area where she cannot use a speaker phone, etc). The OMA PoC Architecture utilizes SIP servers within the network that may perform such roles as a conference focus [12], a RTP translator or a policy server. A possible optimization to minimize the delay in the providing of the caller with an indication to speak is for the SIP network server to perform buffering of media packets in order to provide an early or unconfirmed indication back to the caller and allow the caller to start speaking before the called PoC terminal has answered. An event package and mechanisms for a SIP UA to indicate its current answer mode to a SIP Server in order to enable buffering are defined in [4]. In addition, particularly when multiple domains are involved in the session more than one intermediate SIP server may be involved in the signaling path for the session and the server that performs the buffering may not be the server that has knowledge of the current answer mode of the SIP UA that is the final destination for the SIP INVITE request. A mechanism is therefore required to allow a terminal that acts as a SIP UA or a network based server that acts as a SIP UAC to indicate a preference to the final destination SIP UAS to answer in a particular mode and for an intermediary SIP UAS to relay the unconfirmed indication in a response back towards the originating SIP UAC The answer mode requested in the SIP INVITE request may be determined based on the preference of the calling user and/or the authorization policies of the called user and the currently known answer mode setting of the called user's terminal. In addition to the basic answer mode settings of the terminal a privileged caller may request a Manual Answer Override (MAO) to request that the called terminal answer automatically even when it is in the Manual-Answer mode. This mode is needed for emergency service and also some other dispatch applications. This document proposes two new SIP header fields to support this optimization. One extension may be optionally included in a SIP INVITE request or a REFER that requests an INVITE to be sent by a SIP UAC to request that the terminating SIP UAS alert the user according to the mode indicated by the parameter contained in the header. The other extension may be optionally included in a response to a SIP INVITE request or in a NOTIFY sent as a result of a REFER that requests an INVITE to be sent to provide an indication from an intermediate node acting as a SIP back-to-back UA that it has information that hints that the terminating UA will likely answer automatically and therefore provides an unconfirmed indication back Allen, et al. Expires May 18, 2005 [Page 4] Internet-Draft PoC P-Headers November 2004 towards the inviting SIP UA to transmit media prior to receiving a final response from the final destination of the SIP INVITE request. Each extension, is described in its own section below. 4. SIP Private Headers 4.1 The P-Alerting-Mode header This extension allows a UAC to request that the terminating SIP UAS or group of UAS, alert the user according to the mode indicated by the parameter contained in the header when using the INVITE method to establish a session between two or more SIP UAs. It is possible that the INVITE request traverses one or more application servers that behave as back-to-back UAs, as the INVITE request is routed to the final destination UA. The intermediate node application servers can modify the value of P-Alerting-Mode header or insert this header in the INVITE if it is not already present. 4.1.1 Applicability statement for the P-Alerting-Mode header The P-Alerting-Mode header is applicable in SIP networks where: o There are SIP UAs that support different modes of accepting session (Auto-answer and Manual-Answer; o The inviting UAC can, as an option request the terminating SIP UAS to automatically or manually accept the session; o Where there are intermediate network SIP servers that act as back-to-back User Agents that are trusted and have knowledge of the current answer mode Setting of the terminating UAS; o The intermediate network SIP servers can perform authorization of the privilege of the inviter to request the requested answer mode; and, o This mode of operation is most applicable in environments that where half-duplex communications is the primary mode for the media. Such configurations are generally not applicable to the Internet as a whole where such trust relationships do not exist. 4.1.2 Usage of the P-Alerting-Mode header The P-Alerting-Mode header field provides a mechanism to express the inviting party's preferences towards the alerting of the calling user. Therefore, this header field is a hint or preferences from the inviting party towards the called party. It is at the discretion of the called party UAS to accept this hint or not. For instance, a UAS can decide to ignore this header field. Allen, et al. Expires May 18, 2005 [Page 5] Internet-Draft PoC P-Headers November 2004 A UAC MAY insert a P-Alerting-Mode header field into an INVITE request or a REFER request when it is desired to request the final destination UAS to alert the user manually about the incoming session, or to accept the session automatically and start the receiving media packets without requiring the intervention of the user. The final destination UAS may be identified by the value of the Request-URI in the INVITE request, the value of the Refer-To header field in a REFER request or using the mechanisms specified in [15] or [16]. The header field value is populated with one of the enumeration values "Manual", "Auto" or "MAO". When the value is "Manual" the UAC is requesting the UAS to alert the user and wait for the user to accept the session before returning a 200 OK response for the INVITE request. Normally in this mode the destination UAS will return a 180 Ringing provisional response when alerting the user as per [1]. When the value is set to "Auto" the UAC is requesting the UAS to not alert the user, accept the session and automatically return a 200 OK response without alerting the user and withou requiring the user to manually accept the session. Normally in this mode the destination UAS will return a 200 OK response upon receiving the INVITE as per [1]. When the value is "MAO" the UAC is requesting the UAS to accept the session and return a 200 OK response without requiring the user to manually accept the session even if the mode of the destination UAS is set to normally alert the user and require Manual acceptance. The use of the "Auto" and "MAO" values will likely be subject to authorization by the destination UAS or an intermediate back-to-back UA that acts as an authorization policy server on behalf of the destination UAS. 4.1.2.1 Procedures at the UA A UAC MAY insert a P-Alerting-Mode header field in an INVITE request or in a REFER request that requests another UA to send an INVITE request. A UAS can receive a P-Alerting-Mode header field in an INVITE request or a REFER request. If the UAS is the final destination of the request it MAY use the value of the P-Alerting-Mode header field to determine whether to first alert the user or accept the session automatically without requiring manual user acceptance. The semantics of the parameters are defined in 4.1.2. If the UAS cannot or does not accept the mode of session acceptance requested in the P-Alerting-Mode header field it can safely ignore this header field. If the UA is an intermediate node and not the final destination of the request it MAY, when acting as a UAC, insert a P-Alerting-Mode Allen, et al. Expires May 18, 2005 [Page 6] Internet-Draft PoC P-Headers November 2004 header field into an INVITE request that corresponds with an INVITE request or REFER request received while acting as a UAS. Alternatively the intermediate node MAY, when acting as a UAC, change the value of the P-Alerting-Mode header field in the outgoing INVITE from that received in the corresponding INVITE or REFER when acting as a UAS. This functionality is normally performed as part of the authorization process for the P-Alerting-Mode header field parameter or when the intermediate node has some hint from the intended destination UA of its current alerting mode. An event package and mechanisms for a UA to communicate its current alerting mode to an intermediate node is defined in [4]. 4.1.2.2 Procedures at the proxy This document does not define any procedure for proxy servers. Particularly, A SIP proxy do not need to understand the semantics of the P-Alerting-Mode header field. As part of the regular SIP rules for unknown headers, a proxy will forward unknown headers.. 4.2 The P-Answer-State header This header field MAY be included in a response to a SIP INVITE request or in a NOTIFY request sent as a result of a REFER request to send an INVITE request The purpose of the haeder field is to provide an indication from an intermediate node acting as a SIP back-to-back UA that is has information that hints that the terminating UA identified in the Request-URI of the request will likely answer automatically and therefore provides an unconfirmed indication back towards the inviting SIP UA to transmit media prior to receiving a final response from the final destination of the SIP INVITE request. 4.2.1 Applicability statement for the P-Answer-State header The P-Answer-State header is applicable in the following circumstances: o In networks where there are UAs that engage in half-duplex communication where there is not the possibility for the invited user to verbally acknowledge the answering of the session as is normal in full duplex communication; o Where the invited UA may automatically accept the session without manual acceptance; o The network also contains intermediate network SIP servers that act as back-to-back User Agents that are trusted; o The intermediate network SIP servers have knowledge of the current answer mode setting of the terminating UAS; and, o The intermediate network SIP servers can provide buffering of the media in order to reduce the time for the inviting user to send Allen, et al. Expires May 18, 2005 [Page 7] Internet-Draft PoC P-Headers November 2004 media. Such configurations are generally not applicable to the internet as a whole where such trust relationships do not exist. 4.2.2 Usage of the P-Answer-State header A UAS MAY insert a P-Answer-State header field in any 1XX or 2XX response that is allowed to contain an SDP answer in response to an SDP offer contained in an INVITE as specified in [13]. Typically the P-Answer-State header field is inserted in either a 183 Session Progress or a 200 OK response. A UA that receives a REFER request to send an INVITE MAY also insert a P-Answer-State header field in a NOTIFY request it sends as a result of the implicit subscription created by the REFER request. When the P-Answer-State header field contains the parameter "Unconfirmed" the UAC is indicating that it has information that hints that the final destination UAS for the INVITE request is likely to automatically accept the session but that this is unconfirmed and it is possible that the final destination UAS will first alert the user and require manual acceptance of the session or not accept the session request. This is referred to here as an "unconfirmed response". When the P-Answer-State header field contains the parameter "Confirmed" the UAC is indicating that the destination UAS has accepted the session and is ready to receive media. The parameter value of "Confirmed" has the usual semantics of an SDP answer and is included for completeness. The usual end to end SDP answer response semantics are referred to here as a "confirmed response". 4.2.2.1 Procedures at the UA A UAS MAY insert a P-Answer-State header field in any 1XX or 2XX response that is allowed to contain an SDP answer in response to an SDP offer contained in an INVITE request as specified in [13]. A response containing the P-Answer-State header field containing the parameter "Unconfirmed" MAY or MAY NOT contain an SDP answer. If the response contains an SDP answer then the sending UA MUST be ready to receive media as specified in [13]. A UAC that receives a 1XX or 2XX response containing a P-Answer-State header field containing the parameter "Unconfirmed" and an SDP answer MAY send media as specified in [13], however there is no guarantee that the media will be received by the final recipient. How a UAC confirms whether the media was or was not received by the final destination when it his received a 2XX "unconfirmed response" is application specific and outside of the scope of this document. If Allen, et al. Expires May 18, 2005 [Page 8] Internet-Draft PoC P-Headers November 2004 the application is a conference then the mechanism specified in [13] could be used to determine that the invited user joined. Alternatively a BYE request could be sent or the media could be placed on hold if the final destination UAS does not accept the session. An intermediate node that acts as a back-to-back UA and returns a 1XX or 2XX response in response to an INVITE request MAY insert a P-Answer-State header field containing the parameter "Unconfirmed" in the response if it has not yet received a "confirmed response" from the final destination UA. If the intermediate node UAS also includes SDP in the response along with a P-Answer-State header field containing the parameter "Unconfirmed" the intermediate node MUST be ready to receive media as specified in [13] and MAY buffer any media it receives until it receives a "confirmed response" from the final destination UA or until the buffer is full. Such an intermediate node may insert an SDP answer in the response it generates even if the "unconfirmed response" it received did not contain an SDP answer. An intermediate node that acts as a back-to-back UA and receives a REFER request to send an INVITE request to another UA as specified in [11] MAY insert a P-Answer-State header field containing the parameter "Unconfirmed" in the initial NOTIFY request sent in response to the REFER request if it has not yet received a "confirmed response" from the final destination UA and it has information that hints that the final destination UAS for the INVITE is likely to automatically accept the session. If the REFER was sent as part of an existing dialog established by an INVITE request and for which there has been a successful SDP offer-answer exchange according to [13] the intermediate node MUST be ready to receive media as specified in [13] and MAY buffer any media it receives until it receives a "confirmed response" from the final destination UA or until its buffer is full. An intermediate node that acts as a back-to-back UA and receives a 1XX or 2XX response in response to an INVITE request containing a P-Answer-State header field in the response SHOULD include the P-Answer-State header field unmodified in the 1XX or 2XX response it sends as a result of receiving that response. If the intermediate node that acts as a back-to-back UA sends a NOTIFY request according to [11] then the intermediate node UAC SHOULD include the P-Answer-State header field unmodified in the sipfrag of the response included in the body of the NOTIFY request. A UAC that receives a 1XX or 2XX response without a P-Answer-State Header or containing a P-Answer-State header field containing the parameter "Confirmed" SHALL treat it as a "confirmed response". Allen, et al. Expires May 18, 2005 [Page 9] Internet-Draft PoC P-Headers November 2004 If the UAS knows that the final destination UA is now ready to accept media and the UAS previously sent an "Unconfirmed response" the UAS SHOULD insert a P-Answer-State header field containing the parameter "Confirmed" in the response. An intermediate node that acts as a back-to-back UA that previously sent an initial NOTIFY request containing a P-Answer-State header field containing the parameter "Unconfirmed" that subsequently receives a "confirmed response" without a P-Answer-State header field in response to the INVITE request sent as a result of the REFER request SHOULD include a P-Answer-State header containing the parameter "Confirmed" in the subsequent NOTIFY request generated as a result of the "confirmed response". If the UAS knows that the final destination UA is ready to accept media and the UAS did not previously send an "Unconfirmed response" the UAS MAY insert a P-Answer-State header field containing the parameter "Confirmed" in the response. If an intermediate node that acts as a back-to-back UA and sends an INVITE request in response to a REFER request learns by receiving a "confirmed response" that the final destination UA is ready to accept media and the back-to-back UA did not previously include a P-Answer-State header containing the parameter "Unconfirmed" in the initial NOTIFY request sent in response to the REFER request then the back-to-back UA MAY insert a P-Answer-State header field containing the parameter "Confirmed" in the response if the "confirmed response" does not contain a P-Answer-State header. A UA that receives in response to a REFER request a NOTIFY request request containing a P-Answer-State header field containing the parameter "Unconfirmed" as either a SIP header or contained in a sipfrag in the body of the NOTIFY request received on a pre-existing dialog that was established by an INVITE request and for which there has been a successful SDP offer-answer exchange according to [13] then the UA MAY send media, however there is no guarantee that the media will be received by the final recipient that was indicated in the Refer-To header in the original REFER request. 4.2.2.2 Procedures at the proxy server This document does not define any procedure for proxy servers. Particularly, SIP proxy headers do not need to understand the semantics of the P-Answer-State header field. As part of the regular SIP rules for unknown headers, a proxy will forward unknown headers. Allen, et al. Expires May 18, 2005 [Page 10] Internet-Draft PoC P-Headers November 2004 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 contents of SIP [1] and RFC 2234 [3] to understand this document. 5.1 P-Alerting-Mode header syntax The syntax of the P-Alerting-Mode header is described as follows: P-Alerting-Mode = "P-Alerting-Mode" HCOLON alerting-type alerting-type = "Manual" / "Auto" / "MAO" 5.2 P-Answer-State header syntax The syntax of the P-Answer-State header is described as follows: P-Answer-State = "P-Answer-State" HCOLON answer-type answer-type = "Confirmed" / "Unconfirmed" 5.3 Table of new headers Table 1 extends the headers defined in this document to Table 2 in SIP [1], section 7.1 of the SIP-specific event notification [6], tables 1 and 2 in the SIP INFO method [8], tables 1 and 2 in Reliability of provisional responses in SIP [7], tables 1 and 2 in the SIP UPDATE method [9], tables 1 and 2 in the SIP extension for Instant Messaging [10], and table 1 in the SIP REFER method [11]: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ P-Alerting-Mode R - - - o - - P-Answer-State 1xx,2xx - - - o - - Header field SUB NOT PRA INF UPD MSG REF ___________________________________________________________ P-Alerting-Mode R - - - - - - o P-Answer-State R - o - - - - - Table 1: Header field support Allen, et al. Expires May 18, 2005 [Page 11] Internet-Draft PoC P-Headers November 2004 6. Security Considerations 6.1 P-Alerting-Mode The P-Alerting-Mode header requests that the destination UA behave in the way requested in this header. Although the destination UA does not have to accept what is requested the impact of an unauthorized intermediate attacker modifying this header or an unauthorized user sending an INVITE including the values "Auto" or "MAO" in this header could violate the privacy of the called user as a speaker phone may be engaged by the terminal and the callers voice may be heard by anyone in the vicinity. An INVITE request containing the P-Alerting-Mode header with the values "Auto" or "MAO" SHOULD be authenticated and authorized to ensure that the sender has the permission to trigger the callers terminal in an Auto-Answer mode of operation. The authorization MAY be performed by the destination UA or by a trusted intermediate node that performs authorization policy on behalf of the called party. When an intermediate node is used to perform such authorization it is RECOMMENDED that this extension is used in a secured trusted environment where transitive trust exists between the proxies and UAs if end-to-end protection is not used at the SIP layer. An eavesdropper cannot gain any useful information by obtaining the contents of this header. 6.2 P-Answer-State The information returned in the P-Answer-State header is not viewed as particularly sensitive. Rather, it is informational in nature, providing an indication to the UAC that delivery of any media sent as a result of an answer in this response is not guaranteed. An eavesdropper cannot gain any useful information by obtaining the contents of this header. If end-to-end protection is not used at the SIP layer, it is possible for proxies between the UAs to remove the header or modify the contents of the header value. This attack either denies the caller the knowledge that the callee has yet to be contacted or falsely indicates that the callee has yet to be contacted when they have already answered. It is therefore RECOMMENDED that this extension is used in a secured trusted environment where transitive trust exists between the proxies and UAs if end-to-end protection is not used at the SIP layer. 7. IANA Considerations This document defines two private SIP extension header fields Allen, et al. Expires May 18, 2005 [Page 12] Internet-Draft PoC P-Headers November 2004 (beginning with the prefix "P-" ) based on the registration procedures defined in RFC 3427 [5]. The following extensions are registered as private extension header fields: RFC Number: [To be added by the RFC Editor] Header Field Name: P-Alerting-Mode Compact Form: none RFC Number: [To be added by the RFC Editor] Header Field Name: P-Answer-State Compact Form: none Person to Contact: Andrew Allen, aallen@rim.com 8. Acknowledgments The authors would like to thank Miguel Garcia-Martin and the OMA POC Working Group members for their comments and support of this document. 9. References 9.1 Normative References [1] 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. [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. 9.2 Informative References [4] Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event Package and Data Format for Incoming Session Barring and Answer Mode in support for the Push-to-talk Over Cellular (PoC) service.", draft-garcia-sipping-poc-isb-am-00 (work in progress), April 2005. [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. Allen, et al. Expires May 18, 2005 [Page 13] Internet-Draft PoC P-Headers November 2004 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [8] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [9] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [10] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [11] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [12] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-03 (work in progress), October 2004. [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [14] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-06 (work in progress), October 2004. [15] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", draft-ietf-sipping-uri-list-conferencing-01 (work in progress), October 2004. [16] Camarillo, G., "Refering to Multiple Resources in the Session Initiation Protocol (SIP)", draft-ietf-sipping-multiple-refer-01 (work in progress), October 2004. Allen, et al. Expires May 18, 2005 [Page 14] Internet-Draft PoC P-Headers November 2004 Authors' Addresses Andrew Allen Research in Motion 122 West John Carpenter Parkway, Suite 430 Irving, Texas 75039 USA EMail: aallen@rim.com Jan Holm Ericsson Gotalandsvagen 220 Stockholm 12526 Sweden EMail: Jan.Holm@ericsson.com Tom Hallin Motorola 1501 W Shure Drive Arlington Heights Illinois 60004 USA EMail: thallin@motorola.com Allen, et al. Expires May 18, 2005 [Page 15] Internet-Draft PoC P-Headers November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Allen, et al. Expires May 18, 2005 [Page 16]