| TOC |
|
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 August 11, 2007.
Copyright © The IETF Trust (2007).
This document providing clarifications and guidelines concerning the use of SIPS URI scheme in the Session Initiation Protocol (SIP). It does not make normative changes to SIP. This document also provides discussion of possible future steps in specification, and the pros and cons of making such changes.
1.
Introduction
2.
Terminology
3.
Meaning of SIPS
3.1.
Scope of SIPS
3.2.
Using TLS with SIP instead of SIPS
4.
Routing
4.1.
Detection of hop-by-hop security on each hop
4.2.
Loose and strict routing
5.
Registration
6.
SIPS in a Dialog
7.
Usage of tls transport parameter and TLS Via parameter
8.
GRUU
9.
Call Flows
9.1.
Alice Calls Bob's SIPS AOR
9.2.
Alice Calls Bob's SIP AOR using TCP
9.3.
Alice Calls Bob's SIP AOR using TLS
10.
Conclusion
11.
Security Considerations
12.
IANA Considerations
13.
IAB Considerations
14.
Acknowledgments
15.
References
15.1.
Normative References
15.2.
Informational References
Appendix A.
Future steps in specification
A.1.
Deprecation of Last Hop Exception
A.2.
True-end-to-end SIP security
Appendix B.
To-Be-Done
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
The meaning and usage of the SIPS URI scheme and of TLS [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.) is underspecified in SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and has been the source of confusion for implementors.
This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It does not make normative changes to SIP. This document also provides discussion of possible future steps in specification, and the pros and cons of making such changes.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
[RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/19.1 describes a SIPS URI as follows:
A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain.
Section 26.2.2 re-iterates it, with regards to Request-URIs:
When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured.
Let's take the classic SIP trapezoid to explain the meaning of a sips:b@B URI. Instead of using real domain names like example.com and example.net, logical names like "A" and "B" are used, for clarity.
.......................... ........................... . . . . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |-----TLS---- | Proxy | . . | A | . . | B | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . TLS . . Policy-based . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | UA a | . . | UA b | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . .......................... ...........................
| SIP trapezoid |
In this case, if a@A is sending a request to sips:b@B, the following will apply:
One may then wonder why TLS is mandatory between UA a@A and Proxy A but not between Proxy B and UA b@B. The main reason is that [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) was written before [I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.). At that time, it was recognized that in many practical deployments, Proxy B may not be able to establish a TLS connection with UA b because only Proxy B would have a certificate to provide and UA b would have none. Since UA b would be the TLS Server, it would then not be able to accept the incoming TLS connection. The consequence is that an [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)-compliant UAS b, while it may not need to support TLS for incoming requests, will nevertheless have to support TLS for outgoing requests as it takes the UAC role. Contrary to what many believe erroneously, the last-hop exception was not created to allow for using a SIPS URI to address a UAS that does not support TLS : the last-hop exception was an attempt to allow for incoming requests TLS when a SIPS URI is used, and it does not apply to outgoing requests. The rationale for this was somewhat flawed, and since then, [I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.) has provided a more satisfactory solution to this problem.
Furthemore, consider the problem of using SIPS inside a dialog. If a@A sends a request to b@B using a SIPS Request-URI, according to [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/8.1.1.8, then the contact MUST contain a SIPS URI as well. This means that b@B, upon sending a new Request within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS URI. If there is no Record-Route entry, or if the last Record-Route entry consist of a SIPS URI, this implies that b@B must understand SIPS in the first place, and must also support TLS. If the last Record-Route entry however is a sip URI, then b would be able to send requests without using TLS (but b would still have to be able to handle SIPS schemes when parsing the message). In either case, the Request-URI would be a SIPS URI.
It is therefore RECOMMENDED that implementations do not use the last hop exception rule and use TLS all the way up to the remote target.
The SIPS scheme implies transitive trust. Obviously, there is nothing that prevents a proxy to cheat (see [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.4.4). While SIPS is useful to request that a resource be contacted securely, it is not useful as an indication that a resource was in fact contacted security. Therefore, it is not appropriate to infer that because an incoming request had a Request-URI (or To header) containing a SIPS URI, that it necessarily garantees that the request was in fact transmitted securely on each hop. Some have been tempted to believe that the SIPS scheme was equivalent to an HTTPS scheme in the sense that one could provide a visual indication to a user (e.g., a padlock icon) to the effect that the session is secured. This is obviously not the case, and one must therefore be careful not to oversell the meaning of a SIPS URI. There is currently no mechanism to provide an indication of end-to-end security for SIP. Other mechanisms may provide a more concrete indication of some level of security. For example, SIP Identity [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) describes an authenticated identity mechanism and a domain-to-domain integrity protection mechanism.
| TOC |
SIPS means that the SIP resource designated by the target SIPS URI be contacted securily, using TLS, on each SIP hop (last-hop exception nothwistanding). It is outside of the scope of this document to specify what happens when a SIPS URI identifies a UAS resource that "maps" outside of the SIP network, for example, to other networks such as the PSTN.
| TOC |
Because SIPS URI imply that requests sent to it be sent over each SIP hop over TLS (last-hop exception nothwistranding), SIPS URIs are not suitable for "best-effort TLS": they are only suitable for "TLS-only" requests. This is recognized in section [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.2.2
Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports.
If one wants to use "best-effort TLS" for SIP, one just needs to use a SIP URI, and to send the request over TLS.
Using SIP over TLS is very simple. A UA opens a TLS connection and uses SIP URIs instead of SIPS URIs for all the headers in a SIP message (From, To, Request-URI, Contact, Route, etc.). However, when TLS is used, the Via header MUST indicate TLS.
Similarly, proxies may forward requests using TLS if they can open a TLS connection, even if the route set used SIP URIs instead of SIPS URIs. The proxies may insert Record-Route using SIP URIs even if it uses TLS transport.
Some proxies may have local policies that enforces TLS on all connections, independently of if SIPS is used or not.
| TOC |
This specification clarifies that SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:alice@example.com and sips:alice@example.com) MUST refer to the same resource. This requirement is implicit in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/19.1 which states that "Any resource described by a SIP URI can be "upgraded" to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securily". This does not mean that the SIPS URI will necessarily be reachable, in particular, if the proxy can not establish a secure connection to a client or another proxy. This does not suggest that proxies should arbitrarily "upgrade" SIP URIs to SIPS URIs. Rather, it means that when a proxy has a legitimate reason to do so, it MAY upgrade a SIP URI to a SIPS URI.
An example of such a case is when the Contact binding to an AOR is a SIPS URI and a request was addressed to a SIP Request-URI, the proxy will "upgrade" by forwarding the request to the endpoint that has registered with a SIPS contact, as illustrated by message F13 in Section 9.2 (Alice Calls Bob's SIP AOR using TCP) and in Section 9.3 (Alice Calls Bob's SIP AOR using TLS). Note that the proxy MUST forward the request to the UA using a SIP Request-URI and not a SIPS Request-URI (and it does so by substituting the sip scheme to the sips sheme in the registered Contact binding). If the proxy did not do this, and instead used a SIPS Request-URI, then the response (e.g., a 200 to an INVITE) would have to include a SIPS Contact. That SIPS Contact would then force the other UA to use a SIPS Contact in any mid-dialog request, including the ACK (which wouldn't be possible if that UA did not support SIPS).
Although not mandated specifically in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), the implication is that a resource described by a SIPS URI can not be "downgraded" to a SIP URI by just changing the scheme, unless it is the "last hop exception" described in Section 3 (Meaning of SIPS). This specification clarifies that a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP URI by changing the scheme, or by sending the associated request over a non secure link, except for cases where the "last-hop exception" rule is in effect (in which case the Request-URI would be replaced by a SIP URI).
For example, the sip:bob@example.com and sips:bob@example.com AORs MUST refer to the same user "Bob" in domain "example.com": the first URI is the SIP version, and the second one is the SIPS version. From the point of view of routing, requests to either sip:bob@example.com and sips:bob@example.com are treated the same way. Location services are therefore free to map from SIP to SIPS URIs as appropriate (see [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.4.4). When Bob registers, it therefore does not really matter if he is using a SIP or a SIPS AOR, since they both refer to the same user. At first glance, section [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/19.1.4 seems to contradict this idea by stating that a SIP and a SIPS URI are never equivalent. Specifically, it says that they are never equivalent for the purpose of comparing bindings in Contact URIs in REGISTER requests. The key point is that this statement applies to the Contact bindings in a registration: it is the association of the Contact with the AoR that will determine if the user is reachable or not with a SIPS URI.
Consider this example. If Bob registers with a SIPS contact (e.g., sips:bob@bobphone.example.com), the registar and the location service then knows that Bob (bob@example.com) is reachable at sips:bob@bobphone.example.com, and at sip:bob@bobphone.example.com. If a request is sent to AOR sips:bob@example.com, Bob's proxy will route it to Bob at Request-URI sips:bob@bobphone.example.com. If a request is sent to AOR sip:bob@examplecom, Bob's proxy will route it to Bob at Request-URI sip:bob@bobphone.example.com (because of the "upgrade" scenario described above, and the substitution of SIP to SIPS).
However, if Bob had registered instead with a SIP Contact instead of a SIPS contact (e.g., sip:bob@bobphone.example.com), then a request to AOR sips:bob@example.com would not be routed to Bob, since there is no SIPS contact for Bob, and "downgrades" from SIPS to SIP are not allowed.
See Section 9 (Call Flows) for illustrative call flows.
Since upgrading from SIP to SIPS is allowed it other circumstances (e.g., a user "guessing" a SIPS AOR from a SIP AOR on a business card), it is quite possible that a request will be rejected with response code 416 (either because TLS or SIPS is not supported). When 416 is received, the request MAY be re-attempted with a SIP URI, but the user SHOULD be informed.
Although "downgrading" from SIPS to SIP is disallowed, it is possible that a redirect server or UAS sends a 3XX response to a request to a SIPS URI with a Contact containing a SIP URI. [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/8.1.3.4 recommends that if the UAC decide to recurse to the SIP URI, it SHOULD inform the user. When a proxy is handling the 3XX, it can obviously not indicate anything to the user that it is being redirected from SIPS to SIP: therefore, proxies MUST NOT recurse on the Contact. The proxy may do one of the following:
| TOC |
The presence of a SIPS Request-URI does not necessarily indicate that the request was sent securely on each hop. As described in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.4.4, a proxy may legitimately retarget a request from SIP to SIPS. Therefore, a UAS MUST NOT assume on the basis of the Request-URI alone that SIPS was used for the entire request path.
So how does a UAS know if the SIPS was used for the entire request path to secure the request end-to-end? Effectively, the UAS can not know for sure. However, [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.4.4 recommends how a UAS may make some checks to validate the security. Here is a summary of a potential algorithm:
Again, it should be restated that all the checking may be circumvented by any proxy on the path that does not follow the rules and recommendations of this document and of [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
Proxies MAY have their own policy regarding routing of requests to SIP or SIPS URIs. For example, a proxy in some environment may be configured to only route SIPS. Some proxies MAY be configured to detect uncompliancies and reject unsecure requests. For example, it could inspect Request-URIs, Path, Record-Route, To, From, Contacts and Via headers to enforce SIPS.
[RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.4.4 also explains that S/MIME may also be used by the originating UAC to ensure that the original form of the To header field is carried end-to-end. While not specifically mentioned in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.4.4, this is meant to imply that [RFC3893] (Peterson, J., “Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format,” September 2004.) would be used to "tunnel" important headers (such as To and From) in an encrypted and signed S/MIME body, replicating the information in the SIP message, and allowing the UAS to validate the content of those important headers. While this approach is certainly legal, another approach is to use the SIP Identity mechanism defined in [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.). SIP Identity creates a signed identity digest which includes, amongst other things, the AOR of the sender (from the From header) and the AOR of the original destination (from the To header). It is RECOMMENDED that a UAC use the mechanism in [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) instead of the one defined in [RFC3893] (Peterson, J., “Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format,” September 2004.).
| TOC |
Using strict or loose routing has a huge impact on sips and TLS. Some of the advantages of using loose routing have been discussed in Section 3 (Meaning of SIPS), regarding mid-dialog requests.
When a proxy inserts a Record-Route entry, it must take care in using the proper scheme so that further in-dialog requests are sent to the proper URI. This is particularly important when a proxy changes the Request-URI of a request from SIPS to SIP (when the last hop exception rule is used) or from SIP to SIPS. [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) sections 16.6 and 16.7 describe how this can be done by having the proxy modifying the Record-Route in the response. However, as described in [RFC3608] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration,” October 2003.), this is problematic. This document therefore uses the procedure of [RFC3608] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration,” October 2003.), and instead of following the procedure in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), proxies that are inserting Record-Route or Path header field URIs SHOULD record not one but two route URIs when processing the request in the case where the scheme is changed. The first value recorded indicates the schme of the receiving interface, and the second indicates the scheme of the sending interface. When processing the response, no modification of the recorded route is required. This optimization provides for fully invertible routes that can be effectively used in construction of service routes.
If the Request-URI or the topmost Route header on the receiving interface is SIPS and the Request-URI on the sending interface is SIP, then the first value recorded uses a SIPS URI and the second value indicates a SIP URI. It is illustrated as follows:
UA a Proxy UA b
-------REQUEST sips:-------->-------REQUEST sip:--------->
Record-Route: <sip:p;lr>,
<sips:p;lr>
<------Response sips:-------<-------Response sip:---------
Record-Route: <sip:p;lr> Record-Route: <sip:p;lr>,
<sips:p;lr> <sips:p;lr>
| Record routing from SIPS to SIP |
If the Request-UIR on the receiving interface is SIP and the Request-URI on the sending interface is SIPS, then the first value recorded uses a SIP URI and the second value indicates a SIPS URI. It is illustrated as follows:
UA a Proxy UA b
-------REQUEST sip:--------->-------REQUEST sips:-------->
Record-Route: <sips:p;lr>,
<sip:p;lr>
<------Response sip:--------<-------Response sips:--------
Record-Route: <sips:p;lr> Record-Route: <sips:p;lr>,
<sip:p;lr> <sip:p;lr>
| Record routing from SIP to SIPS |
Note that the same rules apply to the Path Header [RFC3327] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” December 2002.).
When a UAC is using a Service-Route (e.g., as in [RFC3608] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration,” October 2003.)), and sending a request to a SIPS Request-URI, it MUST ensure that the Route header URIs it includes are all SIPS URIs. If the service route included SIP URI, the UAC MUST upgrade the SIP URIs to SIPS URIs simply by changing the scheme from "sip" to "sips" before sending the request. Note that this allows for configuring or discovering one Service Route with all SIP URIs and allowing sending requests to both SIP and SIPS URIs.
| TOC |
This section describes the registration procedures of SIPS versus SIP Contacts that follows from the discussion in Section 4 (Routing) and clarifies [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
The USC registers either a SIPS or a SIP AOR. From a routing perspective, it does not matter which one is used for registration as they identify the same resource.
If all the Contacts are SIPS, a SIPS AOR MUST also be used by the UAC. If at least one of the Contacts is SIP or is neither SIP nor SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also be used by the UAC. However, the UAS (the Registrar), must treat the SIP and SIPS schemes of the AOR the same way (i.e., it must not care if it is SIP or SIPS). Those are mechanical rules with no influence on routing.
Furthermore, it is a matter of local policy for a UA to accept incoming requests addressed to a URI scheme that does not correspond to what it used for registration. For example, a UA with a policy of "always SIPS" MUST address the Registrar using a SIPS Request-URI over TLS, MUST register with a SIPS Contact, and MUST reject requests addressed to a SIP Request-URI with 403 "Forbidden". A UA with a policy of "best-effort SIPS" MUST address the Registrar using a SIPS Request-URI over TLS, MUST register with a SIPS Contact, and MUST accept requests addressed to either SIP or SIPS Request-URIs. A UA with a policy of "No SIPS" MUST address the Registrar using a SIP Request-URI, MAY or MAY NOTt use TLS, MUST register with a SIP AOR and a SIP Contact, and MUST accept requests addressed to a SIP Request-URI.
If proxies are present in the path between the UA and the registrar, they may insert the Path header [RFC3327] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” December 2002.) if the UAC has indicated support for it with a supported header.
A registrar MUST only accept a binding to a SIPS Contact if all the appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the AOR (i.e., To header), the From header, the Contacts and all the Path headers. If the URIs are not of the proper SIPS scheme, it must reject the REGISTER with a 403 "Forbidden".
The usage of the "transport" URI parameter in Contacts in registration is of dubious usefulness. The assumption is that a UAC may choose one transport for the registration itself, and a different transport for receiving requests. Using the transport URI parameters also results in some complex problems. For example, should all the transports be listed as separate contacts (e.g, udp, tcp, sctp, tls over tcp, tls over sctp)? If so, there is no way to signal tls over sctp defined yet. Furthermore, how should they be prioritized using a q-value? If so, it is possible that certain proxies will interpret this as a forking scenario and they might decide to send one incoming request per transport. Another issue is what happens if a UAC fetches bindings by sending an empty REGISTER message. Would the proxy respond with one or all the possible transport? All this would generate unwarranted complexity.
It is therefore RECOMMENDED that UACs do not use any transport URI parameters in Contacts in REGISTER.
For backward compatibility, a registrar should accept a REGISTER message with a transport URI parameter in the Contact. It is recommended that a registrar ignores that parameter, i.e., that it will not influence routing.
However, a registrar MUST record the scheme of the Contact.
| TOC |
There MUST be only one Contact in any request resulting in the establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER).
As mandated by [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/8.1.1.8, in a request, if the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. Furthermore, as mandated by [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/12.1.1, if the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header filed in the response MUST be a SIPS URI.
If a UAS (or proxy acting on behalf of a UAS) does not support SIPS, it MUST reject a request to a SIPS Request-URI with response code 416 "Unsupported URI scheme". Upon receiving a 416 a UAC SHOULD NOT re-attempt the request by automatically replacing the SIPS scheme with a SIP scheme. If the UAC does re-attempt the call with a SIP URI, it SHOULD inform to the user that the security level is downgraded.
If a UAS (or proxy acting on behalf of a UAS) does not want to be contacted with a SIP UI, it MAY reject a request to a SIP Request-URI with response code 403 "Forbidden", or it MAY redirect the request to a SIPS URI with 301 "Moved permanently" or 302 "Moved temporarily" as appropriate.
If the Request-URI in a request is a SIP URI, then the UAC needs to be careful about what to use in the Contact (in case Record-Route is not used for this hop). If the Contact was a SIPS URI, it would mean that it would only accept mid-dialog requests that are over secure transport end-to-end. Since the Request-URI is in this case a SIP URI, it is quite possible that the UA sending a request to that URI may not be able to send requests to SIPS URIs. It is therefore RECOMMENDED that in this case, the Contact be a SIP URI, even if the request is sent over a secure transport (e.g., the first hop could be re-using a TLS connection to the proxy as would be the case with [I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.)).
When a target refresh occurs within a dialog (e.g., re-INVITE, UPDATE), unless there is a need to change it, the UAC SHOULD include a Contact header with a SIPS URI if the original request used a SIPS Request-URI.
| TOC |
[RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.2.2 makes it clear that the use of the "transport=tls" URI transport parameter in SIPS or SIP URIs has been deprecated:
Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=tcp" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543.
However, the "tls" parameter has not been eliminated from the ABNF in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/25, and [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)/26.2.1 has a vague reference to it. This has been a source of confusion. Those omissions are errors in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
- NOTE:
- This needs to be in corrected in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) in another document making normative changes to [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
This specification clarifies that the "transport=tls" parameter MUST NOT be used.
However, for backward compatibility, if a "transport=tls" parameter is received, it should be interpreted as per the following guidelines:
For Via headers, the following transport protocol are defined: "UDP", "TCP", "TLS", "SCTP", and "TLS-SCTP" [RFC4168] (Rosenberg, J., Schulzrinne, H., and G. Camarillo, “The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP),” October 2005.).
| TOC |
When a GRUU [I‑D.ietf‑sip‑gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2006.) is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned. When a GRUU is obtained through registration, if the To header in the REGISTER request contains a SIP URI, the SIP version of the GRUU is returned. If the To header filed in the REGISTER request contains a SIPS URI, the SIPS version of the GRUU is returned.
| TOC |
In the following examples, Bob has two clients, one is a SIP PC client running on his computer, and the other one is a SIP Phone. The PC client does not support SIPS (and does not support TLS either) and consequently only registers with a SIP address. The SIP phone however does support SIPS and TLS, and consequently registers with a SIPS address. Both of Bob's devices are going through Outbound Proxy B, and consequently, they include a Route header indicating Proxy B. Proxy B removes the Route header corresponding to itself, and adds itself in a Path header.
After registration, there are 2 contact bindings associated with Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and sip:bob@bobpc.example.com.
Alice then calls Bob through her own Oubound Proxy A, including a Route header for Proxy A. Proxy A locates Bob's domain example.com. In this example, that domain is co-located with Bob's outbound proxy, but it could easily have been a separate proxy. Outbound Proxy A removes the Route header corresponding to itself, and inserts itself in the Record-Route and forwards the request to Proxy B.
The following subsections illustrates three examples. In the first one, Alice calls Bob using Bob's SIPS URI. In the second one, Alice calls Bob's SIP AOR using TCP transport. In the third example, Alice calls Bob's SIP AOR using TLS transport.
| TOC |
In this first example, Alice calls Bob's SIPS address (sips:bob@example.com). Proxy B consults the binding in the registration database, and finds the 2 Contact bindings. Alice had addressed Bob with a SIPS Request-URI (sips:bob@example.com), so Proxy B determines that the calls needs to be routed only to a SIPS Contact, and therefore the request is only sent to sips:bob@bobphone.example.com. Proxy B inserts itself in the Record-Route. Bob answers.
Outbound Outbound
Bob@bobpc Proxy B Registrar Proxy A Alice
| | | | |
| REGISTER F1 | | | |
|---------------->|REGISTER F2 | | |
| |----------->| | |
| | 200 F3 | | |
| 200 F4 |<-----------| | |
|---------------->| | | |
| | | | |
| Bob@phone | | | |
| | | | | |
| |REGISTER F5 | | | |
| |----------->|REGISTER F6 | | |
| | |----------->| | |
| | | 200 F7 | | |
| | 200 F8 |<-----------| | |
| |----------->| | | |
| | | | INVITE F9 |
| | | INVITE F11 |<-----------|
| | INVITE F13 |<------------------------| 100 F10 |
| |<-----------| 100 F12 |----------->|
| | 100 F14 |------------------------>| |
| |----------->| | |
| | 200 F15 | | |
| |----------->| 200 F16 | |
| | |------------------------>| 200 F17 |
| | | |----------->|
| | | | ACK F18 |
| | | ACK F19 |<-----------|
| | ACK F20 |<------------------------| |
| |<-----------| | |
| Alice Calls Bob's SIPS AOR |
Message details
F1 REGISTER Bob's PC Client -> Proxy B
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path
Route: <sip:proxyb.example.com;lr>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Expires: 7200
Content-Length: 0
F2 REGISTER Proxy B -> Registrar
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path
Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Expires: 7200
Content-Length: 0
F3 200 (REGISTER) Registrar -> Proxy B
SIP 2.0 200 OK
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: outbound
Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=7200
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0
F4 200 (REGISTER) Proxy B -> Bob's PC Client
SIP 2.0 200 OK
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: outbound
Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=7200
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0
F5 REGISTER Bob's Phone -> Proxy B
REGISTER sips:registrar.example.com SIP/2.0
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path
Route: <sips:proxyb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Expires: 7200
Content-Length: 0
F6 REGISTER Proxy B -> Registrar
REGISTER sips:registrar.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path
Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Expires: 7200
Content-Length: 0
F7 200 (REGISTER) Registrar -> Proxy B
SIP 2.0 200 OK
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: outbound
Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=7200
Date: Mon, 12 Jun 2006 16:43:50 GMT
Content-Length: 0
F8 200 (REGISTER) Proxy B -> Bob's Phone
SIP 2.0 200 OK
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: outbound
Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=7200
Date: Mon, 12 Jun 2006 16:43:50 GMT
Content-Length: 0
F9 INVITE Alice -> Proxy A
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F10 100 (INVITE) Proxy A -> Alice SIP 2.0 100 Trying Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 70 To: Bob <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F11 INVITE Proxy A -> Proxy B
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F12 100 (INVITE) Proxy B -> Proxy A SIP 2.0 100 Trying Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F13 INVITE Proxy B -> Bob's Phone
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Bob's Phone -> Proxy B SIP 2.0 100 Trying Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F15 200 (INVITE) Bob's Phone -> Proxy B
SIP 2.0 200 OK
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F16 200 (INVITE) Proxy B -> Proxy A
SIP 2.0 200 OK
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F17 200 (INVITE) Proxy A -> Alice
SIP 2.0 200 OK
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F18 ACK Alice -> Proxy A
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 70
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:KFndf+47KsFH@proxya.example.net;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Lenght: 0
F19 ACK Proxy A -> Proxy B ACK sips:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf Max-Forwards: 69 To: Bob <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: <sips:UJH-hUdvb65@proxyb.example.com;lr> Content-Lenght: 0
F20 ACK Proxy B -> Bob's Phone ACK sips:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bK8msdu2 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf Max-Forwards: 68 To: Bob <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Content-Lenght: 0
| TOC |
In the second example, Alice calls Bob's SIP address instead (sip:bob@example.com), and she uses TCP as a transport. Proxy B consults the binding in the registration database, and finds the 2 Contact bindings. Alice had addressed Bob with a SIP Request-URI (sip:bob@example.com), so Proxy B determines that the calls needs to be routed both to the SIP Contact and the SIPS Contact, and therefore the request is forked sent to sip:bob@boppc.example.com and sips:bob@bobphone.example.com. Proxy B inserts itself in the Record-Route. Bob's phone's policy is to accept calls to SIP and SIPS (i.e., "best effort") so both his PC Client and his SIP Phone ring simultaneously. Bob answers on his SIP phone, and the forked call leg to the PC client is canceled.
Outbound Outbound
Bob@bobpc Proxy B Registrar Proxy A Alice
| | | | |
| REGISTER F1 | | | |
|---------------->|REGISTER F2 | | |
| |----------->| | |
| | 200 F3 | | |
| 200 F4 |<-----------| | |
|---------------->| | | |
| | | | |
| Bob@phone | | | |
| | | | | |
| |REGISTER F5 | | | |
| |----------->|REGISTER F6 | | |
| | |----------->| | |
| | | 200 F7 | | |
| | 200 F8 |<-----------| | |
| |----------->| | | |
| | | INVITE F9 |
| | INVITE F11 |<-----------|
| INVITE F13' |<------------------------| 100 F10 |
|<----------------| 100 F12 |----------->|
| 100 F14' |------------------------>| |
|---------------->| | |
| 180 F15' | | |
|---------------->| 180 F16' | |
| |------------------------>| 180 F17' |
| | INVITE F13 | |----------->|
| |<-----------| | |
| | 100 F14 | | |
| |----------->| | |
| | 200 F15 | | |
| |----------->| 200 F16 | |
| | |------------------------>| 200 F17 |
| | | |----------->|
| | | | ACK F18 |
| | | ACK F19 |<-----------|
| | ACK F20 |<------------------------| |
| |<-----------| | |
| | | |
| CANCEL F20' | | |
|<----------------| | |
| 200 F21' | | |
|---------------->| | |
| 487 F22' | | |
|---------------->| | |
| Alice Calls Bob's SIP AOR |
Messages F1-F8 are identical to the ones in Section 9.1 (Alice Calls Bob's SIPS AOR). The other messages are as follows.
F9 INVITE Alice -> Proxy A
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F10 100 (INVITE) Proxy A -> Alice SIP 2.0 100 Trying Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F11 INVITE Proxy A -> Proxy B
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F12 100 (INVITE) Proxy B -> Proxy A SIP 2.0 100 Trying Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F13' INVITE Proxy B -> Bob's PC Client
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14' 100 (INVITE) Bob's PC Client -> Proxy B SIP 2.0 100 Trying Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F15' 180 (INVITE) Bob's PC Client -> Proxy B
SIP 2.0 180 Ringing
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F16' 180 (INVITE) Proxy B -> Proxy A
SIP 2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F17' 180 (INVITE) Proxy A -> Alice
SIP 2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F13 INVITE Proxy B -> Bob's Phone
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Bob's Phone -> Proxy B SIP 2.0 100 Trying Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F15 200 (INVITE) Bob's Phone -> Proxy B
SIP 2.0 200 OK
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F16 200 (INVITE) Proxy B -> Proxy A
SIP 2.0 200 OK
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F17 200 (INVITE) Proxy A -> Alice
SIP 2.0 200 OK
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F18 ACK Alice -> Proxy A
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:KFndf+47KsFH@proxya.example.net;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Lenght: 0
F19 ACK Proxy A -> Proxy B
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Lenght: 0
F20 ACK Proxy B -> Bob's Phone ACK sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 68 To: Bob <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Content-Lenght: 0
F20' CANCEL Proxy B -> Bob's PC Client CANCEL sip:bob@bobpc.example.com SIP/2.0 Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Max-Forwards: 70 To: Bob <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 CANCEL Content-Lenght: 0
F21' 200 (CANCEL) Proxy B -> Bob's PC Client SIP 2.0 200 OK Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 To: Bob <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 CANCEL Content-Lenght: 0
F22' 487 (INVITE) Proxy B -> Bob's PC Client SIP 2.0 487 Request Terrminated Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
| TOC |
The third example is identical to the second one, except that Alice uses TLS as the transport for her connection to her outbound proxy. Such an arrangement would be common if Alice's UA supported TLS and wanted to use a single connection to the outbound proxy (as would be the case when using [I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.)). In the example below, Outbound proxy A is also using TLS as a transport to communicate with Outbound proxy B, but it is not necessarily the case.
It should be noted that when using a SIP URI in the Request-URI, but TLS as a transport for sending the request, the Via field indicates TLS. The Route header (if present) typically would use a SIP URI (but it could also be a SIPS URI). The Contacts, To and From however would also normally indicate a SIP URI.
The call flow would be exactly as per the second example.
Messages F1-F8 and F20'-F22' are identical to the ones in Section 9.2 (Alice Calls Bob's SIP AOR using TCP). The other messages are as follows.
F9 INVITE Alice -> Proxy A
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F10 100 (INVITE) Proxy A -> Alice SIP 2.0 100 Trying Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F11 INVITE Proxy A -> Proxy B
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F12 100 (INVITE) Proxy B -> Proxy A SIP 2.0 100 Trying Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F13' INVITE Proxy B -> Bob's PC Client
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14' 100 (INVITE) Bob's PC Client -> Proxy B SIP 2.0 100 Trying Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F15' 180 (INVITE) Bob's PC Client -> Proxy B
SIP 2.0 180 Ringing
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F16' 180 (INVITE) Proxy B -> Proxy A
SIP 2.0 180 Ringing
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F17' 180 (INVITE) Proxy A -> Alice
SIP 2.0 180 Ringing
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F13 INVITE Proxy B -> Bob's Phone
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Bob's Phone -> Proxy B SIP 2.0 100 Trying Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0
F15 200 (INVITE) Bob's Phone -> Proxy B
SIP 2.0 200 OK
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F16 200 (INVITE) Proxy B -> Proxy A
SIP 2.0 200 OK
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F17 200 (INVITE) Proxy A -> Alice
SIP 2.0 200 OK
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F18 ACK Alice -> Proxy A
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:KFndf+47KsFH@proxya.example.net;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Lenght: 0
F19 ACK Proxy A -> Proxy B
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Lenght: 0
F20 ACK Proxy B -> Bob's Phone ACK sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 68 To: Bob <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Content-Lenght: 0
| TOC |
The restrictions described in this document have consequences on the applicability of the SIPS URI scheme.
SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) itself introduces some complications with using SIPS, for example when using strict routing instead of loose routing. When a SIPS URI is used in a Contact in a dialog initiating request and Record-Route is not used, that SIPS URI may not be usable by the other end. If the other end does not support SIPS and/or TLS, it will not be able to use it. The "last-hop exception" is an example of when this may occur. In this case, using Record-Route so that the requests are sent through proxies helps in making it work. Another example of issues with strict routing is that even in a case where the Contact is a SIPS URI, no Record-Route is used, and the far end supports SIPS and TLS, it may still not be possible for the far end to establish a TLS connection with the SIP originating end if the certificate can not be validated by the far end. This could typically be the case if the originating end was using server-side authentication as described below, or even if the originating end is not using a certificate that can be validated. In both cases, [I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.) and Record-Route may be used to solve the problem.
TLS itself has a significant impact on how SIPS may be used. "server-side authentication" (where the server side provides its certificate but the client side does not) is typically used between a SIP end-user device acting as the TLS client side (like a phone or a personal computer), and it's SIP server (proxy or registrar) acting as the TLS server side. "Mutual TLS" (where both the client and the server side provide their respective certificate) is typically used between SIP servers (proxies, registrars), or statically configured devices such as PSTN gateways or media servers. In the mutual TLS model, for two entities to be able to establish a TLS connection requires that both side be able to validate each other's certificates, either by static configuration or by being able to recurse to a valid root certificate. With server-side authentication, only the client side is capable of validating the server side's certificate, as the client side does not provide a certificate. The consequences of all this are that whenever a SIPS URI is used to establish a TLS connection, it must be possible for the entity establishing the connection (the client) to validate the certificate from the server side. For server-side authentication, [I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.) is the recommended approach. For mutual TLS, it means that one should be very careful that the architecture of the network is such that connections are made between entities that have access to each other's credential. Record-Route [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and Path [RFC3327] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” December 2002.) are very useful in ensuring that previously established TLS connections can be re-used. Other mechanism may also be used in certain circumstances: for example, using root-certificates that are widely recognized may allow for more easily creqated TLS connections.
The "last hop exception" introduces significant potential vulnerabilities in SIP. Obviously, there is no garantee on the type of security that will be used on that last hop as it will be completely up to the target domain. Annother vulnerability is that there is no way to ensure that the last hop will really be the last hop: that hop could redirect or retarget to more hops. These hops could even be outside of the original target domain, and it is possible that the fact that it was retargeted by an entity that was not secured through TLS may be undetectable.
| TOC |
Most of this document can be considered to be security considerations since it applies to the usage of the SIPS URI.
| TOC |
There are no IANA considerations.
| TOC |
There are no IAB considerations.
| TOC |
The author would like to thank Jon Peterson, Cullen Jennings, and Jonathan Rosenberg for their help. The author would like to thank John Elwell, Paul Kyzivat, Eric Rescorla, Rifaat Shekh-Yusef, Peter Reissner, Samir Srivastava, Tina Tsou, Brian Stucker and Patrick Ma for their careful review and input.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [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. |
| [RFC3327] | Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” RFC 3327, December 2002. |
| TOC |
| TOC |
This section is a placeholder for a discussion of possible future steps in specification, and the pros and cons of making such changes. Protocol and normative changes to any specifications (such as RFC 3261) resulting from this discussion would be specified in futher documents.
| TOC |
[I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.) provides an elegant and complete solution to the problem that was intented to be be solved unsucessfully by the last hop exception rule as described in Section 3 (Meaning of SIPS). It is expected that a further specification may deprecate the option of using the last hop exception rule. It is therefore RECOMMENDED for current implementation to avoid using the last hop exception and instead use [I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.).
| TOC |
SIPS provides a mean to request that every SIP signalling hop be secured using TLS. This is very different than end-to-end security since it implies transitive trust. A true mechanism for end-to-end SIP signalling is a potential area for future specification.
| TOC |
Need to look at Replaces [RFC3891] (Mahy, R., Biggs, B., and R. Dean, “The Session Initiation Protocol (SIP) "Replaces" Header,” September 2004.), Join [RFC3911] (Mahy, R. and D. Petrie, “The Session Initiation Protocol (SIP) "Join" Header,” October 2004.) and Target-Dialog. For example, what if this header field is received in a request to a SIPS URI but the dialog to which it relates has a SIP local target, or vice-versa?
Third-party call control [RFC3725] (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) may also have its own set of issues to investigate.
REFER [RFC3515] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) and also [RFC3892] (Sparks, R., “The Session Initiation Protocol (SIP) Referred-By Mechanism,” September 2004.) introduces its own set of issues with sips:
Handling of annomalies are not very well defined in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). What if a UAS receives a SIP Contact replacing a SIPS contact in a target refresh? Should the UAC tear down the dialog if it can not cope with the unexpected response?
For GRUU, how should the UAC react if the returned GRUU is SIP but the To was SIPS? How should the UAC react if the returned GRUU is SIPS but the To was SIP?
| TOC |
| Francois Audet | |
| Nortel Networks | |
| 4655 Great America Parkway | |
| Santa Clara, CA 95054 | |
| US | |
| Phone: | +1 408 495 2456 |
| Email: | audet@nortel.com |
| TOC |
Copyright © The IETF Trust (2007).
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).