SIP Extensions
QoS, Authentication, Privacy, Billing, ...
Project Packetcable
John R. Pickens, PhD
VP Technology and CTO
jpickens@com21.com
408 953 9228
1
Acknowledgements
Presentation based in part on July 1999 IETF
contributions
W. Marshall, K. K. Ramakrishnan, E. Miller, G. Russell, B. Beser,
M. Mannette, K. Steinbrenner, D. Oran, J. Pickens, P. Lalwaney,
J. Fellows, D. Evans, K. Kelly, F. Andreasen
AT&T, CableLabs, 3Com, Cisco, Com21, General Instrument,
Lucent Cable, NetSpeak, Telcordia
2
Problem Statement

Personal Policy == Cool Applications
Administrative Policy == Desirable Service Revenue
SIP enables “personal policy”
How can SIP enable “administrative policy”?


3
Project Packetcable Overview





IP based multimedia networking services project, emphasizing IP
telephony in the initial phases
Protocols based upon standards, with extensions (submitted to
standards organizations) where needed
North American cable industry market, managed by Cablelabs,
strong vendor support.
Distributed signaling paradigm is SIP (Packetcable 1.1).
Protocols and architecture developed for DOCSIS-based cable, but
applicable to other broadband access network technologies.
Note: Other backoffice uses of SIP are envisioned, not in the current
work.
4
Packetcable Components
Embedded MTA
MTA
Call Management
Server
Cable
Modem
HFC access
network
(DOCSIS)
CMTS
Media
Servers
Announcement Servers
Conference Mixing Bridges
...
Media Gateway
Managed IP Backbone
(QoS Features)
(Headend, Local, Regional)
Embedded MTA
MTA
Media Gateway
Controller
PSTN
Signaling
Gateway
Cable
Modem
HFC access
network
(DOCSIS)
CMTS
OSS
Backoffice
Billing
Provisioning
Problem Resolution
DHCP Servers
TFTP Servers
...
5
SIP Interfaces (Packetcable 1.1)
Embedded MTA
MTA
Call Management
Server
Cable
Modem
HFC access
network
(DOCSIS)
CMTS
Media
Servers
Announcement Servers
Conference Mixing Bridges
...
Media Gateway
Managed IP Backbone
(QoS Features)
(Headend, Local, Regional)
Embedded MTA
MTA
Media Gateway
Controller
PSTN
Signaling
Gateway
Cable
Modem
HFC access
network
(DOCSIS)
CMTS
Call Management
Server
OSS
Backoffice
Billing
Provisioning
Problem Resolution
DHCP Servers
TFTP Servers
...
6
Call Management Server Interfaces
NCS/MGCP
Translation, Congestion Control, PSTN
DB access, Event recording, Routing
Call
Signaling
Call Agent
QoS
Signaling
DCS/SIP
DCS-Proxy
Gate Controller
DQos
COPS
Call Management Server
(CMS)
7
Requirements from a Service Provider’s Perspective

Need for differentiated quality-of-service is fundamental
– must support resource reservation and admission control, where needed
– hope SIP enables lots of new services; also desire to meet needs of current users



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, Called Party
» 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

We must be able to operate in large scale, cost-effectively
– don’t keep state for stable calls in proxies; end-points can keep state associated
with their own calls
8
Distributed Call Signaling Framework
DCSProxy+GC
DCSProxy+GC
Announcement
Server
MTA
M
Access
ER
M
ER
Signaling Transport (IP)
Media transport (IP)
MTA
MTA = Media Terminal Adapter
M = Access Modem
PSTN
G/W
ER = Edge Router

PSTN
Local
LD
Designed as a complete end-to-end signaling architecture for PacketCable
– Philosophy: encourage features and services in intelligent end-points, wherever
technically and economically feasible
– “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 9
DCS Architecture

Enhances SIP With Carrier Class Features
– Resource Management
– Privacy
– Authorization and Theft of Service issues

Tight Coupling Between Call Signaling And QoS Control
– Prevent Call Defects: don’t ring the phone if resources are unavailable
– Prevent Theft Of Service: associate usage recording and resource allocation,
ensuring non-repudiation
» provide the ability to bill for usage, without trusting end-points
» ensure quality requirements for service are met (e.g., don’t clip “Hello”)


Care taken to ensure untrusted end-points behave as desired
Privacy mechanisms built into architecture
10
DCS Architecture

Makes use of end-point intelligence
– useful from the point of view of new feature creation

Distribution of state
– Clients keep Call State
– Edge Routers keep Connection State
– DCS-Proxy only keeps Transaction State

Failure model minimizes service impacts due to component outages
11
DCS Architecture
DCSProxy+GC
DCSProxy+GC
Announcement
Server
MTA
M
ER
Access
ER
Signaling Transport (IP)
Media transport (IP)
M
MTA
MTA = Media Terminal Adapter
PSTN
G/W
M = Modem
ER = Edge Router
Call State
PSTN
Connection State
Local
LD
Transaction State
12
Example Call Flow
Authentication,
DCSAuthorization,
Proxy
Admission control
MTA
M
Access
ER
DCSProxy
Number-toAddress
Translation
Announcement
Server
INVITE (no ring)
CMTS
ER
ER
INVITE (no ring)
M
MTA
INVITE (no ring)

MTA issues an INVITE to destination E.164 (or other) address
– don’t know yet “what” resources are needed to “where”
– provider may choose to block a call if resources are unavailable
» but P(blocking) may be  P(call defect)



