SIP Interconnect Guidelines

draft-hancock-sip-interconnect-guidelines-02David 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-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 doesn’t 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 5.1.2 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 5.1.2 to limit scope of this section to session

establishment when 3PCC isn’t 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 5.1.5 that describes session establishment using 3PCC, 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?