One document matched: draft-boulton-sip-endpoint-view-00.txt
Network Working Group C. Boulton
Internet-Draft NS-Technologies
Intended status: Standards Track I. Evans
Expires: September 27, 2009 G. Liddell
D. Shutt
P. Barrett
Avaya
March 26, 2009
An Extension to the Session Initiation Protocol (SIP) for Endpoint
Session View
draft-boulton-sip-endpoint-view-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 27, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Boulton, et al. Expires September 27, 2009 [Page 1]
Internet-Draft Endpoint Session View March 2009
Abstract
This document defines a standard mechanism for capturing and
providing important session information associated with the Session
Initiation Protocol (SIP). Certain properties of a SIP protocol
exchange are essential for further independent signalling
interactions. In certain environments this information can be lost
when traversing entities such as Back-to-Back User Agents (B2BUA).
This document defines a new optional SIP header, Endpoint-View, for
capturing appropriate information.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Overview . . . . . . . . . . . . . . . . . 3
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 6
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. UAC Behavior - INVITE generation . . . . . . . . . . . . . . . 8
4. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Reliable Provisional . . . . . . . . . . . . . . . . . . . . . 10
6. UAC Behavior - ACK generation . . . . . . . . . . . . . . . . 11
7. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security and Privacy . . . . . . . . . . . . . . . . . . . . . 13
9. The Endpoint-View Header . . . . . . . . . . . . . . . . . . . 14
10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12.1. Header Field . . . . . . . . . . . . . . . . . . . . . . . 19
12.2. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 19
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Boulton, et al. Expires September 27, 2009 [Page 2]
Internet-Draft Endpoint Session View March 2009
1. Introduction
1.1. Background and Overview
The Session Initiation Protocol (SIP) has emerged as one of the
primary multimedia establishment protocols for Voice Over IP(VOIP).
Since its conception it has seen increasing usage as more legacy
systems are replaced by IP based solutions and requirements for
general multimedia content increases.
RFC 3261 [RFC3261] defines the concept of a back-to-back user agent
(B2BUA). Such entities have emerged as an important component in
VOIP architectures as they allow a central focus of control for both
protocol signalling and potentially media. B2BUA's are considered a
logical role composed of SIP User agents acting independently from a
protocol signalling perspective but yet appear as a single entity
externally. Figure 1 illustrates a simple B2BUA logical function.
+--------------------+
| B2BUA |
SIP | +-----+ +-----+ | SIP
<------------|->| UA | | UA |<-|---------->
| +-----+ +-----+ |
| |
+--------------------+
Figure 1: B2BUA
The logical role played by a B2BUA is represented by the outer box
from Figure 1. To the outside world it appears as single entity.
Internally the B2BUA consits of two User Agents which represent
independent SIP signalling entities with the endpoint clients. Both
independent SIP signalling legs have unique dialog identifiers, as
defined in RFC 3261 [RFC3261] and are combined using application
logic. For example, a SIP INVITE request would arrive at the left
hand side of Figure 1 and could be passed out the other side to
another SIP entity. The left hand side and right hand side dialog
identifiers (SIP Call-ID header, To header tag parameter and From
Header tag parameter) would differ.
In general, a B2BUA would need to map and translate certain SIP
headers and parameters to maintain valid information on each side of
a B2BUA. A good example is demonstrated when using the SIP REFER
method in conjunction with an existing INVITE dialog. Some of the
signalling has been left out for simplicity.
Boulton, et al. Expires September 27, 2009 [Page 3]
Internet-Draft Endpoint Session View March 2009
(2) +------+ (1)
UA2 <---------> |B2BUA1|<---------> UA1
| +------+ ^
| |
| | (3)
| |
| V
| (5) +------+
+------------------------------->|B2BUA2|
+------+
^
|
| (4)
|
V
UA3
Figure 2: B2BUA and REFER
In this example 'UA1' has INVITE dialogs set up with both 'UA2' and
'UA3'. Both INVITE dialogs have traversed a B2BUA before reaching
'UA2' and 'UA3'. (1) and (2) represent the two SIP INVITE dialogs
when 'UA1' sends an INVITE to UA2 (through B2BUA1). (3) and (4)
represents the two INVITE dialogs when UA1 sends an INVITE to UA3
(through B2BUA2). At some later time, 'UA1' issues a SIP REFER
request to 'UA2' (in or out of dialog) with a SIP Replaces[RFC3891]
header. The 'Refer-To' header and 'Replaces' parameter are
constructed based on 'UA1's knowledge of the call with 'UA3' - which
is represented by (3). On receiving the REFER request from 'UA1',
'UA2' generates the appropriate INVITE request based on the
'Refer-To' header. As the 'Refer-To' header was constructed based on
(3) by 'UA1', the SIP URI points to 'B2BUA2' and the INVITE dialog
parameters represent dialog (3). This results in 'UA2' generating a
SIP INVITE request that is sent to 'B2BUA2' replacing (3). This is
illustrated by (5).
A number of SIP architectures, for example the IP Multimedia
System(IMS), have based application composition when servicing a user
on a concept known as sequencing. Sequencing involves an intelligent
entity making recursive decisions on behalf of users as to which
application a SIP request should be routed to next. A simple example
is illustrated in Figure 3.
Boulton, et al. Expires September 27, 2009 [Page 4]
Internet-Draft Endpoint Session View March 2009
(1) +--------------------+ (8)
SIP---------->| Sequencing Engine |SIP---------->
+--------------------+
| ^ | ^ | ^
(2)| | (4)| | (6)| |
| |(3) | |(5) | |(7)
v | v | v |
+----+ +----+ +----+
|App1| |App2| |App3|
+----+ +----+ +----+
Figure 3: Sequencing
In Figure 3, firstly a SIP request arrives at the entity carrying out
sequencing, as shown by (1). The Sequencing engines makes the
decision to route the request to 'App1' as shown by (2). The pushing
of two SIP Route headers (one pointing to 'App1' and the other
pointing back to itself) is a common way for a sequencing engine to
ensure the request is returned. Once 'App1' has finished with the
request it is returned back the sequencing engine for further
processing (3). (4) The request is then sequenced to 'App2' and then
returned back to the sequencing engine (5). This is then repeated
for the final application to be sequenced (6)(7). Once all
appropriate applications have been traversed, the SIP request is
routed onwards (8).
The combination of using sequencing in conjunction with B2BUA causes
a number of problems. Some out of dialog SIP requests, headers and
parameters are used to directly reference an existing dialog to avoid
sharing SIP dialog state (as discussed in RFC 5057 [RFC5057]). The
use of GRUU[I-D.ietf-sip-gruu], SIP Join[RFC3911] and
Replaces[RFC3891] headers are good examples where specific dialog
information is used within a SIP message to reference an existing
dialog.
In the simple case, if you have a B2BUA that is aware of translating
all appropriate SIP headers then signalling will traverse
appropriately. You also need to ensure that the request traverses a
B2BUA instance that has appropriate information to achieve the
correct outome. A problem occurs when you are attempting to apply
the sequencing model previously discussed. All SIP signalling
requests arriving at the sequencing engine have to be treated
independently and sequenced appropriately. The applications selected
would most probably result in a different application path being
taken. In fact, it would be seen as a major constraint for a path to
be forced through certain applications to obtain consistent service.
For this reason, requests that are targeted using information such as
Boulton, et al. Expires September 27, 2009 [Page 5]
Internet-Draft Endpoint Session View March 2009
the SIP Join and Replaces headers need to maintain a consistent, end
to end association. From the earlier example illustrated in
Figure 3, an endpoints view of the call is represented in Figure 4.
It should also be noted that even when such sequencing techniques are
not being used, a SIP request as specified in Figure 2 by (3), is not
guaranteed to be sent to the same B2BUA instance. The mapping
carried out in (4) from Figure 2 would not take place.
(1) +----+ +----+ +----+ (2)
UA1 <----------> |App1|<->|App2|<->|App3|<----------> UA2
+----+ +----+ +----+
Figure 4: Endpoint View
Figure 4 illustrates that if App1 and App3 are B2BUAs then the dialog
identifiers will represent the SIP dialog relationship between the
User Agent and the nearest B2BUA (not end to end). This is shown by
(1) and (2) in Figure 4. As a result, if either User Agent wishes to
create a new request that in some way references the existing dialog
(for example the SIP Join/Replaces header) or wants to direct the
request at a specific User Agent instance (by using the contact
address or GRUU), it is only able to populate the new request with
local SIP protocol information (the relationship illustrated by (1)
and (2) between the client and B2BUA). If, for example, one of the
clients wanted to create an out of dialog REFER that included a SIP
Replaces[RFC3891] header parameter in the Refer-To header, it would
only be able to populate based on the local identifiers between the
client and the B2BUA. It is also true that for the SIP R-URI to be
an accurate identifier it also must be populated correctly using the
contact generated by the client and not that by the B2BUA.
This specification proposes a solution to allow an endpoints view of
the call to be provided end-to-end for the purpose of being used in
new, related SIP protocol requests.
1.2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL". In addition, BCP 15 indicates requirement levels for
compliant implementations.
Boulton, et al. Expires September 27, 2009 [Page 6]
Internet-Draft Endpoint Session View March 2009
2. Requirements
o REQ-01 - A SIP User Agent Client is able to request support for a
local view of a dialog.
o REQ-02 - A SIP User Agent Server is able to convey support for the
local view mechanism.
o REQ-03 - A SIP User Agent Client is able to populate a SIP message
appropriately conveying its local view.
o REQ-04 - A SIP User Agent Server is able to populate a SIP message
appropriately conveying its local view.
o REQ-05 - Local view information should include the dialog
identifiers as specified in [RFC3261].
o REQ-06 - Local view information should include a target for
subsequent out of dialog requests. This could either be the local
contact address as specified in [RFC3261] or the appropriate
GRUU[I-D.ietf-sip-gruu].
o REQ-07 - Appropriate guideleins for support from SIP B2BUAs should
be documented to ensure compliance to this extension.
o REQ-08 - The entities receiving the endpoint view information
conveyed by this extension must be able to authenticate the entity
providing the request.
o REQ-09 - Appropriate security and confidentiality is required for
local view mechanism.
Boulton, et al. Expires September 27, 2009 [Page 7]
Internet-Draft Endpoint Session View March 2009
3. UAC Behavior - INVITE generation
The procedures defined in this extension SHOULD only be used in a SIP
INVITE request as specified in[RFC3261]. Future standardisation
mechanisms MAY allow the header to be included in other SIP dialog
creating requests. The client MUST generate a standard SIP INVITE
request as specified in [RFC3261]. A client wishing to demonstrate
support for this extension MUST insert a SIP 'Supported' header as
specified in [RFC3261] with the value of 'Endpoint-View'. A client
wishing to insist on using this extension MUST insert a SIP 'Require'
header as specified in [RFC3261] with the value of 'Endpoint-View'.
The client MUST also insert the 'Endpoint-View' SIP header as
specified in Section 9. The header will be populated with
appropriate information representing the local-tag, call-id and
contact address of the User Agent (which could be a
GRUU[I-D.ietf-sip-gruu]). At this stage the generating client does
not know the value of the remote tag and so it is left out.
Boulton, et al. Expires September 27, 2009 [Page 8]
Internet-Draft Endpoint Session View March 2009
4. UAS Behavior
On receiving an INVITE request, the UAS should inspect the message to
identify if this extension is supported. This would be reflected by
the presence of either a SIP Require or Supported header containing
the 'Endpoint-View' token. If the SIP supported header is present
then the UAS can optionally decide to include a SIP 'Endpoint-View'
header in the corresponding response. If the SIP Require header is
present then the UAS MUST support the extension to successfully
process the INVITE request. If it does not support this extension it
will generate a SIP 420 Bad Extension response as per [RFC3261].
If the UAS decides to indicate support for this draft, either through
the presence of a SIP Require/Supported header, a SIP Endpoint-View
SIP header MUST inserted as specified in Section 9 in a reliable SIP
response. [RFC3261] only defines 2xx responses as reliable while
[RFC3262] can also be used to convey this information. The header
will be populated with appropriate information representing the
local-tag, remote-tag, call-id and contact address of the User Agent
(which could be a GRUU). The response is then sent as normal.
Boulton, et al. Expires September 27, 2009 [Page 9]
Internet-Draft Endpoint Session View March 2009
5. Reliable Provisional
It should be noted that while the 'Endpoint-View' header can be
included in reliable provisional responses, the values included in a
SIP PRACK/200 OK exchange MUST not contradict the values included in
the SIP INVITE request and associated reliable response. In short,
the UAC MUST include the 'Endpoint-View' header in a PRACK request
(when reliable provisional responses[RFC3262] are being used) which
will be identical to the values included in INVITE request with the
addition of the 'remote-tag' header field parameter. This allows the
UAS to gain an earlier view of the full dialog details before waiting
for the SIP ACK request. The header will be the same as that for the
corresponding SIP ACK request. The 'Endpoint-View' header MUST NOT
be included in the 200 OK to a PRACK as it has no meaning when
compared to the value returned in the SIP provisional response.
[Editors Note: Currently we call out that 200 OK to PRACK MUST NOT
include this header. It has no meaning and so its exclusion does not
break anything. Should we be less explicit?]
Boulton, et al. Expires September 27, 2009 [Page 10]
Internet-Draft Endpoint Session View March 2009
6. UAC Behavior - ACK generation
On generating the corresponding SIP ACK request for a successful SIP
200 OK response as per [RFC3261], to complete the INVITE transaction,
the SIP UAC will also include the SIP Endpoint-View header
representing the local view of the dialog. The header will be
populated with appropriate information representing the local-tag,
remote-tag, call-id and contact address representing the User Agent
(which could be a GRUU). The ACK is then sent as normal.
Boulton, et al. Expires September 27, 2009 [Page 11]
Internet-Draft Endpoint Session View March 2009
7. B2BUA Behavior
A B2BUA has no clear definition and is able to manipulate SIP
protocol messages in any number of ways. This specification can in
no way enforce B2BUA behavior but can provide guidelines. For this
extension to work successfully a B2BUA should not remove or
manipulate the SIP 'Endpoint-View' header when it traverses. For
this specification to work the B2BUA is also advised to maintain
appropriate SIP Supported and Require headers when they appear in the
signalling. If supporting this extension contravenes any form of
local policy or security, the B2BUA should act as elegantly as
possible (for example, if a SIP Require header is present it should
act as a UAS and generate a SIP 420 Bad Extension response).
Boulton, et al. Expires September 27, 2009 [Page 12]
Internet-Draft Endpoint Session View March 2009
8. Security and Privacy
[Editors Note: To be included in a later version of the extension.
'Endpoint-View' header information needs to be appropriately
protected using encryption etc.]
Boulton, et al. Expires September 27, 2009 [Page 13]
Internet-Draft Endpoint Session View March 2009
9. The Endpoint-View Header
This specification defines a new SIP protocol header: 'Endpoint-
View'. Its formatting as a SIP header is described by the following
ABNF[RFC5234] and based on standard SIP syntax.
Endpoint-View = "Endpoint-View" HCOLON contact-param *(SEMI
endpoint-param) ;contact-param from RFC
3261 and optionally gruu extension
from RFCXXX
endpoint-param = remote-param / local-param / call-id
generic-param
remote-param = "remote-tag" EQUAL token
local-param = "local-tag" EQUAL token
call-id = "call-id" EQUAL token
;remote-param and local-param from RFC 4538
;token and generic-param from RFC 3261
Table 1 and 2 are an extension of Tables 2 and 3 in RFC 3261
[RFC3261] for the Endpoint-View header field. The column "INF" is
for the INFO method [RFC2976], "PRA" is for the PRACK method
[RFC3262], "UPD" is for the UPDATE method [RFC3311], "SUB" is for the
SUBSCRIBE method [RFC3265], "NOT" is for the NOTIFY method [RFC3265],
"MSG" is for the MESSAGE method [RFC3428], "REF" is for the REFER
method [RFC3515], and "PUB" is for the PUBLISH method [RFC3903].
Header field where proxy ACK BYE CAN INV OPT REG PUB
Endpoint-View R - o - - o - - -
Endpoint-View 2xx,18x - - - - o - - -
Figure 5: Table 1
Header field where proxy PRA UPD SUB NOT INF MSG REF
Endpoint-View R - o - - - - - -
Endpoint-View 2xx,18x - - - - - - - -
Figure 6: Table 2
Boulton, et al. Expires September 27, 2009 [Page 14]
Internet-Draft Endpoint Session View March 2009
10. Example
The following is an example of a simple exchange using the 'Endpoint-
View' SIP header. Some of the messages have been left out for
simplicity.
UAC B2BUA UAS
| | |
| (1) SIP INVITE | |
|----------------------->| |
| | (2) SIP INVITE |
| |----------------------->|
| | (3) SIP 200 OK |
| |<-----------------------|
| (4) SIP 200 OK | |
|<-----------------------| |
| (5) SIP ACK | |
|----------------------->| |
| | (6) SIP ACK |
| |----------------------->|
| | |
(1) UAC->B2BUA (SIP): INVITE requiring support of the 'Endpoint-View'
extension.
INVITE sip:uas@example.com SIP/2.0
To: <sip:uas@examplae.com>
From: <sip:uac@example.com>;tag=8937498
Via: SIP/2.0/UDP uac.example.com;branch=z9hG412345678
CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com
Require: Endpoint-View
Endpoint-View: <sip:uac@pc1.example.com;gr=kowpeojr893274jksd>
;local-tag=8937498
;call-id=893jhoeihjr8392@example.com
Contact: <sip:uac@pc1.example.com;gr=kowpeojr893274jksd>
Content-Type: application/sdp
Cotent-Length: [..]
[SDP NOT INCLUDED]
(2) B2BUA->UAS (SIP): INVITE requiring support of the 'Endpoint-View'
extension with changed dialog parameters and contact address.
Boulton, et al. Expires September 27, 2009 [Page 15]
Internet-Draft Endpoint Session View March 2009
INVITE sip:uas@example.com SIP/2.0
To: <sip:uas@examplae.com>
From: <sip:b2bua@example.com>;tag=438290jdJ239hd
Via: SIP/2.0/UDP b2bua.example.com;branch=z9hG4892374892
CSeq: 1 INVITE
Call-ID: djioHJKd38972yjdfl342@example.com
Require: Endpoint-View
Endpoint-View: <sip:b2bua@example.com;gr=kowpeojr893274jksd>
;local-tag=8937498
;call-id=893jhoeihjr8392@example.com
Contact: <sip:b2bua@example.com>
Content-Type: application/sdp
Cotent-Length: [..]
[SDP NOT INCLUDED]
(3) UAS->B2BUA (SIP): 200 OK
SIP/2.0 200 OK
To: <sip:uas@example.com>;tag=023983774
From: <sip:uac@example.com>;tag=438290jdJ239hd
Via: SIP/2.0/UDP b2bua.example.com;branch=z9hG4892374892
CSeq: 1 INVITE
Call-ID: djioHJKd38972yjdfl342@example.com
Supported: Endpoint-View
Endpoint-View: <sip:uas@pc2.example.com;gr=230plksdajf93824j>
;local-tag=023983774
;remote-tag=438290jdJ239hd
;call-id=djioHJKd38972yjdfl342@example.com
Contact: <uas@pc2.example.com;gr=230plksdajf93824j>
Content-Type: application/sdp
Content-Length: [..]
[SDP NOT INCLUDED]
(4) B2BUA->UAC (SIP): 200 OK
Boulton, et al. Expires September 27, 2009 [Page 16]
Internet-Draft Endpoint Session View March 2009
SIP/2.0 200 OK
To: <sip:uas@example.com>;tag=8jc8923jdl
From: <sip:uac@example.com>;tag=8937498
Via: SIP/2.0/UDP b2bua.example.com;branch=z9hG412345678
CSeq: 1 INVITE
Call-ID: 893jhoeihjr8392@example.com
Supported: Endpoint-View
Endpoint-View: <sip:uas@pc2.example.com;gr=230plksdajf93824j>
;local-tag=023983774
;remote-tag=438290jdJ239hd
;call-id=djioHJKd38972yjdfl342@example.com
Contact: <sip:b2bua@example.com;gr=39uadsj8239ujdj0>
Content-Type: application/sdp
Content-Length: [..]
[SDP NOT INCLUDED]
(5) UAC->B2BUA (SIP): ACK
ACK sip:b2bua@example.com;gr=39uadsj8239ujdj0 SIP/2.0
To: <sip:uas@examplae.com>;tag=8jc8923jdl
From: <sip:uac@example.com>;tag=8937498
Via: SIP/2.0/UDP uac.example.com;branch=z9hG429dj80321je
CSeq: 1 ACK
Call-ID: 893jhoeihjr8392@example.com
Require: Endpoint-View
Endpoint-View: <sip:uac@pc1.example.com;gr=kowpeojr893274jksd>
;local-tag=8937498
;remote-tag=8jc8923jdl
;call-id=893jhoeihjr8392@example.com
(6) B2BUA->UAS (SIP): ACK
ACK sip:uas@pc2.example.com;gr=230plksdajf93824j SIP/2.0
To: <sip:uas@examplae.com>;tag=023983774
From: <sip:uac@example.com>;tag=438290jdJ239hd
Via: SIP/2.0/UDP b2bua.example.com;branch=z9hG43920dj2io3jd98
CSeq: 1 ACK
Call-ID: djioHJKd38972yjdfl342@example.com
Require: Endpoint-View
Endpoint-View: <sip:uac@pc1.example.com;gr=kowpeojr893274jksd>
;local-tag=8937498
;remote-tag=8jc8923jdl
;call-id=893jhoeihjr8392@example.com
Boulton, et al. Expires September 27, 2009 [Page 17]
Internet-Draft Endpoint Session View March 2009
11. Security Considerations
Security Considerations to be included in later versions of this
document.
Boulton, et al. Expires September 27, 2009 [Page 18]
Internet-Draft Endpoint Session View March 2009
12. IANA Considerations
This specification registers a new SIP header field, a new option tag
according to the processes of RFC 3261 [RFC3261].
12.1. Header Field
RFC Number: RFC XXXX
Header Field Name: Endpoint-View
Compact Form: none
12.2. SIP Option Tag
This specification registers a new SIP option tag per the guidelines
in Section 27.1 of RFC 3261 [RFC3261].
Name: Endpoint-View
Description: This option tag is used to identify the Endpoint-View
header field extension. When used in a Require header field, it
implies that the recipient needs to support the Endpoint-View
header field. When used in a Supported header field, it implies
that the sender of the message supports it.
Boulton, et al. Expires September 27, 2009 [Page 19]
Internet-Draft Endpoint Session View March 2009
13. Acknowledgments
The authors would like to thank Gordon Brunson, Harsh Mendiratta and
Joel Ezall who contributed significantly to the proposal.
Boulton, et al. Expires September 27, 2009 [Page 20]
Internet-Draft Endpoint Session View March 2009
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000.
[RFC3261] 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.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Boulton, et al. Expires September 27, 2009 [Page 21]
Internet-Draft Endpoint Session View March 2009
14.2. Informative References
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007.
Boulton, et al. Expires September 27, 2009 [Page 22]
Internet-Draft Endpoint Session View March 2009
Authors' Addresses
Chris Boulton
NS-Technologies
Email: chris@ns-technologies.com
Ian Evans
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: ievansATavaya.com
Gethin Liddell
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: gliddellATavaya.com
David Shutt
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: dshuttATavaya.com
Pete Barrett
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: pbarrettATavaya.com
Boulton, et al. Expires September 27, 2009 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 21:19:16 |