call defect: when the call fails after the parties are notified
Originating DCS-proxy performs authentication and authorization
Terminating DCS-proxy translates dest. number to local IP address
13
Example Call Flow (contd…)
200 OK
Setup
Gate
DCSProxy
Announcement
Server
200 OK
MTA


M
Access
DCSProxy
Setup
Gate
200 OK
ER
M
MTA
ER
200 OK communicates call parameters and gate identity to 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

Policy may be exercised either at Gate controller or associated policy
server
14
Resource Management: 1st Phase
Gatecontroller
Gatecontroller
Announcement
Server
MTA
M
Access
MTA
Backbone Reservation
PATH / Reserve

M
ER
ER
PATH / Reserve
MTA initiates resource reservation
– access resources are “reserved” after an admission control check
» this insures that resources are available when terminating MTA rings
– backbone resources are “reserved” (e.g., explicit reservation or “packet
marking”)

Originating MTA starts end-to-end handshake with terminating MTA
– originating MTA sends INVITE(ring), terminating MTA sends 180 RINGING,
200 OK
15
Resource Management: 2nd Phase
Gatecontroller
Gatecontroller
Announcement
Server
INVITE(ring)
MTA
M
Access
ER
ER
200 OK

MTA
180 Ringing
Commit/Commit Ack

M
Commit/Commit Ack
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
16
Critical Messages
and their Relationships

MTAO
ERO
GCO
GCT
ERT
MTAT
Resource Reservation
Starts ringback
INVITE (RING)
180 RINGING
200 OK
Call In Progress
17
“Gates” and Edge Router
Functionality

“Gates” in edge routers opened for individual calls
– call admission control and policing implemented in edge routers
» gate utilizes packet filters that already exist in edge routers: “allow a call
from this source to this destination” etc.
– gate allows communication between a source and a destination, for a particular
range of traffic parameters, and a particular duration
– however, policy is controlled by the proxy

Proxy sets up gate in edge router after Call Setup authorized
– permit access to managed network resources: users receive dependable QoS

MTA makes 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
18
Signaling Performance Requirements

Short post-dial delay
– no perceptible difference in post-dial delay compared to circuit-switched
network

Short post-pickup delay
– delay from when the user picks up a ringing phone and the voice path being
cut-through should be small
» called party’s “hello” must not be clipped
» calling party’s response to hearing the “hello” must also not be clipped


Probability of Blocking: a metric to which provider may engineer net
Probability of Call Defect (i.e., call that has both parties invited to
and then fails) due to lack of resources needs to be much smaller
– target rates not necessarily under the control of the provider

Flexibility in deployment of DCS-Proxy: start small.
19
SIP Extensions







Two-phase invite
OSPS (Operator Services Positioning System)
Billing info
Gate info
Call State
Ring indicator
Privacy
20
SIP Support needed for
Resource Management

Additional header in initial INVITE message
– No-Ring
= “NoRing” “:”
21
State Header

Motivation:
– Call state stored at endpoints by their SIP-Proxies during the initial INVITE exchange.
This allows Proxies to be stateless during the call.
– Endpoint passes state information to Proxies when call characteristics require change.
– State information includes, but is not limited to: participating endpoint information,
billing information.
– State information cannot be altered undetectably by endpoints.


Syntax of the State Header
State
= "State" ":" private
private
= alpha *alphanum
Usage:
– “State” header encrypted and signed by Proxy and sent to called endpoint in an
INVITE message.
– ‘State” header encrypted and signed by Proxy and sent to the calling endpoint in the
response to the INVITE.
22
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 this header
does not return “Busy”.
 Header
Format
OSPS = “OSPS” “:” OSPS-Tag
OSPS-Tag = “BLV” | “EI”
23
Call (QoS) Authorization

Client needs to know the location of GATE
– Gate-ID

= 1*alphanum
Header placed in messages from Proxy to Client
24
Proxy-Proxy: Billing header

Billing Information:
– Billing-ID = “DCS-Billing-ID” ”:” 1*unreserved
– Billing-Info= “DCS-Billing-Info” “:” hostport [“/”Key] “<“Acct-Data“>”
– Gate-Location = “DCS-Gate-Location” “:” hostport “/” Gate-ID [ Gate-Key]

User-param:
– telephone-subscriber = global-phone-number | local-phone-number | augmented-phone-number
user-param = “user=” ( “ip” | “phone” | “lnp-phone”)

Notes:
New headers should not be sent to User Agents. Only between Proxies. Also,
sensitive information (billing info) should only be passed on secure links.
25
Privacy (Outline Issues/Approaches)

Calling Identity Delivery Blocking (CIDB)
– Depends on trusted intermediary (DCS Proxy)
– User agent control

Inference attacks
– DNS name inference
– IP address inference
– Anonymizer proposals
– Potential exposures: From header field, Contact header field, Via header
fields, Call-ID, SDP parameters, RTCP
26
Summary






SIP is design basis of carrier class service in Packetcable
SIP extensions proposed (administrative policy, privacy, …)
RSVP Extensions also proposed (not covered in this presentation)
Dialogue underway between Packetcable members and IETF to
refine extension proposals
Packetcable vendors in various stages of prototyping and
implementation
Future work and open issues
– IP Address privacy issues
– Multiple administrative domain issues
– Interoperability with other SIP client issues
– LAESS Issues
27