Barry Andrews

andrews@8x8.com

Video & Voice over IP Communications A SIP-based example

Why SIP?
SIP (Session Initiation Protocol) is a communications protocol that defines how devices (computers, telephones, mobile phones) exchange information with each other.

IETF (Internet Engineering Task Force) standard (RFC 326[1-5], obsoletes RFC 2543 which originated in the mid-90s).
Control Over Services is Pushed Out to the Endpoints

In the traditional telecom environment, centralized switching elements control voice and other services By moving service control out to the endpoints (such as SIP-based mobile phones or audio clients), SIP eliminates the need for a central switching element. While SIP can set up any session (voice, video, messaging, games) it does not predefine what that session should be. It supports any MIME type in the messages and hence can support a broad set of services including new applications yet to be defined. SIP can be extended to support new messages and new types of services. E.g.. SIP for Instant Messaging and Presence (SIMPLE) is a SIP extension to support interoperable instant messaging and presence systems. Backwards compatible through base protocol 2

Flexible

Extensible

Why SIP?
Integration with Internet Standards

SIP uses URIs (Universal Resource Indicators), DNS (Domain Name Server), MIME ( Multipurpose Internet Mail Extensions) in ways that are compatible with other IP applications. Easily interoperates with Web applications SIP chosen as the call control standard for 3G networks by 3GPP and 3GPP2 IETFs SIP working groups looking at supporting 3G SIP related requirements Significant VoIP network deployments based on SIP International Softswitch Consortium (ISC) chose SIP as the signaling mechanism between softswitches. SIP used to provide Microsoft real-time communications capabilities in Windows Messenger and MSN Messenger clients Instant Messaging (IM) and presence services based on proprietary technology (AOL, Yahoo!, and MSN) SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) hopes to standardize instant messaging and presence among various service providers.

SIP for Mobile Networks

SIP for Wireline Networks

SIP for Presence

Packet8 Video & Voice Solutions

What is Packet8?

A SIP based communication service Call to/from any phone anywhere in the world Plug and play installation. Dial tone in seconds. Multiple types of devices are supported

IP phones Terminal adapters/analog telephones Windows Messenger IP videophones

Choose your own area code - dedicated phone number associated with account NAT traversal Caller ID Call forwarding Voice and video mail (video mail in development) Free calls between Packet8 users Flat monthly service fee includes all features and bundled long distance minutes Portability

Plug the phone into an Internet connection anywhere in the world to make and receive calls Receive calls on your Packet8 device or Windows Messenger 4

Virtual phone lines that scale with the number of endpoints associated with each DID

Packet8 Servlets

Traverse

Recorder

InCPL

InCDR

InCisco

Endpoints

Front

Registrar

Player

Gateway

OutCDR

Dialplan

OutCPL

OutCisco

MWI

Registration

Unsupported911

MyIP

A SIP Servlet is a piece of code that can initiate, terminate or route SIP transactions and sessions. A complete application like Packet8 is built by assembling multiple servlets and VoiceXML scripts. 5

Packet8 Servlets
Front Servlet

Receives and sends all the SIP messages to and from the Packet8 endpoints. Its primary task is to enable SIP endpoints to be used behind a NAT. Its secondary task is to dispatch requests to the Registrar, Traverse, MWI or InCDR servlet. Used to store the registrations (mapping between an endpoint and its IP address) in a shared database. This database is also used by the InCPL servlet to find the destinations for an incoming call.

Registrar Servlet

Traverse Servlet

Implements a traverse server and an RTP switch. The traverse server implements an 8x8 proprietary protocol to create an RTP switch. The RTP switch forwards the received RTP packets to a destination provided by the traverse protocol. This is used to enable RTP stream NAT traversal. Uses soft states, which means that the endpoint requesting a switch port must renew its request periodically. If an endpoint is brutally disconnected, the resources will be automatically de-allocated after a timeout delay.
Implements the IETF Message Waiting Indicator draft. Each endpoints subscribes to this servlet. Uses soft states, so the resources will be de-allocated if the endpoint does not renew its subscription. When a the subscriber mailbox status changes, a notification is sent back to the endpoint to update its status. 6

MWI Servlet

Packet8 Servlets
OutCDR Servlet

Creates and updates the Call Detail Record (CDR) for each call originating from an endpoint. Stores the time at the beginning of the call (INVITE), when the call is accepted or rejected (ACK or 400-699) and when the call is disconnected (BYE). Uses an international dialplan to quickly accept or reject an invalid phone number. The endpoints are configured to send the phone number entered by the end-user very quickly to the Packet8 server (1 second). The dialplan servlet evaluates if a number is complete, incomplete or invalid: If the number is complete, the call is proxied to the OutCPL servlet. If the number is invalid, the call is rejected. Manages the authorizations for outgoing calls (International, CallerID, etc..). This information is stored in the OpenLDAP database. This is where the calls are dispatched to their destination: Calls to a Packet8 endpoint are proxied to the InCDR servlet. Calls to an internal service (phone numbers starting with 0120) are proxied to this service (Voicemail, Unsupported911, MyIP). Calls to a PSTN number are sent to the OutCisco servlet.

