[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-allen-sipping-poc-p-headers) 00 01 02 03 04 05 RFC 4964

SIPPING Working Group                                      A. Allen, Ed.
Internet-Draft                                  Research in Motion (RIM)
Expires: December 27, 2005                                       J. Holm
                                                                Ericsson
                                                               T. Hallin
                                                                Motorola
                                                           June 25, 2005


 The P-Answer-State Header Extension to the Session Initiation Protocol
  (SIP) for the Open Mobile Alliance (OMA) Push to talk over Cellular
                                 (PoC)
            draft-allen-sipping-poc-p-answer-state-header-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 27, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a private Session InitiationProtocol(SIP)
   header (P-header) used by the Open Mobile Alliance (OMA),For Push to
   talk over Cellular (PoC) along with its applicability, which is



Allen, et al.           Expires December 27, 2005               [Page 1]

Internet-Draft          The P-Answer-State Header              June 2005


   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.

Requirements Language

   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].

Table of Contents

   1.  Overall Applicability  . . . . . . . . . . . . . . . . . . . .  4

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4

   4.  The P-Answer-State header  . . . . . . . . . . . . . . . . . .  5
     4.1   Requirements . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2   Alternatives Considered  . . . . . . . . . . . . . . . . .  7
     4.3   Applicability statement for the P-Answer-State header  . .  8
     4.4   Usage of the P-Answer-State header . . . . . . . . . . . .  8
       4.4.1   Procedures at the UA (terminal)  . . . . . . . . . . .  9
       4.4.2   Procedures at the UA (Intermediate Node) . . . . . . . 10
       4.4.3   Procedures at the proxy server . . . . . . . . . . . . 11

   5.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1   P-Answer-State header syntax . . . . . . . . . . . . . . . 12
     5.2   Table of the new header  . . . . . . . . . . . . . . . . . 12

   6.  Example Usage Session Flows  . . . . . . . . . . . . . . . . . 13
     6.1   Pre-arranged Group Call using On-demand Session  . . . . . 13
     6.2   1-1 Call using Pre-established Session . . . . . . . . . . 18

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
     8.1   Registration of Header Fields  . . . . . . . . . . . . . . 25
     8.2   Registration of Header Field Parameters  . . . . . . . . . 25

   9.  Changes since previous version . . . . . . . . . . . . . . . . 26

   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26

   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 26
     11.1  Normative References . . . . . . . . . . . . . . . . . . . 26
     11.2  Informative References . . . . . . . . . . . . . . . . . . 27



Allen, et al.           Expires December 27, 2005               [Page 2]

Internet-Draft          The P-Answer-State Header              June 2005


       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28

       Intellectual Property and Copyright Statements . . . . . . . . 29
















































Allen, et al.           Expires December 27, 2005               [Page 3]

Internet-Draft          The P-Answer-State Header              June 2005


1.  Overall Applicability

   The SIP extension specified in this document makes certain
   assumptions regarding network topology, and the availability 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
   subsection for the extension.

2.  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 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.

3.  Overview

   The PoC terminal may support such hardware capabilities as a speaker
   phone and/or headset and software that provide the capability for the
   user to configure the PoC terminal to accept the session 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 may
   alternatively configure the PoC terminal to first alert the user and
   require the user to manually accept the session invitation before
   media is accepted.  This mode of operation is known as Manual Answer
   mode.  The PoC terminal may support both or only one of these modes
   of operation.  The user may change the Answer Mode (AM) configuration
   of the PoC terminal frequently based on their current circumstances
   and preference,(perhaps because the user is busy, or in a public area



Allen, et al.           Expires December 27, 2005               [Page 4]

Internet-Draft          The P-Answer-State Header              June 2005


   where she cannot use a speaker phone, etc).

   The OMA PoC Architecture utilizes SIP servers within the network that
   may perform such roles as a conference focus [5], a 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 SIP network server to perform buffering of media
   packets in order to provide an early or unconfirmed indication back
   to the caller and allow the caller to start speaking before the
   called PoC terminal has answered.  An event package and mechanisms
   for a SIP UA to indicate its current answer mode to a SIP Server in
   order to enable buffering are defined in [6].  In addition,
   particularly when multiple domains are involved in the session more
   than one intermediate SIP server may be involved in the signaling
   path for the session and the server that performs the buffering may
   not be the server that has knowledge of the current answer mode of
   the SIP UA that is the final destination for the SIP INVITE request.
   A mechanism is to allow a terminal that acts as a SIP UA or a network
   based server that acts as a SIP UA to indicate a preference to the
   final destination SIP UAS to answer in a particular mode is defined
   in [7].  However a mechanism is required for an intermediary SIP UAS
   or proxy to relay the unconfirmed indication in a response back
   towards the originating SIP UAC.

   This document proposes a new SIP header field to support this
   unconfirmed indication.  The extension may be optionally included in
   a response to a SIP INVITE request or in a NOTIFY sent as a result of
   a REFER that requests an INVITE to be sent to provide an indication
   from an intermediate node acting as a SIP proxy or back-to-back UA
   that it has information that hints that the terminating UA will
   likely answer automatically and therefore provides an unconfirmed
   indication back towards the inviting SIP UA to transmit media prior
   to receiving a final response from the final destination of the SIP
   INVITE request.  The extension is described below.

