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

Versions: 00 01 draft-allen-sipping-poc-p-answer-state-header

SIPPING Working Group                                           A. Allen
Internet-Draft                                        Research in Motion
Expires: August 8, 2005                                          J. Holm
                                                                Ericsson
                                                               T. Hallin
                                                                Motorola
                                                        February 7, 2005


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

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

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

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

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

   This Internet-Draft will expire on August 8, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a set of private Session Initiation



Allen, et al.             Expires August 8, 2005                 [Page 1]

Internet-Draft               PoC P-Headers                February 2005


   Protocol(SIP) headers (P-headers) used by the Open Mobile Alliance
   (OMA),For Push to talk over Cellular (PoC) along with their
   applicability, which is limited to the OMA PoC application.  The
   P-headers are used for requesting and indicating the alerting mode of
   the handset which is particular to the PoC application.

Table of Contents

   1.  Overall Applicability  . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  SIP Private Headers  . . . . . . . . . . . . . . . . . . . . .  5
     4.1   The P-Alerting-Mode header . . . . . . . . . . . . . . . .  5
       4.1.1   Requirements . . . . . . . . . . . . . . . . . . . . .  5
       4.1.2   Alternatives Considered for Selecting the Answer
               Mode . . . . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.3   Applicability statement for the P-Alerting-Mode
               header . . . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.4   Usage of the P-Alerting-Mode header  . . . . . . . . .  7
     4.2   The P-Answer-State header  . . . . . . . . . . . . . . . .  9
       4.2.1   Requirements . . . . . . . . . . . . . . . . . . . . .  9
       4.2.2   Alternatives Considered  . . . . . . . . . . . . . . . 10
       4.2.3   Applicability statement for the P-Answer-State
               header . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.2.4   Usage of the P-Answer-State header . . . . . . . . . . 11
   5.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1   P-Alerting-Mode header syntax  . . . . . . . . . . . . . . 14
     5.2   P-Answer-State header syntax . . . . . . . . . . . . . . . 15
     5.3   Table of new headers . . . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
     6.1   P-Alerting-Mode  . . . . . . . . . . . . . . . . . . . . . 15
     6.2   P-Answer-State . . . . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  draft-allen-sipping-poc-p-headers-01 . . . . . . . . . . . . . 17
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2  Informative References . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 20











Allen, et al.             Expires August 8, 2005                 [Page 2]

Internet-Draft               PoC P-Headers                February 2005


1.  Overall Applicability

   The SIP extensions specified in this document make certain
   assumptions regarding network topology, and the availability of
   transitive trust.  These assumptions are generally NOT APPLICABLE in
   the Internet as a whole.  The mechanisms specified here were designed
   to satisfy the requirements specified by the Open Mobile Alliance for
   Push-to-talk over cellular for which either no general-purpose
   solution was found, where insufficient operational experience was
   available to understand if a general solution is needed, or where a
   more general solution is not yet mature.  For more details about the
   assumptions made about these extensions, consult the Applicability
   subsection for each extension.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [2].

3.  Overview

   The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is
   specifying the Push-to-talk Over Cellular (PoC) service where SIP is
   the protocol used to establish half duplex media sessions across
   different participants.  This document describes private extensions
   to address specific requirements of the PoC service and may not be
   applicable to the general Internet.

   The PoC service allows a SIP UA (PoC terminal) to establish a session
   To one or more SIP UAs simultaneously, usually initiated by the
   initiating user pushing a button.

   OMA has defined a collection of very stringent requirements in
   support of the PoC service.  In order to provide the user with a
   satisfactory experience the initial session establishment from the
   time the user presses the button to the time they get an indication
   to speak must be minimized.

   The PoC terminal may support such hardware capabilities as a speaker
   phone and/or headset and software that provide the capability for the
   user to configure the PoC terminal to accept the session initiations
   immediately and play out the media as soon as it is received without
   requiring the intervention of the called user.  This mode of
   operation is known as Automatic Answer mode.  The user may
   alternatively configure the PoC terminal to first alert the user and
   require the user to manually accept the session invitation before
   media is accepted.  This mode of operation is known as Manual Answer



Allen, et al.             Expires August 8, 2005                 [Page 3]

