One document matched: draft-worley-references-01.txt
Differences from draft-worley-references-00.txt
SIP D. Worley
Internet-Draft Nortel
Intended status: Experimental December 1, 2008
Expires: June 4, 2009
The References Header for SIP
draft-worley-references-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 4, 2009.
Worley Expires June 4, 2009 [Page 1]
Internet-Draft SIP References header December 2008
Abstract
This document defines a SIP extension header, References, to be used
within SIP messages to signify that the message (and the dialog
containing it) is related to one or more other dialogs. It is
expected to be used largely for diagnostic purposes.
Table of Contents
1. Purpose of the References Header . . . . . . . . . . . . . . . 3
2. Syntax and Semantics . . . . . . . . . . . . . . . . . . . . . 4
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. REFER . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Attended Transfer . . . . . . . . . . . . . . . . . . . . 8
3.3. Call Pickup . . . . . . . . . . . . . . . . . . . . . . . 11
4. Practical Experience . . . . . . . . . . . . . . . . . . . . . 15
5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. draft-loreto-sipping-dialog-correlation . . . . . . . . . 16
5.2. draft-kaplan-sip-session-id . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Revision History . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Changes from draft-worley-references-00 to
draft-worley-references-01 . . . . . . . . . . . . . . . . 20
7.2. draft-worley-references-00 . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Worley Expires June 4, 2009 [Page 2]
Internet-Draft SIP References header December 2008
1. Purpose of the References Header
In many situations, the processing of a SIP "telephone call" involves
a number of different SIP dialogs. Of course, the existing SIP
headers provide adequate information for the SIP elements to carry
out the needed operations. But in many cases, it is difficult for an
observer to identify from a network trace the particular SIP dialogs
that are involved in one operation.
For example, if a user agent receives a REFER message within one
dialog, it sends an INVITE to establish a new dialog which replaces
the previous one within the user interface of the user agent. But
since the connection between the new dialog and the old dialog is
only realized within the user agent, there is no algorithmic way to
associate the two dialogs based on the SIP messages alone -- the best
available technique is to extract all the messages to/from the
particular user agent, and then observe the INVITE that is sent
immediately after receipt of the REFER.
The purpose of the References header is to allow a SIP message to
specify that the message carrying it (and by extension, the dialog
that contains the message) is related to one or more other dialogs,
specified by their Call-Id values. Ideally, when given a Call-Id, an
automated process can use the connections between dialogs specified
in References headers to determine the entire set of dialogs that are
needed to understand a complete "telephone call" or other SIP
interaction.
Worley Expires June 4, 2009 [Page 3]
Internet-Draft SIP References header December 2008
2. Syntax and Semantics
The syntax of the References header is as follows. (All rules not
defined here are taken from section 25.1 of RFC 3261[sip].)
message-header =/ References
References = "References" HCOLON reference *(COMMA reference)
reference = callid *( SEMI reference-param )
reference-param = rel-param / generic-param
rel-param = "rel" EQUAL rel-value
rel-value = "refer" / "inquiry" / "xfer" / gen-value
Multiple References headers may appear in a SIP message, and their
values may be combined or separated as allowed by section 7.3 of RFC
3261[sip]. The ordering of References values is not significant.
The call-id elements of the Replaces and Join headers are considered
implicit References and so SHOULD NOT be specified in References
headers.
The presence of a References header in a SIP message means that the
message (and by implication, the dialog containing it) is related to
the dialog(s) bearing the specified Call-Id(s). Note that since
there is no way to specify the to-tag and from-tag of the referenced
dialog, the References header does not distinguish different dialogs
that have the same Call-Id, and all dialogs sharing a Call-Id are
considered to be related a priori. The processor of References
headers should consider the "related" relationship of dialogs to
include the symmetric-transitive closure of the References
relationship; that is, if a message in dialog A references dialog B,
and a message in dialog B references dialog C, then all three dialogs
should be considered related to each other.
The nature of the relationship between the message's dialog and the
referenced dialog(s) is indicated by the "rel" parameter (if it is
present). Since the message containing the References header is
likely to be constrained to be generated after the creation of the
dialog mentioned by the header, and the UA may not have control over
this time-ordering, relationship natures are considered symmetric.
E.g., a request with Call-Id A that performs an inquiry to assist in
routing dialog B may contain "References: B;rel=inquiry", but the
same meaning can be indicated by a message in dialog B containing
"References: A;rel=inquiry".
The currently defined values of the "rel" parameter are:
Worley Expires June 4, 2009 [Page 4]
Internet-Draft SIP References header December 2008
"refer" meaning that this request was generated due to a REFER
with the specified Call-Id
"inquiry" meaning that this request was generated to obtain
information needed to properly process a request with the
specified Call-Id. (For example, in section 2.16, "Call Pickup"
of [service-examples], a SUBSCRIBE is generated to discover the UA
which sent an INVITE to a designated AOR.)
"xfer" meaning that the dialog of this message and the dialog with
the specified Call-Id are the two legs of a consultative (or
attended) transfer. One endpoint of each dialog will become an
endpoint of the final dialog.
It is expected that the References header will usually appear in the
dialog-forming request of a dialog, but it may appear in any request
or response. Since 1xx responses are not delivered reliably, a
References header value that is present only in a 1xx response may
not be seen by an element that ought in principle to see the
response, and such a value SHOULD be present in another message of
the dialog going to that UA.
All parameters and parameter values that are not understood by the
processor of the References header MUST be ignored. Parameters and
values that start with "X-" (case-insensitive) are reserved for non-
standardized purposes.
Note that while the SIP References header is similar in function to
the Internet e-mail References header[message-format], they have
different syntaxes and are not interchangeable.
Worley Expires June 4, 2009 [Page 5]
Internet-Draft SIP References header December 2008
3. Examples
3.1. REFER
One use of References is to connect a REFER to the INVITE that it
causes to be sent. A typical use of REFER is to implement blind
transfer. This example is taken from section 2.4, "Transfer -
Unattended" of [service-examples].
Worley Expires June 4, 2009 [Page 6]
Internet-Draft SIP References header December 2008
Alice Bob Carol
| INVITE F1 | |
|<-------------------| |
| 180 Ringing F2 | |
|------------------->| |
| 200 OK F3 | |
|------------------->| |
| ACK F4 | |
|<-------------------| |
| RTP | |
|<==================>| |
| | |
| Alice performs unattended transfer |
| | |
| REFER Refer-To:C F5| |
|------------------->| |
| 202 Accepted F6 | |
|<-------------------| |
| NOTIFY F7 | |
|<-------------------| |
| 200 OK F8 | |
|------------------->| |
| BYE F9 | |
|------------------->| |
| 200 OK F10 | |
|<-------------------| |
| No RTP Session | INVITE Referred-By: A F11
| |------------------->|
| | 180 Ringing F12 |
| |<-------------------|
| | 200 OK F13 |
| |<-------------------|
| | ACK F14 |
| |------------------->|
| | RTP |
| |<==================>|
| NOTIFY F15 | |
|<-------------------| |
| 200 OK F16 | |
|------------------->| |
| | |
In order to execute the blind transfer, Alice's UA sends a REFER to
Bob's UA:
Worley Expires June 4, 2009 [Page 7]
Internet-Draft SIP References header December 2008
F5 REFER Alice -> Bob
REFER sips:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnashds8
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=314159
Call-ID: 12345601@atlanta.example.com
CSeq: 101 REFER
Refer-To: <sips:carol@chicago.example.com>
Referred-By: <alice@atlanta.example.com>
Contact: <sips:alice@client.atlanta.example.com>
Content-Length: 0
Upon receipt of the REFER, Bob's UA sends an INVITE to Carol's UA.
In order to make explicit the relationship between the REFER and the
INVITE, the INVITE has a References header giving the Call-Id of the
REFER:
F11 INVITE Bob -> Carol
INVITE sips:carol@chicago.example.com SIP/2.0
References: 12345601@atlanta.example.com;rel=refer
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnashds1
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=8675309
To: Carol <sips:carol@chicago.example.com>
Call-ID: 7436222@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@client.biloxi.example.com>
Referred-By: <alice@atlanta.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
3.2. Attended Transfer
An attended transfer normally involves three different dialogs. If
the transfer completes, and the REFER that completes the transfer has
a References header, the References header in the REFER and the
Replaces header in the resulting INVITE will suffice to connect the
three dialogs. However, to provide complete information if the
transfer does not complete, the INVITE that establishes the "second
Worley Expires June 4, 2009 [Page 8]
Internet-Draft SIP References header December 2008
leg" of the transfer scenario should have a References header naming
the "first leg". This example is taken from section 2.5, "Transfer -
Attended" of [service-examples].
Alice Bob Carol
| | |
| INVITE F1 | |
|--------------->| |
| 180 Ringing F2 | |
|<---------------| |
| 200 OK F3 | |
|<---------------| |
| ACK F4 | |
|--------------->| |
| RTP | |
|<==============>| |
|INVITE (hold) F5| |
|<---------------| |
| 200 OK F6 | |
|--------------->| |
| ACK F7 | |
|<---------------| |
| No RTP | |
| | INVITE F8 |
| |------------->|
| | 180 Ringing F9
| |<-------------|
| | 200 OK F10 |
| |<-------------|
| | ACK F11 |
| |------------->|
| | RTP |
| |<============>|
| |INVITE (hold) F12
| |------------->|
| | 200 OK F13 |
| |<-------------|
| | ACK F14 |
| |------------->|
| | No RTP |
| REFER Refer-To: C F15 |
|<---------------| |
|202 Accepted F16| |
|--------------->| |
| NOTIFY F17 | |
|--------------->| |
| 200 OK F18 | |
|<---------------| |
Worley Expires June 4, 2009 [Page 9]
Internet-Draft SIP References header December 2008
| INVITE Replaces: B F19 |
|------------------------------>|
| 200 OK F20 |
|<------------------------------|
| ACK F21 |
|------------------------------>|
| RTP |
|<=============================>|
| | BYE F22 |
| |<-------------|
| | 200 OK F23 |
| |------------->|
| NOTIFY F24 | |
|--------------->| |
| 200 OK F25 | |
|<---------------| |
| BYE F26 | |
|<---------------| |
| 200 OK F27 | |
|--------------->| |
The INVITE that establishes the second leg has a References header
naming the first leg:
F8 INVITE Bob -> Carol
INVITE sips:carol@chicago.example.com SIP/2.0
References: 12345600@atlanta.example.com;rel=xfer
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnash
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=8675309
To: Carol <sips:carol@chicago.example.com>
Call-ID: sdjfdjfskdf@biloxi.example.com
CSeq: 42 INVITE
Contact: <sips:bob@client.biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
As described in Section 3.1, the INVITE that completes the transfer
has a References header giving the dialog of the first leg, within
which the REFER was sent. It also has a Replaces header giving the
dialog of the second leg, which acts as an implicit References.
Worley Expires June 4, 2009 [Page 10]
Internet-Draft SIP References header December 2008
F19 INVITE Alice -> Carol
INVITE sips:39itp34klkd@chicago.example.com;gr SIP/2.0
References: 12345600@atlanta.example.com;rel=refer
Via: SIP/2.0/TLS chicago.example.com:5061
;branch=z9hG4bKadfe4ko
To: Carol <sips:39itp34klkd@chicago.example.com>
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=3461
Call-ID: 9435674543@atlanta.example.com
CSeq: 1 INVITE
Require: replaces
Referred-By: <sips:bob@biloxi.example.com>
Replaces: sdjfdjfskdf@biloxi.example.com
;to-tag=5f35a3;from-tag=8675309
Contact: <sips:alice@client.atlanta.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
3.3. Call Pickup
The References header can be used during a call pickup operation to
connect the SUBSCRIBE that is used to locate the target dialog with
the INVITE which is generated to execute the pickup. This example is
taken from section 2.16, "Call Pickup" of [service-examples].
Worley Expires June 4, 2009 [Page 11]
Internet-Draft SIP References header December 2008
Alice Bob Bill
| | |
| INVITE F1 | |
|------------->| |
|180 Ringing F2| |
|<-------------| |
| | SUBSCRIBE F3 |
| |<------------------|
| | 200 OK F4 |
| |------------------>|
| | NOTIFY F5 |
| |------------------>|
| | 200 OK F6 |
| |<------------------|
| INVITE Replaces:Bob F7 |
|<---------------------------------|
| | 200 OK F8 |
|--------------------------------->|
| CANCEL F9 | |
|------------->| |
| 200 OK F10 | |
|<-------------| |
| 487 F11 | |
|<-------------| |
| ACK F12 | |
|------------->| |
| ACK F13 |
|<---------------------------------|
| |
| Two way RTP Established |
|<================================>|
| BYE F14 |
|--------------------------------->|
| 200 OK F15 |
|<---------------------------------|
| |
Bill's UA sends a SUBSCRIBE to find the target dialog:
Worley Expires June 4, 2009 [Page 12]
Internet-Draft SIP References header December 2008
F3 SUBSCRIBE Bill -> Bob
SUBSCRIBE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc.biloxi.example.com:5061
;branch=z9hG4bK74bf
Max-Forwards: 70
From: Bill <sips:bill@biloxi.example.com>;tag=8675309
To: Bob <sips:bob@biloxi.example.com>
Call-ID: rt4353gs2egg@pc.biloxi.example.com
CSeq: 1 SUBSCRIBE
Contact: <sips:bill@pc.biloxi.example.com>
Event: dialog
Expires: 0
Accept: application/dialog-info+xml
Content-Length: 0
After locating the target dialog, Bill's UA generates an INVITE-with-
Replaces to execute the pickup. The UA adds the References header to
show the connection with the SUBSCRIBE:
F7 INVITE Bill -> Alice
INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
References: rt4353gs2egg@pc.biloxi.example.com;rel=inquiry
Via: SIP/2.0/TLS pc.biloxi.example.com:5061
;branch=z9hG4bK74HH
Max-Forwards: 70
From: Bill <sips:bill@biloxi.example.com>;tag=8675310
To: Alice <sips:alice@atlanta.example.com>
Call-ID: 563456212@b2.biloxi.example.com
CSeq: 1 INVITE
Require: replaces
Replaces: 12345600@atlanta.example.com
;from-tag=314578;to-tag=1234567;early-only
Contact: <sips:bill@pc.biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
Note that the executing INVITE F7 does not mention the Call-Id of the
original INVITE F1 because it is mentioned in the Replaces header.
If the call pickup operation is done by an agent on behalf of Bill's
UA (as in the sipX open-source PBX), the executing INVITE is likely
to exist before the SUBSCRIBE is generated. In that case, the
Worley Expires June 4, 2009 [Page 13]
Internet-Draft SIP References header December 2008
SUBSCRIBE will have a References header giving the Call-Id of the
INVITE:
F3 SUBSCRIBE Bill -> Bob
SUBSCRIBE sips:bob@biloxi.example.com SIP/2.0
References: 563456212@b2.biloxi.example.com;rel=inquiry
Via: SIP/2.0/TLS pc.biloxi.example.com:5061
;branch=z9hG4bK74bf
Max-Forwards: 70
From: Bill <sips:bill@biloxi.example.com>;tag=8675309
To: Bob <sips:bob@biloxi.example.com>
Call-ID: rt4353gs2egg@pc.biloxi.example.com
CSeq: 1 SUBSCRIBE
Contact: <sips:bill@pc.biloxi.example.com>
Event: dialog
Expires: 0
Accept: application/dialog-info+xml
Content-Length: 0
Worley Expires June 4, 2009 [Page 14]
Internet-Draft SIP References header December 2008
4. Practical Experience
The current version of the sipX open-source PBX adds a References
header to the SUBSCRIBE of a call pickup as described in section
2.16, "Call Pickup" of [service-examples]. It has caused no observed
interoperability problem.
Worley Expires June 4, 2009 [Page 15]
Internet-Draft SIP References header December 2008
5. Related Work
This section discusses other Internet-drafts and their relationship
to this work.
5.1. draft-loreto-sipping-dialog-correlation
The Session Initiation Protocol (SIP) Dialog
Correlation[loreto-correlation]
This document defines a new header field for use with SIP. The
Same-Session header field is used to logically correlate an
existing SIP dialog with a new SIP dialog when the media sessions
established by both dialogs can be considered a single logical
session. This mechanism can be used to share the user interface
and other resources between all the media streams from both
sessions.
The "Same-Session" header prescribes that the media sessions of two
INVITE dialog usages are to be considered part of the same session
from the users' points of view. Because of this semantic, it cannot
be used in place of the References header, as References can be used
to express the relationship between two dialogs that are not
connected in any particular way in regard to user interface.
However, it would be possible to define a "parallel" value of the
"rel" parameter to have the semantics of "Same-Session". This usage
would require that the References header appears in the INVITE
establishing the second dialog (and that the two INVITEs are properly
time-sequenced, or that both INVITEs have a References header). But
this still might be considered a conflation of mechanism that have
different semantics.
5.2. draft-kaplan-sip-session-id
A Session Identifier for the Session Initiation Protocol
(SIP)[kaplan-session]
There are several reasons for having a globally unique session
identifier for the same SIP session, which can be maintained
across B2BUA's and other SIP middle-boxes. This draft proposes a
new SIP header to carry such a value: Session-ID.
The semantics of "Session-ID" are close to those of References, and
it would be reasonable to define a "rel" value that meant that the
referenced Call-Id was "the other side" of a B2BUA connection. (This
would require placing a References header in the INVITE request sent
from the recipient side of the B2BUA and one in the response to the
Worley Expires June 4, 2009 [Page 16]
Internet-Draft SIP References header December 2008
INVITE send from the originator side.) But since References contains
the real Call-Id of a dialog, this use would not have the security
properties described in section 5.1 of [kaplan-session].
A possible solution to this problem is for the B2BUA to create a
"phantom" Call-Id that is suitably random, and use it in References
headers sent in both the initial request and response. By the
transitivity propertySection 2, the dialogs on both sides of the
B2BUA are declared to be related, even if the referenced dialog
contains no messages.
For two chained B2BUAs with no forking, this would give a message
flow like this:
UA 1 B2BUA 1 B2BUA 2 UA 2
--->
INVITE 123@aa.example.com
Call-Id: qwerty@aa
--->
INVITE 123@transit.example.com
Call-Id: asdfgh@transit
References: QAZWSXEDCRFV;rel=serial
--->
INVITE 123@bb.example.com
Call-Id: zxcvbn@bb
References: QAZWSXEDCRFV
;rel=serial
<---
SIP/2.0 200 OK
Call-Id: zxcvbn@bb
<---
SIP/2.0 200 OK
Call-Id: asdfgh@transit
References: QAZWSXEDCRFV;rel=serial
<---
SIP/2.0 200 OK
Call-Id: qwerty@aa
References: QAZWSXEDCRFV;rel=serial
Note that B2BUA 2 does not create a new "References serial" value,
but rather reuses the value it received in the initial INVITE. (In
principle, B2BUA 2 does not need to add References to the response it
Worley Expires June 4, 2009 [Page 17]
Internet-Draft SIP References header December 2008
sends, as References is present in the request.)
Worley Expires June 4, 2009 [Page 18]
Internet-Draft SIP References header December 2008
6. Security Considerations
The specification of the relationship between two dialogs could in
principle be a privacy issue. But these relationships can usually be
discerned by heuristic processing of the stream of SIP messages, and
(with one exception) the author knows of no instance where the
security or privacy properties of SIP have been based on the
inability of an eavesdropper to determine that two SIP dialogs or
messages are related.
The one known privacy problem is the the "service provider privacy"
problem discussed in [kaplan-session]. This situation is different
from conventional "user security" situations because the eavesdropper
is assumed to be unable to tap multiple points of the network, and
the goal is to prevent the eavesdropper from obtaining informaiton
about parts of the network that the eavesdropper cannot directly
access. This sort of privacy can be provided by constructing
artificial Call-Ids to use in References headers, if References is
inserted in both requests and responses.
Worley Expires June 4, 2009 [Page 19]
Internet-Draft SIP References header December 2008
7. Revision History
7.1. Changes from draft-worley-references-00 to
draft-worley-references-01
Add the "rel" parameter.
Note that References will usually appear in the dialog-forming
request.
Note that References may appear in a response.
Add the "Related Work" section.
7.2. draft-worley-references-00
Initial version.
Worley Expires June 4, 2009 [Page 20]
Internet-Draft SIP References header December 2008
8. References
8.1. Normative References
[sip] 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.
8.2. Informative References
[service-examples]
Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", RFC 5359, October 2008.
[message-format]
Resnick, P., "Internet Message Format", RFC 5322,
October 2008.
[loreto-correlation]
Loreto, S. and G. Camarillo, "The Session Initiation
Protocol (SIP) Dialog Correlation",
I-D draft-loreto-sipping-dialog-correlation-01, June 2006.
[kaplan-session]
Kaplan, H., "A Session Identifier for the Session
Initiation Protocol (SIP)",
I-D draft-kaplan-sip-session-id-00, November 2008.
Worley Expires June 4, 2009 [Page 21]
Internet-Draft SIP References header December 2008
Author's Address
Dale R. Worley
Nortel Networks Corp.
600 Technology Park Dr.
Billerica, MA 01821
US
Phone: +1 978 288 5505
Email: dworley@nortel.com
URI: http://www.nortel.com
Worley Expires June 4, 2009 [Page 22]
Internet-Draft SIP References header December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Worley Expires June 4, 2009 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 02:46:02 |