4.  The P-Answer-State header

   The purpose of the P-Answer-State header field is to provide an
   indication from an intermediate node acting as a SIP proxy or back-
   to-back UA that is has information that hints that the terminating UA
   identified in the Request-URI of the request will likely answer
   automatically and therefore provides an unconfirmed indication back
   towards the inviting SIP UA to transmit media prior to receiving a
   final response from the final destination of the SIP INVITE request.
   If a Provisional response contains the P-Answer-State header with the
   value "Unconfirmed" and does not contain SDP then a receiving
   intermediate node may send a 200 OK response containing SDP and a
   P-Answer-State header with the value "Unconfirmed" if the



Allen, et al.           Expires December 27, 2005               [Page 5]

Internet-Draft          The P-Answer-State Header              June 2005


   intermediate node is willing to perform media buffering.  If the
   response containing the P-Answer-State header with the value
   "Unconfirmed" also contains SDP the intermediate node that inserted
   the header and SDP 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 MAY be included in a provisional or
   final response to a SIP INVITE request or in a NOTIFY request sent as
   a result of a REFER request to send an INVITE request.  If the
   P-Answer-State header field with value "Unconfirmed" is included in a
   provisional response that contains SDP the intermediate node is
   leaving the decision where to do buffering to other nodes upstream
   and will forward upstream a "Confirmed indication" in a 200 OK
   response when the final response is received from the destination UA.

   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
   B2BUA node that understands this extension in the signaling path
   between itself and the originating UAC that will only pass the header
   on in either a 200 OK response or in the sipfrag of a NOTIFY request.
   Such a situation only occurs with specific network topologies which
   is another reason why use of this header is not relevant to the
   general internet.  The originating UAC will only receive the
   P-Answer-state header in a 200 OK response or in the sipfrag of a
   NOTIFY request.

