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]