IETF VoIP Peering BOF:
Input on Inter-domain SIP
Requirements for VoIP Peering
Jean-François Mulé
CableLabs
jfm@cablelabs.com
1
Agenda
• Overview of CableLabs® PacketCable™
CMSS* Specification
• Examples of Use Cases
• Lessons learned
2
*CMSS = Call Management Server Signaling Specification
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 interdomain 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
3
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 “noncall” related features
Administrative Domain 2
Administrative Domain 1
`
`
SIP
MSO A
Zone 1
CMS
CMSS
CMS
MSO B
Zone 3
PSTN
Gateway
SIP
Managed
IP Backbone
CMSS
`
MSO A
Zone 2
PSTN
SIP
SIP
CMS
Servers
CMS
CMSS
PSTN
`
PSTN
Gateway
`
PSTN
Gateway
MSO C
Zone 4
PSTN
Administrative Domain 3
4
PacketCable 1.5 and SIP/CMSS
CableLabs PacketCable CMSS Overview
IETF SIP Extensions – Partial List of RFC requirements
IETF RFC
RFC 3261
RFC 3262
RFC 3265
RFC 3311
RFC 3312
RFC 3323
RFC 3325
RFC 3420
RFC 3603
RFC 3515
RFC 3891
Name
SIP
Reliability of Provisional Responses in SIP (PRACK)
SIP-Specific Event Notification
SIP UPDATE Method
Integration of Resource Management and SIP for IP Telephony
A Privacy Mechanism for the Session Initiation Protocol
Private Extensions to SIP for Asserted Identity within Trusted Networks
Internet Media Types message/sip and message/sipfrag
Private SIP Proxy-to-Proxy Extensions for Supporting the PacketCable DCS
SIP REFER Method
SIP Replaces Header
RFC 2806/3966 URLs for Telephone Calls
Internet-Draft Tel URI to support Number Portability
RFC 3842
A Message Summary and Message Waiting Indication Event Package for SIP
etc…
this list is not exhaustive and will evolve based on service requirements
Nickname
SIP
PRACK
Event Notification
UPDATE
precondition
privacy
p-asserted-ID
sipfrag
DCS
REFER
Replaces
tel URL
tel extensions
mwi
and IETF updates
(note: current CMSS may still point to some IDs that have become RFCs since last publication)
5
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.
3.
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
4.
Inter-SIP carriers (‘non-trusted’)
–
–
5.
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
6
E.g. Scenario-1.2:
Call-Trace with Number Privacy
CMS1
CMS2
MTA-2
MTA-1
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.
7
Extension Matrix

















Inter-carrier
(trusted)
Inter-carrier Caller dials CIC & ported
(non trusted) number
E911
SIP Apps
Visual MWI
3-way Conference




Visual MWI



Event
Notify




Replaces
Header




REFER



UPDATE
Measured rate call
Carrier Selection – caller
dials CIC
Called number ported
E911 with Privacy
Measured rate call
P-AssertedID


P-DCS


Tel-URI
Flat-rate on-net call
Call-Trace with number
privacy
PRACK
SIP carrierto-PSTN
PreConditions
Intradomain,
Inter-Zone
Extension
Scenario
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 Interdomain SIP arise in
VoIP peering.





8
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, passerted-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”
9
Q&A
Feedback welcome
10