4.1  Requirements

   The OMA PoC service has initial setup performance requirements that
   can be met by an intermediate server (SIP 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 UAs has accepted the
      invitation.

   REQ-2: An intermediate server that is capable of spooling media MAY
      accept an invite request from an inviting SIP UAC even if no
      invited SIP UAS has accepted the invite request if it has a hint
      that the invited SIP UAC is likely to accept the request without
      requiring user intervention.








Allen, et al.           Expires December 27, 2005               [Page 6]

Internet-Draft          The P-Answer-State Header              June 2005


   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 UAC
      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 UAC is likely
      to automatically accept the session invitation.

   REQ-4: An intermediate server that is willing to spool media from the
      inviting SIP UA until one or more invited SIP UAs have accepted
      the invite SHOULD indicate that it is spooling media to the
      inviting SIP UAC.


4.2  Alternatives Considered

   In order to meet REQ-3, an intermediate server needs to receive an
   indication back that the invited SIP UA is likely to accept the
   invite request without requiring user intervention.  In this case,
   the intermediate server or proxy that has a hint that the invited SIP
   UAC is likely to accept the request can include an answer state
   indication in the 183 Session Progress or 200 OK response.

   A number of alternatives were considered for the intermediate server
   to inform the another intermediate server or the inviting SIP UAC of
   the invited PoC SIP UAs answer mode settings.

   One proposal was to create a unique reason-phrase in the 183 and 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.

   Another proposal was to use a Reason header [8] in the 183 and 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 [9].  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



Allen, et al.           Expires December 27, 2005               [Page 7]

Internet-Draft          The P-Answer-State Header              June 2005


   though the UAC sees that its SDP offer has been answered and
   accepted, the header lets the UAC know whether invited PoC subscriber
   has accepted the invite or just an intermediary has done the
   acceptance.

4.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 may automatically accept the session
      without manual acceptance;

      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 can provide buffering of
      the media in order to reduce the time for the inviting user to
      send media.

      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
   which are trusted and use hop by hop security mechanisms and security
   issues with usage of this mechanism in the general internet have not
   been evaluated.

4.4  Usage of the P-Answer-State header

   A UAS B2BUA or proxy MAY insert a P-Answer-State header field in any
   1XX or 2XX response that is allowed to contain an SDP answer in
   response to an SDP offer contained in an INVITE as specified in [2].
   Typically the P-Answer-State header field is inserted in either a 183
   Session Progress or a 200 OK response.  A UA that receives a REFER
   request to send an INVITE MAY also insert a P-Answer-State header



Allen, et al.           Expires December 27, 2005               [Page 8]

Internet-Draft          The P-Answer-State Header              June 2005


   field in a NOTIFY request it sends as a result of the implicit
   subscription created by the REFER request.

   When the P-Answer-State header field contains the parameter
   "Unconfirmed" the UAC or proxy is indicating that it has information
   that hints that the final destination UAS for the INVITE request is
   likely to automatically accept the session but that this is
   unconfirmed and it is possible that the final destination UAS will
   first alert the user and require manual acceptance of the session or
   not accept the session request.  This is referred to here as an
   "unconfirmed response".  When the P-Answer-State header field
   contains the parameter "Confirmed" the UAC 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 an SDP answer and is included for completeness.  The
   usual end to end SDP answer response semantics are referred to here
   as a "confirmed response".

4.4.1  Procedures at the UA (terminal)

   A UAC (terminal) that receives a 1XX or 2XX response containing a
   P-Answer-State header field containing the parameter "Unconfirmed"
   and an SDP answer MAY send media as specified in [2], however there
   is no guarantee that the media will be received by the final
   recipient.  How a UAC confirms whether the media was or was not
   received by the final destination when it his received a 2XX
   "unconfirmed response" is application specific and outside of the
   scope of this document.  If the application is a conference then the
   mechanism specified in [2] could be used to determine that the
   invited user joined.  Alternatively a 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 a 1XX or 2XX response without a
   P-Answer-State Header or containing a P-Answer-State header field
   containing the parameter "Confirmed" SHALL treat it as a "confirmed
   response".  A UAC (terminal) that receives in response to a REFER
   request a NOTIFY request containing a P-Answer-State header field
   containing the parameter "Unconfirmed" as either a SIP header or
   contained in a sipfrag in the body of the NOTIFY request received on
   a pre-existing dialog that was established by an INVITE request and
   for which there has been a successful SDP offer-answer exchange
   according to [2] then the UAC MAY send media, however there is no
   guarantee that the media will be received by the final recipient that
   was indicated in the Refer-To header in the original REFER request.

   There are no P-Answer-State procedures for a terminal acting in the
   UAS role.



Allen, et al.           Expires December 27, 2005               [Page 9]

Internet-Draft          The P-Answer-State Header              June 2005


4.4.2  Procedures at the UA (Intermediate Node)

   A UAS (Intermediate Node) MAY insert a P-Answer-State header field in
   any 1XX or 2XX response that is allowed to contain an SDP answer in
   response to an SDP offer contained in an INVITE request as specified
   in [2].  A response containing the P-Answer-State header field
   containing the parameter "Unconfirmed" MAY or MAY NOT contain an SDP
   answer.  If the response contains an SDP answer then the sending UA
   MUST be ready to receive media as specified in [2].

   An intermediate node that acts as a back-to-back UA and returns a 1XX
   or 2XX response in response to an INVITE request MAY insert a
   P-Answer-State header field containing the parameter "Unconfirmed" in
   the response if it has not yet received a "confirmed response" from
   the final destination UA.  If the intermediate node UAS also includes
   SDP in the response along with a P-Answer-State header field
   containing the parameter "Unconfirmed" the intermediate node MUST be
   ready to receive media as specified in [2] and MAY buffer any media
   it receives until it receives a "confirmed response" from the final
   destination UA or until the buffer is full.  Such an intermediate
   node may insert an SDP answer in the response it generates even if
   the "unconfirmed response" it received did not contain an SDP answer.

   An intermediate node that acts as a back-to-back UA and receives a
   REFER request to send an INVITE request to another UA as specified in
   [11] MAY insert a P-Answer-State header field containing the
   parameter "Unconfirmed" in the initial NOTIFY request sent in
   response to the REFER request if it has not yet received a "confirmed
   response" from the final destination UA and it has information that
   hints that the final destination UAS for the INVITE is likely to
   automatically accept the session.  If the REFER was sent as part of
   an existing dialog established by an INVITE request and for which
   there has been a successful SDP offer-answer exchange according to
   [2] the intermediate node MUST be ready to receive media as specified
   in [2] and MAY buffer any media it receives until it receives a
   "confirmed response" from the final destination UA or until its
   buffer is full.

   An intermediate node that acts as a back-to-back UA and receives a
   1XX or 2XX response in response to an INVITE request containing a
   P-Answer-State header field in the response SHOULD include the
   P-Answer-State header field unmodified in the 1XX or 2XX response it
   sends as a result of receiving that response.  If the intermediate
   node that acts as a back-to-back UA sends a NOTIFY request according
   to [11] then the intermediate node UAC SHOULD include the P-Answer-
   State header field unmodified in the sipfrag of the response included
   in the body of the NOTIFY request.




Allen, et al.           Expires December 27, 2005              [Page 10]

Internet-Draft          The P-Answer-State Header              June 2005


   A UAC (Intermediate Node) that receives a 1XX or 2XX response without
   a P-Answer-State Header or containing a P-Answer-State header field
   containing the parameter "Confirmed" SHALL treat it as a "confirmed
   response".  If the UAS (Intermediate Node) knows that the final
   destination UA is now ready to accept media and the UAS previously
   sent an "Unconfirmed response" the UAS SHOULD insert a P-Answer-State
   header field containing the parameter "Confirmed" in the response.

   An intermediate node that acts as a back-to-back UA that previously
   sent an initial NOTIFY request containing a P-Answer-State header
   field containing the parameter "Unconfirmed" that subsequently
   receives a "confirmed response" without a P-Answer-State header field
   in response to the INVITE request sent as a result of the REFER
   request SHOULD include a P-Answer-State header containing the
   parameter "Confirmed" in the subsequent NOTIFY request generated as a
   result of the "confirmed response".

   If the UAS knows that the final destination UA is ready to accept
   media and the UAS did not previously send an "Unconfirmed response"
   the UAS MAY insert a P-Answer-State header field containing the
   parameter "Confirmed" in the response.

   If an intermediate node that acts as a back-to-back UA and sends an
   INVITE request  in response to a REFER request learns by receiving a
   "confirmed response" that the final destination UA is ready to accept
   media and the back-to-back UA did not previously include a P-Answer-
   State header containing the parameter "Unconfirmed" in the initial
   NOTIFY request sent in response to the REFER request then the back-
   to-back UA MAY insert a P-Answer-State header field containing the
   parameter "Confirmed" in the response if the "confirmed response"
   does not contain a P-Answer-State header.

4.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 proxy MAY
   insert a P-Answer-State header field in a 1XX response that it
   originates compliant with [3] or add it to a 2XX response that
   contains an SDP answer in response to an SDP offer contained in an
   INVITE request as specified in [2].

   A proxy that returns a 1XX response in response to an INVITE request
   MAY insert a P-Answer-State header field containing the parameter
   "Unconfirmed" in  the response if it has not yet received a
   "confirmed response" from  the final destination UA.

   A proxy that receives a 1XX or 2XX response without a P-Answer-State



Allen, et al.           Expires December 27, 2005              [Page 11]

Internet-Draft          The P-Answer-State Header              June 2005


   Header or containing a P-Answer-State header field containing the
   parameter "Confirmed" SHALL for the purposes of this document treat
   it as a "confirmed response".

   If the proxy knows that the final destination UA is now ready to
   accept media and the proxy previously sent an "Unconfirmed response"
   the proxy SHOULD insert a P-Answer-State header field containing the
   parameter "Confirmed" in the response.

   If the proxy knows that the final destination UA is ready to accept
   media and the proxy did not previously send an "Unconfirmed response"
   the proxy MAY insert a P-Answer-State header field containing the
   parameter "Confirmed" in the response.

5.  Formal Syntax

   The mechanisms specified in this document is described in both prose
   and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [3].
   Further, several BNF definitions are inherited from SIP and are not
   repeated here.  Implementers need to be familiar with the notation
   and contents of SIP [3] and RFC 2234 [3] to understand this document.

5.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
      answer-type  = "Confirmed" / "Unconfirmed"

5.2  Table of the new header

   Table 1 extends the headers defined in this document to Table 2 in
   SIP [3], section 7.1 of the SIP-specific event notification [10]
   tables 1 and 2 in the SIP INFO method [11], tables 1 and 2 in
   Reliability of provisional responses in SIP [12], tables 1 and 2 in
   the SIP UPDATE method [13], tables 1 and 2 in the SIP extension for
   Instant Messaging [14], table 1 in the SIP REFER method [15], and
   table 2 in the SIP PUBLISH method [16]:

         Header field          where  proxy  ACK BYE CAN INV OPT REG SUB
         _______________________________________________________________
         P-Answer-State      1xx,2xx    ar    -   -   -   o   -   -   -

         Header field                        NOT PRA INF UPD MSG REF PUB
         _______________________________________________________________
         P-Answer-State          R            o   -   -   -   -   -   -

                                 Figure 1



Allen, et al.           Expires December 27, 2005              [Page 12]

Internet-Draft          The P-Answer-State Header              June 2005


6.  Example Usage Session Flows

   For simplicity some details such as intermediate proxies and 100
   Trying responses are not shown in the following example flows.  The
   term "policy server" is used here to mean a policy enforcement
   server.

6.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 containing SDP is sent by Alices's terminal when Alice
   pushes her push to talk button.

   In this example Alice's Policy Server acts a Call Stateful SIP Proxy
   and Bob's Policy 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.

      Alice's          Alices's      Conference       Bob's           Bob's
      Terminal       Policy Server      focus      Policy 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 2



Allen, et al.           Expires December 27, 2005              [Page 13]

Internet-Draft          The P-Answer-State Header              June 2005


   F1 INVITE Alice -> Alices's Policy Server

   INVITE sip:FriendsOfAlice@atlanta.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   Max-Forwards: 70
   To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sip:alice@pc33.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 142

   (SDP not shown)

   F2 INVITE Alice's Policy Server -> Conference Focus

   INVITE sip:FriendsOfAlice@atlanta.com SIP/2.0
   Via: SIP/2.0/UDP
   AlicesPolicyServer.atlanta.com;branch=z9hG4bK77ef4c2312983.1
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   Record-Route: <sip:AlicesPolicyServer.atlanta.com>
   Max-Forwards: 69
   To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sip:alice@pc33.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 142

   (SDP not shown)

   The Conference Focus explodes the Conference URI and Invites Bob

   F3 INVITE Conference Focus -> Bob's Policy Server

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP
   AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
   Max-Forwards: 70
   To: "Bob" <sip:bob@biloxi.com>
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;tag=2178309898
   Call-ID: e60a4c784b6716
   CSeq: 301166605 INVITE
   Contact: <sip:AlicesConferenceFocus.atlanta.com>
   Content-Type: application/sdp



Allen, et al.           Expires December 27, 2005              [Page 14]

Internet-Draft          The P-Answer-State Header              June 2005


    Content-Length: 142

   (SDP not shown)

   F4 INVITE Bob's Policy Server -> Bob

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bKa27bc93
   Max-Forwards: 70
   To: "Bob" <sip:bob@biloxi.com>
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;tag=781299330
   Call-ID: 6eb4c66a847710
   CSeq: 478209 INVITE
   Contact: <sip:BobsPolicyServer.biloxi.com>
   Content-Type: application/sdp
   Content-Length: 142

   (SDP not shown)

   F5 183 Session Progress Bob's Policy Server -> Conference Focus

   SIP/2.0 183 Session Progress
   Via: SIP/2.0/UDP
   AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
   To: "Bob" <sip:bob@biloxi.com>;tag=a6c85cf
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;tag=2178309898
   Call-ID: e60a4c784b6716
   Contact: <sip:BobsPolicyServer.biloxi.com>
   CSeq: 301166605 INVITE
   P-Answer-State: Unconfirmed
   Content-Length: 0

   F6 200 OK Conference Focus -> Alice's Policy Server

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
   AlicesPolicyServer.atlanta.com;branch=z9hG4bK77ef4c2312983.1
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   Record-Route: <sip:AlicesPolicyServer.atlanta.com>
   To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sip:AlicesConferenceFocus.atlanta.com>
   P-Answer-State: Unconfirmed
   Content-Type: application/sdp



Allen, et al.           Expires December 27, 2005              [Page 15]

Internet-Draft          The P-Answer-State Header              June 2005


    Content-Length: 131

   (SDP not shown)

   F7 200 OK Alice's Policy Server -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   Record-Route: <sip:AlicesPolicyServer.atlanta.com>
   To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sip:AlicesConferenceFocus.atlanta.com>
   P-Answer-State: Unconfirmed
   Content-Type: application/sdp
   Content-Length: 131

   (SDP not shown)

   F8 ACK Alice -> Alice's Policy Server

   ACK sip:AlicesConferenceFocus.atlanta.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
   Route: <sip:AlicesPolicyServer.atlanta.com>
   Max-Forwards: 70
   To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 ACK
   Content-Length: 0

   F9 ACK Alice's Policy Server -> Conference Focus

   ACK sip:AlicesConferenceFocus.atlanta.com SIP/2.0
   Via: SIP/2.0/UDP
   AlicesPolicyServer.atlanta.com;branch=z9hG4bK77ef4c2312983.1
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
   Max-Forwards: 69
   To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;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.



Allen, et al.           Expires December 27, 2005              [Page 16]

Internet-Draft          The P-Answer-State Header              June 2005


   F10 200 OK Bob -> Bob's Policy Server

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bKa27bc93
   To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;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)

   F11 ACK Bob's Policy Server -> Bob

   ACK sip:bob@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bKa27bc93
   Max-Forwards: 70
   To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;tag=781299330
   Call-ID: 6eb4c66a847710
   CSeq: 478209 ACK
   Content-Length: 0

   F12 200 OK Bob's Policy Server -> Conference Focus

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
   AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
   To: "Bob" <sip:bob@biloxi.com>;tag=a6670811
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;tag=2178309898 Call-ID:
   e60a4c784b6716
   Contact: <sip:BobsPolicyServer.biloxi.com>
   CSeq: 301166605 INVITE
   P-Answer-State: Confirmed
   Content-Type: application/sdp
   Content-Length: 131

   (SDP not shown)

   F13 ACK Conference Focus -> Bob's Policy Server

   ACK sip:BobsPolicyServer.biloxi.com SIP/2.0
   Via: SIP/2.0/UDP



