SIP Interconnect Guidelines

draft-hancock-sip-interconnect-guidelines-03David 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

04/19/23

Cable Television Laboratories, Inc. 2009. 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

DomesticTDM/VoIPProvider A

DomesticTDM/VoIPProvider A

DomesticTDM/VoIP Provider B

DomesticTDM/VoIP Provider B

NNICarrier ACarrier A Carrier BCarrier B

04/19/23

Cable Television Laboratories, Inc. 2009. 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

04/19/23

Cable Television Laboratories, Inc. 2009. All Rights Reserved. Proprietary/Confidential.

9

Inter-OperatorIP Backbone

Service Provider

Network A

Service Provider

Network A

Service Provider

Network B

Service Provider

Network B

IPXProxy

IPXProvider-X

IPXProxy

IPXProvider-Y

Service Provider

Network C

Service Provider

Network CDNS/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

PSTNPSTN PSTN

PSTN

NNI

04/19/23

Cable Television Laboratories, Inc. 2009. All Rights Reserved. Proprietary/Confidential.

11

3GPP IMS

• 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:– Basic voice, plus ~20 supplemental MMTEL services– Charging, Security, IPv4/6 interworking, media

IM CN subsystem network A IM CN subsystem network B

Ici

Izi

II-NNI

Mx

Ix

Mx

BGCF Mx

Mx

TrGW Signalling Bearer

Ix

Mx

BGCF Mx

Mx

TrGW

IBCF IBCF

S-CSCF I-CSCF

P-CSCF P-CSCF

S-CSCF I-CSCF

Inter-IMS Network-to-Network Interface

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?