doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

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" <sip:FriendsOfAlice@example.org>
+   From: "Alice" <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314159 INVITE
+   Contact: <sip:alice@pc33.example.org>
+   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: <sip:AlicesPTTServer.example.org>
+   Max-Forwards: 69
+   To: "Alice's Friends" <sip:FriendsOfAlice@example.org>
+   From: "Alice" <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314159 INVITE
+   Contact: <sip:alice@pc33.example.org>
+   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" <sip:bob@example.com>
+   From: "Alice's Friends"
+   <sip:FriendsOfAlice@example.org>;tag=2178309898
+   Call-ID: e60a4c784b6716
+   CSeq: 301166605 INVITE
+   Contact: <sip:AlicesConferenceFocus.example.org>
+   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" <sip:bob@example.com>
+   From: "Alice's Friends"
+   <sip:FriendsOfAlice@example.org>;tag=781299330
+   Call-ID: 6eb4c66a847710
+   CSeq: 478209 INVITE
+   Contact: <sip:BobsPTTServer.example.com>
+   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" <sip:bob@example.com>;tag=a6c85cf
+   From: "Alice's Friends"
+   <sip:FriendsOfAlice@example.org>;tag=2178309898
+   Call-ID: e60a4c784b6716
+   Contact: <sip:BobsPTTServer.example.com>
+   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: <sip:AlicesPTTServer.example.org>
+   To: "Alice's Friends"
+        <sip:FriendsOfAlice@example.org>;tag=c70ef99
+   From: "Alice"
+        <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314159 INVITE
+   Contact: <sip:AlicesConferenceFocus.example.org>
+   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: <sip:AlicesPTTServer.example.org>
+   To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314159 INVITE
+   Contact: <sip:AlicesConferenceFocus.example.org>
+   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: <sip:AlicesPTTServer.example.org>
+   Max-Forwards: 70
+   To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;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" <sip:FriendsOfAlice@example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;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" <sip:bob@example.com>;tag=d28119a
+   From: "Alice's Friends"
+        <sip:FriendsOfAlice@example.org>;tag=781299330
+   Call-ID: 6eb4c66a847710
+   CSeq: 478209 INVITE
+   Contact: <sip:bob@192.0.2.4>
+   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" <sip:bob@example.com>;tag=d28119a
+   From: "Alice's Friends"
+        <sip:FriendsOfAlice@example.org>;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" <sip:bob@example.com>;tag=a6670811
+   From: "Alice's Friends"
+        <sip:FriendsOfAlice@example.org>;tag=2178309898
+   Call-ID: e60a4c784b6716
+   Contact: <sip:BobsPTTServer.example.com>
+   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"
+        <sip:bob@example.com>;tag=a6670811
+   From: "Alice's Friends"
+        <sip:FriendsOfAlice@example.org>;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: <sip:AlicesConferenceFactoryURI.example.org> From: "Alice"
+   <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq:
+   314159 INVITE Contact: <sip:alice@pc33.example.org> 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: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314159 INVITE
+   Contact: <sip:AlicesPre-establishedSession@
+   AlicesPTTServer.example.org>
+   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: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;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: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314160 REFER
+   Refer-To: "Bob" <sip:bob@example.com>
+   Contact: <sip:alice@pc33.example.org>
+
+
+
+
+
+
+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: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314160 REFER
+   Contact: <sip:AlicesPre-establishedSession@
+   AlicesPTTServer.example.org>
+
+   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" <sip:bob@example.com>
+   From: "Alice" <sip:Alice@example.org>;tag=2178309898
+   Referred-By: <sip:Alice@example.org>
+   Call-ID: e60a4c784b6716
+   CSeq: 301166605 INVITE
+   Contact: <sip:AlicesConferenceFocus.example.org>
+   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" <sip:bob@example.com>
+   From: "Alice" <sip:Alice@example.org>;tag=781299330
+   Referred-By: <sip:Alice@example.org>
+   Call-ID: 6eb4c66a847710
+   CSeq: 478209 INVITE
+   Contact: <sip:BobsPTTServer.example.com>
+   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" <sip:bob@example.com>;tag=a6c85cf
+   From: "Alice" <sip:Alice@example.org>;tag=2178309898
+   Call-ID: e60a4c784b6716
+   Contact: <sip:BobsPTTServer.example.com>
+   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: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314161 NOTIFY
+   Contact:
+        <sip:AlicesPre-establishedSession@AlicesPTTServer.example.org>
+   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" <sip:bob@example.com>;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: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;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" <sip:bob@example.com>;tag=d28119a
+   From: "Alice's Friends"
+        <sip:FriendsOfAlice@example.org>;tag=781299330
+   Call-ID: 6eb4c66a847710
+   CSeq: 478209 INVITE
+   Contact: <sip:bob@192.0.2.4>
+   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" <sip:bob@example.com>;tag=d28119a
+   From: "Alice" <sip:Alice@example.org>;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" <sip:bob@example.com>;tag=a6670811
+   From: "Alice's Friends"
+        <sip:FriendsOfAlice@example.org>;tag=2178309898
+   Call-ID: e60a4c784b6716
+   Contact: <sip:BobsPTTServer.example.com>
+   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" <sip:bob@example.com>;tag=a6670811
+   From: "Alice" <sip:Alice@example.org>;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: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314162 NOTIFY
+   Contact: <sip:AlicesPre-establishedSession@
+   AlicesPTTServer.example.org>
+   Event: refer
+   Subscription-State: Active;Expires=60
+   Content-Type: message/sipfrag;version=2.0
+   Content-Length: 83
+
+   SIP/2.0 200 OK
+   To: "Bob" <sip:bob@example.com>;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: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99
+   From: "Alice" <sip:alice@example.org>;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]
+