DialPlan Servlet

OutCPL Servlet

Packet8 Servlets
OutCisco Servlet

The Cisco AS5300 gateway does not implement the latest version of SIP. This servlet implements a SIP B2BUA (Back to Back User-Agent) which isolates the Cisco gateway from the Packet8 network, repairs some of the incompatibilities with Packet8. This servlet does the same thing that the OutCisco servlet does, but for incoming calls. Creates and updates the Call Detail Record (CDR) for each incoming call. An incoming call can come from a PSTN gateway, or from the OutCPL servlet in the case of a Packet8 to Packet8 call. Stores the time at the beginning of the call (INVITE), when the call is accepted or rejected (ACK or 400-699) and when the call is disconnected (BYE). Manages the destinations for incoming calls. The information is stored in an OpenLDAP database and in the Registrar in-memory shared database. A call to the voicemail is directed to the Player servlet. A call to an endpoint has three phases: The list of endpoints attached to the subscriber account are simultaneously called. After a delay, the call is also proxied to the recorder servlet (Voicemail). After a delay the call is also proxied to an additional phone number (forwarding). If the phone number is a PSTN number, this branch is proxied to the OutCDR servlet. 8

InCisco Servlet

InCDR Servlet

InCPL Servlet

Packet8 Servlets
Registration Servlet

This servlet uses VoiceXML to implement an IVR. This is the IVR called when a subscriber registers his endpoint for the first time. The IVR checks the 10 digit code in the LDAP database and creates the binding in the OpenLDAP server This servlet uses VoiceXML to implement the recorder part of the voicemail application. This servlet is called when an endpoint does not respond to an incoming call. The servlet stores the audio message in an SQL database and uses the MWI servlet to update the message waiting indicator on the subscriber's endpoint(s). This servlet uses VoiceXML to implement the player part of the voicemail application. The caller uses menus to play and delete the messages in the mailbox. The application is also used to manage the mailbox.

Recorder Servlet

Player Servlet

MyIP Servlet

This servlet uses VoiceXML to play the caller's IP address.

Video Call Establishment - SDP Negotiation

Non-proprietary
All SDP parameters used as defined in RFC 2327

Caller specifies the call options in the INVITE message:

choices for audio and video codecs audio packetization rate (in ms) maximum video bitrate acceptable to the caller to receive

Callee responds with final call parameters in the 200 (answer) response to the INVITE
final choice of audio and video codec maximum video bitrate acceptable to the callee to receive

Video encode bitrate

both parties encode using the minimum of the two maximum values accepted by each party represents raw video content does not include, but must take into account packet overhead (headers)
RTP + UDP + IP + PPP + Ethernet + DSL/ATM (Gray = DSL)

10

Example SDP Negotiation

Callers SDP (INVITE)
v=0 o=0403242565 0 0 IN IP4 207.82.37.49 s=c=IN IP4 207.82.37.49 t=0 0 m=audio 8208 RTP/AVP 4 0 8 <- Caller can receive audio codecs G.723.1,G.711U,G.711A a=ptime:30 m=video 8210 RTP/AVP 34 31 <- Caller can receive video codecs H.263 and H.261 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 b=AS:640 <- Caller can receive up to 640kbps video bitrate

Callees SDP (200 OK response to INVITE)

v=0 o=0403242509 0 0 IN IP4 207.82.37.103 s=c=IN IP4 207.82.37.103 t=0 0 m=audio 8200 RTP/AVP 4 <- Callee can receive audio a=ptime:30 m=video 8202 RTP/AVP 34 <- Callee can receive video a=rtpmap:34 H263/90000 b=AS:128 <- Callee can receive up to both parties will encode

codec G.723.1 codec H.263 128kbps video bitrate, hence video at this bitrate

11

In Call Video Control Commands

Non-proprietary scheme, with Packet8 extensions Control commands sent using SIP INFO method (with Call-ID of INVITE)

INFO method defined in RFC 2976 Message content is XML Described in draft-levin-mmusic-xml-media-control-01 (March 2003) Packet8 uses a subset of the commands, and adds two proprietary commands

Control commands targeted at the remote partys video encoder

Picture_Fast_Update: Standard command to request intraframe when local decoder detects error Bandwidth_Step_Up: Packet8 extension to request remote encoder to use higher bit rate Bandwidth_Step_Down: Packet8 extension to request remote encoder to use lower bit rate

Controls may be issued manually (by user) or automatically

keypad entry allows user to control bitrate decoder can make decisions based on perceived error rate and/or latency high decode error rates and/or high packet latency may require lower bitrate to resolve

