1 / 15

DOSA: An Architecture for IP Telephony Services

DOSA: An Architecture for IP Telephony Services. Chuck Kalmanek AT&T Labs - Research. With grateful acknowledgement of the contributions of the PacketCable DQoS and DCS focus teams, Bill Marshall, Partho Mishra, Doug Nortz, and K.K. Ramakrishnan. Presentation at Opensig’99 Pittsburgh

simone
Download Presentation

DOSA: An Architecture for IP Telephony Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DOSA: An Architecture for IP Telephony Services Chuck Kalmanek AT&T Labs - Research With grateful acknowledgement of the contributions of the PacketCable DQoS and DCS focus teams, Bill Marshall, Partho Mishra, Doug Nortz, and K.K. Ramakrishnan Presentation at Opensig’99 Pittsburgh October 15, 1999

  2. MTA CM Cable PSTN DOSA Framework • Designed as an end-to-end signaling architecture for PacketCable • Philosophy: encourage features and services in intelligent end-points • DCS “proxy” designed to be scalable transaction server • Resource management protocol provides necessary semantics for telephony • “Gates” (packet classifiers) at network edge allow us to avoid theft of service DCS- Proxy+GC DCS- Proxy+GC Announcement Server CM MTA CMTS ER CMTSER Managed IP Backbone MTA = Media Terminal Adapter PSTN G/W CM = Cable Modem ER = Edge Router

  3. Distributed Call Signaling • Distributed Call Signaling (DCS): SIP w/ carrier class features • takes advantage of SIP feature support in endpoints and proxies • adds resource management, privacy, authorization & billing, LNP • Motivation: service provider must meet user expectations • quality, privacy, existing services are critical needs • Coordination between call signaling and QoS control • authorize a call and allocate resources precisely when needed • prevent Call Defects: don’t ring the phone if resources are unavailable • ensure service quality requirements are met (e.g., don’t clip “Hello”) • provide the ability to bill for usage, without trusting end-points • prevent Theft Of Service: associate usage recording and resource allocation • Care taken to ensure untrusted end-points behave as desired • privacy mechanisms built into architecture

  4. Perspective on Service Provider’s Needs • Need for differentiated quality-of-service is fundamental • must support resource reservation and admission control, where needed • Allow for authentication and authorization on a call-by-call basis • Can’ttrust CPE to transmit accurate information or keep it private • Need to guarantee privacy and accuracy of feature information • e.g., Caller ID, Caller ID-block, Calling Name, Forwarding Number • privacy may also imply keeping IP addresses private • Protect the network from fraud and theft of service • critical, given the incentive to bypass network controls • Must operate in large scale, cost-effectively • SIP philosophy: don’t keep state for stable calls in proxies; end-points keep state associated with their calls

  5. MTA CM Access DCS- Proxy+GC DCS- Proxy+GC Announcement Server CM MTA CMTSER Managed IP Network CMTS ER PSTN MTA = Media Terminal Adapter PSTN G/W CM = Cable Modem ER = Edge Router Local LD Connection State Transaction State DCS Architecture Call State

  6. “Gates” and Edge Routers • “Gates” in edge routers opened for individual calls • call admission control and policing implemented in edge routers • gate is a packet filter in edge router: “allow flow from this source to this destination” • for a particular range of traffic parameters, and a particular duration, etc. • however, policy is controlled by the gate controller • Gate controller manipulates a gate after call setup is authorized • setting up gate in advance of reservation request allows a proxy to be stateless • MTA makes a resource reservation request by signaling to edge router • edge router admits the reservation if consistent with gate parameters • edge router generates usage recording events based on reservation state • Accounting info stored at the edge router to generate usage events • opaque info sent to record keeping servers for tracking usage and billing

  7. INVITE (Stage1) INVITE (no ring) MTA CM Access INVITE (Stage1) Example Call Flow • MTA issues an INVITE to destination E.164 (or other) address • Originating DCS-proxy performs authentication and authorization • Terminating DCS-proxy translates dest number to local IP address • no resources allocated yet; provider may choose to block a call if resources are unavailable • P(blocking)  P(call defect) • Initial INVITE starts call state machine at terminating MTA • but, does not alert the user Number-to-Address Translation Authentication, Authorization, Admission control DCS- Proxy+GC DCS- Proxy+GC Announcement Server CM MTA CMTS ER CMTSER

  8. 200 OK 200 OK Setup Gate Setup Gate 200 OK Example Call Flow (continued…) • 200 OK conveys call parameters and “gate id” to originating MTA • Gate controllers setup “gates” at edge routers as part of call setup • gate is described as an “envelope” of possible reservations issued by MTA • gate permits reservation for this call to be admitted • Gate Controller acts as policy server in COPS framework • policy decisions provided to CMTS based on call signaling • CMTS acts as policy enforcement point DCS- Proxy +GC DCS- Proxy +GC Announcement Server CM MTA CMTSER MTA CM CMTSER Access

  9. MTA CM Access Backbone Resource Management PATH / Reserve PATH / Reserve Resource Management: 1st Phase • MTA initiates resource reservation • access resources are “reserved” after an admission control check • backbone resources are “reserved” (e.g., explicit reservation or “packet marking”) • Originating MTA starts end-to-end handshake with terminating MTA • originating MTA sends 2nd INVITE, terminating MTA sends 180 RINGING, 200 OK • this ensures that resources are available when terminating MTA rings the phone DCS-proxy + GC DCS-proxy + GC Announcement Server CM MTA CMTSER CMTSER

  10. INVITE MTA CM Access 180 Ringing 200 OK Commit/Commit Ack Commit/Commit Ack Resource Management: 2nd Phase • MTA knows voice path is established when it receives a 200 OK • MTAs initiate resource “commitment” • resources “committed” over access channel • CMTS starts sending unsolicited grants; usage recording is started • commitment deferred until far end pick up, to prevent theft of service; allow efficient use of constrained resources in access network • Commit opens the “gate” for this flow Gate- controller Gate- controller Announcement Server CM MTA CMTSER CMTSER

  11. Privacy • Want to meet user expectations r.e. accuracy and privacy of info • Calling Identity Delivery allows called party to get info about caller • Calling Identity Delivery Blocking allows calling party to restrict presentation of info (e.g., calling number, calling name) • SIP supports some privacy mechanisms : From header can be anything chosen by MTA, e.g., “anonymous” • but, can’t be modified by proxies • DCS-Proxy acts a trusted intermediary • ensures calling identity provided by user agent is valid • user agents are CPE and can’t be trusted • proxy adds calling identity info when not provided by user agent to enable call trace • New header conveys caller identity Dcs-Caller: John Smith; 555-1212

  12. Proxy to Proxy SIP extensions: Billing • Motivation: need to monitor and derive revenue from resource usage • proxies have access to customer info (user identity, services subscribed, payment method) • billing models can be complex, requiring billing info from multiple parties (split charging for call forwarding, etc.) • Header requirements • need a unique id to associate event records from multiple sources with the call • need a header to carry information about the billable account, record keeping system, etc. • need a header identifying the location where resource usage info is captured

  13. State Header • Motivation • proxies sometimes need state information about an active call • “return call” for a call where the caller wanted privacy • ability to bill correctly for call forwarding (e.g., international call) • “call trace” where the user wishes to have law enforcement trace a call • but, we want proxies to remain stateless • State Header • proxies stores call state at the endpoints during the initial INVITE exchange • state object is signed and encrypted by proxy; cannot be altered by endpoints • endpoint passes state information to proxies when needed

  14. OSPS Header (Operator Services Positioning System) • Motivation • PSTN based services like Busy Line Verify and Emergency Interrupt require special treatment • PSTN operator is unaware that the call is to a destination on the IP network • PSTN gateway initiates SIP INVITE to endpoint • this includes the OSPS header • an active endpoint receiving an INVITE containing OSPS : EI header does not return “Busy” • Header Format OSPS = “OSPS” “:” OSPS-Tag OSPS-Tag = “BLV” | “EI”

  15. Unique Contributions and Status • DOSA introduced the concept of integrating QoS with call signaling protocol • DCS call signaling allows use of end-point intelligence to support new services and integration with other applications • Dynamic QoS provides common underlying framework of QoS for call signaling protocols • Two phase Reserve/Commit for managing resources • provides semantics that resources are available when phone rings, without billing for ringing • Gates for each call: allows provider to manage access to resources • ensures that users who want toll quality go through network proxies • avoid theft of service with careful coordination between signaling and QoS • DCS proxies not required to be involved throughout call • simple transaction processor; less stringent reliability requirements;scalable

More Related