1 IETF VoIP Peering BOF: Input on Inter-domain SIP Requirements for VoIP Peering Jean-François Mulé CableLabs

2 Agenda Overview of CableLabs ® PacketCable™ CMSS* Specification Examples of Use Cases Lessons learned *CMSS = Call Management Server Signaling Specification

3 CableLabs PacketCable CMSS Overview CMSS = IETF SIP + IETF SIP Extensions PacketCable CMSS –CMSS is the Call Management Server Signaling Specification –Part of PacketCable 1.5, version I01 available publicly at CMSS designed to provide vendor requirements for intra-domain and inter- domain SIP signaling for VoIP applications –CMSS was authored by many vendors involved in IETF based on original service requirements provided by cable MSOs CMSS comprises IETF Basic-SIP RFC 3261, plus the following IETF SIP Extensions: –SIP Extension requirements to support quality-of-service Network Resource Reservation pre-conditions Reliability of Provisional Responses (PRACK) –Extensions to support Regulatory & Billing Requirements (Electronic Surveillance, E911, malicious call trace) Asserted Identity in Trusted Networks (P-Asserted-Identity header) DCS proxy-proxy for event accounting, electronic surveillance, & operator services Uniform Resource Identifiers for telephone calls

4 CableLabs PacketCable CMSS Overview Extensions to support Feature Control: –Session parameter updates (UPDATE) for some call features, codec changes, FAX/modem, … –SIP REFER and Replaces header for advanced call features; e.g. call transfer, call park, conference –SIP SUBSCRIBE/NOTIFY to enable Message Waiting Indication and other “non- call” related features PacketCable 1.5 and SIP/CMSS

5 CableLabs PacketCable CMSS Overview IETF SIP Extensions – Partial List of RFC requirements

6 Examples of CMSS Use Cases Why we need PacketCable CMSS [or something like it] 1.Intra-domain, Inter-zone One administrative domain with multiple CMSes or SIP servers –Scenario-1.1: Flat-rate on-net call –Scenario-1.2: Call trace with number privacy –Scenario-1.3: Measured rate call 2.SIP carrier-to-PSTN One administrative domain, CMS “on-net”  MGC off-net –Scenario-2.1: Carrier selection: caller dials CIC –Scenario-2.2: Called number ported –Scenario-2.3: E911 with Privacy 3.Inter-SIP carriers (‘trusted’) Multiple administrative domains –Scenario-3.1: Measured rate call 4.Inter-SIP carriers (‘non-trusted’) –Scenario-4.1: Caller dials CIC & ported number –Scenario-4.2: E911 5.SIP Applications Voic s, etc. –Scenario-5.1: Visual MWI –Scenario-5.2: 3-way conference

7 E.g. Scenario-1.2: Call-Trace with Number Privacy Caller ID is masked in the From: field so that it is not displayed Caller ID is stored in the P-Asserted-ID field for routing purposes (911, call trace), and other call features (block), etc. [1]INVITE From: “anonymous” P-Asserted-ID: “anonymous” tel: Privacy: id critical Proxy-Require: Privacy Off-hook CMS1CMS2 MTA-1 MTA-2 Remainder of flow same as Scenario-1.1

8 Extension Matrix Extension Scenario Pre-ConditionsPRACKTel-URIP-DCSP-Asserted-IDUPDATEREFERReplacesHeaderEventNotifyVisual MWI Intra- domain, Inter-Zone Flat-rate on-net call Call-Trace with number privacy Measured rate call SIP carrier- to-PSTN Carrier Selection – caller dials CIC Called number ported E911 with Privacy Inter-carrier (trusted) Measured rate call Inter-carrier (non trusted) Caller dials CIC & ported number E911 SIP AppsVisual MWI 3-way Conference The choice of standard, private and future IETF SIP extension(s) for each service scenario can be largely debated. This is just an example, one view on how we meet requirements. This is where the difficulties of Inter- domain SIP arise in VoIP peering.

9 Lessons Learned VoIP SIP peering today No common way of addressing basic VoIP SIP requirements among SIP service providers Issues not limited to service provider model and not necessarily due to “walled garden approach”: end-user model also impacted (SIP UA vendors) Border elements seen as the current “patching solutions” for SIP ‘protocol normalization’ Difficult definition of trust boundaries between providers Various levels of support for common IETF SIP extensions (PRACK, p- asserted-id, UPDATE, etc.) but IETF SIP private extensions perceived as industry specific (e.g. RFC3603) CMSS Specification Enhancements: SIP Implementers should Build standard-based mechanisms for negotiating SIP extensions (Supported, Allow, Require headers) Provide configuration means for end-users and/or providers to be capable of configuring the mandatory/optional SIP extensions advertised in the SIP signaling and provide means for enforcing SIP signaling “policies”

10 Q&A Feedback welcome