Transcript SIP Interconnect Guidelines

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
3/29/2016
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
3/29/2016
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:
3/29/2016
– 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:
3/29/2016
– 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?