From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4964.txt | 1795 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1795 insertions(+) create mode 100644 doc/rfc/rfc4964.txt (limited to 'doc/rfc/rfc4964.txt') diff --git a/doc/rfc/rfc4964.txt b/doc/rfc/rfc4964.txt new file mode 100644 index 0000000..92e0ffc --- /dev/null +++ b/doc/rfc/rfc4964.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group A. Allen, Ed. +Request for Comments: 4964 Research in Motion (RIM) +Category: Informational J. Holm + Ericsson + T. Hallin + Motorola + September 2007 + + + The P-Answer-State Header Extension to the Session Initiation Protocol + for the Open Mobile Alliance Push to Talk over Cellular + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This document describes a private Session Initiation Protocol (SIP) + header (P-header) used by the Open Mobile Alliance (OMA) for Push to + talk over Cellular (PoC) along with its applicability, which is + limited to the OMA PoC application. The P-Answer-State header is + used for indicating the answering mode of the handset, which is + particular to the PoC application. + + + + + + + + + + + + + + + + + + + + + + + + + +Allen, et al. Informational [Page 1] + +RFC 4964 The P-Answer-State Header September 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Overall Applicability ...........................................3 + 3. Terminology .....................................................3 + 4. Background for the Extension ....................................4 + 5. Overview ........................................................5 + 6. The P-Answer-State Header .......................................6 + 6.1. Requirements ...............................................8 + 6.2. Alternatives Considered ....................................8 + 6.3. Applicability Statement for the P-Answer-State Header ......9 + 6.4. Usage of the P-Answer-State Header ........................10 + 6.4.1. Procedures at the UA (Terminal) ....................11 + 6.4.2. Procedures at the UA (PTT Server) ..................11 + 6.4.3. Procedures at the Proxy Server .....................14 + 7. Formal Syntax ..................................................14 + 7.1. P-Answer-State Header Syntax ..............................14 + 7.2. Table of the New Header ...................................14 + 8. Example Usage Session Flows ....................................15 + 8.1. Pre-Arranged Group Call Using On-Demand Session ...........15 + 8.2. 1-1 Call Using Pre-Established Session ....................21 + 9. Security Considerations ........................................28 + 10. IANA Considerations ...........................................28 + 10.1. Registration of Header Fields ............................28 + 11. Acknowledgements ..............................................29 + 12. References ....................................................29 + 12.1. Normative References .....................................29 + 12.2. Informative References ...................................30 + + + + + + + + + + + + + + + + + + + + + + + +Allen, et al. Informational [Page 2] + +RFC 4964 The P-Answer-State Header September 2007 + + +1. Introduction + + 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 a private extension + to address specific requirements of the PoC service and may not be + applicable to the general Internet. + + The PoC service allows a SIP User Agent (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. + +2. Overall Applicability + + The SIP extension specified in this document makes certain + assumptions regarding network topology and the existence of + transitive trust. These assumptions are generally NOT APPLICABLE in + the Internet as a whole. The mechanism specified here was 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 this extension, consult the applicability + statement in section 6.3. + +3. Terminology + + 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 [1]. + + The terms "PTT Server" (Push to talk Server), "Unconfirmed + Indication", "Unconfirmed Response", "Confirmed Indication", and + "Confirmed Response" are introduced in this document. + + A "PTT Server" as referred to here is a SIP network server that + performs the network-based functions for the Push to talk service. + The PTT Server can act as a SIP Proxy (as defined in [2]) or a back- + + + + + +Allen, et al. Informational [Page 3] + +RFC 4964 The P-Answer-State Header September 2007 + + + to-back UA (B2BUA) (as defined in [2]) based on the functions it + needs to perform. There can be one or more PTT Servers involved in a + SIP Push to talk session. + + An "Unconfirmed Indication" as referred to here is an indication that + the final target UA for the request has yet to be contacted and an + intermediate SIP node is indicating that it has information that + hints that the request is likely to be answered by the target UA. + + An "Unconfirmed Response" is a SIP 18x or 2xx response containing an + "Unconfirmed Indication". + + A "Confirmed Indication" as referred to here is an indication that + the target UA has accepted the session invitation and is ready to + receive media. + + A "Confirmed Response" is a SIP 200 (OK) response containing a + "Confirmed Indication" and has the usual semantics of a SIP 200 (OK) + response containing an answer (such as a Session Description Protocol + (SDP) answer). + +4. Background for the Extension + + The PoC terminal could support such hardware capabilities as a + speakerphone and/or headset and software that provide the capability + for the user to configure the PoC terminal to accept the session + invitations 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 can + 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 + mode. The PoC terminal could support both or only one of these modes + of operation. The user can 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 speakerphone, etc.). + + The OMA PoC Architecture [3] utilizes PTT Servers within the network + that can perform such roles as a conference focus [10], a real-time + transport protocol (RTP) translator, or a network policy enforcement + server. A possible optimization to minimize the delay in the + providing of the caller with an indication to speak is for the PTT + 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 PTT Server in order to enable buffering are defined + + + +Allen, et al. Informational [Page 4] + +RFC 4964 The P-Answer-State Header September 2007 + + + in [11]. In addition, particularly when multiple domains are + involved in the session, more than one PTT Server could be involved + in the signaling path for the session. Also, the PTT Server that + performs the buffering might not be the PTT 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 defined in + [12] that allows a terminal that acts as a SIP UA (or as a PTT Server + that acts as a SIP UA) to indicate a preference to the final + destination SIP User Agent Server (UAS) to answer in a particular + mode. However, a mechanism is required for a PTT Server to relay the + "Unconfirmed Indication" in a response back towards the originating + SIP User Agent Client (UAC). + +5. Overview + + The purpose of this extension is to support an optimization that + makes it possible for the network to provide a faster push to talk + experience, through an intermediate SIP user agent (PTT Server) + providing a SIP 200 (OK) response before the called UA does, and a + PTT Server buffering the media generated by the calling UA for replay + to the called UA when it answers. Because of the half-duplex nature + of the call, where media bursts are short typically in the order of + 10-30 seconds, the additional end-to-end latency can be tolerated, + and this considerably improves the user experience. However, the PTT + Server only can do this when there is a high probability that the + called SIP UA is in Automatic Answer mode. It is likely that PTT + Servers near the called UA have up-to-date knowledge of the answering + mode of the called UA, and due to the restricted bandwidth nature of + the cellular network, they can pass upstream an indication of the + called SIP UA's answering mode faster than the called UA can deliver + an automatically generated SIP 200 (OK) response. + + This document proposes a new SIP header field, the P-Answer-State + header field to support an "Unconfirmed Indication". The new SIP + header field can be optionally included in a response to a SIP INVITE + request, or in a sipfrag of a response included in a SIP NOTIFY + request sent as a result of a SIP REFER request that requests a SIP + INVITE request to be sent. The header field is used to provide an + indication from a PTT Server acting as a SIP proxy or back-to-back UA + that it has information that hints that the terminating UA will + likely answer automatically. This 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. No Supported or Require headers are needed because + the sender of the P-Answer-State header field does not depend on the + receiver to understand the extension. If the extension is not + understood, the header field is simply ignored by the recipient. The + extension is described below. + + + +Allen, et al. Informational [Page 5] + +RFC 4964 The P-Answer-State Header September 2007 + + + Thus, when a PTT Server forwards a SIP INVITE request and knows that + the called UA is likely to be in Automatic Answer mode, it also + generates a SIP 183 provisional response with a P-Answer-State header + field with a parameter of "Unconfirmed" to signal to upstream PTT + Servers that they can buffer the caller's media. + + A PTT Server that wishes to buffer the caller's media, upon seeing + the provisional response with a P-Answer-State header field with a + parameter of "Unconfirmed", absorbs it and generates a SIP 200 (OK) + response for the caller's SIP UA with an appropriate answer. + + When the called UA generates a SIP 200 (OK) response, the PTT Server + that generated the provisional response with a P-Answer-State header + field with a parameter "Unconfirmed" adds to the SIP 200 (OK) + response a P-Answer-State header field with a parameter of + "Confirmed". The SIP 200 (OK) response is absorbed by the PTT Server + that is buffering the caller's media, as it has already generated a + SIP 200 (OK) response. The buffering PTT Server then starts playing + out the buffered media. + +6. The P-Answer-State Header + + The purpose of the P-Answer-State header field is to provide an + indication from a PTT Server acting as a SIP proxy or back-to-back UA + that it has information that hints that the terminating UA identified + in the Request-URI of the request will likely answer automatically. + Thus, it enables the PTT Server to provide an "Unconfirmed + Indication" back towards the inviting SIP UA permitting it to + transmit media prior to receiving a final response from the final + destination of the SIP INVITE request. If a provisional response + contains the P-Answer-State header field with the value "Unconfirmed" + and does not contain an answer, then a receiving PTT Server can send + a SIP 200 (OK) response containing an answer and a P-Answer-State + header field with the value "Unconfirmed" if the PTT Server is + willing to perform media buffering. If the response containing the + P-Answer-State header field with the value "Unconfirmed" also + contains an answer, the PTT Server that included the P-Answer-State + header field and answer in the response is also indicating that it is + willing to buffer the media until a final "Confirmed Indication" is + received. + + The P-Answer-State header field can be included in a provisional or + final response to a SIP INVITE request or in the sipfrag of a SIP + NOTIFY request sent as a result of a SIP REFER request to send a SIP + INVITE request. If the P-Answer-State header field with value + "Unconfirmed" is included in a provisional response that contains an + answer, the PTT Server is leaving the decision of where to do + buffering to other PTT Servers upstream and will forward upstream a + + + +Allen, et al. Informational [Page 6] + +RFC 4964 The P-Answer-State Header September 2007 + + + "Confirmed indication" in a SIP 200 (OK) response when the final + response is received from the destination UA. + + NOTE It is not intended that multiple PTT Servers perform buffering + serially. If a PTT Server includes an answer along with P-Answer- + State header field with the value "Unconfirmed" in a provisional + response, then a receiving PTT Server can determine whether it + buffers the media or forwards the media and allows the downstrean PTT + Server that sent the "Unconfirmed Indication" to buffer the media. + It is intended that if a PTT Server buffers media, it does so until a + final "Confirmed Indication" is received, and therefore serial + buffering by multiple PTT Servers does not take place. + + The P-Answer-State header is only included in a provisional response + when the node that sends the response has knowledge that there is a + PTT Server acting as a B2BUA that understands this extension in the + signaling path between itself and the originating UAC. This PTT + Server between the sending node and the originating UAC will only + pass the header field on in either a SIP 200 (OK) response or in the + sipfrag (as defined in [4]) of a SIP NOTIFY request (as defined in + [5]) sent as a result of a SIP REFER request (as defined in [6]). + Such a situation only occurs with specific network topologies, which + is another reason why use of this header field is not relevant to the + general Internet. The originating UAC will only receive the + P-Answer-state header field in a SIP 200 (OK) response or in the + sipfrag of a SIP NOTIFY request. + + Provisional responses containing the P-Answer-State header field can + be sent reliably using the mechanism defined in [13], but this is not + required. This is a performance optimization, and the impact of a + provisional response sent unreliably (failing to arrive) is simply + that buffering does not take place. However, if the provisional + responses are sent reliably and the provisional response fails to + arrive, the time taken for the provisional response sender to time + out on the receipt of a SIP PRACK request is likely to be such that, + by the time the provisional response has been resent, the "Confirmed + Response" could have already been received. When provisional + responses that contain an answer are sent reliably, the 200 (OK) + response for the SIP INVITE request cannot be sent before the SIP + PRACK request is received. Therefore, sending provisional responses + reliably could potentially delay the sending of the "Confirmed + Response". + + + + + + + + + +Allen, et al. Informational [Page 7] + +RFC 4964 The P-Answer-State Header September 2007 + + +6.1. Requirements + + The OMA PoC service has initial setup performance requirements that + can be met by a PTT Server acting as a B2BUA spooling media from the + inviting PoC subscriber until one or more invited PoC subscribers + have accepted the session. The specific requirements are: + + REQ-1: An intermediate server MAY spool media from the inviting SIP + UA until one or more invited PoC SIP UASs has accepted the + invitation. + + REQ-2: An intermediate server that is capable of spooling media MAY + accept a SIP INVITE request from an inviting SIP UAC even if no + invited SIP UAS has accepted the SIP INVITE request if it has a + hint that the invited SIP UAS is likely to accept the request + without requiring user intervention. + + REQ-3: An intermediate server or proxy that is incapable of spooling + media or does not wish to, but has a hint that the invited SIP UAS + is likely to automatically accept the session invitation, MUST be + able to indicate back to another intermediate server that can + spool media that it has some hint that the invited UAS is likely + to automatically accept the session invitation. + + REQ-4: An intermediate server that is willing to spool media from + the inviting SIP UAC until one or more invited SIP UASs have + accepted the SIP INVITE request SHOULD indicate that it is + spooling media to the inviting SIP UAC. + +6.2. Alternatives Considered + + In order to meet REQ-3, a PTT Server needs to receive an indication + back that the invited SIP UA is likely to accept the SIP INVITE + request without requiring user intervention. In this case, the PTT + Server that has a hint that the invited SIP UAC is likely to accept + the request can include an answer state indication in the SIP 183 + (Session Progress) response or SIP 200 (OK) response. + + A number of alternatives were considered for the PTT Server to inform + another PTT Server or the inviting SIP UAC of the invited PoC SIP + UAS's answer mode settings. + + One proposal was to create a unique reason-phrase in the SIP 183 + response and SIP 200 (OK) response. This was rejected because the + reason phrases are normally intended for human readers and not meant + to be parsed by servers for special syntactic and semantic meaning. + + + + + +Allen, et al. Informational [Page 8] + +RFC 4964 The P-Answer-State Header September 2007 + + + Another proposal was to use a Reason header [14] in the SIP 183 + response and SIP 200 (OK) response. This was rejected because this + would be inconsistent with the intended use of the Reason header and + its usage is not defined for these response codes and would have + required creating and registering a new protocol identifier. + + Another proposal was to use a feature-tag in the returned Contact + header as defined in [15]. This was rejected because it was not a + different feature, but is an attribute of the session and can be + applied to many different features. + + Another proposal was to use a new SDP attribute. The choice of an + SDP parameter was rejected because the answer state applies to the + session and not to a media stream. + + The P-Answer-State header was chosen to give additional information + about the state of the SIP session progress and acceptance. Even + though the UAC sees that its offer has been answered and accepted, + the header lets the UAC know whether the invited PoC subscriber or + just an intermediary has accepted the SIP INVITE request. + +6.3. 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 can automatically accept the session without + user intervention; + + o The network also contains intermediate network SIP servers 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 have knowledge of the media + types and codecs likely to be accepted by 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 + media. + + + + + +Allen, et al. Informational [Page 9] + +RFC 4964 The P-Answer-State Header September 2007 + + + o The intermediate network SIP servers assume knowledge of the + network topology and the existence of similar intermediate network + SIP servers in the signaling path. + + Such configurations are generally not applicable to the Internet as a + whole where such trust relationships do not exist. + + In addition, security issues have only been considered for networks + that are trusted and use hop-by-hop security mechanisms with + transitive trust. Security issues with usage of this mechanism in + the general Internet have not been evaluated. + +6.4. Usage of the P-Answer-State Header + + A UAS, B2BUA, or proxy MAY include a P-Answer-State header field in + any SIP 18x or 2xx response that does not contain an offer, sent in + response to an offer contained in a SIP INVITE request as specified + in [7]. Typically, the P-Answer-State header field is included in + either a SIP 183 Session Progress or a SIP 200 (OK) response. A UA + that receives a SIP REFER request to send a SIP INVITE request MAY + also include a P-Answer-State header field in the sipfrag of a + response included in a SIP NOTIFY request it sends as a result of the + implicit subscription created by the SIP REFER request. + + When the P-Answer-State header field contains the parameter + "Unconfirmed", the UAS or proxy is indicating that it has information + that hints that the final destination UAS for the SIP 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. When the P-Answer-State header field + contains the parameter "Confirmed", the UAS or proxy 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 a SIP 200 (OK) response containing an answer and is + included for completeness. A parameter value of "Confirmed" is only + included in a SIP 200 (OK) response or in the sipfrag of a 200 (OK) + contained in the body of a SIP NOTIFY request. + + A received SIP 18x response without a P-Answer-State header field + SHOULD NOT be treated as an "Unconfirmed Response". A SIP 18x + response containing a P-Answer-State header field containing the + parameter "Confirmed" MUST NOT be treated as a "Confirmed Response" + because this is an invalid condition. + + A SIP 200 (OK) response without a P-Answer-State Header field MUST be + treated as a "Confirmed Response". + + + + +Allen, et al. Informational [Page 10] + +RFC 4964 The P-Answer-State Header September 2007 + + +6.4.1. Procedures at the UA (Terminal) + + A UAC (terminal) that receives an "Unconfirmed Response" containing + an answer MAY send media as specified in [7]; however, there is no + guarantee that the media will be received by the final recipient. + + How a UAC confirms whether or not the media was received by the final + destination when it has received a SIP 2xx response containing an + "Unconfirmed Indication" is application specific and outside of the + scope of this document. If the application is a conference then the + mechanism specified in [7] could be used to determine that the + invited user joined. Alternatively, a SIP BYE request could be + received or the media could be placed on hold if the final + destination UAS does not accept the session. + + A UAC (terminal) that receives, in response to a SIP REFER request, a + SIP NOTIFY request containing an "Unconfirmed Response" in a sipfrag + in the body of the SIP NOTIFY request related to a dialog for which + there has been a successful offer-answer exchange according to [5] + 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 SIP REFER request. The dialog could be + related either because the SIP REFER request was sent on the same + dialog or because the SIP REFER request contained a Target-Dialog + header, as defined in [16], that identified the dialog. + + A UAC (terminal) that receives an "Unconfirmed Response" that does + not contain an answer MAY buffer media until it receives another + "Unconfirmed Response" containing an answer or a "Confirmed + Response". + + There are no P-Answer-State procedures for a terminal acting in the + UAS role. + +6.4.2. Procedures at the UA (PTT Server) + + A PTT Server that receives a SIP INVITE request at the UAS part of + its back-to-back UA MAY include, in any SIP 18x or 2xx response that + does not contain an offer, a P-Answer-State header field with the + parameter "Unconfirmed" in the response if it has not yet received a + "Confirmed Response" from the final destination UA, and it has + information that hints that the final destination UA for the SIP + INVITE request is likely to automatically accept the session. + + A PTT Server that receives a SIP 18x response to a SIP INVITE request + containing a P-Answer-State header field with the parameter + "Unconfirmed" at the UAC part of its back-to-back UA MAY include the + P-Answer-State header field with the parameter "Unconfirmed" in a SIP + + + +Allen, et al. Informational [Page 11] + +RFC 4964 The P-Answer-State Header September 2007 + + + 2xx response that the UAS part of its back-to-back UA sends as a + result of receiving that response. Otherwise, a PTT Server that + receives a SIP 18x or 2xx response to a SIP INVITE request containing + a P-Answer-State header field at the UAC part of its back-to-back UA + SHOULD include the P-Answer-State header field unmodified in the SIP + 18x or 2xx response that the UAS part of its back-to-back UA sends as + a result of receiving that response. If the response sent by the UAS + part of its back-to-back UA is a SIP 18x response, then the + P-Answer-State header field included in the response MUST contain a + parameter of "Unconfirmed". + + The UAS part of the back-to-back UA of a PTT Server MAY include an + answer in the "Unconfirmed Response" it sends even if the + "Unconfirmed Response" received by the UAC part of the back-to-back + UA did not contain an answer. + + If a PTT Server receives a "Confirmed Response" at the UAC part of + its back-to-back UA, then the UAS part of its back-to-back UA MAY + include in the forwarded response a P-Answer-State header field with + the parameter "Confirmed". If the UAS part of its back-to-back UA + previously sent an "Unconfirmed Response" as part of this dialog, the + UAS part of its back-to-back UA SHOULD include in the forwarded + "Confirmed Response" a P-Answer-State header field with the parameter + "Confirmed". + + If the UAS part of the back-to-back UA of a PTT Server includes an + answer in a response along with a P-Answer-State header field with + the parameter "Unconfirmed", then the UAS part of its back-to-back UA + needs to be ready to receive media as specified in [7]. Also, it MAY + buffer any media it receives until it receives a "Confirmed Response" + from the final destination UA or until its buffer is full. + + A UAS part of the back-to-back UA of a PTT Server that receives a SIP + REFER request to send a SIP INVITE request to another UA, as + specified in [6], MAY generate a sipfrag of a SIP 200 (OK) response + containing a P-Answer-State header field with the parameter + "Unconfirmed" prior to the UAC part of its back-to-back UA receiving + a response to the SIP INVITE request, if it has information that + hints that the final destination UA for the SIP INVITE request is + likely to automatically accept the session. + + If the UAC part of a back-to-back UA of a PTT Server sent a SIP + INVITE request as a result of receiving a SIP REFER Request, receives + a SIP 18x or 2xx response containing a P-Answer-State header field at + the UAC part of its back-to-back UA, then the UAS part of its back- + to-back UA SHOULD include the P-Answer-State header field in the + sipfrag of the response contained in a SIP NOTIFY request. The + P-Answer-State header field that is contained in the sipfrag, + + + +Allen, et al. Informational [Page 12] + +RFC 4964 The P-Answer-State Header September 2007 + + + contains the parameters from the P-Answer-State from the original + response unmodified. This SIP NOTIFY request is the SIP NOTIFY + request that the UAS part of the back-to-back UA of the PTT Server + sends in response to the original SIP REFER request based upon + receiving the SIP 18x or 2xx response. If the sipfrag of the + response sent in the SIP NOTIFY request is a SIP 18x response, then + the P-Answer-State header field included in the sipfrag of the + response MUST contain a parameter of "Unconfirmed". If the UAC part + of its back-to-back UA receives a "Confirmed Response" that does not + contain a P-Answer-State header field, then the UAS part of its + back-to-back UA MAY include a P-Answer-State header field with the + parameter "Confirmed" in the sipfrag of the response contained in a + SIP NOTIFY request sent in response to the SIP REFER request. + + In the case where a PTT Server that's UAS part of its back-to-back UA + previously sent a SIP NOTIFY request as a result of the SIP REFER + request: + + 1) the SIP NOTIFY request contains a P-Answer-State header field with + the parameter "Unconfirmed" in the sipfrag of a response, and + + 2) the PTT Server subsequently receives at the UAC part of its back- + to-back UA a "Confirmed Response" to the SIP INVITE request. + + Such a PTT Server SHOULD include a P-Answer-State header field with + the parameter "Confirmed" in the sipfrag of the response included in + the subsequent SIP NOTIFY request that the UAS part of its back-to- + back UA sends as a result of receiving the "Confirmed Response". + + If the SIP REFER request is related to an existing dialog established + by a SIP INVITE request for which there has been a successful offer- + answer exchange, the UAS part of its back-to-back UA MUST be ready to + receive media as specified in [7]. Also, it MAY buffer any media it + receives until the UAC part of its back-to-back UA receives a + "Confirmed Response" from the final destination UA or until its + buffer is full. The dialog could be related either because the SIP + REFER request was sent on the same dialog or because the SIP REFER + request contained a Target-Dialog header, as defined in [16], that + identified the dialog. + + A PTT Server that buffers media SHOULD be prepared for the + possibility of not receiving a "Confirmed Response" and SHOULD + release the session if a "Confirmed Response" is not received before + the buffer overflows. + + + + + + + +Allen, et al. Informational [Page 13] + +RFC 4964 The P-Answer-State Header September 2007 + + +6.4.3. Procedures at the Proxy Server + + SIP proxy servers 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. + + A PTT Server that acts as a proxy MAY include a P-Answer-State header + field with the parameter "Unconfirmed" in a SIP 18x response that it + originates (in a manner compliant with [2]) if it has information + that hints that the final destination UA for the SIP INVITE request + is likely to automatically accept the session. + + A PTT Server that acts as a proxy MAY add a P-Answer-State header + field with the parameter "Confirmed" to a "Confirmed Response". + +7. Formal Syntax + + The mechanisms specified in this document is described in both prose + and an augmented Backus-Naur Form (BNF) defined in [8]. 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 [2] and [8] to understand this document. + +7.1. 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 + *(SEMI generic-param) + answer-type = "Confirmed" / "Unconfirmed" / token + +7.2. Table of the New Header + + Table 1 provides the additional table entries for the P-Answer-State + header needed to extend Table 2 in SIP [2], section 7.1 of the SIP- + specific event notification [5], Tables 1 and 2 in the SIP INFO + method [17], Tables 1 and 2 in Reliability of provisional responses + in SIP [13], Tables 1 and 2 in the SIP UPDATE method [18], Tables 1 + and 2 in the SIP extension for Instant Messaging [19], Table 1 in the + SIP REFER method [6], and Table 2 in the SIP PUBLISH method [20]: + + + + + + + + + + + +Allen, et al. Informational [Page 14] + +RFC 4964 The P-Answer-State Header September 2007 + + + Header field where proxy ACK BYE CAN INV OPT REG SUB + _______________________________________________________________ + P-Answer-State 18x,2xx ar - - - o - - - + + Header field NOT PRA INF UPD MSG REF PUB + _______________________________________________________________ + P-Answer-State R - - - - - - - + + Table 1: Additional Table Entries for the P-Answer-State Header + +8. Example Usage Session Flows + + For simplicity, some details such as intermediate proxies and SIP 100 + Trying responses are not shown in the following example flows. + +8.1. Pre-Arranged Group Call Using On-Demand Session + + The following flow shows Alice making a pre-arranged group call using + a Conference URI which has Bob on the member list. The session + initiation uses the on-demand session establishment mechanism where a + SIP INVITE request containing an SDP offer is sent by Alice's + terminal when Alice pushes her push to talk button. + + In this example, Alice's PTT Server acts a Call Stateful SIP Proxy + and Bob's PTT Server (which is aware that the current Answer Mode + setting of Bob's terminal is set to Auto Answer) acts as a B2BUA. + + For simplicity, the invitations by the Conference Focus to the other + members of the group are not shown in this example. + + + + + + + + + + + + + + + + + + + + + + +Allen, et al. Informational [Page 15] + +RFC 4964 The P-Answer-State Header September 2007 + + + Alice's Alice's Conference Bob's Bob's + Terminal PTT Server Focus PTT Server Terminal + | | | | | + |--(1)INVITE-->| | | | + | |--(2)INVITE-->| | | + | | |--(3)INVITE->| | + | | | |--(4)INVITE-->| + | | |<--(5)183----| | + | |<---(6)200----| | | + |<---(7)200----| | | | + |----(8)ACK--->| | | | + | |---(9)ACK---->| | | + | | | | | + |=====Early Media Session====>| | | + | | MEDIA | | + | | BUFFERING | | + | | | |<---(10)200---| + | | | |---(11)ACK--->| + | | |<--(12)200---| | + | | |--(13)ACK--->| | + | | | | | + | | |========Media Session======>| + | | | | | + | | | | | + + Figure 1: Pre-Arranged Group Call Using On-Demand Session + + 1 INVITE Alice -> Alice's PTT Server + + INVITE sip:FriendsOfAlice@example.org SIP/2.0 + Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 + Max-Forwards: 70 + To: "Alice's Friends" + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (SDP not shown) + + 2 INVITE Alice's PTT Server -> Conference Focus + + INVITE sip:FriendsOfAlice@example.org SIP/2.0 + Via: SIP/2.0/UDP + AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 + Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 + + + +Allen, et al. Informational [Page 16] + +RFC 4964 The P-Answer-State Header September 2007 + + + Record-Route: + Max-Forwards: 69 + To: "Alice's Friends" + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (SDP not shown) + + The Conference Focus explodes the Conference URI and Invites Bob + + 3 INVITE Conference Focus -> Bob's PTT Server + + INVITE sip:bob@example.com SIP/2.0 + Via: SIP/2.0/UDP + AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 + Max-Forwards: 70 + To: "Bob" + From: "Alice's Friends" + ;tag=2178309898 + Call-ID: e60a4c784b6716 + CSeq: 301166605 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (SDP not shown) + + 4 INVITE Bob's PTT Server -> Bob + + INVITE sip:bob@example.com SIP/2.0 + Via: SIP/2.0/UDP + BobsPTTServer.example.com;branch=z9hG4bKa27bc93 + Max-Forwards: 70 + To: "Bob" + From: "Alice's Friends" + ;tag=781299330 + Call-ID: 6eb4c66a847710 + CSeq: 478209 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (SDP not shown) + + + + +Allen, et al. Informational [Page 17] + +RFC 4964 The P-Answer-State Header September 2007 + + + 5 183 (Session Progress) Bob's PTT Server -> Conference Focus + + SIP/2.0 183 Session Progress + Via: SIP/2.0/UDP + AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 + To: "Bob" ;tag=a6c85cf + From: "Alice's Friends" + ;tag=2178309898 + Call-ID: e60a4c784b6716 + Contact: + CSeq: 301166605 INVITE + P-Answer-State: Unconfirmed + Content-Length: 0 + + 6 200 (OK) Conference Focus -> Alice's PTT Server + + SIP/2.0 200 OK + Via: SIP/2.0/UDP + AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 + Via: SIP/2.0/UDP + pc33.example.org;branch=z9hG4bKnashds8 + Record-Route: + To: "Alice's Friends" + ;tag=c70ef99 + From: "Alice" + ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Contact: + P-Answer-State: Unconfirmed + Content-Type: application/sdp + Content-Length: 131 + (SDP not shown) + + 7 200 (OK) Alice's PTT Server -> Alice + + SIP/2.0 200 OK + Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 + Record-Route: + To: "Alice's Friends" ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Contact: + P-Answer-State: Unconfirmed + Content-Type: application/sdp + Content-Length: 131 + + + + +Allen, et al. Informational [Page 18] + +RFC 4964 The P-Answer-State Header September 2007 + + + (SDP not shown) + + 8 ACK Alice -> Alice's PTT Server + + ACK sip:AlicesConferenceFocus.example.org SIP/2.0 + Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9 + Route: + Max-Forwards: 70 + To: "Alice's Friends" ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 ACK + Content-Length: 0 + + 9 ACK Alice's PTT Server -> Conference Focus + + ACK sip:AlicesConferenceFocus.example.org SIP/2.0 + Via: SIP/2.0/UDP + AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 + Via: SIP/2.0/UDP + pc33.example.org;branch=z9hG4bKnashds9 + Max-Forwards: 69 + To: "Alice's Friends" ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 ACK + Content-Length: 0 + + The early half-duplex media session between Alice and the Conference + Focus is now established, and the Conference Focus buffers the media + it receives from Alice. + + 10 200 (OK) Bob -> Bob's PTT Server + + SIP/2.0 200 OK + Via: SIP/2.0/UDP + BobsPTTServer.example.com;branch=z9hG4bKa27bc93 + To: "Bob" ;tag=d28119a + From: "Alice's Friends" + ;tag=781299330 + Call-ID: 6eb4c66a847710 + CSeq: 478209 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 131 + + (SDP not shown) + + + + +Allen, et al. Informational [Page 19] + +RFC 4964 The P-Answer-State Header September 2007 + + + 11 ACK Bob's PTT Server -> Bob + + ACK sip:bob@192.0.2.4 SIP/2.0 + Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93 + Max-Forwards: 70 + To: "Bob" ;tag=d28119a + From: "Alice's Friends" + ;tag=781299330 + Call-ID: 6eb4c66a847710 + CSeq: 478209 ACK + Content-Length: 0 + + 12 200 (OK) Bob's PTT Server -> Conference Focus + + SIP/2.0 200 OK + Via: SIP/2.0/UDP + AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 + To: "Bob" ;tag=a6670811 + From: "Alice's Friends" + ;tag=2178309898 + Call-ID: e60a4c784b6716 + Contact: + CSeq: 301166605 INVITE + P-Answer-State: Confirmed + Content-Type: application/sdp + Content-Length: 131 + + (SDP not shown) + + 13 ACK Conference Focus -> Bob's PTT Server + + ACK sip:BobsPTTServer.example.com SIP/2.0 + Via: SIP/2.0/UDP + AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 + Max-Forwards: 70 + To: "Bob" + ;tag=a6670811 + From: "Alice's Friends" + ;tag=2178309898 + Call-ID: e60a4c784b6716 + CSeq: 301166605 ACK + Content-Length: 0 + + The media session between Alice and Bob is now established and the + Conference Focus forwards the buffered media to Bob. + + + + + + +Allen, et al. Informational [Page 20] + +RFC 4964 The P-Answer-State Header September 2007 + + +8.2. 1-1 Call Using Pre-Established Session + + The following flow shows Alice making a 1-1 Call to Bob using a pre- + established session. A pre-established session is where a dialog is + established with Alice's PTT Server using a SIP INVITE SDP offer- + answer exchange to pre-negotiate the codecs and other media + parameters to be used for media sessions ahead of Alice initiating a + communication. When Alice initiates a communication to Bob, a SIP + REFER request is used to request Alice's PTT Server to send a SIP + INVITE request to Bob. In this example, Bob's terminal does not use + the pre-established session mechanism. + + In this example, Alice's PTT Server acts as a B2BUA and also performs + the Conference Focus function. Bob's PTT Server (which is aware that + the current Answer Mode setting of Bob's terminal is set to Auto + Answer) acts as a B2BUA. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allen, et al. Informational [Page 21] + +RFC 4964 The P-Answer-State Header September 2007 + + + Alice's Alice's Bob's Bob's + Terminal PTT Server / PTT Server Terminal + Conference Focus + | | | | + |-----(1)INVITE-- ----->| | | + |<-----(2)200-----------| | | + |-------(3)ACK--------->| | | + | | | | + | | | | + | | | | + |----(4)REFER---------->| | | + |<-----(5)202-----------| | | + | |----(6)INVITE---->| | + | | |--(7)INVITE---->| + | | | | + | |<----(8)183-------| | + |<---(9)NOTIFY----------| | | + |-----(10)200---------->| | | + | | | | + |=Early Media Session==>| | | + | MEDIA | | + | BUFFERING | | + | | |<---(11)200-----| + | | |---(12)ACK----->| + | |<----(13)200------| | + | |-----(14)ACK----->| | + | |===========Media Session==========>| + | | | | + |<---(15)NOTIFY---------| | | + |-----(16)200---------->| | | + | | | | + + Figure 2: 1-1 Call Using Pre-Established Session + + 1 INVITE Alice -> Alice's PTT Server + + INVITE sip:AlicesConferenceFactoryURI.example.org SIP/2.0 Via: + SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Max-Forwards: 70 + To: From: "Alice" + ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: + 314159 INVITE Contact: Content-Type: + application/sdp Content-Length: 142 + + (SDP not shown) + + + + + + + +Allen, et al. Informational [Page 22] + +RFC 4964 The P-Answer-State Header September 2007 + + + 2 200 (OK) Alice's PTT Server -> Alice + + SIP/2.0 200 OK + Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 + To: ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 131 + + (SDP not shown) + + 3 ACK Alice -> Alice's PTT Server + + ACK sip:AlicesPre-establishedSession@AlicesPTTServer.example.org + SIP/2.0 + Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9 + Max-Forwards: 70 + To: ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 ACK + Content-Length: 0 + + Alice's terminal has established a Pre-established Session with + Alice's PTT Server. All the media parameters are pre-negotiated for + use at communication time. + + Alice initiates a communication to Bob. + + 4 REFER Alice -> Alice's PTT Server + + REFER sip:AlicesPre-establishedSession@AlicesPTTServer.example.org + SIP/2.0 + Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 + Max-Forwards: 70 + To: ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314160 REFER + Refer-To: "Bob" + Contact: + + + + + + +Allen, et al. Informational [Page 23] + +RFC 4964 The P-Answer-State Header September 2007 + + + 5 202 (ACCEPTED) Alice's PTT Server -> Alice + + SIP/2.0 202 ACCEPTED + Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 + To: ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314160 REFER + Contact: + + 6 INVITE Conference Focus -> Bob's PTT Server + + INVITE sip:bob@example.com SIP/2.0 + Via: SIP/2.0/UDP + AlicesConferenceFocus.example.org;branch=z9hG4bk4721d8 + Max-Forwards: 70 + To: "Bob" + From: "Alice" ;tag=2178309898 + Referred-By: + Call-ID: e60a4c784b6716 + CSeq: 301166605 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (SDP not shown) + + 7 INVITE Bob's PTT Server -> Bob + + INVITE sip:bob@example.com SIP/2.0 + Via: SIP/2.0/UDP + BobsPTTServer.example.com;branch=z9hG4bKa27bc93 + Max-Forwards: 70 + To: "Bob" + From: "Alice" ;tag=781299330 + Referred-By: + Call-ID: 6eb4c66a847710 + CSeq: 478209 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (SDP not shown) + + + + + + + +Allen, et al. Informational [Page 24] + +RFC 4964 The P-Answer-State Header September 2007 + + + 8 183 (Session Progress) Bob's PTT Server -> Conference Focus + + SIP/2.0 183 Session Progress + Via: SIP/2.0/UDP + AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 + To: "Bob" ;tag=a6c85cf + From: "Alice" ;tag=2178309898 + Call-ID: e60a4c784b6716 + Contact: + CSeq: 301166605 INVITE + P-Answer-State: Unconfirmed + Content-Length: 0 + + 9 NOTIFY Alice's PTT Server -> Alice + + NOTIFY sip:alice@pc33.example.org SIP/2.0 + Via: SIP/2.0/UDP + AlicesPre-establishedSession@AlicesPTTServer.example.org; + branch=z9hG4bKnashds8 + Max-Forwards: 70 + To: ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314161 NOTIFY + Contact: + + Event: refer + Subscription-State: Active;Expires=60 + Content-Type: message/sipfrag;version=2.0 + Content-Length: 99 + + SIP/2.0 183 Session Progress + To: "Bob" ;tag=d28119a + P-Answer-State: Unconfirmed + + 10 200 (OK) Alice -> Alice's PTT Server + + SIP/2.0 200 OK + Via: SIP/2.0/UDP + AlicesPre-establishedSession@AlicesPTTServer.example.org; + branch=z9hG4bKnashds8 + To: ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314161 NOTIFY + + + + + + +Allen, et al. Informational [Page 25] + +RFC 4964 The P-Answer-State Header September 2007 + + + The early half-duplex media session between Alice and the Conference + Focus is now established and the Conference Focus buffers the media + it receives from Alice. + + 11 200 (OK) Bob -> Bob's PTT Server + + SIP/2.0 200 OK + Via: SIP/2.0/UDP + BobsPTTServer.example.com;branch=z9hG4bK927bc93 + To: "Bob" ;tag=d28119a + From: "Alice's Friends" + ;tag=781299330 + Call-ID: 6eb4c66a847710 + CSeq: 478209 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 131 + + (SDP not shown) + + 12 ACK Bob's PTT Server -> Bob + + ACK sip:bob@192.0.2.4 SIP/2.0 + Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bK927bc93 + Max-Forwards: 70 + To: "Bob" ;tag=d28119a + From: "Alice" ;tag=781299330 + Call-ID: 6eb4c66a847710 + CSeq: 478209 ACK + Content-Length: 0 + + F13 200 (OK) Bob's PTT Server -> Conference Focus + + SIP/2.0 200 OK + Via: SIP/2.0/UDP + AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 + To: "Bob" ;tag=a6670811 + From: "Alice's Friends" + ;tag=2178309898 + Call-ID: e60a4c784b6716 + Contact: + CSeq: 301166605 INVITE + P-Answer-State: Confirmed + Content-Type: application/sdp + Content-Length: 131 + + (SDP not shown) + + + + +Allen, et al. Informational [Page 26] + +RFC 4964 The P-Answer-State Header September 2007 + + + 14 ACK Conference Focus -> Bob's PTT Server + + ACK sip:BobsPTTServer.example.com SIP/2.0 + Via: SIP/2.0/UDP + AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 + Max-Forwards: 70 + To: "Bob" ;tag=a6670811 + From: "Alice" ;tag=1928301774 + Call-ID: e60a4c784b6716 + CSeq: 301166605 ACK + Content-Length: 0 + + The media session between Alice and Bob is now established and the + Conference Focus forwards the buffered media to Bob. + + 15 NOTIFY Alice's PTT Server -> Alice + + NOTIFY sip:alice@pc33.example.org SIP/2.0 + Via: SIP/2.0/UDP + AlicesPre-establishedSession@AlicesPTTServer.example.org; + branch=z9hG4bKnashds8 + Max-Forwards: 70 + To: ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314162 NOTIFY + Contact: + Event: refer + Subscription-State: Active;Expires=60 + Content-Type: message/sipfrag;version=2.0 + Content-Length: 83 + + SIP/2.0 200 OK + To: "Bob" ;tag=d28119a + P-Answer-State: Confirmed + + 16 200 (OK) Alice -> Alice's PTTServer + + SIP/2.0 200 OK + Via: SIP/2.0/UDP + AlicesPre-establishedSession@AlicesPTTServer.example.org; + branch=z9hG4bKnashds8 + To: ;tag=c70ef99 + From: "Alice" ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314162 NOTIFY + + + + +Allen, et al. Informational [Page 27] + +RFC 4964 The P-Answer-State Header September 2007 + + +9. Security Considerations + + 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. + + End-to-end protection is not appropriate because the P-Answer-State + header is used and added by proxies and intermediate UAs. As a + result, a "malicious" proxy between the UAs or attackers on the + signaling path could add or 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. The attack that falsely indicates that the callee + has yet to be contacted when they have already answered attack could + result in the caller deciding not to transmit media because they do + not wish to have their media stored by an intermediary even though in + reality the callee has answered. The attack that denies the callee + the additional knowledge that the callee has yet to be contacted does + not appear to be a significant concern since this is the same as the + situation when a B2BUA sends a 200 (OK) before the callee has + answered without the use of this extension. + + It is therefore necessary to protect the messages between proxies and + implementation SHOULD use a transport that provides integrity and + confidentially between the signaling hops. The Transport Layer + Security (TLS) [9] based signaling in SIP can be used to provide this + protection. + + Security issues have only been considered for networks that are + trusted and use hop-by-hop security mechanisms with transitive trust. + Security issues with usage of this mechanism in the general Internet + have not been evaluated. + +10. IANA Considerations + +10.1. Registration of Header Fields + + This document defines a private SIP extension header field (beginning + with the prefix "P-" ) based on the registration procedures defined + in RFC 3427 [21]. + + The following row has been added to the "Header Fields" section of + the SIP parameter registry: + + + + +Allen, et al. Informational [Page 28] + +RFC 4964 The P-Answer-State Header September 2007 + + + +----------------+--------------+-----------+ + | Header Name | Compact Form | Reference | + +----------------+--------------+-----------+ + | P-Answer-State | | [RFC4964] | + +----------------+--------------+-----------+ + +11. Acknowledgements + + The authors would like to thank Jon Peterson, Cullen Jennings, Jeroen + van Bemmel, Paul Kyzivat, Dale Worley, Dean Willis, Rohan Mahay, + Christian Schmidt, Mike Hammer, and Miguel Garcia-Martin for their + comments that contributed to the progression of this work. The + authors would also like to thank the OMA POC Working Group members + for their support of this document and, in particular, Tom Hiller for + presenting the concept of the P-Answer-State header to SIPPING at + IETF 62. + +12. References + +12.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [3] OMA, "Push to talk over Cellular - Architecture", + OMA-AD-PoC-V1_0_1-20061128-A, November 2006. + + [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, + November 2002. + + [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + + [6] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, April 2003. + + [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + [8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.1", RFC 4346, April 2006. + + + +Allen, et al. Informational [Page 29] + +RFC 4964 The P-Answer-State Header September 2007 + + +12.2. Informative References + + [10] Rosenberg, J., "A Framework for Conferencing with the Session + Initiation Protocol (SIP)", RFC 4353, February 2006. + + [11] Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event + Package and Data Format for Various Settings in Support for the + Push-to-Talk over Cellular (PoC) Service", RFC 4354, January + 2006. + + [12] Willis, D., Ed., and A. Allen, "Requesting Answering Modes for + the Session Initiation Protocol (SIP)", Work in Progress, June + 2007. + + [13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional + Responses in Session Initiation Protocol (SIP)", RFC 3262, June + 2002. + + [14] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header + Field for the Session Initiation Protocol (SIP)", RFC 3326, + December 2002. + + [15] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating + User Agent Capabilities in the Session Initiation Protocol + (SIP)", RFC 3840, August 2004. + + [16] Rosenberg, J., "Request Authorization through Dialog + Identification in the Session Initiation Protocol (SIP)", RFC + 4538, June 2006. + + [17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. + + [18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE + Method", RFC 3311, October 2002. + + [19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and + D. Gurle, "Session Initiation Protocol (SIP) Extension for + Instant Messaging", RFC 3428, December 2002. + + [20] Niemi, A., "Session Initiation Protocol (SIP) Extension for + Event State Publication", RFC 3903, October 2004. + + [21] 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. Informational [Page 30] + +RFC 4964 The P-Answer-State Header September 2007 + + +Authors' Addresses + + Andrew Allen (editor) + Research in Motion (RIM) + 102 Decker Court, Suite 100 + Irving, Texas 75062 + USA + + EMail: aallen@rim.com + + + Jan Holm + Ericsson + Tellusborgsvagen 83-87 + Stockholm 12526 + Sweden + + EMail: Jan.Holm@ericsson.com + + + Tom Hallin + Motorola + 1501 W Shure Drive + Arlington Heights, IL 60004 + USA + + EMail: thallin@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + +Allen, et al. Informational [Page 31] + +RFC 4964 The P-Answer-State Header September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + + 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, THE IETF TRUST 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. + +Intellectual Property + + 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. + + + + + + + + + + + + +Allen, et al. Informational [Page 32] + -- cgit v1.2.3