SIPPING Working Group A. Allen, Ed.
Internet-Draft Research in Motion (RIM)
Expires: June 13, 2006 J. Holm
Ericsson
T. Hallin
Motorola
December 10, 2005
The P-Answer-State Header Extension to the Session Initiation Protocol
(SIP) for the Open Mobile Alliance (OMA) Push to talk over Cellular
(PoC)
draft-allen-sipping-poc-p-answer-state-header-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 13, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a private Session Initiation Protocol(SIP)
header (P-header) used by the Open Mobile Alliance (OMA),For Push to
talk over Cellular (PoC) along with its applicability, which is
Allen, et al. Expires June 13, 2006 [Page 1]
Internet-Draft The P-Answer-State Header December 2005
limited to the OMA PoC application. The P-Answer-State header is
used for indicating the answering mode of the handset which is
particular to the PoC application.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
Table of Contents
1. Overall applicability . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Background for the extension . . . . . . . . . . . . . . . . . 5
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. The P-Answer-State header . . . . . . . . . . . . . . . . . . 7
6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Alternatives considered . . . . . . . . . . . . . . . . . 8
6.3. Applicability statement for the P-Answer-State header . . 9
6.4. Usage of the P-Answer-State header . . . . . . . . . . . . 10
6.4.1. Procedures at the UA (terminal) . . . . . . . . . . . 10
6.4.2. Procedures at the UA (PTT Server) . . . . . . . . . . 11
6.4.3. Procedures at the proxy server . . . . . . . . . . . . 13
7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. P-Answer-State header syntax . . . . . . . . . . . . . . . 13
7.2. Table of the new header . . . . . . . . . . . . . . . . . 14
8. Example usage session flows . . . . . . . . . . . . . . . . . 14
8.1. Pre-arranged group call using on-demand session . . . . . 14
8.2. 1-1 Call using pre-established session . . . . . . . . . . 19
9. Security considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. Registration of Header Fields . . . . . . . . . . . . . . 26
10.2. Registration of header field parameters . . . . . . . . . 26
11. Changes since previous version . . . . . . . . . . . . . . . . 27
Allen, et al. Expires June 13, 2006 [Page 2]
Internet-Draft The P-Answer-State Header December 2005
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative references . . . . . . . . . . . . . . . . . . . 28
13.2. Informative references . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Allen, et al. Expires June 13, 2006 [Page 3]
Internet-Draft The P-Answer-State Header December 2005
1. Overall applicability
The SIP extension specified in this document makes certain
assumptions regarding network topology, and the availability of
transitive trust. These assumptions are generally NOT APPLICABLE in
the Internet as a whole. The mechanism specified here was designed
to satisfy the requirements specified by the Open Mobile Alliance for
Push-to-talk over cellular for which either no general-purpose
solution was found, where insufficient operational experience was
available to understand if a general solution is needed, or where a
more general solution is not yet mature. For more details about the
assumptions made about this extension, consult the Applicability
subsection for the extension.
2. Introduction
The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is
specifying the Push-to-talk Over Cellular (PoC) service where SIP is
the protocol used to establish half duplex media sessions across
different participants. This document describes a private extension
to address specific requirements of the PoC service and may not be
applicable to the general Internet.
The PoC service allows a SIP UA (PoC terminal) to establish a session
to one or more SIP UAs simultaneously, usually initiated by the
initiating user pushing a button.
OMA has defined a collection of very stringent requirements in
support of the PoC service. In order to provide the user with a
satisfactory experience the initial session establishment from the
time the user presses the button to the time they get an indication
to speak must be minimized.
3. Terminology
The terms "PTT Server","Unconfirmed Indication", "Unconfirmed
Response", "Confirmed Indication" and "Confirmed Response" are
introduced in this document.
A "PTT Server" as referred to here is a SIP network server that
performs the network based functions for the Push to Talk service.
The PTT Server may act as a SIP Proxy or back-to-back UA (B2BUA)based
on the functions it needs to perform. There may be one or more PTT
Servers involved in a SIP Push to Talk session.
An "Unconfirmed Indication" as referred to here is an indication that
Allen, et al. Expires June 13, 2006 [Page 4]
Internet-Draft The P-Answer-State Header December 2005
the final target UA for the request has yet to be contacted and an
intermediate SIP node is indicating that it has information that
hints that the request is likely to be answered by the target UA. An
"Unconfirmed Response" is a SIP response containing an "Unconfirmed
Indication".
A "Confirmed Indication" as referred to here is an indication that
the target UA has accepted the session invitation and is ready to
receive media. A "Confirmed Response" is a SIP 200 OK response
containing a "Confirmed Indication" and has the usual semantics of a
response containing an answer (such as an SDP answer).
4. Background for the extension
The PoC terminal may support such hardware capabilities as a speaker
phone and/or headset and software that provide the capability for the
user to configure the PoC terminal to accept the session invitations
immediately and play out the media as soon as it is received without
requiring the intervention of the called user. This mode of
operation is known as Automatic Answer mode. The user may
alternatively configure the PoC terminal to first alert the user and
require the user to manually accept the session invitation before
media is accepted. This mode of operation is known as Manual Answer
mode. The PoC terminal may support both or only one of these modes
of operation. The user may change the Answer Mode (AM) configuration
of the PoC terminal frequently based on their current circumstances
and preference,(perhaps because the user is busy, or in a public area
where she cannot use a speaker phone, etc).
The OMA PoC Architecture utilizes PTT Servers within the network that
may perform such roles as a conference focus [5], a RTP translator or
a network policy enforcement server. A possible optimization to
minimize the delay in the providing of the caller with an indication
to speak is for the PTT server to perform buffering of media packets
in order to provide an early or unconfirmed indication back to the
caller and allow the caller to start speaking before the called PoC
terminal has answered. An event package and mechanisms for a SIP UA
to indicate its current answer mode to a PTT Server in order to
enable buffering are defined in [6]. In addition, particularly when
multiple domains are involved in the session more than one PTT server
may be involved in the signaling path for the session and the PTT
Server that performs the buffering may not be the PTT Server that has
knowledge of the current answer mode of the SIP UA that is the final
destination for the SIP INVITE request. A mechanism to allow a
terminal that acts as a SIP UA or a PTT server that acts as a SIP UA
to indicate a preference to the final destination SIP UAS to answer
in a particular mode is defined in [7]. However a mechanism is
Allen, et al. Expires June 13, 2006 [Page 5]
Internet-Draft The P-Answer-State Header December 2005
required for a PTT Server to relay the unconfirmed indication in a
response back towards the originating SIP UAC.
5. Overview
The purpose of this extension is to support an optimisation that
makes it possible for the network to provide a faster push-to-talk
experience, through an intermediate SIP agent (PTT Server) providing
a 200 response before the called UA does, and a PTT Server buffering
the media generated by the calling UA for replay to the called UA
when it answers. However the PTT Server only can do this when there
is a high probability that the called UA is in Automatic Answer mode.
It is likely that PTT Servers near the called UA have up-to-date
knowledge of the answering mode of the called UA, and due to the
restricted bandwidth nature of the cellular network, they can pass
upstream an indication of the called UA's answering mode faster than
the called UA can deliver an automatically generated 200 response.
Thus, when a PTT Server forwards an INVITE and knows that the called
UA is likely to be in Automatic Answer mode, it also generates a 183
response containing a "P-Answer-State: Unconfirmed" header to signal
to upstream PTT Servers that they may buffer the caller's media.
A PTT Server that wishes to buffer the caller's media, upon seeing
the provisional response containing "P-Answer-State: Unconfirmed"
absorbs it and generates a 200 response for the caller's UA with an
appropriate answer.
When the called UA generates a 200 response, the PTT Server that
generated the provisional response containing "P-Answer-State:
Unconfirmed" adds to the 200 response a header "P-Answer-State:
Confirmed". The 200 response is absorbed by the PTT Server that is
buffering the caller's media, as it has already generated a 200
response. The buffering PTT Server then starts un-buffering the
media.
This document proposes a new SIP header field to support this
unconfirmed indication. The new SIP header may be optionally
included in a response to a SIP INVITE request or in the sipfrag of a
NOTIFY sent as a result of a REFER that requests an INVITE to be
sent. The header is used to provide an indication from an PTT Server
acting as a SIP proxy or back-to-back UA that it has information that
hints that the terminating UA will likely answer automatically. This
provides an unconfirmed indication back towards the inviting SIP UA
to transmit media prior to receiving a final response from the final
destination of the SIP INVITE request. The extension is described
below.
Allen, et al. Expires June 13, 2006 [Page 6]
Internet-Draft The P-Answer-State Header December 2005
6. The P-Answer-State header
The purpose of the P-Answer-State header field is to provide an
indication from a PTT Server acting as a SIP proxy or back-to-back UA
that is has information that hints that the terminating UA identified
in the Request-URI of the request will likely answer automatically
and therefore provides an unconfirmed indication back towards the
inviting SIP UA to transmit media prior to receiving a final response
from the final destination of the SIP INVITE request. If a
Provisional response contains the P-Answer-State header with the
value "Unconfirmed" and does not contain an answer then a receiving
PTT Server may send a 200 OK response containing an answe and a
P-Answer-State header with the value "Unconfirmed" if the PTT Server
is willing to perform media buffering. If the response containing
the P-Answer-State header with the value "Unconfirmed" also contains
an answer the PTT Server that inserted the header and answer in the
response is also indicating that it is willing to buffer the media
until a final confirmed indication is received.
The P-Answer-State header field MAY be included in a provisional or
final response to a SIP INVITE request or in the sipfrag of a NOTIFY
request sent as a result of a REFER request to send an INVITE
request. If the P-Answer-State header field with value "Unconfirmed"
is included in a provisional response that contains an answer the PTT
Server is leaving the decision where to do buffering to other PTT
Servers upstream and will forward upstream a "Confirmed indication"
in a 200 OK response when the final response is received from the
destination UA.
The P-Answer-State header is only included in a provisional response
when the node that sends the response has knowledge that there is a
PTT Server that acts as a B2BUA that understands this extension in
the signaling path between itself and the originating UAC that will
only pass the header on in either a 200 OK response or in the sipfrag
of a NOTIFY request. Such a situation only occurs with specific
network topologies which is another reason why use of this header is
not relevant to the general internet. The originating UAC will only
receive the P-Answer-state header in a 200 OK response or in the
sipfrag of a NOTIFY request.
6.1. Requirements
The OMA PoC service has initial setup performance requirements that
can be met by a PTT Server acting as a B2BUA spooling media from the
inviting PoC subscriber until one or more invited PoC subscribers
have accepted the session. The specific requirements are
Allen, et al. Expires June 13, 2006 [Page 7]
Internet-Draft The P-Answer-State Header December 2005
REQ-1: An intermediate server MAY spool media from the inviting SIP
UA until one or more invited PoC SIP UAs has accepted the
invitation.
REQ-2: An intermediate server that is capable of spooling media MAY
accept an invite request from an inviting SIP UAC even if no
invited SIP UAS has accepted the invite request if it has a hint
that the invited SIP UAC is likely to accept the request without
requiring user intervention.
REQ-3: An intermediate server or proxy that is incapable of spooling
media or does not wish to, but has a hint that the invited SIP UAC
is likely to automatically accept the session invitation MUST be
able to indicate back to another intermediate server that can
spool media that it has some hint that the invited UAC is likely
to automatically accept the session invitation.
REQ-4: An intermediate server that is willing to spool media from the
inviting SIP UA until one or more invited SIP UAs have accepted
the invite SHOULD indicate that it is spooling media to the
inviting SIP UAC.
6.2. Alternatives considered
In order to meet REQ-3, a PTT Server needs to receive an indication
back that the invited SIP UA is likely to accept the invite request
without requiring user intervention. In this case, the PTT Server
that has a hint that the invited SIP UAC is likely to accept the
request can include an answer state indication in the 183 Session
Progress or 200 OK response.
A number of alternatives were considered for the PTT Server to inform
another PTT Server or the inviting SIP UAC of the invited PoC SIP UAs
answer mode settings.
One proposal was to create a unique reason-phrase in the 183 and 200
OK response. This was rejected because the reason phrases are
normally intended for human readers and not meant to be parsed by
servers for special syntactic and semantic meaning.
Another proposal was to use a Reason header [8] in the 183 and 200 OK
response. This was rejected because this would be inconsistent with
the intended use of the reason header and its usage is not defined
for these response codes and would have required creating and
registering a new protocol identifier.
Another proposal was to use a feature-tag in the returned Contact
Allen, et al. Expires June 13, 2006 [Page 8]
Internet-Draft The P-Answer-State Header December 2005
header as defined in [9]. This was rejected because it was not a
different feature, but is an attribute of the session and can be
applied to many different features.
Another proposal was to use a new SDP attribute. The choice of an
SDP parameter was rejected because the answer state applies to the
session and not to a media stream.
The P-Answer-State header was chosen to give additional information
about the state of the SIP session progress and acceptance. Even
though the UAC sees that its 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.
6.3. Applicability statement for the P-Answer-State header
The P-Answer-State header is applicable in the following
circumstances:
o In networks where there are UAs that engage in half-duplex
communication where there is not the possibility for the invited
user to verbally acknowledge the answering of the session as is
normal in full duplex communication;
o Where the invited UA 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 have knowledge of the media
types and codecs likely to be accepted by the terminating UAS;
and,
o The intermediate network SIP servers can provide buffering of
the media in order to reduce the time for the inviting user to
send media.
o The intermediate network SIP servers assume knowledge of the
network topology and the existence of similar intermediate network
SIP servers in the signaling path.
Such configurations are generally not applicable to the internet as a
whole where such trust relationships do not exist.
Allen, et al. Expires June 13, 2006 [Page 9]
Internet-Draft The P-Answer-State Header December 2005
In addition security issues have only been considered for networks
which are trusted and use hop by hop security mechanisms and security
issues with usage of this mechanism in the general internet have not
been evaluated.
6.4. Usage of the P-Answer-State header
A UAS B2BUA or proxy MAY insert a P-Answer-State header field in any
1XX or 2XX response that is allowed to contain an answer in response
to an offer contained in an INVITE as specified in [2]. Typically
the P-Answer-State header field is inserted in either a 183 Session
Progress or a 200 OK response. A UA that receives a REFER request to
send an INVITE MAY also insert a P-Answer-State header field in the
sipfrag of 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. 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 a 200 OK response containing an answer and is included
for completeness.
6.4.1. Procedures at the UA (terminal)
A UAC (terminal) that receives a 1XX or 2XX response containing a
P-Answer-State header field containing the parameter "Unconfirmed"
and an answer MAY send media as specified in [2], however there is no
guarantee that the media will be received by the final recipient.
How a UAC confirms whether the media was or was not received by the
final destination when it his received a 2XX "unconfirmed response"
is application specific and outside of the scope of this document.
If the application is a conference then the mechanism specified in
[2] could be used to determine that the invited user joined.
Alternatively a BYE request could be received or the media could be
placed on hold if the final destination UAS does not accept the
session.
A UAC (terminal) that receives a 1XX or 2XX response without a
P-Answer-State Header or containing a P-Answer-State header field
containing the parameter "Confirmed" SHALL treat it as a "confirmed
response". A UAC (terminal) that receives in response to a REFER
Allen, et al. Expires June 13, 2006 [Page 10]
Internet-Draft The P-Answer-State Header December 2005
request a NOTIFY request containing a P-Answer-State header field
containing the parameter "Unconfirmed" 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 offer-answer exchange according to [2] then the UAC MAY
send media, however there is no guarantee that the media will be
received by the final recipient that was indicated in the Refer-To
header in the original REFER request.
There are no P-Answer-State procedures for a terminal acting in the
UAS role.
6.4.2. Procedures at the UA (PTT Server)
A UAS (PTT Server) MAY insert a P-Answer-State header field in any
1XX or 2XX response that is allowed to contain an answer in response
to an offer contained in an INVITE request as specified in [2]. A
response containing the P-Answer-State header field containing the
parameter "Unconfirmed" MAY or MAY NOT contain an answer. If the
response contains an answer then the sending UA MUST be ready to
receive media as specified in [2].
A PTT Server 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 PTT Server UAS also includes an answer in the
response along with a P-Answer-State header field containing the
parameter "Unconfirmed" the PTT Server MUST be ready to receive media
as specified in [2] and MAY buffer any media it receives until it
receives a "confirmed response" from the final destination UA or
until the buffer is full. Such a PTT Server may insert an answer in
the response it generates even if the "unconfirmed response" it
received did not contain an answer.
A PTT Server that acts as a back-to-back UA and receives a REFER
request to send an INVITE request to another UA as specified in [10]
MAY insert a P-Answer-State header field containing the parameter
"Unconfirmed" in the sipfrag of a 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 PTT Server that receives the REFER
request receives the P-Answer-State header in a response from another
node then the headers and parameters from that response are included
in the sipfrag. If the PTT Server that receives the REFER request
itself has the hint that the terminating UAC will automatically
answer the INVITE sent as a result of the REFER request then the PTT
Allen, et al. Expires June 13, 2006 [Page 11]
Internet-Draft The P-Answer-State Header December 2005
Server generates a sipfrag for a 200 OK response. If the REFER was
sent as part of an existing dialog established by an INVITE request
and for which there has been a successful offer-answer exchange
according to [2] the PTT Server MUST be ready to receive media as
specified in [2] and MAY buffer any media it receives until it
receives a "confirmed response" from the final destination UA or
until its buffer is full.
A PTT Server 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 PTT Server that acts as a back-to-
back UA sends a NOTIFY request according to [10] then the PTT Server
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 PTT Server 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 PTT Server 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.
A PTT Server 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 PTT Server UAS knows that the final destination UA is ready to
accept media and the PTT Server UAS did not previously send an
"Unconfirmed response" the PTT Server UAS MAY insert a P-Answer-State
header field containing the parameter "Confirmed" in the response.
If a PTT Server 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 PTT Server did not previously include a P-Answer-State
header containing the parameter "Unconfirmed" in the sipfrag of a
NOTIFY request sent in response to the REFER request then the PTT
Server 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.
Allen, et al. Expires June 13, 2006 [Page 12]
Internet-Draft The P-Answer-State Header December 2005
6.4.3. Procedures at the proxy server
SIP proxy servers do not need to understand the semantics of the
P-Answer-State header field. As part of the regular SIP rules for
unknown headers, a proxy will forward unknown headers. A proxy MAY
insert a P-Answer-State header field in a 1XX response that it
originates compliant with [3] or add it to a 2XX response that
contains an answer in response to an offer contained in an INVITE
request as specified in [2].
A proxy that returns a 1XX response in response to an INVITE request
MAY insert a P-Answer-State header field containing the parameter
"Unconfirmed" in the response if it has not yet received a "confirmed
response" from the final destination UA.
A proxy that receives a 1XX or 2XX response without a P-Answer-State
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.
7. Formal syntax
The mechanisms specified in this document is described in both prose
and an augmented Backus-Naur Form (BNF) defined in [4]. Further,
several BNF definitions are inherited from SIP and are not repeated
here. Implementers need to be familiar with the notation and
contents of SIP [3] and [4] to understand this document.
7.1. P-Answer-State header syntax
The syntax of the P-Answer-State header is described as follows:
P-Answer-State = "P-Answer-State" HCOLON answer-type
answer-type = "Confirmed" / "Unconfirmed"
Allen, et al. Expires June 13, 2006 [Page 13]
Internet-Draft The P-Answer-State Header December 2005
7.2. Table of the new header
Table 1 extends the headers defined in this document to Table 2 in
SIP [3], section 7.1 of the SIP-specific event notification [11]
tables 1 and 2 in the SIP INFO method [12], tables 1 and 2 in
Reliability of provisional responses in SIP [13], tables 1 and 2 in
the SIP UPDATE method [14], tables 1 and 2 in the SIP extension for
Instant Messaging [15], table 1 in the SIP REFER method [10], and
table 2 in the SIP PUBLISH method [16]:
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Answer-State 1xx,2xx ar - - - o - - -
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Answer-State R - - - - - - -
Figure 1
8. Example usage session flows
For simplicity some details such as intermediate proxies and 100
Trying responses are not shown in the following example flows. The
term "policy server" is used here to mean a policy enforcement
server.
8.1. Pre-arranged group call using on-demand session
The following flow shows Alice making a Pre-arranged Group Call using
a Conference URI which has Bob on the member list. The session
initiation uses the On-demand Session establishment mechanism where a
SIP INVITE containing an SDP offer is sent by Alices's terminal when
Alice pushes her push to talk button.
In this example Alice's Policy Server acts a Call Stateful SIP Proxy
and Bob's Policy Server which is aware that the current Answer Mode
setting of Bob's terminal is set to Auto Answer acts as a B2BUA.
For simplicity the invitations by the Conference Focus to the other
members of the group are not shown in this example.
Allen, et al. Expires June 13, 2006 [Page 14]
Internet-Draft The P-Answer-State Header December 2005
Alice's Alices's Conference Bob's Bob's
Terminal Policy Server focus Policy Server Terminal
| | | | |
|--(1)INVITE-->| | | |
| |--(2)INVITE-->| | |
| | |--(3)INVITE->| |
| | | |--(4)INVITE-->|
| | |<--(5)183----| |
| |<---(6)200----| | |
|<---(7)200----| | | |
|----(8)ACK--->| | | |
| |---(9)ACK---->| | |
| | | | |
|=====Early Media Session====>| | |
| | MEDIA | |
| | BUFFERING | |
| | | |<---(10)200---|
| | | |---(11)ACK--->|
| | |<--(12)200---| |
| | |--(13)ACK--->| |
| | | | |
| | |========Media Session======>|
| | | | |
| | | | |
Figure 2
F1 INVITE Alice -> Alices's Policy Server
INVITE sip:FriendsOfAlice@atlanta.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
F2 INVITE Alice's Policy Server -> Conference Focus
INVITE sip:FriendsOfAlice@atlanta.com SIP/2.0
Via: SIP/2.0/UDP
AlicesPolicyServer.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Allen, et al. Expires June 13, 2006 [Page 15]
Internet-Draft The P-Answer-State Header December 2005
Record-Route: <sip:AlicesPolicyServer.atlanta.com>
Max-Forwards: 69
To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
The Conference Focus explodes the Conference URI and Invites Bob
F3 INVITE Conference Focus -> Bob's Policy Server
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@biloxi.com>
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 INVITE
Contact: <sip:AlicesConferenceFocus.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
F4 INVITE Bob's Policy Server -> Bob
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@biloxi.com>
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:BobsPolicyServer.biloxi.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
F5 183 Session Progress Bob's Policy Server -> Conference Focus
Allen, et al. Expires June 13, 2006 [Page 16]
Internet-Draft The P-Answer-State Header December 2005
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@biloxi.com>;tag=a6c85cf
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPolicyServer.biloxi.com>
CSeq: 301166605 INVITE
P-Answer-State: Unconfirmed
Content-Length: 0
F6 200 OK Conference Focus -> Alice's Policy Server
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesPolicyServer.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPolicyServer.atlanta.com>
To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesConferenceFocus.atlanta.com>
P-Answer-State: Unconfirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
F7 200 OK Alice's Policy Server -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Record-Route: <sip:AlicesPolicyServer.atlanta.com>
To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesConferenceFocus.atlanta.com>
P-Answer-State: Unconfirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
F8 ACK Alice -> Alice's Policy Server
Allen, et al. Expires June 13, 2006 [Page 17]
Internet-Draft The P-Answer-State Header December 2005
ACK sip:AlicesConferenceFocus.atlanta.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Route: <sip:AlicesPolicyServer.atlanta.com>
Max-Forwards: 70
To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
F9 ACK Alice's Policy Server -> Conference Focus
ACK sip:AlicesConferenceFocus.atlanta.com SIP/2.0
Via: SIP/2.0/UDP
AlicesPolicyServer.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 69
To: "Alice's Friends" <sip:FriendsOfAlice@atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
The early half duplex media session between Alice and the Conference
Focus is now established and the Conference Focus buffers the media
it receives from Alice.
F10 200 OK Bob -> Bob's Policy Server
SIP/2.0 200 OK
Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bKa27bc93
To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
F11 ACK Bob's Policy Server -> Bob
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
Allen, et al. Expires June 13, 2006 [Page 18]
Internet-Draft The P-Answer-State Header December 2005
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 ACK
Content-Length: 0
F12 200 OK Bob's Policy Server -> Conference Focus
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@biloxi.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=2178309898 Call-ID:
e60a4c784b6716
Contact: <sip:BobsPolicyServer.biloxi.com>
CSeq: 301166605 INVITE
P-Answer-State: Confirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
F13 ACK Conference Focus -> Bob's Policy Server
ACK sip:BobsPolicyServer.biloxi.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@biloxi.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 ACK
Content-Length: 0
The media session between Alice and Bob is now established and the
Conference Focus forwards the buffered media to Bob.
8.2. 1-1 Call using pre-established session
The following flow shows Alice making a 1-1 Call to Bob using a pre-
established session. A pre-established session is where a dialog is
established with Alices's Policy Server using a SIP INVITE SDP offer
answer exchange to pre-negotiate the codecs and other media
Parameters to be used for media sessions ahead of Alice initiating a
Communication. When Alice initiates a communication to Bob a SIP
REFER is used to Request Alice's Policy Server to send an INVITE to
Allen, et al. Expires June 13, 2006 [Page 19]
Internet-Draft The P-Answer-State Header December 2005
Bob. In this example Bob's Terminal does not use the Pre-established
Session mechanism.
In this example Alice's Policy Server acts a B2BUA and also performs
the Conference Focus function. Bob's Policy Server which is aware
that the current Answer Mode setting of Bob's terminal is set to Auto
Answer acts as a B2BUA.
Alice's Alice's Bob's Bob's
Terminal Policy Server / Policy Server Terminal
Conference Focus
| | | |
|-----(1)INVITE-- ----->| | |
|<-----(2)200-----------| | |
|-------(3)ACK--------->| | |
| | | |
| | | |
| | | |
|----(4)REFER---------->| | |
|<-----(5)202-----------| | |
| |----(6)INVITE---->| |
| | |--(7)INVITE---->|
| | | |
| |<----(8)183-------| |
|<---(9)NOTIFY----------| | |
|-----(10)200---------->| | |
| | | |
|=Early Media Session==>| | |
| MEDIA | |
| BUFFERING | |
| | |<---(11)200-----|
| | |---(12)ACK----->|
| |<----(13)200------| |
| |-----(14)ACK----->| |
| |===========Media Session==========>|
| | | |
|<---(15)NOTIFY---------| | |
|-----(16)200---------->| | |
| | | |
Figure 3
F1 INVITE Alice -> Alices's Policy Server
INVITE sip: AlicesConferenceFactoryURI.atlanta.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.atlanta.com>
Allen, et al. Expires June 13, 2006 [Page 20]
Internet-Draft The P-Answer-State Header December 2005
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
F2 200 OK Alice's Policy Server -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:AlicesPre-establishesSession@
AlicesPolicyServer.atlanta.com>
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
F3 ACK Alice -> Alice's Policy Server
ACK sip:AlicesPre-establishesSession@AlicesPolicyServer.atlanta.com
SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
Alices's terminal has established a Pre-established Session with
Alice's Policy Server. All the media parameters are pre-negotiated
for use at communication time.
Alice initiates a Communication to Bob
F4 REFER Alice -> Alices's Policy Server
REFER sip:AlicesPre-establishesSession@AlicesPolicyServer.atlanta.com
SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
Allen, et al. Expires June 13, 2006 [Page 21]
Internet-Draft The P-Answer-State Header December 2005
To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Refer-To: "Bob" <sip:bob@biloxi.com>
Contact: <sip:alice@pc33.atlanta.com>
F5 202 ACCEPTED Alice's Policy Server -> Alice
SIP/2.0 202 ACCEPTED
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
Contact: <sip:AlicesPre-establishesSession@
AlicesPolicyServer.atlanta.com>
F6 INVITE Conference Focus -> Bob's Policy Server
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.atlanta.com;branch=z9hG4bk4721d8
Max-Forwards: 70
To: "Bob" <sip:bob@biloxi.com>
From: "Alice" <sip:Alice@atlanta.com>;tag=2178309898
Call-ID: e60a4c784b6716
CSeq: 301166605 INVITE
Contact: <sip:AlicesConferenceFocus.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
F7 INVITE Bob's Policy Server -> Bob
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bKa27bc93
Max-Forwards: 70
To: "Bob" <sip:bob@biloxi.com>
From: "Alice" <sip:Alice@atlanta.com>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:BobsPolicyServer.biloxi.com>
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
Allen, et al. Expires June 13, 2006 [Page 22]
Internet-Draft The P-Answer-State Header December 2005
F8 183 Session Progress Bob's Policy Server -> Conference Focus
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@biloxi.com>;tag=a6c85cf
From: "Alice" <sip:Alice@atlanta.com>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPolicyServer.biloxi.com>
CSeq: 301166605 INVITE
P-Answer-State: Unconfirmed
Content-Length: 0
F9 NOTIFY Alices's Policy Server -> Alice
NOTIFY sip:alice@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP AlicesPre-establishesSession@
AlicesPolicyServer.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 NOTIFY
Contact: <sip:AlicesPre-establishesSession@
AlicesPolicyServer.atlanta.com>
Event: refer
Subscription-State: Active;Expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 99
SIP/2.0 183 Session Progress
To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
P-Answer-State: Unconfirmed
F10 202 ACCEPTED Alice -> Alice's Policy Server
SIP/2.0 202 ACCEPTED
Via: SIP/2.0/UDP AlicesPre-establishesSession@
AlicesPolicyServer.atlanta.com;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 NOTIFY
The early half duplex media session between Alice and the Conference
Focus is now established and the Conference Focus buffers the media
it receives from Alice.
Allen, et al. Expires June 13, 2006 [Page 23]
Internet-Draft The P-Answer-State Header December 2005
F11 200 OK Bob -> Bob's Policy Server
SIP/2.0 200 OK
Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bK927bc93
To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
F12 ACK Bob's Policy Server -> Bob
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP BobsPolicyServer.biloxi.com;branch=z9hG4bK927bc93
Max-Forwards: 70
To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
From: "Alice" <sip:Alice@atlanta.com>;tag=781299330
Call-ID: 6eb4c66a847710
CSeq: 478209 ACK
Content-Length: 0
F13 200 OK Bob's Policy Server -> Conference Focus
SIP/2.0 200 OK
Via: SIP/2.0/UDP
AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
To: "Bob" <sip:bob@biloxi.com>;tag=a6670811
From: "Alice's Friends"
<sip:FriendsOfAlice@atlanta.com>;tag=2178309898
Call-ID: e60a4c784b6716
Contact: <sip:BobsPolicyServer.biloxi.com>
CSeq: 301166605 INVITE
P-Answer-State: Confirmed
Content-Type: application/sdp
Content-Length: 131
(SDP not shown)
F14 ACK Conference Focus -> Bob's Policy Server
ACK sip:BobsPolicyServer.biloxi.com SIP/2.0
Via: SIP/2.0/UDP
AlicesConferenceFocus.atlanta.com;branch=z9hG4bK4721d8
Allen, et al. Expires June 13, 2006 [Page 24]
Internet-Draft The P-Answer-State Header December 2005
Max-Forwards: 70
To: "Bob" <sip:bob@biloxi.com>;tag=a6670811
From: "Alice" <sip:Alice@atlanta.com>;tag=1928301774
Call-ID: e60a4c784b6716
CSeq: 301166605 ACK
Content-Length: 0
The media session between Alice and Bob is now established and the
Conference Focus forwards the buffered media to Bob.
F15 NOTIFY Alices's Policy Server -> Alice
NOTIFY sip:alice@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP AlicesPre-establishesSession@
AlicesPolicyServer.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 NOTIFY
Contact: <sip:AlicesPre-establishesSession@
AlicesPolicyServer.atlanta.com>
Event: refer
Subscription-State: Active;Expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 83
SIP/2.0 200 OK
To: "Bob" <sip:bob@biloxi.com>;tag=d28119a
P-Answer-State: Confirmed
F16 202 ACCEPTED Alice -> Alice's PolicyServer
SIP/2.0 202 ACCEPTED
Via: SIP/2.0/UDP AlicesPre-establishesSession@
AlicesPolicyServer.atlanta.com;branch=z9hG4bKnashds8
To: <sip:AlicesConferenceFactoryURI.atlanta.com>;tag=c70ef99
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 NOTIFY
9. Security considerations
The information returned in the P-Answer-State header is not viewed
as particularly sensitive. Rather, it is informational in nature,
providing an indication to the UAC that delivery of any media sent as
a result of an answer in this response is not guaranteed. An
Allen, et al. Expires June 13, 2006 [Page 25]
Internet-Draft The P-Answer-State Header December 2005
eavesdropper cannot gain any useful information by obtaining the
contents of this header.
If end-to-end protection is not used at the SIP layer, it is possible
for proxies between the UAs to remove the header or modify the
contents of the header value. However end-to-end protection has not
been considered as the P-Answer-State header is normally added by an
intermediate node that acts either as a B2BUA or proxy. This attack
either denies the caller the knowledge that the callee has yet to be
contacted or falsely indicates that the callee has yet to be
contacted when they have already answered. It is therefore
RECOMMENDED that this extension is used in a secured trusted
environment where transitive trust exists between the proxies and
UAs.
If end-to-end security mechanisms are to be used issues such as key
exchange between endpoints and intermediate network nodes need to be
considered."
10. IANA considerations
10.1. Registration of Header Fields
This document defines a private SIP extension header field (beginning
with the prefix "P-" ) based on the registration procedures defined
in RFC 3427 [17].
The following rows shall be added to the "Header Fields" section of
the SIP parameter registry:
+----------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+----------------+--------------+-----------+
| P-Answer-State | | [RFCXXXX] |
+----------------+--------------+-----------+
Editor Note: [RFCXXXX] should be replaced with the designation of
this document.
10.2. Registration of header field parameters
This document defines parameters for the header fields defined in the
preceding section. The header field named "P-Answer-State" may take
the values "Unconfirmed", or "Confirmed".
Allen, et al. Expires June 13, 2006 [Page 26]
Internet-Draft The P-Answer-State Header December 2005
The following rows shall be added to the "Header Field Parameters and
Parameter Values" section of the SIP parameter registry:
+----------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+----------------+----------------+-------------------+-----------+
| P-Answer-State | Unconfirmed | Yes | [RFCXXXX] |
| P-Answer-State | Confirmed | Yes | [RFCXXXX] |
+----------------+----------------+-------------------+-----------+
Editor Note: [RFCXXXX] should be replaced with the designation of
this document.
11. Changes since previous version
The following changes have been made since the 00 version:
The term "intermediate node" has been replaced by "PTT Server".
A Terminology section has been added for clarity of new terms
introduced in this document.
The mechanism for delivering the P-Answer_state header in a Notify
when only a single PTT Server is involved has been changed to be
included in a sipfrag.
The term "an SDP answer" has been replaced by "an answer" to make
the text compatible with other session descriptions.
The term "an SDP offer" has been replaced by "an offer" to make
the text compatible with other session descriptions.
The text has been improved in some sections to improve the
readability.
Various nits and editorial corrections have been made.
12. Acknowledgements
The authors would like to thank Paul Kyzivat, Dale Worley, Dean
Willis, Rohan Mahay, Christian Schmidt, Mike Hammer, and Miguel
Garcia-Martin for their comments that contributed to the progression
of this work. The authors would also like to thank the OMA POC
Working Group members for their support of this document and in
particular Tom Hiller for presenting the concept of the P-Answer-
State header to SIPPING at IETF#62.
Allen, et al. Expires June 13, 2006 [Page 27]
Internet-Draft The P-Answer-State Header December 2005
13. References
13.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
13.2. Informative references
[5] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-05 (work in
progress), May 2005.
[6] Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event
Package and Data Format for Various Settings in Support for
the Push-to-talk Over Cellular (PoC) Service",
draft-garcia-sipping-poc-isb-am-04 (work in progress),
September 2005.
[7] Willis, D. and A. Allen, "Requesting Answering and Alerting
Modes for the Session Initiation Protocol (SIP)",
draft-willis-sip-answeralert-01 (work in progress),
August 2005.
[8] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
[9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[10] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
Allen, et al. Expires June 13, 2006 [Page 28]
Internet-Draft The P-Answer-State Header December 2005
[12] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[14] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[16] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[17] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
Allen, et al. Expires June 13, 2006 [Page 29]
Internet-Draft The P-Answer-State Header December 2005
Authors' Addresses
Andrew Allen (editor)
Research in Motion (RIM)
122 West John Carpenter Parkway, Suite 430
Irving, Texas 75039
USA
Phone: unlisted
Fax: unlisted
Email: aallen@rim.com
Jan Holm
Ericsson
Gotalandsvagen 220
Stockholm 612526
Sweden
Phone: unlisted
Fax: unlisted
Email: Jan.Holm@ericsson.com
Tom Hallin
Motorola
1501 W Shure Drive
Arlington Heights 60004
USA
Phone: unlisted
Fax: unlisted
Email: thallin@motorola.com
Allen, et al. Expires June 13, 2006 [Page 30]
Internet-Draft The P-Answer-State Header December 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 June 13, 2006 [Page 31]
