conventions of [19] are used to describe representation of long
message lines.
A Server-A Server-B B
|(1) INVITE | | |
|----------->| | |
| |(2) INVITE | |
| |----------->| |
| | |(3) INVITE |
| | |----------->|
| | |(4) 200 OK |
| | |<-----------|
| |(5) 200 OK | |
| |<-----------| |
|(6) 200 OK | | |
|<-----------| | |
|(7) ACK | | |
|------------------------------------->|
| |(8) REFER | |
| |<-----------| |
|(9) REFER | | |
|<-----------| | |
|(10) 200 OK | | |
|----------->| | |
| |(11) 200 OK | |
| |----------->| |
Figure 5
First, the caller sends an INVITE, as shown in message 1.
INVITE sips:B@example.com SIP/2.0
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Supported: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER
Accept: application/sdp, text/html
<allOneLine>
Contact: <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>;schemes="http,sip,sips"
</allOneLine>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--
The INVITE indicates that the caller supports GRUU (note its presence
in the Contact header field of the INVITE) and the Target-Dialog
header field. This INVITE is forwarded to the callee (messages 2-3),
which generates a 200 OK response that is forwarded back to the
caller (message 4-5). Message 5 might look like:
SIP/2.0 200 OK
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>;tag=6544
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Contact: <sips:B@pc.example.org>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--
In this case, the called party does not support GRUU or the Target-
Dialog header field. The caller generates an ACK (message 7).
Server B then decides to send a REFER to user A:
<allOneLine>
REFER sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0
</allOneLine>
Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10
From: Server B <sip:serverB.example.org>;tag=mreysh
<allOneLine>
To: Caller <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>
</allOneLine>
Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com
;local-tag=kkaz-
;remote-tag=6544
Refer-To: http://serverB.example.org/ui-component.html
Call-ID: 86d65asfklzll8f7asdr@host.example.com
CSeq: 1 REFER
Max-Forwards: 70
Require: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY
Contact: <sips:serverB.example.org>
Content-Length: 0
This REFER will be delivered to server A because it was sent to the
GRUU. From there, it is forwarded to user agent A (message 9) and
authorized because of the presence of the Target-Dialog header field.
11. IANA Considerations
This specification registers a new SIP header field, a new option tag
according to the processes of RFC 3261 [2], and two new header field
parameters according to the processes of RFC 3968 [10].
11.1. Header Field
RFC Number: RFC 4538
Header Field Name: Target-Dialog
Compact Form: none
11.2. Header Field Parameters
This section registers two header field parameters according to the
processes of RFC 3968 [10].
11.2.1. local-tag
Header Field: Target-Dialog
Header Field Parameter: local-tag
Predefined Values: None
RFC: RFC 4538
11.2.2. remote-tag
Header Field: Target-Dialog
Header Field Parameter: remote-tag
Predefined Values: None
RFC: RFC 4538
11.3. SIP Option Tag
This specification registers a new SIP option tag per the guidelines
in Section 27.1 of RFC 3261.
Name: tdialog
Description: This option tag is used to identify the target dialog
header field extension. When used in a Require header field, it
implies that the recipient needs to support the Target-Dialog
header field. When used in a Supported header field, it implies
that the sender of the message supports it.
12. Acknowledgements
This specification is based on a header field first proposed by
Robert Sparks in the dialog usage draft [12]. John Elwell provided
helpful comments.
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., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[9] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[10] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", BCP 98, RFC 3968, December 2004.
13.2. Informative References
[11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[12] Sparks, R., "Multiple Dialog Usages in the Session Initiation
Protocol", Work in Progress, March 2006.
[13] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", Work in Progress, May 2006.
[14] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Work in Progress,
July 2005.
[15] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State", Work in Progress, July 2005.
[17] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[18] Burger, E., "A Session Initiation Protocol (SIP) Event Package
for Key Press Stimulus (KPML)", Work in Progress,
December 2004.
[19] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture
Test Messages", RFC 4475, May 2006.
Author’s Address
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).