Cisco SIP VoIP Application – Microsoft Voice.NET

1. Cisco SIP VoIP Application –Microsoft Voice.NET Jimmy K. Lai Service Providers Cisco Systems Taiwan July 23, 2003

2. Agenda • SIP Architecture Overview • Overview of MSN Voice.NET • Technical Challenges • Understanding the ITSP Models • SIP Proxy requirements • SIP Gateway requirements • Network Engineering requirements

3. SIP Basics - Architecture Applications • Can reside in end-points or centralized servers • Need to be URL addressable • May or May Not be SIP URLs Call-Control • Can reside in end-points or centralized servers (B2BUA) • Can be stateful or stateless. • All Signaling uses SIP • Allows features to be implemented on end-points or servers. SIP SIP PSTN RTP Legacy PBX

4. SIP Basics - Architectural Elements Endpoints: • User Agent Client (UAC) / User Agent Server (UAS) • Originate & Terminate SIP requests • Typically an endpoint will have both UAC & UAS, UAC for originating requests, and UAS for terminating requests Servers: • Proxy Server • Redirect Server • Registrar Server • Back-to-Back User Agent (B2BUA) Applications Standalone SIP Server

5. SIP Servers/Services SIP Servers/ Services LocationDatabase Redirect Registrar “Where is this name/phone#?” 3xx Redirection “They moved, try this address” REGISTER “Here I am” SIP Proxy Proxied INVITE “I’ll handle it for you” INVITE “I want to talk to another UA SIP User Agents SIP User Agents SIP-GW

6. PSTN PSTN Calling Party Called Party INVITE w/ SDP 100 Trying 180/183 Ringing w/ SDP 200 OK RTCPStream SIP VoIP Review - Signaling Call Flow SIP VoIP Network SIP Signaling & SDP Signaling (UDP or TCP) Signaling ACK Bearer Or Media Media (UDP)

7. PSTN PSTN ACK ACK INVITE INVITE Calling Party Called Party 100 Trying 100 Trying 200 OK 180 Ringing 180 Ringing 200 OK RTCP Stream SIP VoIP Review –Proxy Server Signaling SIP VoIP Network SIP Signaling & SDP Signaling (UDP or TCP) Signaling Bearer Or Media Media (UDP) NOTE-1: Proxy Server NEVER originates signaling. NOTE-2: Proxy Server can be Stateless or Transaction-Stateful

8. PSTN PSTN INVITE ACK INVITE Calling Party Called Party 3xx Redirect 100 Trying 180 Ringing 200 OK RTCP Stream SIP VoIP Review –Redirect Server Signaling SIP VoIP Network SIP Signaling & SDP Signaling (UDP or TCP) Signaling Bearer Or Media Media (UDP) NOTE-1: Redirect Server NEVER originates signaling. NOTE-2: Redirect Server can be Stateless or Transaction-Stateful

