voip-tutorial - Computer Science & Engineering

Internet Telephony: VoIP, SIP & more Shivkumar Kalyanaraman : “shiv kalyanaraman rpi” Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Adapted from slides of Henning Schulzrinne, Doug Moeller Overview      Telephony: history and evolution IP Telephony: What, Why & Where?  Adding interactive multimedia to the web  Being able to do telephony on IP with a variety of devices  Consumer & business markets  Key element of convergence in carrier infrastructure Basic IP telephony model Protocols: SIP, H.323, RTP, Coding schemes, Megaco Future: Invisible IP telephony and control of appliances Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2 What is VoIP? Why VoIP? Where is VoIP Today? Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3 What is VoIP?  VoIP = “Voice over IP”    Complements or replaces other Voice-over-data architecture     Transmission of telephony services via IP infrastructure => need history/concepts reg. both “telephony” (or “voice”) and “IP” Voice-over-TDM Voice-over-Frame-Relay Voice-over-ATM First proprietary IP Telephony implementations in 1994, VoIP-related standards available 1996   Buzzwords related to VoIP: H.323 v2, SIP, MEGACO/H.248, Sigtrans Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 4 What is VoIP? Protocol Soup “The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year’s model.” [Tanenbaum] H.GCP H.245 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5 Telephony over IP standards bodies       ITU - International Telecommunication Union  http://www.itu.org IETF - Internet Engineering Task Force.  http://www.ietf.org ETSI - European Telecommunications Standards Institute  http://www.etsi.org/tiphon ANSI - American National Standards Institute  http://www.ansi.org TIA - Telecommunications Industry Association  http://www.tiaonline.org IEEE - Institute for Electrical and Electronics Engineers  http://www.ieee.org Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6 Why VoIP? Telephony: Mature Industry AT&T Divestiture Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7 Why VoIP: Price/call plummeting due to overcapacity AT&T Divestiture 1996 deregulation Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8 Relevant Telecom Industry Trends    1984: AT&T breakup: baby bells vs long distance carriers 1996: Telecom deregulation, Internet takeoff Late 1990s: explosion of fiber capacity in long-distance + many new carriers        Long-distance prices plummet Despite internet, the last-mile capacity did not grow fast enough 2000s: shakeout & consolidation in developed countries Wireless substitution in last mile => cell phone instead of land-lines  Developing countries leap frog to cell phones  3G, WiMax => broadband, VoIP & mobility Broadband rollouts happening slowly, but picking up steam now. Cable offering converged & bundled services:  digital cable, VoIP, video Recent mergers: AT&T (long-distance & data network provider) bought by SBC (baby bell); Verizon/Qwest vs MCI saga… Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9 Why VoIP ? Data vs Voice Traffic Note: quantity  quality  value-added Interactive svcs (phone, cell, sms) still dominate on a $$-per-Mbps basis Infrastructure convergence: Since we are building future networks for data, can we slowly junk the voice infrastructure and move over to IP? Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10 Trends: Total Phone vs Data Revenues Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11 Motivations and drivers Class-4/5 switches bulky, expensive. Incentive to switch to cheaper easily managed IP Voice PSTN Class 4 switch Class 5 switch Users Class 5 switch ISDN Switch Data Initial gateway between PSTN and Internet was H.323. Gateway did signaling, call control, translation in one box. Not scalable. Users H.323 gateway Packet networks Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12 Voice Over IP Marketplace Drivers        Rate arbitrage declining but still has importance as cost driver  TDM origination and termination with IP transport in the WAN  International settlement and domestic access cost avoidance Enterprises seeking to save on intra-company calls and faxes on converged network Emergence of native IP origination environments  IP PBX, IP Phones, Soft Phones, Multimedia on the LAN  3G Wireless, Broadband Networks Companies: web-based call centers/web callback/e-commerce with IP Enablement New network-based IP features and services  Hosted IP PBX/IP Centrex , Unified Messaging, Multimedia Conferencing  Presence: Mobility, Follow me, Teleworker, Voice Portal Services, WiFi Technology maturing with open standards for easier, faster innovation Converging Local, long-distance (LD) and data services Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 13 VoIP Volumes Are Accelerating While Adoption of Applications is Growing M of Minutes VoIP VPN Traffic Enterprise Adoption of VoIP / IPT Applications 200000 180000 160000 140000 120000 100000 80000 60000 40000 20000 0 Respondents 2001 2002 2003 2004 North America M of Minutes 2005 2006 2007 Rest of the World Virtual PBX + Managed IP PBX traffic 350000 300000 Source: Giga Group, "Next Generation IP Telephony Applications Deliver Strategic Business Value", October 20, 2003 250000 200000 • 150000 100000 50000 0 2001 2002 2003 2004 North America 2005 2006 2007 • Rest of the World Source: Probe Research Inc.: Reaching the Big Guys + Global Enterprise Forecast. September 2002 VoIP VPNs will continue to be driven by increased IPT deployments in larger enterprises, coupled with economic benefits accruing, especially for MNCs IPT Deployments are the leading edge market driver for the development of converged LANs and WANs Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 14 Drivers Are Evolving From Cost Savings to Added Business Value… Cost Savings • Toll By-Pass • Effective Use of Bandwidth • Personnel / Staffing Efficiencies • Less Expensive Moves, Adds Changes • Convergence / Consolidation • Decreased Capital • Upgrading to an IP PBX Percentage IP Phones Performing Functions Other Than POTS Increased Investment Protection • Contact Center Functions • Future Proofing Infrastructure • Leveraging embedded infrastructure with a phased roll-out • Networking Expertise for Integration From Concept to Deployment Business Case Justification Based on Cost Savings Business Case Justification Based on Investment Protection Business Case Justification Based on Business Value V2 Apps V1 Apps 2002 2003 2004 2005 V3 Apps 2006 2007 2008 V1 Apps - e.g. IP-PBX, Basic Call Functions, Branch offices, Toll-bypass V2 Apps - e.g. Call Center Functions, Messaging, Administration Tools and Reports V3 Apps - e.g. Unified Communications, Application Integration With Communications Gartner Group, Sept. 16, 2003 Optimized Business Value • Services over IP • Consistent Client / User Experience • Integrated Infrastructure • End-to-End Interoperability Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15 Summary: Why VoIP?  Cost reduction: Toll by-pass  WAN Cost Reduction  Lowered Infrastructure Costs   Operational Improvement: Simplification of Routing Administration  LAN/Campus Integration  Policy and Directory Consolidation   Business Tool Integration: Voice mail, email and fax mail integration  Mobility enabled by IP networking  Web + Overseas Call Centers  Collaborative applications  New Integrated Applications  3Cs: “Convergence” & “Costs” & “Competition” Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 16 Where is VoIP? Consumer VoIP Markets  Convergence & Competition  Vonage: pure VoIP CLEC (300K subscribers)  Cable companies:  Eg: Time Warner (220K subscribers and signing on 10K per week (end of 2004)):  Bundled with digital cable services  Skype (computer-computer p2p VoIP): tens of millions…  Also has a WiFi service & a product co-developed by Motorola (over 3G networks)  Long-distance providers: AT&T CallVantage  Local (ILECs): Verizon  Future: convergence of VoIP + WiMax (802.16) as a open low-cost competitor to 3G wireless (closed system)  Combines: broadband Internet, mobility and VoIP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 17 Consumer VoIP over broadband Broadband Infrastructure Residential Media Gateway Media Gateway Controller Traditional phone Signaling and media gateways To reach PSTN or other networks Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 18 Consumer VoIP at home with cable PacketCable standard with DOCSIS 1.1 access infrastructure Call Management Server Cable Modem Term. Sys. Media Gateway MGC Signaling Gateway Cable Modem MTA (Media Terminal Adapter) Rensselaer Polytechnic Institute Shivkumar Kalyanaraman Other access mechanisms will similarly hand over to an MGC 19 Consumer VoIP: AT&T CallVantage  New consumer services:  Personal conferencing: earlier available to businesses only  Prepaid Calling cards offering personal conferencing  Portable TA (terminal adaptor): can plug into any ethernet jack or WiFi (eg: many hotels providing free internet)  Universal messaging: voice messages in email  LocateMe,  Do-Not-Disturb,  Unified Portal Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 20 Skype: p2p VoIP over Internet    Skype is entirely peer-topeer and is equivalent to two H.323 terminals or 2 SIP terminals talking to each other  Provides a namespace  Efficient coding of voice packets Instant messaging with voice Uses Kazaa-like p2p directory + secure authentication (login server) and e2e encryption Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 21 VoIP over Wireless  Cellular networks with 2.5G and 3G have packet services  1xRTT on 2.5 G  EV-DO on 3G  The voice on these networks is circuit switched voice…  However, …    Combined with bluetooth or USB interfaces, a PC-based VoIP software can do VoIP anywhere there is cellular coverage. Or Cellphone can be a SIP terminal Near Future: VoIP over WiMax (802.16) and WiFi (802.11) networks Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 22 Enterprise: Private Branch Exchange (PBX) Post-divestiture phenomenon... 7040 212-8538080 External line 7041 Corporate/Campus Private Branch Exchange Telephone switch Another switch 7042 7043 Corporate/Campus LAN Internet Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 23 Enterprise VoIP: Yesterday’s networks Circuit Switched Networks (Voice) CO PBX PBX CO CO Headquarters Branch Offices Router Router Router Router Router Packet Switched Networks (IP) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 24 Enterprise VoIP: Today’s networks Toll by-pass Circuit Switched Networks (Voice) PBX CO PBX CO Headquarters CO Branch Offices Router Router Router Router Router Packet Switched Networks (IP) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 25 Enterprise VoIP: Tomorrow’s networks Unified/Converged Networks CO CO Legacy PSTN Router Router Router Router Router Unified Networks (Voice over IP) Headquarters Branch Offices Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 26 AT&T’s Integrated Infrastructure Supports Multiple Endpoints, Access Technologies and Application Services • VoIP infrastructure is Voice Applications: IP Centrex, IP Call Center and Distant Worker • AT&T Call Control Element • Common VoIP Connectivity Layer NG Border Elements SIP Border Elements H.323 Border Elements • MGCP Border Elements • IP/MPLS Converged Network • PSTN SIP endpoints H.323 endpoints MGCP endpoints • converged onto a single IP/ MPLS network Open standards architecture based on SIP protocol Call Control Element manages all SIP signaling within our core network Access Agnostic: TDM, ATM, Frame, MIS, IP Enabled Frame and EVPN Border Elements: “translate” the multiple protocols into SIP, provide compression and security Provides secure, integrated voice / data / video access Flexibility to support future applications Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 27 VoIP Network Utilities Ensure Seamless Operations  Outbound Call • IP to Circuit Switched Circuit Switched Network  Inbound Call Network Adjunct • Circuit Switched to IP Customer Records  800 Call • Circuit Switched to IP App. Server Media Server App. Server Gateway  Redirect Call Softswitch • Circuit Switched to IP IP Network  SDN Call • IP to Circuit Switched Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 28 IP-enabled circuit switches PBX with VoIP trunk card  trunk between PBX  Key system or PBX with VoIP line card  for IP phones  VoIP Gateway CO Switch Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 29 Telephony-enabled packet networks Enterprise Router with telco interfaces  T1/PRI  BRI  Branch office router with telco interfaces  BRI  Analog trunk/line  Analog “dongle”  a few analog lines for fax/phone  Central Office VoIP Gateway Router Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 30 VoFR (Voice over Frame Relay) FRF.11 standard  Allows for G.711, 729, 728, 726, and 723.1  Signaling is done by transporting CAS natively or CCS as data  Has support for T.30 Fax, and Dialed Digits natively  Router Switch PBX VFRAD VFRAD PBX Switch Switch Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 31 Voice over Packet: Market Forecast – North America Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 32 Telephony: History, Review & Trends Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 33 VoIP: Where Does it Fit in Trends ?  Phase 1: Analog Networks:   Voice carried as analog signal Phase 2: Digital Networks & the rise of the Internet    Network is digital: analog conversion at end systems Benefits: [Noise , capacity] Egs: TDM and T-hierarchy (T1, T3, SONET etc)  Used as the base for the internet & private data networks  Phase 3: Voice-over-X:  Voice over Packets: VoFR, VoIP  Key: Voice moves to a higher layer (from layer 1)  I.e. an app over a frame relay, ATM or IP network VoIP Sales pitch: Convergence, Choice, Services, Integration with Web applications [Better chance of convergence compared to earlier attempts: ISDN, BISDN]   Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 34 Public Telephony (PSTN) History 1876 invention of telephone  1915 first transcontinental telephone (NY–SF)  1920’s first automatic switches  1956 TAT-1 transatlantic cable (35 lines)  1962 digital transmission (T1)  1965 1ESS analog switch  1974 Internet packet voice  1977 4ESS digital switch  1980s Signaling System #7 (out-of-band)  1990s Advanced Intelligent Network (AIN)  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 35 PSTN Evolution Full Mesh Office Switched Office Switched W/ Hierarchy Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 36 AT&T Telephony Hierarchy 3 4 5 2 7 10 9 1 2 1 2 2 65 3 66 228 3 3 Class 1 8 3 2 1 1 10 regional offices (full mesh) 6 1 229 67 230 1298 1299 1300 4 5 19,000 200 million telephones 67 sectional offices Class 2 230 primary offices Class 3 1300 toll offices Class 4 19,000 end offices Class 5 Source: Computer Networks, Andrew S. Tanenbaum Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 37 PSTN early days 40s-60s 1. In-band signaling: voice and control channel same 2. Complex and dedicated hardware 3. Hard to add new apps like caller-id, 800 calling etc Tandem Office Local Office Local Office User A User B Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 38 Advanced Intelligent Network •Out-of-band signaling •Introduce adv services like caller-id easily •Reduced wastage of circuits in voice network •Signaling could be over a packet network •E.g. SS7 stack Signaling Network Voice Network Customer Info for Advanced services Local Office User A User B Sometimes also called Intelligent Network, arrival of services other Kalyanaraman than voice Shivkumar Rensselaer Polytechnic Institute 39 The PSTN – Architecture    PSTN – Public Switched Telephone Network Uses digital trunks between Central Office switches (CO) Uses analog line from phones to CO Analog line Digital Trunks Central Office (CO) Analog Digital Rensselaer Polytechnic Institute 40 Analog Shivkumar Kalyanaraman The PSTN – Digitization    Voice frequency is 100 - 5000 Hz, with the main portion from 300 – 3400 Hz Nyquist Theorem states that sampling must be done at twice the highest frequency to recreate. 4000 Hz was chosen as the maximum frequency, thus sampling at 8000 Hz PCM = 8kHz * 8 bits per sample = 64 kbit/s Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 41 Quantization Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 42 Companding Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 43 The PSTN – Digitization The PCM encoding used in the PSTN is standardized as G.711 by the ITU  Each sample is represented by one byte  The voice signal is companded to improve voice quality at low amplitude levels (Which most conversation is at)  The ITU standards for companding are called A-law and u-law  G.711 A-law is used in Europe  G.711 -law is used in the US and Japan  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 44 The PSTN – Digital Voice Transmission    The digital trunks between the COs are based upon the Tcarrier system, developed in the 1960s Each frame carries one sample (8 bits) for each 24 channels, plus one framing bit = 193 bits 193 * 8000 (samples/sec) = 1.544 Mbit/sec = T-1 Channel 1 Channel 2 … Channel 3 Framing Bit TDM Channel 1 Channel 2 Channel 3 … Channel 24 Channel 24 1 D4 Frame Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 45 The PSTN – Architecture, Switches     PSTN – Public Switched Telephone Network As the name says, it’s switched… Each conversation requires a channel switched throughout the network Circuit setup uses a separate out-of-band intelligent network (SS7) 1. Call is requested 3. Channel is established 2. Call is accepted Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 46 Legacy Digital Circuit Switch SS7 Network • • • • Centralized Intelligence Proprietary Code Proprietary service deployment Switch Controller Line Card Trunk Card Next Switch Line Card Trunk Card Next Switch Line Card Trunk Card Next Switch Very expensive Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 47 What’s the difference between a Class 5 and a Class 4 switch? Class 5  Located at the edge of the network  Trunk to Line/Line to Line  Aprox. 30,000 deployed  Services: Caller ID, call waiting, voice mail, E911, billing, etc.  Ex: Lucent 5ESS, Nortel DMS, Siemens EWSD Class 4  Located in the Core of the network  Trunk to Trunk  Aprox. 800 deployed  Services: call routing, screening, 800 services, calling cards, etc.  Ex: Lucent 4ESS, Nortel DMS, Siemens Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 48 The PSTN – NANP     NANP – North American Numbering Plan 3 digits area code + 3 digits office code + 4 digits phone Each Local Exchange Carrier (LEC) switch are assigned a block of at least 10,000 numbers The Inter-Exchange Carrier (IXC) switches are responsible for transmitting long distance PSTN 4210 IXC 212 LEC 555 (212) 555 4210 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 49 The PSTN – Call Routing  Both NANP and International Numbering Plan – E.164, use prefix-based dialing SS7 408 PSTN 1+212+555+5644 212 5644 555 555+5644 5644 The first LEC receives a call, seeing ‘1’ as the first digit and then passing the call on to the IXC switch. The IXC then routes the call to the remote IXC responsible for ‘212’ The ‘212’ IXC looks at the office code and passes it on to the ‘555’ LEC switch The ‘555’ LEC switch then checks the station code and signals the appropriate phone Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 50 Telephone System Summary Analog narrowband circuits: home-> central office  64 kb/s continuous transmission, with compression across oceans  -law: 12-bit linear range -> 8-bit bytes  Everything clocked a multiple of 125 s  Clock synchronization  framing errors  AT&T: 136 “toll”switches in U.S.  Interconnected by T1, T3 lines & SONET rings  Call establishment “out-of-band” using packetswitched signaling system (SS7)  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 51 Telecommunications Regulation History  FCC regulations cover telephony, cable, broadcast TV, wireless etc  “Common Carrier”: provider offers conduit for a fee and does not control the content   Customer controls content/destination of transmission & assumes criminal/civil responsibility for content Local monopolies formed by AT&T’s acquisition of independent telephone companies in early 20th century    Regulation forced because they were deemed natural monopolies (only one player possible in market due to enormous sunk cost) FCC regulates interstate calls and state commissions regulate intra-state and local calls Bells + 1000 independents interconnected & expanded Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 52 Deregulation of telephony  1960s-70s: gradual de-regulation of AT&T due to technological advances  Terminal equipment could be owned by customers (CPE) => explosion in PBXs, fax machines, handsets  Modified final judgement (MFJ): breakup of AT&T into ILECs (incumbent local exchange carrier) and IXC (interexchange carrier) part Long-distance opened to competition, only the local part regulated…  Equal access for IXCs to the ILEC network  1+ long-distance number introduced then…  800-number portability: switching IXCs => retain 800 number  1995: removed price controls on AT&T  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 53 US Telephone Network Structure (after 1984) Eg: AT&T, Sprint, MCI Eg: SBC, Verizon, BellSouth Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 54 Telecom Act of 1996  Required ILECs to open their markets through unbundling of network elements (UNE-P), facilities ownership of CLECs….   Today UNE-P is one of the most profitable for AT&T and other longdistance players in the local market: due to apparently below-cost regulated prices… ILECs could compete in long-distance after demonstrating opening of markets Only now some ILECs are aggressively entering long distance markets  CLECs failed due to a variety of reasons…  But long-distance prices have dropped precipitously (AT&T’s customer unit revenue in 2002 was $11.3 B compared to 1999 rev of $23B) ILECs still retain over 90% of local market Wireless substitution has caused ILECs to develop wireless business units VoIP driven cable telephony + wireless telephony => more demand elasticity for local services     Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 55 VoIP Technologies Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 56 IP Telephony Protocols: SIP, RTP  Session Initiation Protocol - SIP Contact “office.com” asking for “bob”  Locate Bob’s current phone and ring  Bob picks up the ringing phone   Real time Transport Protocol - RTP  Send and receive audio packets Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 57 Inside the Endpoint: Data-plane   … I.e.after signaling is done… Consists of three components: User A/D Codec User speaks into microphone, either PC attached, regular analogue phone or IP phone Device digitizes voice according to certain codecs: G.711 / G.723.1 / G.729 ... IP Gateway Voice gets transmitted via RTP over an IP infrastructure Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 58 Internet Multimedia Protocol Stack Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 59 Packet Encapsulation RTP datagram Version, flags & CC Payload Type 1 1 Sequence Number Synchronization Source ID Timestamp 2 4 CSRC ID (if any) Codec Data 0-60 0-1460 4 UDP datagram Source Port Number Destination Port Number 2 2 Version & header length 1 UDP length 2 Total Length 1 2 Packet ID 2 Ethernet Frame Inter-frame gap Preamble 12 7 Flags & TTL Frag Offset 2 2 1 Header Checksum 1 Source Address 2 Destination Address 4 Start of frame delimiter 0-1472 Options (if any) 4 Data 0-40 0-1480 Length or Ethertype Destination Address 1 Data Protocol IP packet TOS UDP checksum 6 Source Address 6 Data 2 0-1500 Pad Checksum 0-46 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 60 4 RTP – Real-time Transport Protocol RTP datagram Version, flags & CC Payload Type 1 1 Sequence Number 2 Timestamp 4 Synchronization Source ID 4 CSRC ID (if any) Codec Data 0-60 0-1460 Byte 1: Version number, padding yes/no, extension y/n, CSRC count  Byte 2: Marker, Payload type  Bytes 3,4: Sequence number for misordered and lost packet detection  Bytes 5-8: Timestamp of first data octet for jitter calculation  Bytes 9-12: Random syncronization source ID  Bytes 13-x: Contributing Source ID for payload  Codec Data: the actual Voice or Video bytes  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 61 RTCP – Real-time Transport Control Protocol    RTCP is sent between RTP endpoints periodically to provide:  Feedback on quality of the call by sending jitter, timestamps, and delay info back to sender  Carry a persistent transport-level identifier called the canonical name (CNAME) to keep track of participants and synchronize audio with video  Carry minimal session information (like participant IDs), although signaling protocols do this much better RTCP is mandatory for multicast sessions and for many pointto-point protocols, but some boxes don’t implement it Uses another UDP port (usually RTP’s port + 1) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 62 SIP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 63 Signaling: VoIP Camps Conferencing Industry Netheads “IP over Everything” Circuit switch engineers “We over IP” “Convergence” ITU standards H.323 SIP “Softswitch” BICC ISDN LAN conferencing I-multimedia WWW Call Agent SIP & H.323 BISDN, AIN H.xxx, SIP IP IP IP “any packet” Rensselaer Polytechnic Institute Our focus 64 Shivkumar Kalyanaraman H.323 vs SIP    H.323: ITU standard  Derived from telephony protocol (Q.931)  Follows ISDN model: same control message sequences  Interfaces well with telephony services (H.450, Q.SIG) SIP: IETF standard  Derived from HTTP style signaling,  Simple and interfaces well with IP networks, instant messaging (IM)  Services are not explicitly exposed to protocol  Well-defined methods can be used to design services: most telephony services have analogs in the SIP world today SIP is gathering market share rapidly Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 65 SIP Audio Codec Video Codec G.711 H.261 G.723 H.263 G.729 RTP SIP TCP RTCP UDP IP LAN Interface Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 66 SIP functionality IETF-standardized peer-to-peer signaling protocol (RFC 2543):  Locate user given email-style address  Setup session (call)  (Re)-negotiate call parameters  Manual and automatic forwarding  Personal mobility: different terminal, same identifier  Call center: reach first (load distribution) or reach all (department conference)  Terminate and transfer calls  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 67 SIP Addresses Food Chain Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 68 Why is SIP interesting?  SIP is IETF’s equivalent for H.323 to provide a peer-based signaling protocol for session setup, management and teardown  Simple, did not inherit the complexity of ISDN  Analogy: CISC architecture  Though all services arent defined as in H.323, you can compose them with primitives  Was designed with multimedia in mind  Just requires a MIME type  Tremendous flexibility – can add video, text etc to a voice session, similar to what HTTP did to Internet content  Like H.323, can use SIP end-to-end with no network infrastructure (MGC etc.) – peer-to-peer Lightweight  can be embedded in small devices like handhelds  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 69 IP SIP Phones and Adaptors 1 Are true Internet hosts • Choice of application • Choice of server Analog phone adaptor 2 • IP appliances Implementations • 3Com (3) 3 • Columbia University Palm control • MIC WorldCom (1) • Mediatrix (1) • Nortel (4) • Siemens (5) 44 5 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 70 SIP: Personal Mobility Users maintain a single externally visible identifier regardless of their network location Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 71 Expand existing PBXs w/ IP phones  Transparently … Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 72 SIP as Event Notification Protocol Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 73 SIP: Presence Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 74 Light-weight signaling: Session Initiation Protocol (SIP) IETF MMUSIC working group  Light-weight generic signaling protocol  Part of IETF conference control architecture:  SAP for “Internet TV Guide” announcements  RTSP for media-on-demand  SDP for describing media  others: malloc, multicast, conference bus, . . .  Post-dial delay: 1.5 round-trip time (with UDP)  Network-protocol independent: UDP or TCP (or AAL5 or X.25)  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 75 SIP components UAC: user-agent client (caller application)  UAS: user-agent server: accept, redirect, refuse call  redirect server: redirect requests  proxy server: server + client  registrar: track user locations  user agent = UAC + UAS  often combine registrar + (proxy or redirect server)  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 76 SIP-based Architecture rtspd Quicktime RTSP media server RTSP sipconf Telephone SIP conference server Telephone switch RTSP clients sipum SIP/RTSP Unified messaging Web server sipd T1/E1 RTP/SIP Web based configuration SIP proxy, redirect server SQL database e*phone Cisco 2600 gateway Hardware Internet (SIP) phones sipc NetMeeting sip323 SIPH.323 convertor Software SIP user agents H.323 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 77 Example Call • Bob signs up for the service from the web as “bob@ecse.rpi.edu” • He registers from multiple phones • sipd canonicalizes the destination to sip:bob@ecse.rpi.edu • sipd rings both e*phone and sipc • Bob accepts the call from sipc and starts talking • Alice tries to reach Bob INVITE ip:Bob.Wilson@ecse.rpi.edu Web based configuration sipd SIP proxy, redirect server Call Bob SQL database Web server e*phone Hardware Internet (SIP) phones sipc ecse.rpi.edu Software SIP user agents Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 78 SIP Sessions         “Session”: exchange of data between an association of participants Users may move between endpoints Users may be addressable by multiple names Users may communicate in several different media SIP: enables internet endpoints to  Discover each other  Characterize the session Location infrastructure: proxy servers, invite/register…  Name mapping and redirection services Add/remove participants from session Add/remove media from session Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 79 SIP Capabilities      User location: determination of the end system to be used for communication; User availability: determination of the willingness of the called party to engage in communications; User capabilities: determination of the media and media parameters to be used; Session setup: "ringing", establishment of session parameters at both called and calling party; Session management: including transfer and termination of sessions, modifying session parameters, and invoking services. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 80 What SIP is not…    SIP is not a vertically integrated communications system.  It is a component in a multimedia architecture. SIP does not provide services.  Rather, SIP provides primitives that can be used to implement different services.  For example, SIP can locate a user and deliver an opaque object to his current location. SIP does not offer conference control services  … such as floor control or voting  SIP does not prescribe how a conference is to be managed. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 81 SIP Structure  3 “layers”, loosely coupled, fairly independent processing stages Lowest layer: syntax, encoding (augmented BNF) Second layer: transport layer.  Defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network. Third layer: transaction layer.  A transaction is a request sent by a client transaction (using the transport layer) to a server transaction …  …along with all responses to that request sent from the server transaction back to the client.  The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts  The layer above the transaction layer is called the transaction user (TU).    Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 82 SIP Design Choices Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 83 Proxy Server 1. INVITE sip:president@us.gov SIP/2.0 From: sip:tony@parliament.uk 2. INVITE sip:dcheney@wh SIP/2.0 From: sip:tony@parliament.uk 3. SIP/2.0 200 ok From: sip:dcheney@wh parliament.uk Location Server george.w.bush 1&5 tony@parliament.uk us.gov 4 2&6 4. SIP/2.0 100 OK From: sip:president@us.gov Proxy server dcheney@wh 3 5. ACK sip:president@us.gov SIP/2.0 From: sip:tony@parliament.uk 6. ACK sip:dcheney@wh SIP/2.0 From: sip:tony@parliament.uk Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 84 Redirect Server us.gov parliament.uk george.w.bush Location Server 1&3 2 tony@parliament.uk dcheney@wh.us.gov Redirect Server 4&6 5 1. INVITE sip:president@us.gov From: sip:tony@parliament.uk 2. SIP/2.0 320 Moved temporarily Contact: sip:dcheney@wh.us.gov 3. ACK sip:president@us.gov From: sip:tony@parliament.uk 4. INVITE sip:dcheney@wh.us.gov6. ACK sip:dcheney@wh.us.gov From: tony@parliament.uk From: sip:tony@parliament.uk 5. SIP/2.0 200 OK To: tony@parliament.uk Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 85 SIP Call Signaling Assumes Endpoints(Clients) know each other’s IP addresses SIP Endpoint Signaling Plane SIP Gateway Invite 180 Ringing 200 OK SIP + SDP (TCP or UDP) Ack Bearer Plane RTP Stream RTP Stream RTCP Stream Media (UDP) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 86 PSTN to IP Call PBX PSTN External T1/CAS 1 Call 9397134 Gateway Internal T1/CAS (Ext:7130-7139) 2 Call 7134 Ethernet Regular phone (internal) 5 3 SIP server SQL database sipd sipc Bob’s phone 4 7134 => bob Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 87 IP to PSTN Call PBX PSTN External T1/CAS 5 Call 5551212 Gateway (10.0.2.3) Internal T1/CAS 4 Call 85551212 3 Ethernet 5551212 Regular phone (internal, 7054) 1 Bob calls 5551212 SIP server sipc 2 SQL database sipd Use sip:85551212@10.0.2.3 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 88 Traditional voice mail system Dial 853-8119 Alice 939-7063 Phone is ringing Bob 853-8119 .. The person is not available now please leave a message ... ... Your voice message ... Disconnect Bob can listen to his voice mails by dialing some number. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 89 SIP-based Voicemail Architecture Bob INVITE bob@phone1.office.com phone1.office.com INVITE bob@office.com REGISTER bob@vm.office.com Alice INVITE bob@vm.office.com vm.office.com The voice mail server registers with the SIP proxy, sipd Alice calls bob@office.com through SIP proxy. SIP proxy forks the request to Bob’s phone as well as to a voicemail server. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 90 Voicemail Architecture Bob phone1.office.com; CANCEL 200 OK Alice 200 OK RTP/RTCP After 10 seconds vm contacts the RTSP server for recording. vm accepts the call. Sipd cancels the other branch and ... ...accepts the call from Alice. Now user message gets recorded Rensselaer Polytechnic Institute 91 v-mail vm.office.com; SETUP rtspd Shivkumar Kalyanaraman IETF SIP Architecture Tour: Roundup PSTN, ISDN, ATM, etc Registrar & Proxy or Redirect Server *Gateway *User Agent *User Agent *User Agent *Endpoints Media streams: RTP/RTCP (G.911, G.723.1, … ) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 92 IETF SIP Architecture Tour: Roundup PSTN, ISDN, ATM, etc Registrar & Proxy or Redirect Server *Gateway System Management • admission control User Agent • address translation/forwarding • Firewall bypassing Interface to non-IP or H.323 networks *Endpoints * *User Agent *User Agent Media streams: RTP/RTCP (G.911, G.723.1, … ) Conferencing does not need another box (MCU) End-user devices and network proxies Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 93 IETF SIP Architecture Tour: Roundup Registrar & Proxy or Redirect Server *Gateway PSTN, ISDN, ATM, etc *User Agent *User Agent *User Agent *Endpoints Media streams: RTP/RTCP (G.911, G.723.1, … ) Components of the SIP protocol suite: • • • • SIP SDP DNS RSVP = = = = almost all signaling, optional services, etc. negotiation/capabilities address translation QoS bandwidth guarantee Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 94 SDP: Session Description Protocol  Not really a protocol – describes data carried by other protocols  Used by SAP, SIP, RTSP, H.332, PINT. Eg: v=0 o=g.bell 877283459 877283519 IN IP4 132.151.1.19 s=Come here, Watson! u=http://www.ietf.org e=g.bell@bell-telephone.com c=IN IP4 132.151.1.19 b=CT:64 t=3086272736 0 k=clear:manhole cover m=audio 3456 RTP/AVP 96 a=rtpmap:96 VDVI/8000/1 m=video 3458 RTP/AVP 31 m=application 32416 udp wb Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 95 Upcoming SIP Extensions (probable)              Call Admission Control Caller Preferences and Callee Capabilities Call Transfer SIP to ISUP mapping SIP to H.323 mapping Resource Management (QoS preconditions) Caller/Callee Name Privacy SIP Security Supported Options Header Session Timer Refresh Distributed Call State 3rd Party Call Control Early media for PSTN interoperability  There  are currently 47 drafts in the pipeline! 174 Drafts have expired Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 96 SIP Dialogs (RFC 3261)       A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag. A dialog contains certain pieces of state needed for further message transmissions within the dialog. Note: dialog is within SIP whereas sessions are outside SIP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 97 UPDATE method (RFC 3311)    INVITE method: initiation and modification of sessions.  INVITE affects two pieces of state: session (the media streams SIP sets up) and dialog (the state that SIP itself defines). Issue: need to modify session aspects before the initial INVITE has been answered.  A re-INVITE cannot be used for this purpose: impacts the state of the dialog, in addition to the session.  Ans: The UPDATE method Operation: (Offer/Answer model)  The caller begins with an INVITE transaction, which proceeds normally.  Once a dialog is established, either early or confirmed, …  … the caller can generate an UPDATE method that contains an SDP offer for the purposes of updating the session.  The response to the UPDATE method contains the answer.  Similarly, once a dialog is established, the callee can send an UPDATE offer Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 98 Locating SIP Servers (RFC 3263)  UA  Proxy  Remote Proxy  UA  I.e Go via proxies (per-domain)  Issue: need to locate remote proxy (use DNS)  DNS NAPTR (type of server) and SRV (server URL) queries are used to locate the specific servers.  Different transport protocols can be used (TLS+TCP, TCP, UDP, SCTP) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 99 SIP for instant messaging: IM (RFC 3428)    IM: transfer of (short) messages in near real-time, for conversational mode.  Current IM: proprietary, server-based and linked to buddy lists etc MESSAGE method: inherits SIP’s request routing and security features  Message content as MIME body parts  Sent in the context of some SIP dialog  (note: slightly different from pager mode: asynchronous)  Sent over TCP (or congestion controlled transports): lots of messaging volumes… Allows IM applications to potentially interoperate and also provides SIP-based integration with other multimedia streams. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 100 SIP compression (RFC 3486)   Cannot use DNS SRV and NAPTR techniques: non-scalable (only useful for specifying transport protocol options) Use an application-level exchange to specify compression of signaling info sip:alice@atlanta.com;comp=sigcomp  Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp SIGCOMP is the compression protocol   Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 101 Device Configuration Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 102 SIP Scaling Issues Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 103 SIP Scaling (contd) SIP Load Characteristics: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 104 H.323 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 105 SIP vs H.323 vs Megaco Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 106 H.323 vs SIP Typical UserAgent Protocol stack for Internet Terminal Control/Devices Q.931 H.245 RAS RTCP TPKT TCP Terminal Control/Devices Codecs Codecs SIP SDP RTP RTCP RTP UDP Transport Layer IP and lower layers Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 107 SIP versus H.323 H.323 and SIP are direct competitors in peer-level call control space H.323 SIP Stds Body • ITU-T SG-16 • IETF SIP Properties • Complex, monolithic design • Difficult to extend & update • Based on H.320 conferencing and ISDN Q.931 legacy (“Bell headed”) • Powerful for video-conferencing • Modular, simplistic design • Easily extended & updated • Based on Web principals (“Internetfriendly”) • Readily extensible beyond telephony Stds Status (end device) • H.450.x series provides minimal feature set only, and not implemented by many • Options and versions cause interop problems • Slow moving • Few real end-device features standard, and not implemented by many • Many options for advanced telephony features • Good velocity Industry Acceptance • Established now, primarily system level • Few H.323-based telephones • End-user primarily driven by Microsoft (NetMeeting), Siemens, Intel • Rapidly growing industry momentum, at system and device level • Growing interest in SIP-phones and soft clients Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 108 SIP-H.323: Interworking Problems Eg: Call setup translation H.323 SIP Q.931 SETUP Q.931 CONNECT INVITE Destination address (Bob@office.com) 200 OK Terminal Capabilities Terminal Capabilities Open Logical Channel Open Logical Channel Media capabilities (audio/video) ACK Media transport address (RTP/RTCP receive) • H.323: Multi-stage dialing Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 109 H.323 Standard Series System Control H.245 Control Audio Codec Video Codec G.711 H.261 G.723 H.263 G.729 Data Interface T.120 H.225 Call Setup RTP RAS Gatekeeper TCP RTCP UDP IP LAN Interface Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 110 Internet Telephony Protocols: H.323 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 111 H.323 (contd)  Terminals, Gateways, Gatekeepers, and Multipoint Control Units (MCUs) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 112 H.323 Model - Gatekeeper Routed Call Gatekeeper Voice Channel Endpoint Gateway Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 113 H.323 Model - Gatekeeper Direct Call Gatekeeper RAS RAS Call Setup/Signaling Call Control Voice Channel Endpoint Gateway Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 114 H.323 Call Signaling Assumes Endpoints(Clients) know each other’s IP addresses H.323 Endpoint Setup Alerting H.323 H.225 (TCP) Gateway (Q.931) Connect Terminal Capability Set Signaling Plane Terminal Capability Set & Acknowledge Terminal Capability Set Acknowledge Open Logical Channel H.245 (TCP) Open Logical Channel & Acknowledge Open Logical Channel Acknowledge Bearer Plane Rensselaer Polytechnic Institute RTP Stream RTP Stream RTCP Stream Media (UDP) H.323v1 (5/96) - 7 or 8 Round Trips H.323v2 Fast Start (2/98) - 2 Round Trips Shivkumar Kalyanaraman 115 ITU-T H.323 Architecture Tour PSTN, ISDN, ATM, etc Gate Keeper (GK) *Gateway (GW) *Multipoint Control Unit (MCU) Multipoint Multipoint Controller Processor (MC) (MP) *Endpoints *Terminal *Terminal *Terminal Media streams: RTP/RTCP (G.911, G.723.1, … ) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 116 ITU-T H.323 Architecture Tour PSTN, ISDN, ATM, etc Gate Keeper (GK) *Gateway (GW) *Multipoint Control Unit (MCU) Multipoint Multipoint Interface to Processor Controller (MC) (MP) non-IP networks *Endpoints System Management • zone management • b/w management Terminal & Terminal Terminal admission control • address translation • centralized control (“gatekeeper control Media streams: RTP/RTCP (G.911, G.723.1, … ) mode”) * * * Conferencing End-user devices and network proxies Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 117 ITU-T H.323 Architecture Tour PSTN, ISDN, ATM, etc Gate Keeper (GK) *Gateway (GW) H.225.0 RAS H.225.0 CS H.245 CC H.450.x SS *Multipoint Control Unit (MCU) Multipoint Multipoint Controller Processor (MC) (MP) *Endpoints *Terminal *Terminal *Terminal Media streams: RTP/RTCP (G.911, G.723.1, … ) Components of the H.323 protocol suite: • Q.931 = ISDN call signalling • H.225.0 = RAS (registration/admissions/status) gatekeeping functions + Call signalling channel (CS), contains Q.931 • H.245 = Control channel (CC), negotiation/capabilities, logical signalling, maintenance • H.450.x = Supplementary services (SS), transfer, hold, park, msg wait, … incomplete! Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 118 Gatekeeper Routed Call 1. Setup called: 5551234 caller: 9642749::10.0.0.5 2. Setup called: 5551234::192.168.0.3 caller: 9642749 3. Connect Atlanta Zone (404) 2, 6, 10, 14 1, 5, 9, 13 Gatekeeper 132.177.120.5 223-2749 10.0.0.5 3, 7, 11, 15 4, 8, 12, 16 223-4211 192.168.0.3 4. Connect 9. Open Channel G.729/30ms, 10.0.0.5:6400 5. TCS media: G.711/30ms, G.729/30ms 10. Open Channel G.729/30ms, 10.0.0.5:6400 6. TCS media: G.711/30ms, G.729/30ms 11. Open Channel G.729/20ms, 192.168.0.3:2300 7. TCS media: G.729/20ms, G.723 12. Open Channel G.729/20ms, 192.168.0.3:2300 8. TCS media: G.729/20ms, G.723 13. ACK 14. ACK 15. ACK 16. ACK Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 119 Gatekeeper Direct Call 1. ARQ called: 5551234 caller: 9642749::10.0.0.5 2. ACF called: 5551234::192.168.0.3 3. Setup called: 5551234 caller: 9642749::10.0.0.5 Atlanta Zone (404) 1 2 223-2749 10.0.0.5 Gatekeeper 132.177.120.5 3, 5, 7, 9 223-4211 192.168.0.3 4, 6, 8, 10 4. Connect 9. ACK 5. TCS media: G.711/30ms, G.729/30ms 10. ACK 6. TCS media: G.729/20ms, G.723 7. Open Channel G.729/30ms, 10.0.0.5:6400 8. Open Channel G.729/20ms, 192.168.0.3:2300 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 120 MEGACO/H.248, Softswitch Concepts Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 121 Master/Slave vs. Peer Comparison Master/Slave (Thin Client) Peer (Thick Client) • Simple/dumb slave end device • Stimulus control, proxy in network • Smart/complex end device • Functional control, peer interaction • Lowest cost end device • Higher cost end device Performance • Lower performance “local” services • Sometimes higher performance distributed services (e.g.. call control) • Higher performance local services • High performance User Interface Feature development • Generic development tools • Shorter time to market for new features on a range of end devices • End device does not “get out of date” as quickly • Device-specific development • Possibly shorter time to market for new features on specific devices • End device may need hardware upgrade over time • Update servers only • Services can come and go dynamically • Update / download all end devices in network (yikes!) • Features more static per-device • MEGACO/H.248, MGCP • H.323, SIP Operation Cost Feature deployment Protocols Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 122 Megaco/H.248 Audio Codec Video Codec G.711 H.261 G.723 H.263 G.729 RTP Megaco TCP RTCP UDP IP LAN Interface Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 123 Megaco/H.248 – Convoluted History PacketCable Network-based Call Signaling (NCS) based on earlier version of MGCP (March 99) DSM-CC Diameter IPDC SGCP MGCP NonStandard I-RFC 2705 (proposal) MGCP proposal MDCP Not fully accepted by Megaco WG, diverged (Spring 99) Industry Defacto Std. PacketCable NCS (proposal) MGCP released as Informational RFC (Oct 99) Megaco Protocol Megaco Protocol stream created, true consensus (March 99) ITU: H.GCP ITU SG-16 initiates gateway control project, H.GCP starting from MDCP (May 99) Megaco/H.248 WORLD STANDARD Agreement reached between ITU SG16 and IETF Megaco to work together to create one standard (Summer 99) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 124 Megaco Vs MGCP Megaco/H.248 Call Model Termination +Context +Topology P2P Single Media Single Media Conferencing P2P Multimedia Multimedia Conferencing Terminations Physical & Ephemeral & Muxing Template Command Grouping Transaction Events Event Buffering Event Packages (MGCP Packages + Additional Packages) National Variants Media Session Description SDP + H.245 Protocol Encoding Binary & Text Transport TCP + UDP +SCTP Security Authentication Header MGC Backup MGCP Call Model Termination + Connection P2P Single Media Single Media Conferencing Terminations Physical & Ephemeral Command Grouping Ad hoc Embedding Event Quarantine Event Packages (MGCP) Media Session Description SDP Protocol Encoding Text Transport UDP Bold entries indicate additional features in Megaco vs. MGCP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 125 Megaco Architecture Whirlwind Tour SS7 etc Signalling Gateway Layer (SG) Signalling Gateway • Interface to SS7 signalling etc • Not in Megaco scope (IETF Sigtran) Sigtran Call Agent PSTN, ATM, Call control (e.g.. H.323, SIP…) Gateway Endpoint Function Media Gateway Controller Media Gateway Control Layer (MGC) Megaco Protocol • Contains all call control intelligence • Implements call level features (forward, transfer, conference, hold, …) etc (e.g..H.323 H.323Gateway, Gateway, PSTN (e.g.. trunking Megaco Scope trunks Media Gateway Terminal, MCU) Terminal, MCU) lines PSTN line Media Gateway Media Gateway Control Protocol • Master / slave control of MGs by MGCs –Connection control –Device control and configuration • Orthogonal to call control protocols Media Gateway Layer (MG) Analog Media Gateway IP Phone Media Gateway • Implements connections to/from IP cloud (through RTP) • Implements or controls end device features (including UI) • No knowledge of call level features Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 126 Framework for H248/Megaco Protocol Media Gateway Media GW Controller • Call processing and Service logic • Call routing • Inter-peer entity communication via call control protocols (e.g. H.323, SIP, etc) • • • • Connection and device control No call processing, no call model Service-independent Cost effective Media GW Controller PBX/CO Media Gateway Device control Device control PSTN trunking Media Gateway PSTN line Media Gateway Telephone/Residential Media Gateway PBX Media Gateway IP (or ATM) Network IP Phone Media Gateway Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 127 PBX/ CO Megaco Framework    The MGC and MGs form a virtual IP-based switch Looks like an H.323 Gateway to other H.323 devices, and a SIP Server to other SIP devices RTP (the voice media itself) is still point-to-point Virtual Switch SS7 Signalling Gateway Media Gateways PSTN Trunking Media Gateway PSTN Line Media Gateway Telephone/Residential Media Gateway Sigtrans Media GW Controller H.323 Megaco/ H.248 H.323 Device SIP RTP Cable Modem Media Gateway RTP SIP Device Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 128 Megaco call in action (optional) MG1 Powered On ServiceChange: Restart ServiceChange: Restart Reply: ServiceChange Modify: Look for Off-Hook Ready Off-Hook MG2 MGC Reply: Modify Powered On Reply: ServiceChange Modify: Look for Off-Hook Reply: Modify Ready Notify: Off-Hook Reply: Notify Dial Tone, User Dials Modify: Dial Tone, Digit Map Reply: Modify Notify: number “19782886160” Reply: Notify Add: TDM to RTP, what codecs? Reply: Add, codec G.729 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 129 Megaco call in action (continued) MG1 MG2 MGC Add: TDM to RTP, ring phone Reply: Add Hears Ring Phone Rings Modify: ip of MG2, ringback Reply: Modify Notify: Off-hook Reply: Notify Off-Hook Modify: stop ring Reply: Modify Modify: stop ringback, fullduplex Stops Ring Reply: Modify Open RTP Active Call/End of Invite Request Open RTP Notify: On-hook Reply: Notify Disconnect Subtract: TDM and RTP Reply: Subtract On-Hook Subtract:TDM and RTP Reply: Subtract Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 130 Megaco/H.248 IP Phone Control Cisco’s Skinny, Nortel’s UNIStim, etc., are very similar protocols but they’re not interoperable H.323 GW MGC H.323 Voice (RTP) In theory the RTP stream should go direct phone<>GW, but many today tandem through the MGC Voice (RTP) IP Phone Media Gateway IP Phone Media Gateway Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 131 Vendor Support for Standards VoIP Protocol Support Percentage of Vendors currentlly supporting the protocol Percentage of vendors planning to add support within the next year 73 H.323 V1 26 H.323 V2 57 17 H.323 other versions 77 32 40 SIP (orig. RFC 2543) 66 30 SIP (Latest spec) 81 42 MGCP (orig. RFC2705) 56 30 MGCP (latest spec) 54 11 H.248 (Megaco) 64 22 Other 0 10 20 30 30 40 50 60 70 80 90 Source: Network World and Mier Communications August, Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2001 132 H.323 limitations Gateway did a lot of things that were easily decomposed into functionally complete pieces  Key insight from layering – separate functionally complete pieces as far as possible.  Quickly faced scaling problems  Call setup and control was a complex control plane operation  Media translation between a variety of networks  Take-away point  Build a distributed system that acts as a single logical entity to the user  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 133 MGCP/H.248/Megaco Media Gateway Controller (MGC) Master/Slave SIP Media Gateway Controller (MGC) MGCP Media Gateway Signaling Gateway Media Gateway Signaling Gateway Distributed entities acting in co-ordination Separate signaling and voice planes, but user unaware of it User A Rensselaer Polytechnic Institute Connect to variety of networks, home users and other media receptors like H.323 terminals etc Interface to variety of signaling mechanisms Shivkumar Kalyanaraman For examples of gateways see RFC 3435 134 Softswitch: Motivation Class-4/5 switches bulky, expensive. Incentive to switch to cheaper easily managed IP Voice PSTN Class 4 switch Class 5 switch Users Class 5 switch ISDN Switch Data Initial gateway between PSTN and Internet was H.323. Gateway did signaling, call control, translation in one box. Not scalable. Users H.323 gateway Packet networks Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 135 What is a Softswitch? A Softswitch is a device independent software platform designed to facilitate telecommunication services in an IP network • A Softswitch controls the network • At a high level, a Softswitch is responsible for: • Protocol Conversion • Control and synchronization of Media Gateways • It’s an Architecture, NOT a box Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 136 The softswitch concept  Build a distributed system that performs the functions of the Class-4/5 switches  Use generic computing platforms to reduce cost, size and flexibility  E.g., DSPs or other programmable architectures  Software components to implement many of the switching tasks give the “soft” part of “softswitch”  The MGC which does the call control and is the brain of the system is usually referred to as the softswitch or call agent The gateways are dumb devices which do whatever MGC instructs them to do MGC therefore does  Call setup, state maintenance, tear-down Megaco was an earlier non-standard framework which was later standardized jointly by ITU and IETF as MGCP    Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 137 Softswitch: What’s the big deal?  Unprecedented flexibility  Smaller offices can have just gateways, MGCs can be at some remote data center  Standards-based interactions drive down costs and offer wider architectural choices  Fast introduction of services and applications that can again be located remotely – only need MGCs to upgrade  New hosted-services solutions due to flexibility  Dramatic space savings  Sometimes as much as 10 times smaller even with all the components of the softswitch architecture Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 138 Softswitch Architecture • Distributed functionality • Open platforms • Open interfaces enable new services • • Application Server Media Gateway Controller Signaling Gateway Leverages the intelligence of endpoints Media Gateway Media agnostic PSTN/ End users Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 139 Softswitch - Media Gateway Controller An SS7 Enabled Media Gateway Controller integrates the functionality of new applications with the large installed based of legacy systems. Application Server • Multiple controllers can collaborate on a single call • May be distributed across the globe • May or may not be collocated with SS7 Signaling Gateway Media Gateway Controller Signaling Gateway Media Gateway PSTN/ End users Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 140 Softswitch - Media Gateway Controller Functions • • • Application Server Connections (call setup and teardown) Media Gateway Controller Events (detection and processing) Signaling Gateway Device management (gateway startup, shutdown, alerts) Media Gateway PSTN/ End users Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 141 Softswitch - Media Gateways Media Gateways provide interaction between audio in the network and software controlled applications Application Server • Convert PSTN to IP packets • Convert IP packets to PSTN • In-band event detection and generation Signaling Gateway • Compression (G.7xx,…) Media Gateway • May be distributed across the globe PSTN/ End users Media Gateway Controller Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 142 MGC and MG Roles Media Gateway Controller MGC’s allow intelligence to be distributed in the network    Basic call routing functions Synchronization of Media Gateways Protocol Conversion Media Gateway MG’s are purpose built specialist devices      Trunking gateways VoATM gateways Access gateways Circuit switches Network Access Servers Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 143 Softswitch - Signaling Gateway Signaling Gateways provide interaction between the SS7 network and Media Gateway Controllers. Application Server • • • Convert SS7 to IP packets Media Gateway Controller Convert IP to SS7 packets Signaling Gateway Signaling transport (SS7, SIP-T, Q.931…) • Extremely secure • Extremely fault tolerant Media Gateway PSTN/ End users Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 144 Softswitch – Application Server Application Servers(AS) provide the new services that are the real “value-add” for Softswitches. Application Server • • Many core features are part of the MGC Media Gateway Controller Allows new features to be developed by third parties Signaling Gateway Media Gateway PSTN/ End users Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 145 Softswitch – Application Server Application Servers(AS) Can be broken apart and distributed in the network LDAP Feature Server Directory Server COPS Corba Network Elements Policy Server SIP Corba Media Server Management Server Connectivity Server SIP,Parlay,JAIN Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 146 Softswitch Architecture – The protocols Application Server SIP, Parlay, Jain Media Gateway Controller Sigtran w/SCTP Signaling Gateway H.248,MGCP Media Gateway PSTN/ End users Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 147 Softswitch Architecture – Interdomain protocols Application Server Application specific Application Server SIP, Parlay, Jain Media Gateway Controller Media Gateway Controller Sigtran SIP-T,BICC Signaling Gateway Signaling Gateway H.248,MGCP Media Gateway RTP Media Gateway PSTN/ End users PSTN/ End users Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 148 SIP vs MEGACO: Summary Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 149 SIP vs MEGACO (contd) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 150 VoIP Signaling Model: Summary End-system: SIP signaling (beat out H.323)  PSTN gateway, with interfaces looking into PSTN and interfaces looking into VoIP networks  Media Gateway Controller (MGC): “intelligent” endpoint: supervises call services end-end  Media Gateway (MG): interface to the IP network or PSTN: “simple” endpoint instructed by MGC  MEGACO: MG  MGC interaction protocol;  ITU (H.248) and IETF (RFC 3525) standard  Replaces proprietary APIs and RFC 3435 (MGCP)  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 151 Speech Coding and Speech Coders for VoIP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 152 Taxonomy of Speech Coders Speech Coders Waveform Coders Time Domain: PCM, ADPCM Source Coders Frequency Domain: e.g. Sub-band coder, Adaptive transform coder Linear Predictive Coder Vocoder Waveform coders: attempts to preserve the signal waveform not speech specific (I.e. general A-to-D conv)  PCM 64 kbps, ADPCM 32 kpbs, CVSDM 32 kbps Vocoders:  Analyse speech, extract and transmit model parameters  Use model parameters to synthesize speech  LPC-10: 2.4 kbps Hybrids: Combine best of both… Eg: CELP (used Kalyanaraman in GSM) Shivkumar Rensselaer Polytechnic Institute  153 Speech Quality of Various Coders Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 154 Speech Quality (Contd) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 155 Actual Bandwidth Used Frame size in ms 10 20 30 10 20 30 Packet In bytes G.723.1 (5.3 kbps) G.723.1 (6.3 kbps) G.711 (64 kbps) G.729A /G.729 ( 8 kbps) T-LAN kbps WAN kbps 116.8 90.4 81.5 60.8 34.4 25.6 96.0 80.0 74.6 40.0 24.0 18.6 86 22.9 16.0 90 24.0 17.0 80 160 240 10 20 30 + RTP+ UDP+IP in bytes 120 200 280 50 60 70 LAN frame in bytes 146 226 306 76 86 96 30 20 60 30 24 64 Note: (1) 26-bytes Ethernet overhead was removed for WAN calculation. (2) No backbone protocol overhead was used for WAN bandwidth. (3) This is per voice direction, so multiply by 2 if on a shared (half-duplex) media (4) No Ethernet Interframe Gap was included (another 12 bytes) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 156 Applications of Speech Coding Telephony, PBX  Wireless/Cellular Telephony  Internet Telephony  Speech Storage (Automated call-centers)  High-Fidelity recordings/voice  Speech Analysis/Synthesis  Text-to-speech (machine generated speech)  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 157 Pulse Amplitude Modulation (PAM) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 158 Pulse Code Modulation (PCM) * PCM = PAM + quantization Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 159 Companded PCM •Small quantization intervals to small samples and large intervals for large samples • Excellent quality for BOTH voice and data • Moderate data rate (64 kbps) • Moderate cost: used in T1 lines etc Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 160 How it works for T1 Lines • Companding blocks are shared by all 16 channels Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 161 Recall: Taxonomy of Speech Coders Speech Coders Waveform Coders Time Domain: PCM, ADPCM Source Coders Frequency Domain: e.g. Sub-band coder, Adaptive transform coder Linear Predictive Coder Vocoder Waveform coders: attempts to preserve the signal waveform not speech specific.  PCM 64 kbps, ADPCM 32 kpbs, CVSDM 32 kbps Vocoders:  Analyse speech, extract and transmit model parameters  Use model parameters to synthesize speech  LPC-10: 2.4 kbps Hybrids: Combine best of both… Eg: CELP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute  162 Vocoders Encode only perceptually important aspects of speech w/ fewer bits than waveform coders: eg: power spectrum vs time-domain accuracy Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 163 LPC Analysis/Synthesis Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 164 Speech Generation in LPC Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 165 CELP Encoder Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 166 Example: GSM Digital Speech Coding  PCM: 64kbps too wasteful for wireless  Regular Pulse Excited -- Linear Predictive Coder (RPE-LPC) with a Long Term Predictor loop.  Subjective speech quality and complexity (related to cost, processing delay, and power)  Information from previous samples used to predict the current sample: linear function.  The coefficients, plus an encoded form of the residual (predicted - actual sample), represent the signal.  20 millisecond samples: each encoded as 260 bits =>13 kbps (Full-Rate coding). Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 167 Codecs: Quality Measures Standard G.711 G.723.1 G.728 G.729 G.722 G.726 GSM-EF Algorithm PCM MPE/ACELP LD-CELP CS-ACELP Sub-band ADPCM ADPCM ACELP Bit Rate (Kbit/s) Codec Induced Delay (msecs) 56, 64 5.3, 6.3 16 8 64 <<1 67-97 <<2 25-35 5-10 16, 24, 32, 40 12.2 <<1 40 Resultant Voice Quality Excellent Fair(5.3), Good(6.3) Good Good Good-Excellent (it’s wideband) Fair(24), Good(40) Good Only G.711, G.723.1, and G.729 are popular (because they are mandatory for several specs)  G.711 is the best (obviously), but G.729 isn’t much worse  G.723.1 is HORRIBLE  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 168 Packet Encapsulation RTP datagram Version, flags & CC Payload Type 1 1 Sequence Number Synchronization Source ID Timestamp 2 4 CSRC ID (if any) Codec Data 0-60 0-1460 4 UDP datagram Source Port Number Destination Port Number 2 2 Version & header length 1 UDP length 2 Total Length 1 2 Packet ID 2 Ethernet Frame Inter-frame gap Preamble 12 7 Flags & TTL Frag Offset 2 2 1 Header Checksum 1 Source Address 2 Destination Address 4 Start of frame delimiter 0-1472 Options (if any) 4 Data 0-40 0-1480 Length or Ethertype Destination Address 1 Data Protocol IP packet TOS UDP checksum 6 Source Address 6 Data 2 0-1500 Pad Checksum 0-46 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 169 4 G.711 (10ms) Clear Channel Voice 80 byte voice bundles RTP Frame UDP Datagram Voice Payload 80 2 2 2 2 12 Source Length Checksum Destination 12 4 4 Header 80 RTP Header Destination IP Packet 12 8 RTP Header Voice Payload 80 12 Source Type Destination IP into Ethernet Source IP into Frame Relay Flag 5 CRC. 4 120 12 21 IP Payload + 48 IP Payload Header Voice Payload IP Payload Address IP into ATM RTP Header 120 6 6 2 8 Preamble UDP Header 5 Frame Check + 48 IP Payload Header Header 5 24 16 IP Payload Padding Flag 8 Trailer Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 170 G.729 (30ms) Clear Channel Voice 30 byte voice bundles RTP Frame UDP Datagram Voice Payload 30 2 2 2 2 12 Source Length Checksum Destination 12 4 4 Header 30 RTP Header Destination IP Packet 12 8 RTP Header Voice Payload 30 12 Source Type Destination IP into Ethernet Preamble IP into Frame Relay UDP Header Source Flag CRC. 4 IP Payload 70 12 21 IP Payload Address IP into ATM Voice Payload 70 6 6 2 8 RTP Header 48 5 Frame Check + 5 IP Payload Header Header 22 18 IP Payload Padding Flag 8 Trailer Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 171 G.729 (20ms) Clear Channel Voice 20 byte voice bundles RTP Frame UDP Datagram Voice Payload 20 2 2 2 2 12 Source Length Checksum Destination 12 4 4 Header 20 RTP Header Destination IP Packet 12 8 RTP Header Voice Payload 20 12 Source Type Destination IP into Ethernet Preamble IP into Frame Relay UDP Header Source Flag CRC. 4 IP Payload 60 12 21 IP Payload Address IP into ATM Voice Payload 60 6 6 2 8 RTP Header 48 5 Frame Check + 5 IP Payload Header Header 12 28 IP Payload Padding Flag 8 Trailer Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 172 G.723.1 (30ms) Clear Channel Voice 20-24 byte voice bundles RTP Frame UDP Datagram Voice Payload 20-24 2 2 2 2 12 Source Length Checksum Destination 12 4 4 Header 20-24 RTP Header Destination IP Packet 12 8 RTP Header Voice Payload 20-24 12 Source Type Destination IP into Ethernet Preamble IP into Frame Relay UDP Header Source Flag CRC. 4 IP Payload 60-64 12 21 IP Payload Address IP into ATM Voice Payload 60-64 6 6 2 8 RTP Header 48 5 Frame Check + 5 IP Payload Header Header Flag 12-16 28-24 8 IP Payload Padding Trailer Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 173 Coding Technology Side-effects   Coded VoIP is NOT the same as a telephone line (I.e. it is not a content-neutral “carrier”):  Without special support, you cannot send “fax” or “modem traffic” over VoIP  The “carrier” is now IP (or some data-transport protocol like frame-relay or ATM)  The same is true for 3G or GSM telephony  Why? Voice is encoded and the encoding works only for voice! (it is no longer a 64 kbps bit stream) Fax support: Fax Passthru, T.38 fax Relay Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 174 Voice Quality: Loss Tolerance   Voice codecs are unevenly tolerant of packet loss,  but loss above 2 to 5 percent will have a perceptible effect on quality.  Losses also associated with higher jitter  1-way delay > 150 milliseconds, => trouble  Jitter buffer (major component of delay budget)  Capacity reservations & priority for key packets: setup through RSVP  Priority: using TOS bits: 8 levels of precedence Carrier networks use some combination of:  MPLS (traffic engineering, stable routing) and  Diff-serv (expedited forwarding) to provide superior service for VoIP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 175 VoIP QoS Myths  Packet voice=> voice could take multiple paths or failover.  But it usually does not…  VoIP is sensitive to routing failures or congestion in paths  OSPF and BGP convergence times too bad for VoIP: SONET and (now) MPLS much better  However, FEC packets for VoIP can be sent on a separate path or on the same path:  hedge against performance fluctuations (eg: congestion) on the primary path,  but limited hedge against failure of the primary path. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 176 Voice codecs: Summary      G.711  uncompressed PCM audio stream  8ks/s of 8 bit values = 64kbps  packet “sizes” = 10, 20, 30 and 60ms G.722 - Wideband (7kHz) G.726  ADPCM - 10,20,30,60ms - 32kbps G.723.1  MLQ - 30ms - 5.3 or 6.3kbps  Silence suppression G.729  CS-ACELP - 10, 20, 30ms - 8kbps  Annex B adds silence suppression Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 177 Recap: Speech Quality of Various Coders Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 178 Miscl: Other standards, ENUM, E-911, Presence etc Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 179 Sigtrans (Signaling Transport)  Signalling transport protocol and adaptation layers for SG to MGC communication, and for SG to SG communication  Signalling Gateways can be stand-alone or co-located with an MGC Signaling Gateway Signaling Gateway Sigtrans SS7 CO Virtual Switch Trunk Gateway D-channel PRI B-channels PBX Signalling Gateway Media Gateway Sigtrans SIP, H.323 Megaco/ H.248 Media GW Controller Virtual Switch Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 180 RTP SCTP (Stream Control Transmission Protocol)     Sigtrans needs to carry SS7 Needed a reliable transport mechanism (like TCP) without the overhead of a connection-oriented protocol SCTP created: like UDP, but with acknowledgment, fragmentation, and congestion-avoidance This has much broader use than just carrying SS7: it’s being looked at for SIP, RTP, T.38, and more... 6 - Presentation 5 - Session 4 - Transport 3 - Network 2 - Link Rensselaer Polytechnic 1 -Institute Physical User Adaptation Modules SCTP IP MLPPP / FR / ATM Shivkumar Kalyanaraman Ethernet / SONET/Serial 181 (1) SS7 Signaling Using IP Transport SSP The IETF M2UA MTP2-User Adaptation Layer from the Sigtran WG Applications SSP Applications STP TCAP TCAP ISUP ISUP SCCP SCCP MTP3 MTP2 MTP3* MTP2 MTP3 M2UA M2UA SCTP SCTP IP IP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 182 (2) SS7 / IP Interworking SSP The IETF M3UA MTP3-User Adaptation Layer from the Sigtran WG SS7 SG Call Processing Application MGC Call Processing Application Nodal Inter-working Function ISUP ISUP MTP3 MTP3 MTP2 MTP2 M3UA M3UA SCTP SCTP IP IP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 183 BICC (Bearer Independent Call Control)    Offers a migration path from SS7/TDM to packet-based voice Defines Interface Serving Node for Bearer, Bearer Control, and Call Serving Functions Specifies Transit Serving Nodes to change bearer types, and Gateway Serving Node to transit operators BICC ISN ISUP BICC ISN BICC ISUP PSTN PSTN TDM TDM Class 4 Switch Class 4 Switch Data Network Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 184 VPIM (Voice Profile for Internet Mail)      Uses SMTP to send/receive voice/faxmail messages Attaches messages as wav/mpeg/tiff files in MIME Useful for transferring across voicemail systems Adds more useful info: vcard, signature, multiple addresses POP3 still used to download voicemail to your favorite email client (Outlook, Eudora, Pine, etc.) POP3 Email Browser VPIM Plain Phone SIP/H.323 PBX Unified Messaging System Unified Messaging System SIP Device Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 185 TRIP – Telephony Routing over IP TRIP is a protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. Can serve as a routing protocol for any signaling protocol  TRIP is used to distribute telephony routing information between telephony administrative domains.  TRIP is essentially BGP for phone numbers and the protocol is actually based on BGP-4  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 186 Midcom (Middlebox Communication) 1. INVITE sip:president@us.gov SIP/2.0 From: sip:tony@parliament.uk 2. INVITE sip:dcheney@wh SIP/2.0 From: sip:tony@parliament.uk 3. SIP/2.0 200 ok From: sip:dcheney@wh parliament.uk Location Server george.w.bush 1&5 tony@parliament.uk us.gov 4 2&6 4. SIP/2.0 100 OK From: sip:president@us.gov Firewall Proxy server dcheney@wh 3 5. ACK sip:president@us.gov SIP/2.0 From: sip:tony@parliament.uk 3.5 Midcom Protocol 6. ACK sip:dcheney@wh SIP/2.0 From: sip:tony@parliament.uk Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 187 Mediation and Billing Current State  Non real time  Non-scalable  Limited functionality  No revenue assurance capabilities  Proprietary CDR formats  No OSS functionality (fraud, churn, etc.)  Mainly stand alone systems (no integration with the legacy systems) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 188 Call Detail Records • To be able to run reports and bill, Call Detail Records (CDRs) must be recorded for each call: Time Reason From 16:45 Call req. 5551212 To Duratio n Details 6663434 01:45 Normal disc. With VoIP far more detail is necessary:  Packets transmitted  Packets lost  Jitter  Delay  Call Control / Gateway used  Codec used … Rensselaer Polytechnic Institute 189 Shivkumar Kalyanaraman  Mediation and Billing Requirements Complete call details including  Call descriptors  caller ID, called #, time, length, disconnect reason, QoS requested, etc., Complete network QoS information (dropped packets, trunk failure, etc.)  Complete application level QoS (dropped frames, disconnect reason, CODEC type, etc.) Carrier-grade solution  Scalable    Large number of calls/sec  Cover large, distributed networks  Real Time  Revenue Assurance  99.999% accuracy  Audit capabilities  Highly available  Support of standards Integration with other OSS/BSS systems (fraud, churn, etc)   Fault tolerant  Local cache  Roll back Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 190 IPDR – IP Data Records The purpose of the IPDR initiative is to define the essential elements of data exchange between network elements, operation support systems and business support systems. Specific goals include:  Define an open, flexible record format (the IPDR record) for exchanging usage information.  Define essential parameters for any IP transaction.  Provide an extension mechanism so network elements and support systems exchange optional usage metrics for a particular service. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 191 ENUM vs DNS    DNS (or internet) names: interpreted right to left:  Eg: www.rpi.edu Telephone numbers: interpreted left to right:  Eg: +1 518 276 8979 ENUM: (RFC 3761)  telephone numbers written DNS-style, Rooted at the domain e164.arpa.  So, 1.212.543.6789 becomes 9.8.7.6.3.4.5.2.1.2.1.e164.arpa.  When queried, DNS can return an IP address for the telephone number,  or it can return a rule for re-formatting the original number  For example, rules can be returned to rewrite 1.212.543.6789 as sip:36789@nyc-gw.example.net, sip:caryfitz@serviceShivkumar Kalyanaraman Rensselaer Polytechnic Institute provider.com.  192 Continuity of Telephone Svcs in VoIP  A number of basic features remain same:  Phone looks and behaves like a phone  DTMF (touch-tone) features: mid-call signaling  E.911 will provide 911 location services  Bearer (“data-plane”) is separated from signaling (“control-plane”) and is handled differently  But, unlike telephony, it is multiplexed on the same network  Interfaces smoothly with internet applications: IM, Web, email… Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 193 E911 - Requirements  911 Services  Power  Need stays on when building power fails callers phone number and location  Services must be modified during a 911 call Disable call-waiting Disable three-party calls Caller cannot hangup and place another call Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 194 E911 – VoIP Enhancements VoIP has the potential of enhancing E911 functionality  Multimedia communication  Audio – emulate existing services  Video – images and/or biometrics to/from emergency technicians  Text – for hearing impaired  Call setup could contain medical background  Can be locally maintained, does not a master database  Calls can easily be forwarded or transferred  Fast call setup times  PSAP could easily be deployed or relocated anywhere Internet access is available. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 195 E911 – Using DNS to convey location  Based on network device name pigface 192.168.200.20 GL S3.US.95401.4500 “110 Stony Point Rd.,Santa Rosa CA”  Based on Geographic location (longitude/latitude) pigface 192.168.200.20 GPOS -38.43954 122.72821 10.0  Binary (includes precision indicator) pigface 192.168.200.20 LOC 23 45 32 N 89 23 18 W –24m 30m Issues   Only works if mapping between device and location is correct. Not secure/private Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 196 Invisible Internet Telephony VoIP technology will appear in . . .  Internet appliances  home security cameras, web cams  3G mobile terminals  fire alarms  chat/IM tools  interactive multiplayer games Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 197 VoIP Reliability & Manageability   Reliability: PSTN benchmarks…  Work all the time, except for maintenance windows  Faults: network, hardware, software  Duplicated systems: no upgrade downtime  Monitors, automatic failovers Manageability:  accurate and flexible billing systems,  error reporting and resolution,  call tracing, adds/moves/changes,  Lack of network state (IP model) makes this difficult => mediated calls (eg: softswitch etc reinstate some of this…) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 198 IPtel for appliances: “Presence” Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 199 VoIP Standards (Enterprise View) 3rd Party Call Servers & Gatekeepers H.323 annex G, SIP Enterprise Call Server H.323, SIP, Q.Sig IP-enabled PBX/KS H.248, Stimulus H.323 H.248, Stimulus SIP H.323 SIP, H.323 SIP, H.323 SIP Gateway RTP RTP Stimulus Terminals RTP H.323 Gateway Thick Terminals RTP RTP RTP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 200 VoIP Standards (Carrier View) 3rd Party Call Agents & Gatekeepers H.323, SIP-T Softswitch/ BICC Call Agent/ MGC SIP SIP Gateway Sigtrans, Q.BICC Megaco/ H.248 RTP Signalling (SS7) Gateway SIP MGCP RTP Megaco Gateway MGCP Gateway RTP Application/ Media Server RTP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 201 VoIP Summary: Big Picture Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 202

voip-tutorial - Computer Science & Engineering

Related documents

Products

Support

voip-tutorial - Computer Science & Engineering

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib