Jean-François Mulé CableLabs jfm@cablelabs.com IETF VoIP Peering BOF: Input on Inter-domain SIP Requirements for VoIP Peering Jean-François Mulé CableLabs jfm@cablelabs.com

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

CableLabs PacketCable CMSS Overview CMSS = IETF SIP + IETF SIP Extensions CMSS is the Call Management Server Signaling Specification Part of PacketCable 1.5, version I01 available publicly at http://www.packetcable.com/specifications/specifications15.html http://www.packetcable.com/downloads/specs/PKT-SP-CMSS1.5-I01-050128.pdf 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

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

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

Examples of CMSS Use Cases Why we need PacketCable CMSS [or something like it] 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 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 Inter-SIP carriers (‘trusted’) Multiple administrative domains Scenario-3.1: Measured rate call Inter-SIP carriers (‘non-trusted’) Scenario-4.1: Caller dials CIC & ported number Scenario-4.2: E911 SIP Applications Voicemails, etc. Scenario-5.1: Visual MWI Scenario-5.2: 3-way conference

E.g. Scenario-1.2: Call-Trace with Number Privacy CMS1 CMS2 MTA-1 MTA-2 Off-hook [1]INVITE From: “anonymous” sip:anonymous@anonymous.invalid P-Asserted-ID: “anonymous” tel:+2125551212 Privacy: id critical Proxy-Require: Privacy Remainder of flow same as Scenario-1.1 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.

Extension Matrix Extension Scenario Intra-domain, Inter-Zone Pre-Conditions PRACK Tel-URI P-DCS P-Asserted-ID UPDATE REFER Replaces Header Event Notify Visual 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) (non trusted) Caller dials CIC & ported number E911 SIP Apps 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.

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”

Q&A Feedback welcome