Allen, et al.           Expires December 27, 2005              [Page 17]

Internet-Draft          The P-Answer-State Header              June 2005


   AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
   Max-Forwards: 70
   To: "Bob" <sip:bob@biloxi.com>;tag=a6670811
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;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.

6.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 Alices's Policy 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 is used to Request Alice's Policy Server to send an INVITE to
   Bob. In this example Bob's Terminal does not use the Pre-established
   Session mechanism.

   In this example Alice's Policy Server acts a B2BUA and also performs
   the Conference Focus function.  Bob's Policy 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.           Expires December 27, 2005              [Page 18]

Internet-Draft          The P-Answer-State Header              June 2005


      Alice's                  Alice's               Bob's           Bob's
      Terminal            Policy Server /       Policy 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 3

   F1 INVITE Alice -> Alices's Policy Server

   INVITE sip: AlicesConferenceFactoryURI.atlanta.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   Max-Forwards: 70
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sip:alice@pc33.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 142

   (SDP not shown)



Allen, et al.           Expires December 27, 2005              [Page 19]

Internet-Draft          The P-Answer-State Header              June 2005


   F2 200 OK Alice's Policy Server -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sip:AlicesPre-establishesSession@
   AlicesPolicyServer.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 131

   (SDP not shown)

   F3 ACK Alice -> Alice's Policy Server

   ACK sip:AlicesPre-establishesSession@AlicesPolicyServer.atlanta.com
   SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
   Max-Forwards: 70
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 ACK
   Content-Length: 0

   Alices's terminal has established a Pre-established Session with
   Alice's Policy Server.  All the media parameters are pre-negotiated
   for use at communication time.

   Alice initiates a Communication to Bob

   F4 REFER Alice -> Alices's Policy Server

   REFER sip:AlicesPre-establishesSession@AlicesPolicyServer.atlanta.com
   SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   Max-Forwards: 70
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 REFER
   Refer-To: "Bob" <sip:bob@biloxi.com>
   Contact: <sip:alice@pc33.atlanta.com>

   F5 202 ACCEPTED Alice's Policy Server -> Alice




