Encryption of messages

If the media encryption key must be protected, then the SDP requests and replies must be encrypted. There are many other reasons for protecting SIP messages (e.g., to hide the origin or destination of calls and the related information fields such as Subject, etc.). In general, however, SIP messages only need to be authenticated, which is useful not only to prevent call spoofing, but also for accounting and billing.

SIP messages can be encrypted hop by hop (e.g., using IPsec). They can also be transported over a secure transport layer such as TLS (in this case “sips:” URIs are used). SIP also describes an end-to-end encryption strategy based either on a shared secret key between the sender and the receiver or on a public key mechanism. If a common secret

key is used, then the receiver of the message is able to decrypt a message encrypted by the sender by using the shared password. If a public key scheme is used, the sender encrypts the message using the public key of the receiver. This encryption can be performed by the sender of the request or by an intermediary security proxy.

RFC 2543 also defined an encryption mechanism based on PGP, which has been depre- cated. The request line and unencrypted headers were sent first, followed by an Encryption header field, which indicates the encryption method in use; for instance:

Encryption: PGP version=2.6.2,encoding=ascii

The encrypted part began after the first empty line (CR+ LF of the previous line imme- diately followed by CR+ LF). Figure 3.49 is taken from RFC 2543.

If just the message body has to be encrypted, an extra empty line had to be inserted in the body before encryption to prevent the receiver from mixing up message body data and encrypted headers. There are specific issues with the Via header, since it is used by proxies to route the request back to the source.

3.7

SIP AND H.323

The SIP versus H.323 debate has been a very heated one among VoIP engineers. Behind the technology facade of some arguments, the debate has been fueled and biased by the interests of many telecom manufacturer companies who roughly fall in the follow- ing categories:

• Early VoIP players, with a strategy based on standards, who have already captured the largest VoIP market share and defend H.323. In this camp there is also the vast majority of PBX manufacturers, who like the similarity between ISDN and H.323 and offer H.323 WAN interfaces.

Call-ID: [email protected] Subject:Mr. Watson, come here.

Content-Type:application/sdp

v=0

o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180.144.94

m=audio 3456 RTP/AVP 0 3 4 5

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5

To: T. A. Watson <sip:[email protected]> From: A. Bell<sip:a.g.bell@bell-telephone com>. Encryption: PGP version=5.0

Content-Length: 224

CSeq: 488 Empty line

Clear part Encrypted part Encryption method Encrypted headers Empty line (encrypted) Encrypted SDP

• Early VoIP players, with proprietary products, who are trying to extend the life of their existing products, by criticizing H.323 and announcing a leapfrog to future standards in their roadmap. This is also the case of most traditional central office manufacturers, who must pay lip service to VoIP but also wish to extend the life of their existing systems and most of all the ‘closed model’ which ensures comfortable maintenance fees. These manufacturers usually build mostly proprietary VoIP systems, but very often label proprietary protocols with a reassuring ‘pre-XXX’, where XXX is a still- immature protocol.

• Start-ups arriving too late to catch the first H.323 wave, who engaged all their marketing resources to promote SIP and present H.323 as obsolete.

Let’s now turn to discuss some of the features of SIP and H.323 that are most frequently used for or against them. The conclusion is that the ‘protocol war’ has been very beneficial to both protocols, stimulating many improvements, to the point that SIP and H.323 are now virtually identical protocols!

In 2004, H.323 still has the lion’s share of VoIP deployments, in telephony carrier networks. It is also used by virtually all corporate IP-PBXs for the VoIP trunk interfaces. (In 2002, over 2 million such H.323 PBX trunk ports were sold in the USA alone.) All versions of Microsoft Windowsstill include the NetMeetingH.323 client, as well as a TAPI H.323 implementation. NetMeeting is also used as a VoIP and collaboration com- ponent in most other client-side and server-side programs of the company. However, SIP has become more prevalent on the desktop since the XP version, which hides NetMeeting and exposes Messenger, a general purpose instant-messaging and VoIP client, based on proprietary protocols but where SIP can also be used.

SIP seems to be winning the battle for instant messaging, and this will probably drive the adoption of SIP for multimedia user interaction on a PC desktop. One can only guess what the future will be, but it is likely that SIP will become the de facto standard on PCs, while H.323 will remain dominant inside carrier networks and for the interconnection of IP-PBXs for some years, until SIP matures enough to include all the required features for PSTN interworking. In time, H.323 and SIP will probably continue to coexist in the market for carrier telephony over IP, but with a more balanced share.

The winner for IP phones and analog residential gateways is likely to be neither SIP nor H.323 (today most IP phones implement a proprietary PBX stimulus protocol, but among standard phones most support H.323, with a growing number offering SIP IP). IP phones controlled by a PBX, a hosted PBX, or a virtual PBX share common requirements with today’s PBX business phones. These requirements led the market to implement dumb stimulus phones as opposed to smart phones, allowing the PBX to control any aspect of the phone user interface, including lamps, buttons, screens, etc. A stimulus phone makes it easier to implement any service without waiting for a standardized way of implementing this standard on a smart phone. It also facilitates centralized management. In VoIP, the leading stimulus phone protocol is MGCP, and it is likely that most IP phones will have to support MGCP is the coming years. MGCP is also required to interwork completely with analog gateways, as it supports services on- and off-hook. MGCP is the dominant protocol in the cable market.