Your SlideShare is downloading. ×
0
IETF VoIP Peering BOF: Input on Inter-domain SIP Requirements for VoIP Peering Jean-François Mulé CableLabs [email_address]
Agenda <ul><li>Overview of CableLabs ®  PacketCable™ CMSS* Specification </li></ul><ul><li>Examples of Use Cases  </li></u...
CableLabs PacketCable CMSS Overview CMSS = IETF SIP + IETF SIP Extensions <ul><li>PacketCable CMSS </li></ul><ul><ul><li>C...
CableLabs PacketCable CMSS Overview <ul><li>Extensions to support Feature Control: </li></ul><ul><ul><li>Session parameter...
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] <ul><li>Intra-domain, Inter-zone One admin...
E.g. Scenario-1.2:  Call-Trace with Number Privacy <ul><li>Caller ID is masked in the From: field  so that it is not displ...
Extension Matrix The choice of standard, private and future IETF SIP extension(s) for each service scenario can be largely...
Lessons Learned <ul><li>VoIP SIP peering today </li></ul><ul><ul><li>No common way of addressing basic VoIP SIP requiremen...
Q&A Feedback welcome
Upcoming SlideShare
Loading in...5
×

IETF VoIP peering BOF

262

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
262
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "IETF VoIP peering BOF"

  1. 1. IETF VoIP Peering BOF: Input on Inter-domain SIP Requirements for VoIP Peering Jean-François Mulé CableLabs [email_address]
  2. 2. Agenda <ul><li>Overview of CableLabs ® PacketCable™ CMSS* Specification </li></ul><ul><li>Examples of Use Cases </li></ul><ul><li>Lessons learned </li></ul>*CMSS = Call Management Server Signaling Specification
  3. 3. CableLabs PacketCable CMSS Overview CMSS = IETF SIP + IETF SIP Extensions <ul><li>PacketCable CMSS </li></ul><ul><ul><li>CMSS is the Call Management Server Signaling Specification </li></ul></ul><ul><ul><li>Part of PacketCable 1.5, version I01 available publicly at </li></ul></ul><ul><ul><li>http://www.packetcable.com/specifications/specifications15.html http://www.packetcable.com/downloads/specs/PKT-SP-CMSS1.5-I01-050128.pdf </li></ul></ul><ul><li>CMSS designed to provide vendor requirements for intra-domain and inter-domain SIP signaling for VoIP applications </li></ul><ul><ul><li>CMSS was authored by many vendors involved in IETF based on original service requirements provided by cable MSOs </li></ul></ul><ul><li>CMSS comprises IETF Basic-SIP RFC 3261, plus the following IETF SIP Extensions: </li></ul><ul><ul><li>SIP Extension requirements to support quality-of-service </li></ul></ul><ul><ul><ul><li>Network Resource Reservation pre-conditions </li></ul></ul></ul><ul><ul><ul><li>Reliability of Provisional Responses (PRACK) </li></ul></ul></ul><ul><ul><li>Extensions to support Regulatory & Billing Requirements (Electronic Surveillance, E911, malicious call trace) </li></ul></ul><ul><ul><ul><li>Asserted Identity in Trusted Networks (P-Asserted-Identity header) </li></ul></ul></ul><ul><ul><ul><li>DCS proxy-proxy for event accounting, electronic surveillance, & operator services </li></ul></ul></ul><ul><ul><ul><li>Uniform Resource Identifiers for telephone calls </li></ul></ul></ul>
  4. 4. CableLabs PacketCable CMSS Overview <ul><li>Extensions to support Feature Control: </li></ul><ul><ul><li>Session parameter updates (UPDATE) for some call features, codec changes, FAX/modem, … </li></ul></ul><ul><ul><li>SIP REFER and Replaces header for advanced call features; e.g. call transfer, call park, conference </li></ul></ul><ul><ul><li>SIP SUBSCRIBE/NOTIFY to enable Message Waiting Indication and other “non-call” related features </li></ul></ul>PacketCable 1.5 and SIP/CMSS
  5. 5. CableLabs PacketCable CMSS Overview IETF SIP Extensions – Partial List of RFC requirements
  6. 6. Examples of CMSS Use Cases Why we need PacketCable CMSS [or something like it] <ul><li>Intra-domain, Inter-zone One administrative domain with multiple CMSes or SIP servers </li></ul><ul><ul><li>Scenario-1.1: Flat-rate on-net call </li></ul></ul><ul><ul><li>Scenario-1.2: Call trace with number privacy </li></ul></ul><ul><ul><li>Scenario-1.3: Measured rate call </li></ul></ul><ul><li>SIP carrier-to-PSTN One administrative domain, CMS “on-net”  MGC off-net </li></ul><ul><ul><li>Scenario-2.1: Carrier selection: caller dials CIC </li></ul></ul><ul><ul><li>Scenario-2.2: Called number ported </li></ul></ul><ul><ul><li>Scenario-2.3: E911 with Privacy </li></ul></ul><ul><li>Inter-SIP carriers (‘trusted’) Multiple administrative domains </li></ul><ul><ul><li>Scenario-3.1: Measured rate call </li></ul></ul><ul><li>Inter-SIP carriers (‘non-trusted’) </li></ul><ul><ul><li>Scenario-4.1: Caller dials CIC & ported number </li></ul></ul><ul><ul><li>Scenario-4.2: E911 </li></ul></ul><ul><li>SIP Applications Voicemails, etc. </li></ul><ul><ul><li>Scenario-5.1: Visual MWI </li></ul></ul><ul><ul><li>Scenario-5.2: 3-way conference </li></ul></ul>
  7. 7. E.g. Scenario-1.2: Call-Trace with Number Privacy <ul><li>Caller ID is masked in the From: field so that it is not displayed </li></ul><ul><li>Caller ID is stored in the P-Asserted-ID field for routing purposes (911, call trace), and other call features (block), etc. </li></ul>[1]INVITE From: “anonymous” sip:anonymous@anonymous.invalid P-Asserted-ID: “anonymous” tel:+2125551212 Privacy: id critical Proxy-Require: Privacy Off-hook CMS1 CMS2 MTA-1 MTA-2 Remainder of flow same as Scenario-1.1
  8. 8. Extension Matrix 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. 3-way Conference Visual MWI E911 Caller dials CIC & ported number Measured rate call E911 with Privacy Called number ported Carrier Selection – caller dials CIC Measured rate call Call-Trace with number privacy Flat-rate on-net call SIP carrier-to-PSTN Inter-carrier (trusted) Inter-carrier (non trusted) SIP Apps Intra-domain, Inter-Zone Extension Scenario Visual MWI Event Notify Replaces Header REFER UPDATE P-Asserted-ID P-DCS Tel-URI PRACK Pre-Conditions
  9. 9. Lessons Learned <ul><li>VoIP SIP peering today </li></ul><ul><ul><li>No common way of addressing basic VoIP SIP requirements among SIP service providers </li></ul></ul><ul><ul><ul><li>Issues not limited to service provider model and not necessarily due to “walled garden approach”: end-user model also impacted (SIP UA vendors) </li></ul></ul></ul><ul><ul><ul><li>Border elements seen as the current “patching solutions” for SIP ‘protocol normalization’ </li></ul></ul></ul><ul><ul><ul><li>Difficult definition of trust boundaries between providers </li></ul></ul></ul><ul><ul><li>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) </li></ul></ul><ul><li>CMSS Specification Enhancements: SIP Implementers should </li></ul><ul><ul><li>Build standard-based mechanisms for negotiating SIP extensions (Supported, Allow, Require headers) </li></ul></ul><ul><ul><li>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” </li></ul></ul>
  10. 10. Q&A Feedback welcome
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×