Allen, et al.           Expires December 27, 2005              [Page 20]

Internet-Draft          The P-Answer-State Header              June 2005


   SIP/2.0 202 ACCEPTED
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 REFER
   Contact: <sip:AlicesPre-establishesSession@
   AlicesPolicyServer.atlanta.com>

   F6 INVITE Conference Focus -> Bob's Policy Server

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP
   AlicesConferenceFocus.atlanta.com;branch=z9hG4bk4721d8
   Max-Forwards: 70
   To: "Bob" <sip:bob@biloxi.com>
   From: "Alice" <sip:Alice@atlanta.com>;tag=2178309898
   Call-ID: e60a4c784b6716
   CSeq: 301166605 INVITE
   Contact: <sip:AlicesConferenceFocus.atlanta.com>
   Content-Type: application/sdp
   Content-Length: 142

   (SDP not shown)

   F7 INVITE Bob's Policy Server -> Bob

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bKa27bc93
   Max-Forwards: 70
   To: "Bob" <sip:bob@biloxi.com>
   From: "Alice" <sip:Alice@atlanta.com>;tag=781299330
   Call-ID: 6eb4c66a847710
   CSeq: 478209 INVITE
   Contact: <sip:BobsPolicyServer.biloxi.com>
   Content-Type: application/sdp
   Content-Length: 142

   (SDP not shown)

   F8 183 Session Progress Bob's Policy Server -> Conference Focus

   SIP/2.0 183 Session Progress
   Via: SIP/2.0/UDP
   AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
   To: "Bob" <sip:bob@biloxi.com>;tag=a6c85cf
   From: "Alice" <sip:Alice@atlanta.com>;tag=2178309898
   Call-ID: e60a4c784b6716



