Title: SIP Extensions QoS, Authentication, Privacy, Billing, ... Project Packetcable
1SIP ExtensionsQoS, Authentication, Privacy,
Billing, ...Project Packetcable
- John R. Pickens, PhD
- VP Technology and CTO
- jpickens_at_com21.com
- 408 953 9228
2Acknowledgements
- 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
- ATT, CableLabs, 3Com, Cisco, Com21, General
Instrument, Lucent Cable, NetSpeak, Telcordia
3Problem Statement
- Personal Policy Cool ApplicationsAdministrat
ive Policy Desirable Service Revenue - SIP enables personal policy
- How can SIP enable administrative policy?
4Project 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.
5Packetcable Components
6SIP Interfaces (Packetcable 1.1)
7Call Management Server Interfaces
NCS/MGCP
DCS/SIP
Translation, Congestion Control, PSTN
DB access, Event recording, Routing
Call
Signaling
Call Agent
DCS-Proxy
QoS
Gate Controller
Signaling
DQos
Call Management Server (CMS)
COPS
8Requirements from a Service Providers 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 - Cant 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 - dont keep state for stable calls in proxies
end-points can keep state associated with their
own calls
9Distributed Call Signaling Framework
DCS- ProxyGC
DCS- ProxyGC
Announcement Server
M
MTA
ER
Signaling Transport (IP)
ER
Media transport (IP)
MTA Media Terminal Adapter
PSTN G/W
M Access Modem
ER Edge Router
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
10DCS 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 dont 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., dont clip Hello) - Care taken to ensure untrusted end-points behave
as desired - Privacy mechanisms built into architecture
11DCS 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
12DCS Architecture
13Example Call Flow
Number-to-Address Translation
Authentication, Authorization, Admission control
DCS- Proxy
DCS- Proxy
Announcement Server
M
MTA
CMTSER
ER
ER
- MTA issues an INVITE to destination E.164 (or
other) address - dont 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
14Example Call Flow (contd)
DCS- Proxy
DCS- Proxy
Announcement Server
MTA
M
ER
MTA
M
ER
Access
- 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
15Resource Management 1st Phase
Gate- controller
Gate- controller
Announcement Server
M
MTA
ER
ER
- 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
16Resource Management 2nd Phase
Gate- controller
Gate- controller
Announcement Server
M
MTA
ER
ER
- 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
17Critical Messages and their Relationships
MTAO
MTAT
ERO
ERT
GCT
GCO
INVITE (AI, E.164T, CPO)
INVITE (, CPO, E.164T, CIO)
INVITE (GIDT, E.164T, CPO, CIO(GCT))
200 OK (IPT, CIT)
200 OK (IPT)
200 OK (GIDO, IPT, CIT(GCO))
Resource Reservation
Starts ringback
INVITE (RING)
180 RINGING
200 OK
Call In Progress
18Gates 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
19Signaling 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 partys hello must not be clipped
- calling partys 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.
20SIP Extensions
- Two-phase invite
- OSPS (Operator Services Positioning System)
- Billing info
- Gate info
- Call State
- Ring indicator
- Privacy
21SIP Support needed forResource Management
- Additional header in initial INVITE message
- No-Ring NoRing
22State 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.
23OSPS 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
24Call (QoS) Authorization
- Client needs to know the location of GATE
- Gate-ID 1alphanum
- Header placed in messages from Proxy to Client
25Proxy-Proxy Billing header
- Billing Information
- Billing-ID DCS-Billing-ID 1unreserved
- Billing-Info DCS-Billing-Info hostport
/Key ltAcct-Datagt - 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) - NotesNew headers should not be sent to User
Agents. Only between Proxies. Also, sensitive
information (billing info) should only be passed
on secure links.
26Privacy (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
27Summary
- 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