Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7
To: Customer <sip:UA2@HOME.EXAMPLE.COM>
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248
Call-ID: 38615183343@s1i1l2j6u
CSeq: 18 INVITE
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr>
Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
. . .
Note: P1 has added itself to the Record Route.
F3 Invite P2 -> HSP
INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0
Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7
To: Customer <sip:UA2@HOME.EXAMPLE.COM>
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248
Call-ID: 38615183343@s1i1l2j6u
CSeq: 18 INVITE
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Record-Route: <sip:P2.HOME.EXAMPLE.COM;lr>
Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr>
Route: <sip:HSP.HOME.EXAMPLE.COM;lr>
. . .
Note: HSP is selected using a DNS lookup for HSP within
HOME.EXAMPLE.COM.
P2 has added itself to the Record-Route.
P2 has removed itself from the Route.
F4 HSP executes service
HSP identifies the service to be executed from UA1’s stored
profile. The specifics of this are outside the scope of this
document. For this example HSP writes a record to "Lawyer’s log
book", then looks up the AOR "sip:UA2@HOME.EXAMPLE.COM" and
discovers that the current contact for UA2 is at host
UAADDR2.HOME.EXAMPLE.COM. This will be the Request-URI of the
next-hop INVITE.
F5 Invite HSP -> P2
INVITE sip:UA2@UAADDR2.HOME.EXAMPLE.COM SIP/2.0
Via: SIP/2.0/USP HSP.HOME.EXAMPLE.COM:5060;branch=z9hG4bKHSP10120323
Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7
To: Customer <sip:UA2@HOME.EXAMPLE.COM>
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248
Call-ID: 38615183343@s1i1l2j6u
CSeq: 18 INVITE
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Record-Route: <sip:HSP.HOME.EXAMPLE.COM;lr>
Record-Route: <sip:P2.HOME.EXAMPLE.COM;lr>
Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr>
. . .
Note: P2 selected by outbound proxy rule on HSP.
HSP has removed itself from the Route.
INVITE propagates toward UA2 as usual.
7. Security Considerations
It is possible for proxies between the UA and the registrar during
the REGISTER transaction to modify the value of Service-Route
returned by the registrar, or to insert a Service-Route even when one
was not returned by the registrar. The consequence of such an attack
is that future requests made by the UA using the service route might
be diverted to or through a node other than would normally be
visited. It is also possible for proxies on the INVITE path to
execute many different attacks. It is therefore desirable to apply
transitive mutual authentication using sips: or other available
mechanisms in order to prevent such attacks.
The "sips:" URI as defined in [3] defines a mechanism by which a UA
may request transport-level message integrity and mutual
authentication. Since there is no requirement for proxies to modify
messages, S/MIME signed bodies may be used to provide end-to-end
protection for the returned value.
Systems using Service-Route SHOULD provide hop-by-hop message
integrity and mutual authentication. UAs SHOULD request this support
by using a "sips:" URI. Registrars returning a Service-Route MUST
implement end-to-end protection using S/MIME and SHOULD use S/MIME to
protect all such responses. UAs receiving Service-Route SHOULD
authenticate attached S/MIME bodies if present.
8. IANA Considerations
This document defines the SIP extension header field "Service-Route"
which has been included in the registry of SIP header fields defined
in [3]. The change process for SIP, [5] mandates that general SIP
extension header fields be defined by a standards-track RFC. This
document provides the required definition.
The following is the registration for the Service-Route header field:
RFC Number: RFC 3608
Header Field Name: Service-Route
Compact Form: none
9. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[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] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
10. Informative References
[6] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol
(SIP)", Work in Progress, October 2002.
11. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF’s procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
12. Authors’ Addresses
Dean Willis
dynamicsoft Inc.
3100 Independence Parkway
#311-164
Plano, TX 75075
US
Phone: +1 972 473 5455
EMail: dean.willis@softarmor.com
Bernie Hoeneisen
Switch
Limmatquai 138
CH-8001 Zuerich
Switzerland
Phone: +41 1 268 1515
EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
URI: http://www.switch.ch/
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.