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

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

SIPPING Working Group                                           A. Allen
Internet-Draft                                        Research in Motion
Expires: May 18, 2005                                            J. Holm
                                                                Ericsson
                                                               T. Hallin
                                                                Motorola
                                                       November 17, 2004


     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-00.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 May 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes a set of private Session Initiation
   Protocol(SIP) headers (P-headers) used by the Open Mobile Alliance



Allen, et al.             Expires May 18, 2005                  [Page 1]


Internet-Draft               PoC P-Headers                 November 2004


   (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   Applicability statement for the P-Alerting-Mode
               header . . . . . . . . . . . . . . . . . . . . . . . .  5
       4.1.2   Usage of the P-Alerting-Mode header  . . . . . . . . .  5
     4.2   The P-Answer-State header  . . . . . . . . . . . . . . . .  7
       4.2.1   Applicability statement for the P-Answer-State
               header . . . . . . . . . . . . . . . . . . . . . . . .  7
       4.2.2   Usage of the P-Answer-State header . . . . . . . . . .  8
   5.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1   P-Alerting-Mode header syntax  . . . . . . . . . . . . . . 11
     5.2   P-Answer-State header syntax . . . . . . . . . . . . . . . 11
     5.3   Table of new headers . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     6.1   P-Alerting-Mode  . . . . . . . . . . . . . . . . . . . . . 12
     6.2   P-Answer-State . . . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 13
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16


















Allen, et al.             Expires May 18, 2005                  [Page 2]


Internet-Draft               PoC P-Headers                 November 2004


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 May 18, 2005                  [Page 3]


Internet-Draft               PoC P-Headers                 November 2004


   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 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 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 May 18, 2005                  [Page 4]


Internet-Draft               PoC P-Headers                 November 2004


   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 back-to-back UAs, 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  Applicability statement for the P-Alerting-Mode header

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

   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 act as
      back-to-back User Agents 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.2  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 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.




Allen, et al.             Expires May 18, 2005                  [Page 5]


Internet-Draft               PoC P-Headers                 November 2004


   A UAC 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
   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 withou requiring the user to
   manually accept the session.  Normally in this mode the destination
   UAS will return a 200 OK response upon receiving the INVITE as per
   [1].  When the value is "MAO" the UAC 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 back-to-back
   UA that acts as an authorization policy server on behalf of the
   destination UAS.

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



Allen, et al.             Expires May 18, 2005                  [Page 6]


Internet-Draft               PoC P-Headers                 November 2004


   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.2.2  Procedures at the proxy

   This document does not define any procedure for proxy servers.
   Particularly, A SIP proxy do 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..

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 haeder field is to provide
   an indication from an intermediate node acting as a SIP 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  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
      act as back-to-back User Agents 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



Allen, et al.             Expires May 18, 2005                  [Page 7]


Internet-Draft               PoC P-Headers                 November 2004


      media.

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

4.2.2  Usage of the P-Answer-State header

   A UAS 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 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 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.2.1  Procedures at the UA

   A UAS 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 [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



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


Internet-Draft               PoC P-Headers                 November 2004


   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.

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




Allen, et al.             Expires May 18, 2005                  [Page 9]


Internet-Draft               PoC P-Headers                 November 2004


   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]
   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.2.2  Procedures at the proxy server

   This document does not define any procedure for proxy servers.
   Particularly, SIP proxy headers 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.





Allen, et al.             Expires May 18, 2005                 [Page 10]


Internet-Draft               PoC P-Headers                 November 2004


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
   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
   ___________________________________________________________
   P-Alerting-Mode         R            -   -   -   o   -   -
   P-Answer-State       1xx,2xx         -   -   -   o   -   -

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


                       Table 1: Header field support






Allen, et al.             Expires May 18, 2005                 [Page 11]


Internet-Draft               PoC P-Headers                 November 2004


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



Allen, et al.             Expires May 18, 2005                 [Page 12]


Internet-Draft               PoC P-Headers                 November 2004


   (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

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

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

9.  References

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

9.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.", draft-garcia-sipping-poc-isb-am-00 (work in
         progress), April 2005.

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



Allen, et al.             Expires May 18, 2005                 [Page 13]


Internet-Draft               PoC P-Headers                 November 2004


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

   [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",
         draft-ietf-sipping-conferencing-framework-03 (work in
         progress), October 2004.

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

   [14]  Rosenberg, J. and H. Schulzrinne, "A Session Initiation
         Protocol (SIP) Event Package for Conference State",
         draft-ietf-sipping-conference-package-06 (work in progress),
         October 2004.

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

   [16]  Camarillo, G., "Refering to Multiple Resources in the Session
         Initiation Protocol (SIP)",
         draft-ietf-sipping-multiple-refer-01 (work in progress),
         October 2004.










Allen, et al.             Expires May 18, 2005                 [Page 14]


Internet-Draft               PoC P-Headers                 November 2004


Authors' Addresses

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

   EMail: aallen@rim.com


   Jan Holm
   Ericsson
   Gotalandsvagen 220
   Stockholm  12526
   Sweden

   EMail: Jan.Holm@ericsson.com


   Tom Hallin
   Motorola
   1501 W Shure Drive
   Arlington Heights Illinois  60004
   USA

   EMail: thallin@motorola.com
























Allen, et al.             Expires May 18, 2005                 [Page 15]


Internet-Draft               PoC P-Headers                 November 2004


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 (2004).  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 May 18, 2005                 [Page 16]


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