Allen, et al.           Expires December 27, 2005              [Page 21]

Internet-Draft          The P-Answer-State Header              June 2005


    Contact: <sip:BobsPolicyServer.biloxi.com>
   CSeq: 301166605 INVITE
   P-Answer-State: Unconfirmed
   Content-Length: 0

   F9 NOTIFY Alices's Policy Server -> Alice

   NOTIFY sip:alice@pc33.atlanta.com SIP/2.0
   Via: SIP/2.0/UDP AlicesPre-establishesSession@
   AlicesPolicyServer.atlanta.com;branch=z9hG4bKnashds8
   Max-Forwards: 70
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314161 NOTIFY
   Contact: <sip:AlicesPre-establishesSession@
   AlicesPolicyServer.atlanta.com>
   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@biloxi.com>;tag=d28119a
   P-Answer-State: Unconfirmed

   F10 202 ACCEPTED Alice -> Alice's Policy Server

   SIP/2.0 202 ACCEPTED
   Via: SIP/2.0/UDP AlicesPre-establishesSession@
   AlicesPolicyServer.atlanta.com;branch=z9hG4bKnashds8
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314161 NOTIFY

   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.

   F11 200 OK Bob -> Bob's Policy Server

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bK927bc93
   To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;tag=781299330
   Call-ID: 6eb4c66a847710



