F4: 486 192.0.2.2 -> proxy.example.com
SIP/2.0 302 Moved temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486>
Content-Length: 0
F7: INVITE proxy.example.com -> gw.example.com
INVITE sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486\
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
6.4. Endpoint Forwards Busy to Voicemail with History Info
This example illustrates how History Info works in conjunction with
service retargeting. The scenario is the same as Section 6.1.
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4>;index=1.1
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F7: INVITE proxy.example.com -> um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4?Reason=SIP%3Bcause%3D302;\
text="Moved Temporarily">;index=1.1
<sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486>;index=2
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
6.5. Zero Configuration UM System
In this example, the UM system has no configuration information
specific to any user. The proxy is configured to pass a URI that
provides the prompt to play and an email address in the user portion
of the URI to which the recorded message is to be sent.
The call flow is the same as in Section 6.1, except that the URI in
F7 changes to specify the user part as Bob’s email address, and the
Netann [7] URI play parameter specifies where the greeting to play
can be fetched from.
F7: INVITE proxy.example.com -> voicemail.example.com
INVITE sip:voicemail@example.com;target=mailto:bob%40example.com;\
cause=486;play=http://www.example.com/bob/busy.wav SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15555551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
In addition, if the proxy wished to indicate a Voice XML (VXML)
script that the UM should execute, it could add a parameter to the
URI in the above message that looked like:
voicexml=http://www.example.com/bob/busy.vxml
6.6. Call Coverage
In a Call Coverage example, a user on the PSTN calls an 800 number.
The gateway sends this to the proxy, which recognizes that the
helpdesk is the target. Alice and Bob are staffing the help desk and
are tried sequentially, but neither answers, so the call is forwarded
to the helpdesk’s voicemail.
The details of this flow are trivial and not shown. The key item in
this example is that the INVITE to Alice and Bob looks as follows:
INVITE sip:voicemail@example.com;target=helpdesk%40example.com;\
cause=302 SIP/2.0
7. IANA Considerations
This specification adds two new values to the IANA registration in
the "SIP/SIPS URI Parameters" registry as defined in [3].
Parameter Name Predefined Values Reference
____________________________________________
target No [RFC4458]
cause Yes [RFC4458]
8. Security Considerations
This document discusses transactions involving at least three
parties, which increases the complexity of the privacy issues.
The new URI parameters defined in this document are generally sent
from a Proxy or call control system to a Unified Messaging (UM)
system or to a gateway to the PSTN and then to a voicemail system.
These new parameters tell the UM what service the proxy wishes to
have performed. Just as any message sent from the proxy to the UM
needs to be integrity protected, these messages need to be integrity
protected to stop attackers from, for example, causing a voicemail
meant for a company’s CEO to go to an attacker’s mailbox. RFC 3261
provides a TLS mechanism suitable for performing this integrity
protection.
The signaling from the Proxy to the UM or gateway will reveal who is
calling whom and possibly some information about a user’s presence
based on whether the call was answered or sent to voicemail. This
information can be protected by encrypting the SIP traffic between
the Proxy and UM or gateway. Again, RFC 3261 contains mechanisms for
accomplishing this using TLS.
Implementations should implement and use TLS.
8.1. Integrity Protection of Forwarding in SIP
The forwarding of a call in SIP brings up a very strange trust issue.
Consider the normal case -- A calls B and the call gets forwarded to
C by a network element in B’s domain, and then C answers the call. A
has called B but ended up talking to C. This scenario may be hard to
separate from a man-in-the-middle attack.
There are two possible solutions. One is that B sends back
information to A saying don’t call me, call C, and signs it as B.
The problem is that this solution involves revealing that B has
forwarded to C, which B often may not want to do. For example, B may
be a work phone that has been forwarded to a mobile or home phone.
The user does not want to reveal their mobile or home phone number
but, even more importantly, does not want to reveal that they are not
in the office.
The other possible solution is that A needs to trust B only to
forward to a trusted identity. This requires a hop-by-hop transitive
trust such that each hop will only send to a trusted next hop and
each hop will only do things that the user at that hop desired. This
solution is enforced in SIP using the SIPS URI and TLS-based
hop-by-hop security. It protects from an off-axis attack, but if one
of the hops is not trustworthy, the call may be diverted to an
attacker.
Any redirection of a call to an attacker’s mailbox is serious. It is
trivial for an attacker to make its mailbox seem very much like the
real mailbox and forward the messages to the real mailbox so that the
fact that the messages have been intercepted or even tampered with
escapes detection. Approaches such as the SIPS URL and the
History-Info[6] can help protect against these attacks.
8.2. Privacy Related Issues on the Second Call Leg
In the case where A calls B and gets redirected to C, occasionally
people suggest that there is a requirement for the call leg from B to
C to be anonymous. The SIP case is not the PSTN, and there is no
call leg from B to C; instead, there is a VoIP session between A and
C. If A has put a To header field value containing B in the initial
invite message, unless something special is done about it, C would
see that To header field value. If the person who answers phone C
says "I think you dialed the wrong number; who were you trying to
reach?", A will probably specify B.
If A does not want C to see that the call was to B, A needs a special
relationship with the forwarding Proxy to induce it not to reveal
that information. The call should go through an anonymization
service that provides session or user level privacy (as described in
RFC 3323 [2]) service before going to C. It is not hard to figure
out how to meet this requirement, but it is unclear why anyone would
want this service.
The scenario in which B wants to make sure that C does not see that
the call was to B is easier to deal with but a bit weird. The usual
argument is that Bill wants to forward his phone to Monica but does
not want Monica to find out his phone number. It is hard to imagine
that Monica would want to accept all Bill’s calls without knowing how
to call Bill to complain. The only person Monica will be able to
complain to is Hillary, when she tries to call Bill. Several popular
web portals will send SMS alert messages about things like stock
prices and weather to mobile phone users today. Some of these
contain no information about the account on the web portal that
initiated them, making it nearly impossible for the mobile phone
owner to stop them. This anonymous message forwarding has turned out
to be a really bad idea even where no malice is present. Clearly
some people are fairly dubious about the need for this, but never
mind: let’s look at how it is solved.
In the general case, the proxy needs to route the call through an
anonymization service and everything will be cleaned up. Any
anonymization service that performs the "Privacy: Header" Service in
RFC 3323 [2] must remove the cause and target URI parameters from the
URI. Privacy of the parameters, when they form part of a URI within
the History-Info header, is covered in History-Info [6].
This specification does not discuss the security considerations of
mapping to a PSTN Gateway. Security implications of mapping to ISUP,
for example, are discussed in RFC 3398 [5].
9. Acknowledgements
Many thanks to Mary Barnes, Steve Levy, Dean Willis, Allison Mankin,
Martin Dolly, Paul Kyzivat, Erick Sasaki, Lyndsay Campbell, Keith
Drage, Miguel Garcia, Sebastien Garcin, Roland Jesske, Takumi Ohba,
and Rohan Mahy.
10. References
10.1. Normative References
[1] 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.
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[3] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
December 2004.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
10.2. Informative References
[5] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated
Services Digital Network (ISDN) User Part (ISUP) to Session
Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[6] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244,
November 2005.
[7] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media
Services with SIP", RFC 4240, December 2005.
[8] "Stage 3 description for call offering supplementary services
using signalling system No. 7: Call diversion services", ITU-T
Recommendation Q.732.2-5, December 1999.
[9] "Usage of cause and location in the Digital Subscriber
Signalling System No. 1 and the Signalling System No. 7 ISDN
User Part", ITU-T Recommendation Q.850, May 1998.
[10] "ISDN user-network interface layer 3 specification for basic
call control", ITU-T Recommendation Q.931, May 1998.
[11] "Information technology - Telecommunications and information
exchange between systems - Private Integrated Services Network
- Circuit mode bearer services - Inter-exchange signalling
procedures and protocol", ISO/IEC 11572, March 2000.
Authors’ Addresses
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Francois Audet
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
US
Phone: +1 408 495 3756
EMail: audet@nortel.com
John Elwell
Siemens plc
Technology Drive
Beeston, Nottingham NG9 1LA
UK
EMail: john.elwell@siemens.com
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).
<!--
erfc("4458</TITLE>");
// -->