Internet-Draft               PoC P-Headers                February 2005


   mode.  The PoC terminal may support both or only one of these modes
   of operation.  The user may change the Answer Mode (AM) configuration
   of the PoC terminal frequently based on their current circumstances
   and preference,(perhaps because the user is busy, or in a public area
   where she cannot use a speaker phone, etc).

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

   The answer mode requested in the SIP INVITE request may be determined
   based on the preference of the calling user and/or the authorization
   policies of the called user and the currently known answer mode
   setting of the called user's terminal.  In addition to the basic
   answer mode settings of the terminal a privileged caller may request
   a Manual Answer Override (MAO) to request that the called terminal
   answer automatically even when it is in the Manual-Answer mode.  This
   mode is needed for emergency service and also some other dispatch
   applications.

   This document proposes two new SIP header fields to support this
   optimization.  One extension may be optionally included in a SIP
   INVITE request or a REFER that requests an INVITE to be sent by a SIP
   UAC to request that the terminating SIP UAS alert the user according
   to the mode indicated by the parameter contained in the header.  The
   other extension may be optionally included in a response to a SIP
   INVITE request or in a NOTIFY sent as a result of a REFER that
   requests an INVITE to be sent to provide an indication from an
   intermediate node acting as a SIP 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



Allen, et al.             Expires August 8, 2005                 [Page 4]

Internet-Draft               PoC P-Headers                February 2005


   towards the inviting SIP UA to transmit media prior to receiving a
   final response from the final destination of the SIP INVITE request.
   Each extension, is described in its own section below.

4.  SIP Private Headers

4.1  The P-Alerting-Mode header

   This extension allows a UAC to request that the terminating SIP UAS
   or group of UAS, alert the user according to the mode indicated by
   the parameter contained in the header when using the INVITE method to
   establish a session between two or more SIP UAs.  It is possible that
   the INVITE request traverses one or more application servers that
   behave as SIP back-to-back UAs or proxies, as the INVITE request is
   routed to the final destination UA.  The intermediate node
   application servers can modify the value of P-Alerting-Mode header or
   insert this header in the INVITE if it is not already present.

4.1.1  Requirements

   The OMA PoC service has the following requirements for the answer
   mode requests:

   REQ-AM1: It MUST be possible for a SIP UAC to request an automatic
   answer mode which allows the inviting SIP UA to send media to the
   invited PoC subscriber's SIP UA without any action by the
   invited PoC user.

   REQ-AM2: It MUST be possible for a SIP UAC to request a manual answer
   mode which allows requires the invited PoC user to accept the
   invitation to the PoC half-duplex session before the inviting SIP UA
   is permitted to send media to the invited PoC subscriber's terminal.

   REQ-AM3: It MUST be possible for a SIP UAC to request a manual answer
   override which allows an inviting PoC user to request to override an
   the invited PoC users manual answer settings.

   REQ-AM4: It MUST be possible for an intermediary server (SIP Proxy or
   B2BUA) to validate that the invited SIP UAS current answer mode
   settings will support the specified requested answer mode from the
   inviting SIP UAC and if not modify it appropriately.

   REQ-AM5: It MUST be possible for an intermediary server (SIP Proxy or
   B2BUA) to validate that the inviting user is authorized by the
   invited user to request the answer mode contained in the request from
   the inviting SIP UAC and if not modify it appropriately.

   REQ-AM6: It MUST be possible for an intermediary server (SIP Proxy or



Allen, et al.             Expires August 8, 2005                 [Page 5]

Internet-Draft               PoC P-Headers                February 2005


   B2BUA) to add a request for a specific answer mode based on the
   current answer mode settings of the invited SIP UAS and any policy
   settings if no answer mode request was contained in the invitation.

   REQ-AM7: It MUST be possible for a SIP UAC to request a specific
   answer mode when inviting a user using an INVITE.

   REQ-AM8: It MUST be possible for a SIP UAC to request a specific
   answer mode when inviting a user using a REFER that request an INVITE
   to be sent.

