1 SIP Extensions QoS, Authentication, Privacy, Billing,... Project Packetcable John R. Pickens, PhD VP Technology and CTO

2 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 Acknowledgements

3 Problem Statement Cool Applications Desirable Service Revenue  Personal Policy == Cool Applications Administrative Policy == Desirable Service Revenue  SIP enables “personal policy”  How can SIP enable “administrative policy”?

4 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.

5 Packetcable Components

6 SIP Interfaces (Packetcable 1.1)

7 Call Management Server Interfaces Call AgentDCS-Proxy Gate Controller DQos Call Signaling QoS Signaling Translation, Congestion Control, PSTN DB access, Event recording, Routing Call Management Server (CMS) COPS DCS/SIP NCS/MGCP

8 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

9 Distributed Call Signaling Framework  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 PSTN MTAM PSTN G/W Local LD DCS- Proxy+GC DCS- Proxy+GC Signaling Transport (IP) Media transport (IP) Access MTA = Media Terminal Adapter M = Access Modem ER = Edge Router ER MMTA ER Announcement Server

10 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

11 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

12 Transaction State Connection State Call State DCS Architecture PSTN MTAM PSTN G/W Local LD DCS- Proxy+GC DCS- Proxy+GC Signaling Transport (IP) Media transport (IP) Access MTA = Media Terminal Adapter M = Modem ER = Edge Router ER MMTA ER Announcement Server

13 Example Call Flow  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 Authentication, Authorization, Admission control INVITE (no ring) Number-to- Address Translation INVITE (no ring) CMTS ER MTAM DCS- Proxy DCS- Proxy Access MMTA ER Announcement Server INVITE (no ring)

14 Example Call Flow (contd…)  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 200 OK Setup Gate Setup Gate 200 OK MTA M DCS- Proxy DCS- Proxy Access ER M Announcement Server

15 Resource Management: 1 st Phase  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 MTAM Gate- controller Gate- controller Access Backbone Reservation ER MMTA PATH / Reserve Announcement Server

16 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 MTAM Gate- controller Gate- controller Access ER MMTA INVITE(ring) Commit/Commit Ack Announcement Server 180 Ringing 200 OK

17 Critical Messages and their Relationships  200 OK (GID O, IP T, [CI T ](GC O )) INVITE (AI, E.164 T, CP O ) MTA O MTA T ER O ER T GC T GC O Call In Progress INVITE ($, CP O, E.164 T, CI O ) 200 OK ( IP T, CI T ) INVITE (RING) 180 RINGING Starts ringback 200 OK 200 OK ( IP T ) INVITE (GID T, E.164 T, CP O, [CI O ](GC T )) Resource Reservation

18 “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

19 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.

20  Two-phase invite  OSPS (Operator Services Positioning System)  Billing info  Gate info  Call State  Ring indicator  Privacy SIP Extensions

21 SIP Support needed for Resource Management  Additional header in initial INVITE message –No-Ring= “NoRing” “:”

22 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.

23 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”

24 Call (QoS) Authorization  Client needs to know the location of GATE –Gate-ID= 1*alphanum  Header placed in messages from Proxy to Client

25 Proxy-Proxy: Billing header  Billing Information: –Billing-ID = “DCS-Billing-ID” ”:” 1*unreserved –Billing-Info= “DCS-Billing-Info” “:” hostport [“/”Key] “ ” –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.

26 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

27 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