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

8/13/2015 Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 7 i3 Forum - INTERNATIONAL INTERCONNECT FORUM FOR SERVICES OVER IP 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 Domestic TDM/VoIP Provider A Domestic TDM/VoIP Provider A Domestic TDM/VoIP Provider B Domestic TDM/VoIP Provider B NNI Carrier A Carrier B

8/13/2015 Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 8 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

GSMA - Global System for Mobile Communications Alliance Document: – 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: – Focuses on non-SIP aspects of interconnect – No significant SIP guidelines provided 8/13/2015 Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 9 Inter-Operator IP Backbone Service Provider Network A Service Provider Network B IPX Proxy IPX Provider-X IPX Proxy IPX Provider-Y Service Provider Network C DNS/ ENUM

ITU-T Study Group 11 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 VoIP Provider A VoIP Provider A VoIP Provider B VoIP Provider B PSTN NNI

8/13/2015 Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 11 3GPP IMS Document: – TS – 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: – Basic voice, plus ~20 supplemental MMTEL services – Charging, Security, IPv4/6 interworking, media Inter-IMS Network- to-Network Interface

3GPP IMS (cont’d) Large number of IMS specs referenced – Base (app-agnostic) SIP procedures IMS TS 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., 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?