15
1 DOSA: An DOSA: An Architecture Architecture for IP for IP Telephony Telephony Services 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

DOSA: An Architecture for IP Telephony Services

  • Upload
    simone

  • View
    36

  • Download
    0

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

1

DOSA: An DOSA: An Architecture for IP Architecture for IP Telephony ServicesTelephony Services

Chuck KalmanekAT&T Labs - Research

Presentation at Opensig’99Pittsburgh

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

DOSA FrameworkDOSA 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

MTA CM

PSTNG/W

DCS-Proxy+GC

DCS-Proxy+GC

Managed IP BackboneCable

MTA = Media Terminal Adapter

CM = Cable Modem

ER = Edge Router

CMTSER

CM MTACMTSER

Announcement Server

3

Distributed Call SignalingDistributed 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 Perspective on Service Provider’s NeedsNeeds

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

5Transaction StateConnection State

Call State

DCS ArchitectureDCS Architecture

PSTN

MTA CM

PSTNG/W

Local

LD

DCS-Proxy+GC

DCS-Proxy+GC

Managed IP NetworkAccess

MTA = Media Terminal Adapter

CM = Cable Modem

ER = Edge Router

CMTS ER

CM MTACMTSER

Announcement Server

6

““Gates” and Edge RoutersGates” 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

Example Call FlowExample 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-Address Translation

INVITE (Stage1)

MTA CM

DCS-Proxy+GC

DCS-Proxy+GC

AccessCM MTA

CMTS

ER

CMTS

ER

Announcement Server

INVITE (no ring)

INVITE (Stage1)

8

Example Call Flow (continued…)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

SetupGate

SetupGate

200 OK200 OK

MTA

MTA CM

DCS-Proxy +GC

DCS-Proxy +GC

Access

CM

Announcement Server

CMTSE

R

CMTSE

R

9

Resource Management: 1Resource Management: 1st st PhasePhase

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

MTA CM

DCS-proxy + GC

DCS-proxy+ GC

AccessBackbone Resource Management

CMTSE

R

CMTSER

CM MTA

PATH / ReservePATH / Reserve

Announcement Server

10

Resource Management: 2Resource Management: 2nd nd Phase 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

MTA CM

Gate-controller

Gate-controller

AccessCMTSER

CM MTAINVITE

Commit/Commit Ack

Announcement Server

180 Ringing200 OK

CMTSER

11

PrivacyPrivacy

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 identityDcs-Caller: John Smith; 555-1212

12

Proxy to Proxy SIP extensions: BillingProxy 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 HeaderState 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 OSPS Header (Operator Services Positioning System)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 FormatOSPS = “OSPS” “:” OSPS-Tag

OSPS-Tag = “BLV” | “EI”

15

Unique Contributions and StatusUnique 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