summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4964.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4964.txt')
-rw-r--r--doc/rfc/rfc4964.txt1795
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]
+