SIP Interconnect Guidelines draft-hancock-sip-interconnect-guidelines-03 David Hancock, Daryl Malas Topics Covered • What entity is responsible for supporting interconnect requirements? • Ensure local policies to limit extensions don’t stifle innovation • Audit these guidelines against similar work being done in other standards organizations Responsible Entity • Comment: – Interconnect interface requirements should not be placed the egress/ingress border elements – Rather, responsibility for meeting these requirements belongs to the SSP network as a whole • Resolution: – Expanded definition of SBE within context of this draft so that it includes all SIP entities in the SIP signaling chain within the SSP network that can affect SIP signaling on the peering interface Extension Negotiation • Comment: The following text inhibits transparent deployment of new extensions/services: – The SBE MAY support configuration controls to disable certain extensions based on bilateral agreement between peer networks. • Propose following note to resolve: – Policies that limit or block the use of SIP extensions should be applied with care, since their application tends to disable SIP's native extension negotiation mechanism, and therefore inhibit the deployment of new services. Standards Bodies Included in Review • • • • • IETF/SPEERMINT i3 Forum GSMA ITU-T 3GPP IMS SPEERMINT SIP Interconnect Guidelines • Purpose/Scope: – Resolve common SIP/SDP interworking issues between peer VoIP networks – Focus on basic voice services (base SIP plus small set of extensions) – Provide sufficient detail to avoid ambiguity • Describes “on the wire” SIP signaling procedures for the interconnect interface – Places requirements on the SSP network as a whole to support this interface, not on a specific SIP entity such as egress proxy i3 Forum - INTERNATIONAL INTERCONNECT FORUM FOR SERVICES OVER IP Domestic TDM/VoIP Provider A Carrier A NNI Carrier B Domestic TDM/VoIP Provider B • Documents: – IP international interconnections for voice & other related services (V 1.0) – Technical Interconnection Model for International Voice Services (Release 2.0) – White Paper – Mapping of Signalling Protocols ISUP to/from SIP,SIP-I • Purpose: – Describe interworking interface between international carrier networks connecting two domestic TDM or IP-based service provider networks 5/6/2019 Cable Television Laboratories, Inc. 2009. All Rights Reserved. Proprietary/Confidential. 7 i3 Forum - INTERNATIONAL INTERCONNECT FORUM FOR SERVICES OVER IP (cont’d) • Scope – – – – – – Transport Function (describes various IP interconnect arrangements) Signaling Functions (SIP – see below) Media Functions Security (topology hiding, IPSec encryption, access control) Quality of Service (jitter, packet loss, MOS scores) Accounting & Charging • Level of detail for SIP signaling – Defines high-level profile of RFC 3261, plus mandates short list of SIP extensions – Lists mandatory/optional SIP methods and headers with minimal additional detail – White Paper very ISUP focused 5/6/2019 Cable Television Laboratories, Inc. 2009. All Rights Reserved. Proprietary/Confidential. 8 GSMA - Global System for Mobile Communications Alliance Inter-Operator IP Backbone Service Provider Network A • Document: IPX Provider-X IPX Provider-Y IPX Proxy IPX Proxy DNS/ ENUM Service Provider Network B Service Provider Network C – Inter-Service Provider IP Backbone Guidelines (V 4.4) • Purpose: – Defines a hierarchical peering model where Inter-Operator IP Backbone provides interconnect services (e.g., routing, QoS) between peering SP partners – An SP can peer with multiple partners via a single connection to IP backbone • Scope: 5/6/2019 – Focuses on non-SIP aspects of interconnect – No significant Cable SIPTelevision guidelines provided Laboratories, Inc. 2009. All Rights Reserved. Proprietary/Confidential. 9 ITU-T Study Group 11 VoIP Provider A NNI VoIP Provider B PSTN PST N • Document: – Q.3401 NGN NNI signalling profile, March, 2007 • Purpose/Scope: – Define SIP/SDP requirements on NNI for basic voice • Level of detail: – Less detailed than SPEERMINT SIP Interconnect Guidelines • Defines profile of RFC 3261 and lists mandatory/optional support SIP & SDP RFCs – Does not describe SIP procedures associated with basic call features • Early media, call-fwd loop detection, Hold/Conf/Xfer, AC/AR 3GPP IMS S-CSCF I-CSCF BGCF BGCF Mx P-CSCF Mx I-CSCF S-CSCF Mx Mx P-CSCF Mx II-NNI Mx IBCF IBCF Mx Ici Ix Ix TrGW Signalling TrGW Izi Bearer IM CN subsystem network A Inter-IMS Networkto-Network Interface IM CN subsystem network B • Document: – TS 29.165 – Inter-IMS Network to Network Interface (V.9.1.0) • References many other IMS specs • Purpose: – Identify NNI requirements across a wide sweep of IMS specs – Define NNI profile where necessary • Scope: 5/6/2019 – Basic voice, plus ~20 supplemental MMTEL services – Charging, Security, IPv4/6 interworking, media Cable Television Laboratories, Inc. 2009. All Rights Reserved. Proprietary/Confidential. 11 3GPP IMS (cont’d) • Large number of IMS specs referenced – Base (app-agnostic) SIP procedures • IMS TS 24.229 • Identifies specific IBCF procedures (e.g., topology hiding) • Lists mandatory/optional support of all SIP/SDP parameters per request for Proxy and UA role (Annex-A tables ~250 pages) – Multi-Media Telephony (MMTEL) Services • Sixteen 24.xxx specs • IMS-specific procedures/mechanisms include – Private headers unique to IMS • e.g., P-Access-Network, P-Charging-Vector, P-Asserted-Service – IMS roaming, where UE registers with home network via IBCF – MMTEL Service URN urn:urn-7:3gpp-service.ims.icsi.mmtel Conclusion of Comparison • SPEERMINT SIP Interconnect Guidelines – Provides a unique and unmet need in enabling peering relationships • i3 Forum, GSMA, & ITU – Lack sufficient detail to address specific SIP/SDP interworking issues • 3GPP/IMS – Much broader scope than SPEERMINT interconnect doc • More services, more extensions – Very rigorous on specifying NNI level of support (yes/no) for a large number of signaling parameters (i.e., 24.229 Annex-A) – Less detail on guidance to resolve specific interworking issues • E.g., congestion control, call-fwd loop detection, early-media & forking – IMS-specific requirements do not universally apply to non-IMS networks Questions?