IETF VoIP peering BOF
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
440
On Slideshare
440
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. IETF VoIP Peering BOF: Input on Inter-domain SIP Requirements for VoIP Peering Jean-François Mulé CableLabs [email_address]
  • 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
      • 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
  • 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]
    • 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
  • 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” 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. 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. 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