Internet Communications Using SIP : Delivering VoIP and Multimedia Services With Session Initiation Protocol {2Nd Ed.}

Encryption at the transport layer using TLS is visible at the application.

Therefore, a SIP UA that attempts to open a TLS connection over TCP to

another UA or server will receive a failure message if it is not established. TLS

transport is recorded in the Viaheader fields, so the encryption of previous

hops can be verified. The use of TLS with SIP is described in Section 26 of

RFC 3261.

Secure SIP URI Scheme

However, TLS only provides a single hop of confidentiality and authentica-

tion. Since most SIP sessions involve at least one proxy server, there is typically

more than one hop between the two communicating UAs. If TLS is used on the

first hop but not on the second, then end-to-end confidentiality has not been

provided. To solve this problem, RFC 3261 defines Secure SIP.

Secure SIP, which uses the URI scheme sips, is used to guarantee end-to-

end confidentiality of a SIP session. At each hop, TLS transport must be used

or the connection is failed back to the initiator with a 416 error response mes-

sage. The only exception made is for the very last hop, which may be secured

by another mechanism providing confidentiality, besides TLS. For example,

IPSec or radio-layer encryption is acceptable for the last or first hop. The use of

Secure SIP is shown in Figure 9.2.

Figure 9.2 Secure SIP

User B Proxy A

Open TLS Connection

1 INVITE sips : A

2 100 Trying

Open TLS Connection

Last hop could

be non-TLS if

secured using

some other

protocol such as

IPSec.

3 INVITE sips : A

Open TLS Connection

4 100 Trying

Proxy B

5 INVITE sips : A

User A

164 Chapter 9