Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 DOSA: An Architecture for IP Telephony Services Chuck Kalmanek AT&T Labs - Research Presentation at Opensig’99 Pittsburgh October 15, 1999 With grateful.

Similar presentations


Presentation on theme: "1 DOSA: An Architecture for IP Telephony Services Chuck Kalmanek AT&T Labs - Research Presentation at Opensig’99 Pittsburgh October 15, 1999 With grateful."— Presentation transcript:

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

2 2 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 PSTN MTACM PSTN G/W DCS- Proxy+GC DCS- Proxy+GC Managed IP Backbone Cable MTA = Media Terminal Adapter CM = Cable Modem ER = Edge Router CM TS ER CMMTA CM TS ER Announcement Server

3 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 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’t trust 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 5 Transaction State Connection State Call State DCS Architecture PSTN MTACM PSTN G/W Local LD DCS- Proxy+GC DCS- Proxy+GC Managed IP Network Access MTA = Media Terminal Adapter CM = Cable Modem ER = Edge Router CM TS ER CMMTA CM TS ER Announcement Server

6 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 7 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 Authentication, Authorization, Admission control Number -to- Addres s Translat ion INVITE (Stage1) MTACM DCS- Proxy+GC DCS- Proxy+GC Access CMMTA CMT S ER CMT S ER Announcement Server INVITE (no ring) INVITE (Stage1)

8 8 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 200 OK Setup Gate Setup Gate 200 OK MTA CM DCS- Proxy +GC DCS- Proxy +GC Access CM Announcement Server CM TSE R

9 9 Resource Management: 1 st 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 MTACM DCS-proxy + GC DCS-proxy + GC Access Backbone Resource Management CM TSE R CMMTA PATH / Reserve Announcement Server

10 1010 Resource Management: 2 nd 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 Commit/Commit Ack MTACM Gate- controller Gate- controller Access CM TS ER CMMTA INVITE Commit/Commit Ack Announcement Server 180 Ringing 200 OK CM TS ER

11 1 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 1212 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 1313 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 1414 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 1515 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


Download ppt "1 DOSA: An Architecture for IP Telephony Services Chuck Kalmanek AT&T Labs - Research Presentation at Opensig’99 Pittsburgh October 15, 1999 With grateful."

Similar presentations


Ads by Google