4.1.2  Alternatives Considered for Selecting the Answer Mode

   A number of alternatives to the P-Alerting-Mode header were
   considered.

   There were proposals to add this information in the body
   of a SIP INVITE request, either in a separate multi-part body section
   or in the SDP body.  - The choice of an SDP parameter was rejected
   because the answer mode attribute applies to the session and not to a
   media stream.  - A separate multi-part body section was rejected
   because this would require the UAS to build a parser for a new
   sub-protocol when deciding when and how to accept or reject a session
   and also increase the overhead in the message.

   There was a proposal to add a URI parameter to the request
   URI.  This was rejected because the answer mode of the terminating
   party is not an attribute of the Request-URI, but is an attribute of
   the session.

   There was a proposal to add it as a feature tag in the
   Accept-Contact header.  This was rejected because it was not agreed
   that the answer mode is a different  feature or capability of the UA,
   but is an attribute of the session and can be applied to many
   different features.  There was also concern that frequent changes in
   the answer mode settings in the terminal and corresponding callee
   capabilities refresh registrations would provide a heavy load on the
   registrar.

   The P-Alerting-Mode header was chosen because answer mode is an
   attribute of a session.  As a header, SIP Proxies and B2BUA's can
   pass it on without needing to analyze the header or they can perform
   authorization checks before sending the header to a subsequent UAS.

4.1.3  Applicability statement for the P-Alerting-Mode header

   The P-Alerting-Mode header is applicable in SIP networks where:




Allen, et al.             Expires August 8, 2005                 [Page 6]