Allen, et al.           Expires December 27, 2005              [Page 22]

Internet-Draft          The P-Answer-State Header              June 2005


    CSeq: 478209 INVITE
   Contact: <sip:bob@192.0.2.4>
   Content-Type: application/sdp
   Content-Length: 131

   (SDP not shown)

   F12 ACK Bob's Policy Server -> Bob

   ACK sip:bob@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bK927bc93
   Max-Forwards: 70
   To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
   From: "Alice" <sip:Alice@atlanta.com>;tag=781299330
   Call-ID: 6eb4c66a847710
   CSeq: 478209 ACK
   Content-Length: 0

   F13 200 OK Bob's Policy Server -> Conference Focus

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
   AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
   To: "Bob" <sip:bob@biloxi.com>;tag=a6670811
   From: "Alice's Friends"
   <sip:FriendsOfAlice@atlanta.com>;tag=2178309898
   Call-ID: e60a4c784b6716
   Contact: <sip:BobsPolicyServer.biloxi.com>
   CSeq: 301166605 INVITE
   P-Answer-State: Confirmed
   Content-Type: application/sdp
   Content-Length: 131

   (SDP not shown)

   F14 ACK Conference Focus -> Bob's Policy Server

   ACK sip:BobsPolicyServer.biloxi.com SIP/2.0
   Via: SIP/2.0/UDP
   AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
   Max-Forwards: 70
   To: "Bob" <sip:bob@biloxi.com>;tag=a6670811
   From: "Alice" <sip:Alice@atlanta.com>;tag=1928301774
   Call-ID: e60a4c784b6716
   CSeq: 301166605 ACK
   Content-Length: 0

   The media session between Alice and Bob is now established and the



Allen, et al.           Expires December 27, 2005              [Page 23]

Internet-Draft          The P-Answer-State Header              June 2005


   Conference Focus forwards the buffered media to Bob.

   F15 NOTIFY Alices's Policy Server -> Alice

   NOTIFY sip:alice@pc33.atlanta.com SIP/2.0
   Via: SIP/2.0/UDP AlicesPre-establishesSession@
   AlicesPolicyServer.atlanta.com;branch=z9hG4bKnashds8
   Max-Forwards: 70
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314162 NOTIFY
   Contact: <sip:AlicesPre-establishesSession@
   AlicesPolicyServer.atlanta.com>
   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@biloxi.com>;tag=d28119a
   P-Answer-State: Confirmed

   F16 202 ACCEPTED Alice -> Alice's PolicyServer

   SIP/2.0 202 ACCEPTED
   Via: SIP/2.0/UDP AlicesPre-establishesSession@
   AlicesPolicyServer.atlanta.com;branch=z9hG4bKnashds8
   To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
   From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314162 NOTIFY

7.  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.

   If end-to-end protection is not used at the SIP layer, it is possible
   for proxies between the UAs to remove the header or modify the
   contents of the header value.  However end-to-end protection has not
   been considered as the P-Answer-State header is normally added by an
   intermediate node that acts either as a B2BUA or proxy.  This attack
   either denies the caller the knowledge that the callee has yet to be



Allen, et al.           Expires December 27, 2005              [Page 24]

