SIP Interconnect Guidelines drafthancocksipinterconnectguidelines02 David Hancock Daryl Malas

SIP Interconnect Guidelines draft-hancock-sip-interconnect-guidelines-02 David Hancock, Daryl Malas

Background • Overall goal of SIP Interconnect Guidelines – Reduce the cost of establishing peering relationships between SSP networks • Why there’s a problem – SSPs tend to have their own unique “SIP interconnect guidelines” – SSPs establishing peering relationships spend majority of time resolving interop issues – SSPs indicate that this is the most challenging part of peering, and typically dedicate groups and tools just for interop testing • How this draft solves the problem – Establishes a common, required framework for SIP peering to resolve common interop issues – Defines the following aspects of SIP at the peering interface • Framework for SIP and a common set of SIP extensions • Common use of SIP parameters • Actions associated with requests and responses – Allows flexibility for bilateral agreements to add SIP and media functionality as desired

Major Changes to Resolve Version-01 Comments

Expand Scope • Comment: expand scope to include… – Enterprise peering – Sessions involving multiple media types beyond voice • Resolution: comments incorporated… – Updated section 1. 1 “Scope” to include • Enterprise peering • Multi-media (voice, video, RTT) • Did not add any interworking use-cases unique to enterprise peering – Updated section 5. 1. 1. “SDP Requirements” • Added support for multiple SDP media descriptors

Requirement Entity • Comment: – Draft is inconsistent in naming target entity responsible for meeting requirements of peering interface – For example, the draft places SIP requirements on all of the following • • SBE Originating network SIP UA SIP entity involved in session peering • Resolution: – Make the SBE responsible for all SIP requirements – One issue with this solution • As defined in Speermint architecture draft, SBE is a border element that can take on a variety of roles, including a firewall or SIP proxy that largely transparent to SIP signaling • In these cases the responsibility for meeting a peering requirement really belongs to a SIP entity beyond the SBE, such as a SIP UA in a user’s endpoint device – How issue was resolved • 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: – Why is there text that says an SBE can remove extensions from the Supported header? – Instead, why not let the SIP endpoints negotiate SIP extensions end-toend (per RFC 3261 extension negotiation procedures)? • Resolution – The original reason for this requirement was to provide a way for the operator to disable a specific extension that is supported by peering networks, but that the operator doesn’t want to use for some reason • E. g. , disable use of ‘ 100 rel’ because it adds message traffic and therefore affects scaling – To accommodate this operator requirement while still supporting the spirit of end-to-end extension negotiation, added the following text: • “The SBE MAY support configuration controls to disable certain extensions based on bilateral agreement between peer networks. ”

Initial INVITE with no SDP • Comment: – Section 5. 1. 2 says that all INVITEs MUST contain SDP, which implies that 3 PCC cannot be used to establish calls • Resolution: – Authors agree that 3 PCC should be supported – Updated 5. 1. 2 to limit scope of this section to session establishment when 3 PCC isn’t used • For normal (non-3 PCC) session establishment, we want to encourage the originating network to offer SDP with the initial INVITE in order to avoid answer-clipping – Added new section 5. 1. 5 that describes session establishment using 3 PCC, where INVITE without SDP is allowed

Early Media from Multi Endpoints • Comment: – Section 5. 1. 2. 3. 1 “Early Answer” and 5. 1. 2. 3. 2 “Media Anchor” are not really acceptable mechanisms for supporting early media from multiple terminating endpoints • They can cause billing and codec negotiation and issues – This case can also be supported by Re-directing the INVITE • Resolution: authors agree – The Early-Answer and Media-Relay mechanisms were removed – The INVITE-redirect procedure as added as an option, in addition to the already defined “sequential forking” mechanism

Call Forward Loop Detection • Comment – How is History-Info used to detect call-forwarding loops? • Resolution: – Updated section 5. 3. 1. to… • Mandate that a loop-detection and max-number-of-forwards mechanism must be supported • Describe how H-I can be used to support both of these • SBEs SHOULD support this H-I mechanism – Moving forward, should we… • Mandate support for a single loop detection mechanism (e. g. , using H-I header) • Allow support for multiple loop-detection mechanisms, and specify how they interwork • Don’t mandate support for a loop detection mechanism

Auto-Recall/Callback • Comment: – Clarify how dialog-event package is used to support Auto-Recall/Callback • Resolution – Updated section 5. 6 to describe the procedure for support of AC/AR, using the dialog-event package to detect when the target line becomes available – Note, BLISS is defining a mechanism for AC/AR, but at this point it isn’t ready to be referenced by this draft

Question • Is there interest in making this a working group item?