Internet-Draft               PoC P-Headers                February 2005


   o  There are SIP UAs that support different modes of accepting
      session (Auto-answer and Manual-Answer;
   o  The inviting UAC can, as an option request the terminating SIP UAS
      to automatically or manually accept the session;
   o  Where there are intermediate network SIP servers that are trusted
      and have knowledge of the current answer mode Setting of the
      terminating UAS;
   o  The intermediate network SIP servers can perform authorization of
      the privilege of the inviter to request the requested answer mode;
      and,
   o  This mode of operation is most applicable in environments that
      where half-duplex communications is the primary mode for the
      media.

   Such configurations are generally not applicable to the Internet as a
   whole where such trust relationships do not exist.

4.1.4  Usage of the P-Alerting-Mode header

   The P-Alerting-Mode header field provides a mechanism to express the
   inviting party's preferences towards the alerting of the calling
   user.  Therefore, this header field is a hint or preferences from the
   inviting party's preferences towards the alerting of the calling
   user.  Therefore, this header field is a hint or preferences from the
   inviting party towards the called party.  It is at the discretion of
   the called party UAS to accept this hint or not.  For instance, a UAS
   can decide to ignore this header field.  A UAC or proxy MAY insert a
   P-Alerting-Mode header field into an INVITE request or a REFER
   request when it is desired to request the final destination UAS to
   alert the user manually about the incoming session, or to accept the
   session automatically and start the receiving media packets without
   requiring the intervention of the user.

      The final destination UAS MAY be identified by the value of the
      Request-URI in the INVITE request, the value of the Refer-To
      header field in a REFER request or using the mechanisms specified
      in [15] or [16].

   The header field value is populated with one of the enumeration
   values "Manual", "Auto" or "MAO".  When the value is "Manual" the UAC
   or proxy is requesting the UAS to alert the user and wait for the
   user to accept the session before returning a 200 OK response for the
   INVITE request.  Normally in this mode the destination UAS will
   return a 180 Ringing provisional response when alerting the user as
   per [1].  When the value is set to "Auto" the UAC is requesting the
   UAS to not alert the user, accept the session and automatically
   return a 200 OK response without alerting the user and without
   requiring the user to manually accept the session.  Normally in this



Allen, et al.             Expires August 8, 2005                 [Page 7]

Internet-Draft               PoC P-Headers                February 2005


   mode the destination UAS will return a 200 OK response upon receiving
   the INVITE as per [1].  When the value is "MAO" the UAC or proxy is
   requesting the UAS to accept the session and return a 200 OK response
   without requiring the user to manually accept the session even if the
   mode of the destination UAS is set to normally alert the user and
   require Manual acceptance.  The use of the "Auto" and "MAO" values
   will likely be subject to authorization by the destination UAS or an
   intermediate proxy or back-to-back UA that acts as an authorization
   policy server on behalf of the destination UAS.

4.1.4.1  Procedures at the UA

   A UAC MAY insert a P-Alerting-Mode header field in an INVITE request
   or in a REFER request that requests another UA to send an INVITE
   request.  A UAS can receive a P-Alerting-Mode header field in an
   INVITE request or a REFER request.  If the UAS is the final
   destination of the request it MAY use the value of the
   P-Alerting-Mode header field to determine whether to first alert the
   user or accept the session automatically without requiring manual
   user acceptance.  The semantics of the parameters are defined in
   4.1.4.  If the UAS cannot or does not accept the mode of session
   acceptance requested in the P-Alerting-Mode header field it can
   safely ignore this header field.

   If the UA is an intermediate node and not the final destination of
   the request it MAY, when acting as a UAC, insert a P-Alerting-Mode
   header field into an INVITE request that corresponds with an INVITE
   request or REFER request received while acting as a UAS.
   Alternatively the intermediate node MAY, when acting as a UAC, change
   the value of the P-Alerting-Mode header field in the outgoing INVITE
   from that received in the corresponding INVITE or REFER when acting
   as a UAS.  This functionality is normally performed as part of the
   authorization process for the P-Alerting-Mode header field parameter
   or when the intermediate node has some hint from the intended
   destination UA of its current alerting mode.  An event package and
   mechanisms for a UA to communicate its current alerting mode to an
   intermediate node is defined in [4].

4.1.4.2  Procedures at the proxy server

   A SIP proxy does not need to understand the semantics of the
   P-Alerting-Mode header field.  As part of the regular SIP rules for
   unknown headers, a proxy will forward unknown headers.

   A proxy MAY insert a P-Alerting-Mode header field into an INVITE
   Request or MAY change the value of the P-Alerting-Mode header field
   in an INVITE request.  This functionality is normally performed as
   part of the authorization process for the P-Alerting-Mode header



Allen, et al.             Expires August 8, 2005                 [Page 8]

Internet-Draft               PoC Answer Mode                February 2005


   field parameter or when the proxy has some hint from the intended
   destination UA of its current alerting mode.  An event package and
   mechanisms for a UA to communicate its current alerting mode to a
   proxy is defined in [4].

4.2  The P-Answer-State header

   This header field MAY be included in a response to a SIP INVITE
   request or in a NOTIFY request sent as a result of a REFER request to
   send an INVITE request The purpose of the 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.

4.2.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 1 one or more invited PoC
   subscribers have accepted the session.  The specific requirements
   are:

   REQ-AS1: An intermediate server MAY spool media from the inviting SIP
   UA until 1 one or more invited PoC SIP UAs haves accepted
   the invite.

   REQ-AS2: 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.

   REQ-AS3: 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 accept the request MUST be able to indicate back
   to another intermediate server that can spool media SHOULD only
   accept the invite request if that it has some indication hint that
   one or more invited PoC SIP UAs is likely to accept the
   invite request without requiring user intervention.

   REQ-AS4: 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.



Allen, et al.             Expires August 8, 2005                 [Page 9]

Internet-Draft               PoC P-Headers                February 2005


4.2.2  Alternatives Considered

   In order to meet REQ-AS3, 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 suggestion 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 suggestion proposal was to use a Reason header 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 would have required creating
   and registering a new protocol identifier.

   Another suggestion proposal was to use a feature-tag in the returned
   Contact header.  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 for the same reasons that the use of a
   feature-tag was rejected in 4.1.2.

   Another suggestion 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 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.2.3  Applicability statement for the P-Answer-State header

   The P-Answer-State header is applicable in the following



Allen, et al.             Expires August 8, 2005                [Page 10]

Internet-Draft               PoC P-Headers                February 2005


   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.

   Such configurations are generally not applicable to the internet as a
   whole where such trust relationships do not exist.

4.2.4  Usage of the P-Answer-State header

   A UAS 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 [13].  Typically
   the P-Answer-State header field is inserted in either a 183 Session
   Progress or a 200 OK response.  A UA that receives a REFER request to
   send an INVITE MAY also insert a P-Answer-State header field in a
   NOTIFY request it sends as a result of the implicit subscription
   created by the REFER request.

   When the P-Answer-State header field contains the parameter
   "Unconfirmed" the UAC 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.2.4.1  Procedures at the UA

   A UAS MAY insert a P-Answer-State header field in any 1XX or 2XX



Allen, et al.             Expires August 8, 2005                [Page 11]

Internet-Draft               PoC P-Headers                February 2005


   response that is allowed to contain an SDP answer in response to an
   SDP offer contained in an INVITE request as specified in [13].  A
   response containing the P-Answer-State header field containing the
   parameter "Unconfirmed" MAY or MAY NOT contain an SDP answer.  If the
   response contains an SDP answer then the sending UA MUST be ready to
   receive media as specified in [13].

   A UAC that receives a 1XX or 2XX response containing a P-Answer-State
   header field containing the parameter "Unconfirmed" and an SDP answer
   MAY send media as specified in [13], however there is no guarantee
   that the media will be received by the final recipient.  How a UAC
   confirms whether the media was or was not received by the final
   destination when it his received a 2XX "unconfirmed response" is
   application specific and outside of the scope of this document.  If
   the application is a conference then the mechanism specified in [13]
   could be used to determine that the invited user joined.
   Alternatively a BYE request could be sent or the media could be
   placed on hold if the final destination UAS does not accept the
   session.

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

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




Allen, et al.             Expires August 8, 2005                [Page 12]

Internet-Draft               PoC P-Headers                February 2005


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

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

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

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

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

   A UA that receives in response to a REFER request a NOTIFY request
   request containing a P-Answer-State header field containing the
   parameter "Unconfirmed" as either a SIP header or contained in a
   sipfrag in the body of the NOTIFY request received on a pre-existing
   dialog that was established by an INVITE request and for which there
   has been a successful SDP offer-answer exchange according to [13]



Allen, et al.             Expires August 8, 2005                [Page 13]

Internet-Draft               PoC P-Headers                February 2005


   then the UA MAY send media, however there is no guarantee that the
   media will be received by the final recipient that was indicated in
   the Refer-To header in the original REFER request.

4.2.4.2  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 [1] 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 [13].

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

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

5.1  P-Alerting-Mode header syntax

   The syntax of the P-Alerting-Mode header is described as follows:

   P-Alerting-Mode        = "P-Alerting-Mode" HCOLON alerting-type



Allen, et al.             Expires August 8, 2005                [Page 14]

Internet-Draft               PoC P-Headers                February 2005


   alerting-type          = "Manual" / "Auto" / "MAO"

5.2  P-Answer-State header syntax

   The syntax of the P-Answer-State header is described as follows:

   P-Answer-State          = "P-Answer-State" HCOLON answer-type
   answer-type             = "Confirmed" / "Unconfirmed"

5.3  Table of new headers

   Table 1 extends the headers defined in this document to Table 2 in
   SIP [1], section 7.1 of the SIP-specific event notification [6],
   tables 1 and 2 in the SIP INFO method [8], tables 1 and 2 in
   Reliability of provisional responses in SIP [7], tables 1 and 2 in
   the SIP UPDATE method [9], tables 1 and 2 in the SIP extension for
   Instant Messaging [10], and table 1 in the SIP REFER method [11]:



      Header field          where  proxy  ACK BYE CAN INV OPT REG SUB
      _______________________________________________________________
      P-Alerting-Mode         R     am     -   -   -   o   -   -   -
      P-Answer-State       1xx,2xx  a      -   -   -   o   -   -   -

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

                       Table 1: Header field support


6.  Security Considerations

6.1  P-Alerting-Mode

   The P-Alerting-Mode header requests that the destination UA behave in
   the way requested in this header.  Although the destination UA does
   not have to accept what is requested the impact of an unauthorized
   intermediate attacker modifying this header or an unauthorized user
   sending an INVITE including the values "Auto" or "MAO" in this header
   could violate the privacy of the called user as a speaker phone may
   be engaged by the terminal and the callers voice may be heard by
   anyone in the vicinity.  An INVITE request containing the
   P-Alerting-Mode header with the values "Auto" or "MAO" SHOULD be
   authenticated and authorized to ensure that the sender has the
   permission to trigger the callers terminal in an Auto-Answer mode of



Allen, et al.             Expires August 8, 2005                [Page 15]

Internet-Draft               PoC P-Headers                February 2005


   operation.  The authorization MAY be performed by the destination UA
   or by a trusted intermediate node that performs authorization policy
   on behalf of the called party.  When an intermediate node is used to
   perform such authorization it is RECOMMENDED that this extension is
   used in a secured trusted environment where transitive trust exists
   between the proxies and UAs if end-to-end protection is not used at
   the SIP layer.

   An eavesdropper cannot gain any useful information by obtaining the
   contents of this header.

6.2  P-Answer-State

   The information returned in the P-Answer-State header is not viewed
   as particularly sensitive.  Rather, it is informational in nature,
   providing an indication to the UAC that delivery of any media sent as
   a result of an answer in this response is not guaranteed.  An
   eavesdropper cannot gain any useful information by obtaining the
   contents of this header.

   If end-to-end protection is not used at the SIP layer, it is possible
   for proxies between the UAs to remove the header or modify the
   contents of the header value.  This attack either denies the caller
   the knowledge that the callee has yet to be contacted or falsely
   indicates that the callee has yet to be contacted when they have
   already answered.  It is therefore RECOMMENDED that this extension is
   used in a secured trusted environment where transitive trust exists
   between the proxies and UAs if end-to-end protection is not used at
   the SIP layer.

7.  IANA Considerations

   This document defines two private SIP extension header fields
   (beginning with the prefix "P-" ) based on the registration
   procedures defined in RFC 3427 [5].

   The following extensions are registered as private extension header
   fields:


      RFC Number:         [To be added by the RFC Editor]
      Header Field Name:  P-Alerting-Mode
      Compact Form:       none


      RFC Number:         [To be added by the RFC Editor]
      Header Field Name:  P-Answer-State
      Compact Form:       none



Allen, et al.             Expires August 8, 2005                [Page 16]

Internet-Draft               PoC P-Headers                February 2005


   Person to Contact: Andrew Allen, aallen@rim.com

8.  draft-allen-sipping-poc-p-headers-01

   Version 01 includes changes based on comments from the SIPPING chairs
   and members of the OMA PoC WG.  Functions for the proxy role were
   added and requirements and alternatives considered sections included.

9.  Acknowledgments

   The authors would like to thank Miguel Garcia-Martin and the OMA POC
   Working Group members for their comments and support of this
   document.

10.  References

10.1  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

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

10.2  Informative References

   [4]   Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event
         Package and Data Format for  Incoming Session Barring and
         Answer Mode in support for the Push-to-talk Over Cellular (PoC)
         service", Internet-Draft draft-garcia-sipping-poc-isb-am-01,
         December 2004.

   [5]   Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
         Rosen, "Change Process for the Session Initiation Protocol
         (SIP)", BCP 67, RFC 3427, December 2002.

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

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

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



Allen, et al.             Expires August 8, 2005                [Page 17]

Internet-Draft               PoC P-Headers                February 2005


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

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

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

   [12]  Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         Internet-Draft draft-ietf-sipping-conferencing-framework-03,
         October 2004.

   [13]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [14]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
         Package for Conference State",
         Internet-Draft draft-ietf-sipping-conference-package-08,
         December 2004.

   [15]  Camarillo, G. and A. Johnston, "Conference Establishment Using
         Request-Contained Lists in the Session  Initiation Protocol
         (SIP)",
         Internet-Draft draft-ietf-sipping-uri-list-conferencing-02,
         December 2004.

   [16]  Camarillo, G., "Refering to Multiple Resources in the Session
         Initiation Protocol (SIP)",
         Internet-Draft draft-ietf-sipping-multiple-refer-02, December
         2004.


Authors' Addresses

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


   Email: aallen@rim.com







Allen, et al.             Expires August 8, 2005                [Page 18]

Internet-Draft               PoC P-Headers                February 2005


   Jan Holm
   Ericsson
   Gotalandsvagen 220
   Stockholm  612526
   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.             Expires August 8, 2005                [Page 19]

Internet-Draft               PoC P-Headers                February 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 August 8, 2005                [Page 20]


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