12

Example INFO Command

Example (Fast Update Request for intraframe):
INFO sip:0403242565@207.82.37.49:5060 SIP/2.0 Call-ID: 8076bb8-31f5d21-cf5238f5@packet8.net From: <sip:0403242509@packet8.net>;tag=402fff4 To: "BVP8770 "<sip:0403242565@packet8.net>;tag=4031e7c-31f5d21 CSeq: 101 INFO Via: SIP/2.0/UDP 207.82.37.48:5060;branch=z9hG4bK.4035e6c.31f510e;rport Contact: BVP8770<sip:0403242509@207.82.37.48:5060> Max-Forwards: 70 Route: <sip:192.84.18.254:5060;lr> User-Agent: 8x8 SIP Phone Content-Type: text/plain Content-Length: 195 <?xml version="1.0" encoding="utf-8" ?> <media_control> <vc_primitive> <to_encoder> <picture_fast_update> (or <bandwidth_step_up> or <bandwidth_step_down>) </picture_fast_update> </to_encoder> </vc_primitive> </media_control>

13

Packet8 Registration

The endpoint sends a REGISTER

Endpoint
REGISTER

Packet8
REGISTER sip:packet8.net SIP/2.0 Via: SIP/2.0/UDP 10.1.28.247;branch=z9hG4bK.28f98.676a9102;rport From: <sip:02104412@packet8.net>;tag=t286c0a676a9101g To: <sip:02104412@packet8.net> Call-ID: 4aecc-114c-0-a0130bb@packet8.net CSeq: 64649 REGISTER Contact: sip:02104412@10.1.28.247 Expires: 180 Max-Forwards: 70 User-Agent: DTA SIP/0.11.8 NNOS/VR30 Content-Length: 0

14

Packet8 Registration
Packet8 stores the mapping

Endpoint
REGISTER

Packet8
200 OK
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.28.247;branch=z9hG4bK.28f98.676a9102;rport=5060 ;received=12.234.8.147 From: test<sip:02104412@packet8.net>;tag=t286c0a676a9101g To: test<sip:02104412@packet8.net>;tag=9zvw48shdnbemkglcny5b9wuy Call-ID: 4aecc-114c-0-a0130bb@packet8.net CSeq: 64649 REGISTER Server: Packet8/0.2.6 (RegistrarServlet) eSLEE/0.8.9 Content-Length: 0 Expires: 30 Contact: <sip:02104412@10.1.28.247>;expires=30

15

Message Waiting Indicator

The endpoint subscribes to the MWI events

Endpoint
SUBSCRIBE

Packet8
SUBSCRIBE sip:02104412@packet8.net SIP/2.0 Via: SIP/2.0/UDP 10.1.28.247;branch=z9hG4bK.28c3c.192e;rport From: test<sip:02104412@packet8.net>;tag=t28e6ca192eg41a7 To: test<sip:02104412@packet8.net> Call-ID: 4b678-192d-a2f420-a0130bb@packet8.net CSeq: 100 SUBSCRIBE Contact: sip:02104412@10.1.28.247 Expires: 1800 Max-Forwards: 70 Event: message-summary User-Agent: DTA SIP/0.11.8 NNOS/VR30 Content-Length: 0

16

Message Waiting Indicator

Packet8 accepts

Endpoint
SUBSCRIBE

Packet8
200 OK
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.28.247;branch=z9hG4bK.28c3c.192e ;rport=5060;received=12.234.8.147 From: test<sip:02104412@packet8.net>;tag=t28e6ca192eg41a7 To: test<sip:02104412@packet8.net>;tag=dimn9pu1sxelbix6kr4xsl5s4 Call-ID: 4b678-192d-a2f420-a0130bb@packet8.net CSeq: 100 SUBSCRIBE Record-Route: <sip:02104412@192.84.18.251:5060;lr> Contact: <sip:02104412@192.84.18.252:5066> Server: eSLEE/0.8.7 Packet8-MWINotifier (StVallier) Content-Length: 0 Expires: 1800

17

Message Waiting Indicator

And sends the current state

Endpoint
SUBSCRIBE

Packet8
200 OK NOTIFY NOTIFY sip:02104412@10.1.28.247 SIP/2.0
Via: SIP/2.0/UDP 192.84.18.251:5060 ;branch=z9hG4bK9rp493qfntaagovhw7t0qixro Via: SIP/2.0/UDP 192.84.18.252:5066 ;branch=z9hG4bKbnsrkh0lc50bhwp8tv5qoe4s0 From: test<sip:02104412@packet8.net>;tag=dimn9pu1sxelbix6kr4xsl5s4 To: test<sip:02104412@packet8.net>;tag=t28e6ca192eg41a7 Call-ID: 4b678-192d-a2f420-a0130bb@packet8.net CSeq: 1964223776 NOTIFY Contact: <sip:02104412@192.84.18.252:5066> Max-Forwards: 69 Event: message-summary Subscription-State: active Content-Length: 44 Content-Type: application/simple-message-summary User-Agent: eSLEE/0.8.7 Packet8-MWINotifier (StVallier) Record-Route: <sip:02104412@192.84.18.251:5060;lr> Message-Waiting: yes Voicemail: 9/9 (0/0)

