1. SIP Interconnect Guidelines draft-hancock-sip-interconnect-guidelines-01 David Hancock, Daryl Malas

2. 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

3. Major Changes to Resolve Version-00 Comments

4. Section 4.1 Extension Negotiation Comment: clarify that … – Extensions in a Supported header must be supported by the calling UA, not the “network” – The SBE can remove extensions/methods from the Supported/Allow header, but should not add them Resolution: comment incorporated… – E.g., "… on sending a dialog initiating request to a peer network, the SBE MUST ensure that all the SIP extensions identified in the Supported header field are supported by the sending UA"

5. Section 4.2 Public User IDs Comments: – Mandate lower-case "sip" – Requirement to assume that an "rn" parameter missing the country code belongs to North America is too NANP-centric Resolution: comments incorporated

6. 5.1.2.1 Basic Call Setup Comment: – Inconsistency 5.1.2.1 says initial INVITE MUST contain an SDP offer, while 5.4.2 allows 3PCC to be used for call xfer, which implies offer-less INVITEs – Too restrictive Mandating that PRACK MUST not be used breaks interworking with networks that require PRACK Resolution – Updated 5.1.2.1 to clarify that scope is basic 2-way call establishment not using 3PCC – Removed requirement to disable PRACK

7. Section 5.4.1 Call-Transfer Using REFER/Replaces Comment: – Text refers to RFC 3603 (5503), which is too PacketCable-specific Resolution: – Since the text was referring to this RFC only for the "private URL", removed reference and described private URL inline

8. Version-00 Comments that Need More Discussion

9. Scope Current scope – Define SIP/SDP/RTP interworking procedures to support basic voice calls between peering Service Provider networks Comments – Increase scope to... Add Interworking between peering enterprise networks Add transport, security, authentication procedures Add non-voice media such as video – Reduce scope Cover only lower-level hop-by-hop issues specific to the peering interface such as NAPTR, SRV, TLS, and congestion Exclude endpoint SIP procedures that happen to cross the session peering interface Discussion – Moving enterprise network peering in-scope – while outside the scope originally envisaged by the authors, we don’t think the requirements will change dramatically if we move this in-scope – Reducing scope to lower-level issues – authors disagree, since this would defeat the stated goal reducing the SIP interworking issues between peer SSP networks

10. Clarify Target Entity for Requirements Comment: Text is inconsistent & ambiguous in identifying the entity responsible for supporting requirements – E.g. current text places requirements on entities such as "originating network" "terminating network" "SIP entities involved in session peering" Proposal: place requirements on entity defined in reference architecture – On SBE/DBE, if primary use of document is to ask egress/ingress SBC vendors “Does your product comply with this RFC?” – On SSP, if primary use is to ask operators “Does your network comply with this RFC?” +------+ | DNS, | +---------->| Db, |<---------+ | | etc | | | +------+ | | | ------|-------- -------|------- / v \ / v \ | +--LUF-+ | | | | | | +------+ | | | | +--LRF-+ | | | | | | +------+ | | | | +---SF--+ +---SF--+ | | | | | | SBE | | SBE | | | Originating | | | | Target | | +---SF--+ +---SF--+ | | SSP | | +---MF--+ +---MF--+ | | | | | | DBE | | DBE | | | | | | +---MF--+ +---MF--+ | \ / \ / --------------- --------------- Reference Architecture

11. 5.1.2.3 Early Media from Multiple Endpoints Comment – the "correct" way of supporting early media from multiple terminating media endpoints before answer is the "sequential forking" solution – The other documented mechanisms (early-answer, media anchor, etc) all have disadvantages – There is one additional mechanism – using redirection to establish a new media session to the new media endpoint Resolution – Agreed – Updates in progress to re-org section Focus on the “forking” solution Add the “redirect” solution as an alternative Relegate other mechanisms to “work-arounds” with known deficiencies

12. Section 5.3 Call Forwarding Relying on History-Info header as a loop detection mechanism is problematic – H-I not widely implemented – Therefore, H-I unlikely to survive along the signaling chain Resolution: – Propose that we keep this requirement – History-Info is the only standard loop-detection mechanism available, and therefore we would like to encourage / promote its wide-spread adoption

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