9. PSTN PSTN ACK ACK Calling Party Called Party 100 Trying 100 Trying 200 OK 200 OK 180 Ringing 180 Ringing RTCP Stream SIP VoIP Review – B2BUA Signaling SIP VoIP Network INVITE (Call-ID#1) INVITE (Call-ID#2) SIP Signaling & SDP Signaling (UDP or TCP) Signaling Bearer Or Media Media (UDP) NOTE-1: B2BUA does originate signaling. NOTE-2: B2BUA is Call-Stateful

10. Agenda • SIP Architecture Overview • Overview of MSN Voice.NET • Technical Challenges • Understanding the ITSP Models • SIP Proxy requirements • SIP Gateway requirements • Network Engineering requirements

11. Overview of MSN Voice.NET - Phase 1 • October, 2001 - MSN Voice.NET project goes live • MSN Messenger client will support SIP for VoIP calls - PC to PC calls (now) - PC to PSTN calls (now) - PSTN to PC calls • MSN will work with worldwide ITSPs to terminate the VoIP calls. • MSN will own the customers, but ITSPs own the billing of the customers for PSTN calls.

12. STP MSN Voice.NET Architecture – Infrastructure (High-Level) Microsoft Voice.NET ITSP Data Center Passport Servers Microsoft SIP Proxies Cisco SIP Proxy Servers DNS Servers Cisco VPN 5000/ 3000 ITSP POP 1 (CAS,PRI, R2) Cisco VPN product VPN Cisco Voice Gateways Billing/Authentication Account Signup Radius Server Billing System ITSP POP 2 (SS7) Database SC2200 Internet ITSP IP Backbone Cisco Voice Gateways MSN User

13. STP STP MSN Voice.NET Architecture –Call Flow (High Level) 2. MSN associates a user with their preferred ITSP in the MSN Proxy 1. MSN user selects an ITSP from the menu for PSTN calls MSN Network 5. MSN Proxy forwards the SIP messages to the ITSP Proxy MSN SIP Proxy Internet MSN Client 4. MSN routes the call to an ITSP Internet ITSP SIP Proxy SS7 ITSP Managed Network GK SLT PSTN IMT 3. MSN user dials a PSTN number from the MSN Messenger client. ITSP - Wholesale VoIP 6. ITSP Proxy forwards call to SIP- GW

14. MSN Voice.NET Architecture –User Sign-Up • The MSN user will select an ITSP when they sign-up for the service. - The lists of ITSPs is provided at this time. - The MSN user’s preference is loaded into the MSN SIP Proxy - This will allow the ITSP to “advertise” on the MSN client • MSN will provide the MSN user information to the ITSP via an external “push” mechanism. - MSN user information is provided by the Passport (PUID) login service - The PUID (Passport User ID) identifies the MSN user - The PUID password is not provided to the ITSP - The PUID must be used to bill the MSN user

15. MSN Voice.NET Architecture –MSN Proxy Provisioning • MSN User <-> ITSP preference will be provisioned in the MSN SIP Proxy - All calls from specific MSN user will go to a specific ITSP - MSN currently doesn’t define calling areas (Regional or International) per ITSP • MSN will keep a list of ITSP SIP Proxy servers in their routing tables - Route to ITSP-A would point to proxy.itsp-a.com - The route points to the DNS SRV record of the ITSP Proxy

16. MSN Voice.NET Architecture –MSN Proxy Provisioning ITSP Logo

17. MSN Voice.NET Architecture –ITSP Routing • MSN Proxy will route PSTN calls to the ITSP SIP Proxy servers. • MSN will add a “Record-Route:” header to all INVITE messages, so it sees the BYE messages. • MSN will add a “Proxy-Authorization:” header, will encodes the PUID in base64. • ITSP is responsible for getting the call to the PSTN via a SIP-GW.

18. MSN Voice.NET Architecture –ITSP Branding ITSP Status Window

19. Agenda • SIP Architecture Overview • Overview of MSN Voice.NET • Technical Challenges • Understanding the ITSP Models • SIP Proxy requirements • SIP Gateway requirements • Network Engineering requirements

20. MSN Voice.NET requirements • ITSP must have a secure VPN connection to the MSN Network. IPSec VPN is used. • ITSP must provide a VoIP capable (within defined delay budgets) network. • ITSP must be responsible for providing the billing to the MSN user. • ITSP must support SIP, UDP or TCP calls. • ITSP must support RFC2833 for DTMF-Relay. • ITSP must support G.711 and G.723 codecs • ITSP must be verified against the MSN “Saturn” test-lab.

21. MSN Voice.NET -Technical Challenges • Billing model is not explicitly defined by MSN. - ITSP could use prepaid or postpaid - GW must be able to support either model • SIP-GW needed some new functionality - RFC2833 for DTMF-Relay - Addition for MSN-specific headers & tags - Co-existance testing with H.323 • SIP Proxy needed some new functionality - New RADIUS VSAs required - Addition for MSN-specific headers

22. SIP Billing Models • Billing relationships can be: • Retail – ITSP has a direct billing relationship with MSN / MSN users • Wholesale – Terminating ITSP will partner with a retail ASP or another ITSP and bill them for total number of minutes. ASP / partner ITSP provides subscriber billing. • Billing model can be: • Post-Paid – bill the MSN user at the end of the month for total minutes used. • Pre-Paid – deduct from a pre-paid account for minutes used on a per call basis • Billing collection point can be: • Gateways – on the edge of the network • Proxy / B2BUA - core of the network

23. H.323 vs. SIP Billing Differences ARQ GK ACF H.225, H.245, H.323 PSTN OGW TGW • RAS signaling between the GW and GK provides next-hop address resolution • VoIP signaling is direct between GWs, so TGW can bill the call off the IP Address of OGW Wholesale ITSP Retail ITSP INVITE INVITE INVITE TGW PSTN MSN User • SIP signaling is hop-by-hop between UAs and Proxies • TGW knows previous-hop as upstream Proxy. • TGW needs to look at Via:, Contact: or Record-Route headers

24. Possible Billing Models • Post-Paid on the SIP Proxy (IP Side) • Post-Paid on Egress SIP Gateway (IP Side) • Pre-Paid on the B2BUA (IP Side) • Pre-Paid on Egress SIP Gateways (IP Side) • Wholesale – Retail models

25. Post-Paid on the SIP Proxy Billing System MSN RADIUS Proxy SIP PSTN SIP SIP RTP ITSP MSN User In this model, the Billing Records would be generated by the Cisco SIP Proxy which resides in the ITSP network. It would generate RADIUS Start and Stop records for each call

26. Possible Billing Models • Post-Paid on the SIP Proxy (IP Side) • Post-Paid on Egress SIP Gateway (IP Side) • Pre-Paid on the B2BUA (IP Side) • Pre-Paid on Egress SIP Gateways (IP Side) • Wholesale – Retail models

27. Post-paid on the Egress SIP Gateway Billing System MSN RADIUS SIP Proxy PSTN SIP SIP RTP ITSP MSN User

28. Possible Billing Models • Post-Paid on the SIP Proxy (IP Side) • Post-Paid on Egress SIP Gateway (IP Side) • Pre-Paid on the SIP B2BUA (IP Side) • Pre-Paid on Egress SIP Gateways (IP Side) • SIP Wholesale – Retail models

29. Pre-paid on the SIP B2BUA Billing System MSN RADIUS SIP Proxy PSTN SIP SIP B2BUA SIP ITSP RTP

30. Possible Billing Models • Post-Paid on the SIP Proxy (IP Side) • Post-Paid on Egress SIP Gateway (IP Side) • Pre-Paid on the SIP B2BUA (IP Side) • Pre-Paid on Egress SIP Gateways (IP Side) - PrePaid TCL IVR scripts • SIP Wholesale – Retail models

31. Pre-Paid (IP Side) on the Egress SIP Gateways (TCL Script Timer) Billing System MSN RADIUS SIP Proxy PSTN SIP SIP RTP ITSP IP Phone Or Softclient “Pre- Paid” TCL-IVR Script

32. Possible Billing Models • Post-Paid on the SIP Proxy (IP Side) • Post-Paid on Egress SIP Gateway (IP Side) • Pre-Paid on the SIP B2BUA (IP Side) • Pre-Paid on Egress SIP Gateways (IP Side) • SIP Wholesale – Retail models

33. SIP Wholesale – Retail Model Billing System Wholesale ITSP MSN RADIUS Proxy SIP SIP SIP SIP Retail ITSP RTP PSTN In this model Wholesaler records where the call originated from “Previous Hop” and Bills the retailer back. This could be recorded at the Gateway or Network Proxy.

34. Agenda • SIP Architecture Overview • Overview of MSN Voice.NET • Technical Challenges • Understanding the ITSP Models • SIP Proxy requirements • SIP Gateway requirements • Network Engineering requirements

35. DGK V V Authentication Call Routing Call Routing BILL AAA How existing ITSPs are preparing forMSN Voice.NET SIP Client • Expand infrastructure capabilities to address new markets • Cisco based carriers can easily add new protocol capabilities to the core network, simultaneously supporting both H.323 and SIP on the Cisco gateways • H.323 routing information is passed from the DGK to the Cisco SIP Proxy using RAS messages • Billing records can be generated from the gateways (prepaid and postpaid) and the proxy (postpaid only) • Billing enhancements for Windows Messenger supported on IOS Gateways [12.2(2)XB] and Cisco SIP Proxy Server [Version 1.2] • Gateways are configured to handle both SIP and H.323 traffic on a dial-peer basis Application SP AAA LRQ 1212 1408

36. Agenda • SIP Architecture Overview • Overview of MSN Voice.NET • Technical Challenges • Understanding the ITSP Models • SIP Proxy requirements • SIP Gateway requirements • Network Engineering requirements

37. ITSP SIP Proxy requirements • Support for UDP or TCP calls • Support for Record-Route: header • Support for all MSN-specific headers & tags - transport=tls in Contact: header - tags on Record-Route: headers - Proxy-Authorization: header - Unknown/Unsupported codecs & attributes in the SDP fields • Support the ability to generate RADIUS records for billing. • CSPS v1.2 added support & compliance for all aspects.

38. Agenda • SIP Architecture Overview • Overview of MSN Voice.NET • Technical Challenges • Understanding the ITSP Models • SIP Proxy requirements • SIP Gateway requirements • Network Engineering requirements

39. MSN - ITSP SIP Gateway requirements • Supports UDP or TCP calls - Gateway can support either • Supports RFC2833 for DTMF-Relay • Supports MSN-specific headers & tags - transport=tls in Contact: header - tags on Record-Route: headers - Proxy-Authorization: header - Unknown/Unsupported codecs & attributes in the SDP fields • Supports either PrePaid or PostPaid billing models - PrePaid via TCL-IVR scripts and RADIUS - PostPaid via RADIUS

40. Agenda • SIP Architecture Overview • Overview of MSN Voice.NET • Technical Challenges • Understanding the ITSP Models • Call Flows • SIP Proxy requirements • SIP Gateway requirements • Network Engineering requirements

41. Network Engineering Overview • VPN Planning: - IPSec VPN is required between MSN and ITSP - MSN will use either Cisco VPN3000 or VPN5000 - ITSP VPN platform requirements are not defined by MSN. - Any compliant Cisco product could be used to terminate the VPN tunnel • IOS Router • PIX • VPN 3000/5000

42. Network Engineering Overview • Capacity Planning: - MSN has not provided Cisco with details about volume of traffic expect to specific ITSPs - SIP signaling bandwidth should be ~5kb per call. • INVITE - 1000 bytes • 100 Trying - 500 bytes • 18x Ringing - 700 bytes • 200 OK - 700 bytes • ACK - 500 bytes • BYE - 500 bytes • 100 Trying - 500 bytes • 200 OK - 500 bytes - RTP is using 20ms / 24ms samples for G.711 or G.723