18

Message Waiting Indicator

The endpoint accepts the current state

Endpoint
SUBSCRIBE

Packet8
200 OK NOTIFY

200 OK

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.84.18.251:5060 ;branch=z9hG4bK9rp493qfntaagovhw7t0qixro Via: SIP/2.0/UDP 192.84.18.252:5066 ;branch=z9hG4bKbnsrkh0lc50bhwp8tv5qoe4s0 From: test<sip:02104412@packet8.net>;tag=dimn9pu1sxelbix6kr4xsl5s4 To: test<sip:02104412@packet8.net>;tag=t28e6ca192eg41a7 Call-ID: 4b678-192d-a2f420-a0130bb@packet8.net CSeq: 1964223776 NOTIFY Record-Route: <sip:02104412@192.84.18.251:5060;lr> Server: DTA SIP/0.11.8 NNOS/VR30 Content-Length: 0

19

Message Waiting Indicator

Later, Packet8 updates the MWI state

Endpoint
SUBSCRIBE

Packet8
200 OK NOTIFY
NOTIFY sip:02104412@10.1.28.247 SIP/2.0 Via: SIP/2.0/UDP 192.84.18.251:5060 ;branch=z9hG4bK9rp493qfntaagovhw7t0qixro Via: SIP/2.0/UDP 192.84.18.252:5066 ;branch=z9hG4bKbnsrkh0lc50bhwp8tv5qoe4s0 NOTIFY From: test<sip:02104412@packet8.net>;tag=dimn9pu1sxelbix6kr4xsl5s4 To: test<sip:02104412@packet8.net>;tag=t28e6ca192eg41a7 Call-ID: 4b678-192d-a2f420-a0130bb@packet8.net CSeq: 1964223777 NOTIFY Contact: <sip:02104412@192.84.18.252:5066> Max-Forwards: 69 Event: message-summary Subscription-State: active Content-Length: 44 Content-Type: application/simple-message-summary User-Agent: eSLEE/0.8.7 Packet8-MWINotifier (StVallier) Record-Route: <sip:02104412@192.84.18.251:5060;lr> Message-Waiting: yes Voicemail: 10/10 (0/0)

200 OK

20

Message Waiting Indicator

The endpoint accepts the update

Endpoint
SUBSCRIBE

Packet8
200 OK NOTIFY

200 OK

NOTIFY 200 OK
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.84.18.251:5060 ;branch=z9hG4bK9rp493qfntaagovhw7t0qixro Via: SIP/2.0/UDP 192.84.18.252:5066 ;branch=z9hG4bKbnsrkh0lc50bhwp8tv5qoe4s0 From: test<sip:02104412@packet8.net>;tag=dimn9pu1sxelbix6kr4xsl5s4 To: test<sip:02104412@packet8.net>;tag=t28e6ca192eg41a7 Call-ID: 4b678-192d-a2f420-a0130bb@packet8.net CSeq: 1964223777 NOTIFY Record-Route: <sip:02104412@192.84.18.251:5060;lr> Server: DTA SIP/0.11.8 NNOS/VR30 Content-Length: 0

21

NAT Traversal Protocols

Network Address Translators (NATs), while providing many benefits, also come with many drawbacks. The most troublesome of those drawbacks is the fact that they break many existing IP applications, and make it difficult to deploy new ones. Examples of such protocols include multimedia applications and file sharing. When the Packet8 Service was designed, there was one standard solution for NAT traversal - Simple Traversal of UDP Through NAT (STUN) STUN (RFC 3489) is a client server protocol used to detect what kind of NAT is used, and to discover the NAT mapping that can be used for sending the incoming RTP stream. STUN by itself does not provide a complete solution for NAT traversal. A complete solution requires a means by which a client can obtain a transport address from which it can receive media from any peer which can send packets to the public Internet. This can only be accomplished by relaying data though a server that resides on the public Internet. TURN (Traversal Using Relay NAT) is a new IETF draft that allows a client to obtain IP addresses and ports from such a relay.

22

NAT Traversal Protocols

Although TURN will almost always provide connectivity to a client, it comes at high cost to the provider of the TURN server. It is therefore desirable to use TURN as a last resort only, preferring other mechanisms (such as STUN or direct connectivity) when possible. As TURN was not available when Packet8 was designed, we chose to design and implement our own protocol, which is described in the following slides but which is similar in principle to TURN.

23