Internet-Draft          The P-Answer-State Header              June 2005


   contacted or falsely indicates that the callee has yet to be
   contacted when they have already answered.  It is therefore
   RECOMMENDED that this extension is used in a secured trusted
   environment where transitive trust exists between the proxies and
   UAs.

   If end-to-end security mechanisms are to be used issues such as key
   exchange between endpoints and intermediate network nodes need to be
   considered."

8.  IANA Considerations

8.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 [17].

   The following rows shall be added to the "Header Fields" section of
   the SIP parameter registry:

             +----------------+--------------+-----------+
             | Header Name    | Compact Form | Reference |
             +----------------+--------------+-----------+
             | P-Answer-State |              | [RFCXXXX] |
             +----------------+--------------+-----------+

   Editor Note: [RFCXXXX] should be replaced with the designation of
   this document.

8.2  Registration of Header Field Parameters

   This document defines parameters for the header fields defined in the
   preceding section.  The header field named "P-Answer-State" may take
   the values "Unconfirmed", or "Confirmed".

   The following rows shall be added to the "Header Field Parameters and
   Parameter Values" section of the SIP parameter registry:

  +----------------+----------------+-------------------+-----------+
  | Header Field   | Parameter Name | Predefined Values | Reference |
  +----------------+----------------+-------------------+-----------+
  | P-Answer-State | Unconfirmed    | Yes               | [RFCXXXX] |
  | P-Answer-State | Confirmed      | Yes               | [RFCXXXX] |
  +----------------+----------------+-------------------+-----------+

   Editor Note: [RFCXXXX] should be replaced with the designation of
   this document.



Allen, et al.           Expires December 27, 2005              [Page 25]

Internet-Draft          The P-Answer-State Header              June 2005


9.  Changes since previous version

   This document is based upon the definition of the P-Answer-State
   header in [18] with the following changes:

      The P-Alerting-Mode header definition has been removed as this
      extension will be progressed separately as a standards track RFC
      [7].

      The text on security considerations has been improved.

      PUBLISH method has been added to figure 1.

      The procedures at the UA text has been split into UA-terminal and
      UA- intermediate-node for better clarity.

      A session flow example section has been added.

      Various nits and editorial corrections have been made.

10.  Acknowledgements

   The authors would like to thank 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.

11.  References

11.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. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

   [3]  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.

   [4]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.






Allen, et al.           Expires December 27, 2005              [Page 26]

Internet-Draft          The P-Answer-State Header              June 2005


11.2  Informative References

   [5]   Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         draft-ietf-sipping-conferencing-framework-05 (work in
         progress), May 2005.

   [6]   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",
         draft-garcia-sipping-poc-isb-am-02 (work in progress),
         June 2005.

   [7]   Willis, D. and A. Allen, "Requesting Answering and Alerting
         Modes for the Session Initiation Protocol  (SIP)",
         draft-willis-sip-answeralert-00 (work in progress), June 2005.

   [8]   Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
         Field for the Session Initiation Protocol (SIP)", RFC 3326,
         December 2002.

   [9]   Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
         User Agent Capabilities in the Session Initiation Protocol
         (SIP)", RFC 3840, August 2004.

   [10]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [11]  Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.

   [12]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.

   [13]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, October 2002.

   [14]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [15]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [16]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

   [17]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.



Allen, et al.           Expires December 27, 2005              [Page 27]

Internet-Draft          The P-Answer-State Header              June 2005


         Rosen, "Change Process for the Session Initiation Protocol
         (SIP)", BCP 67, RFC 3427, December 2002.

   [18]  Allen, A., "Private Header (P-Header) Extensions to the Session
         Initiation Protocol  (SIP) for the Open Mobile Alliance (OMA)
         Push to talk over Cellular (PoC)",
         draft-allen-sipping-poc-p-headers-01 (work in progress),
         February 2005.


Authors' Addresses

   Andrew Allen (editor)
   Research in Motion (RIM)
   122 West John Carpenter Parkway, Suite 430
   Irving, Texas  75039
   USA

   Phone: unlisted
   Fax:   unlisted
   Email: aallen@rim.com


   Jan Holm
   Ericsson
   Gotalandsvagen 220
   Stockholm  612526
   Sweden

   Phone: unlisted
   Fax:   unlisted
   Email: Jan.Holm@ericsson.com


   Tom Hallin
   Motorola
   1501 W Shure Drive
   Arlington Heights  60004
   USA

   Phone: unlisted
   Fax:   unlisted
   Email: thallin@motorola.com








Allen, et al.           Expires December 27, 2005              [Page 28]

Internet-Draft          The P-Answer-State Header              June 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Allen, et al.           Expires December 27, 2005              [Page 29]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/