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 theres 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 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 users 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-to- end (per RFC3261 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 doesnt want to use for some reason E.g., disable use of 100rel 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 says that all INVITEs MUST contain SDP, which implies that 3PCC cannot be used to establish calls Resolution: – Authors agree that 3PCC should be supported – Updated to limit scope of this section to session establishment when 3PCC isnt used For normal (non-3PCC) 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 that describes session establishment using 3PCC, where INVITE without SDP is allowed

Early Media from Multi Endpoints Comment: – Section Early Answer and 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 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 Dont 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 isnt ready to be referenced by this draft

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