Subject: [Speermint] Summary of v01->v02 updates to draft-hancock-sip-interconnect-guidelines

From: "David Hancock" <[email-masked]>
Date: Wed, 4 Nov 2009 15:18:58 -0700

Here is a summary of the major updates between v01 and v02 of the
draft-hancock-sip-interconnect-guidelines.

--------------------------------------------------

Comment-1:

Expand scope to include enterprise peering (John Elwell):

Resolution:

Added following sentence to section 1...

"This document describes the SIP interconnect procedures between two
SIP-based networks for both peering SIP Service Providers networks and
peering Enterprise networks."

--------------------------------------------------

Comment-2:

Expand scope to include video and RTT media types (Gunnar Hellstrom,
Hadriel Kaplan)

Resolution:

Updated sections 1.1 and 5.1.1 to allow multiple media types.

--------------------------------------------------

Comment-3:

Be more specific and consistent when identifying the entity that is
responsible for meeting the peering requirements. For example, current
text places requirements on a variety of entities, such as "originating
network", or "SIP UA" - entities that are not defined as part of the
Speermint architecture. (John Elwell)

Resolution:

Placed requirements on the SBE and DBE throughout document. One slight
problem with this approach is that the SBE (for example) can play the
role of a firewall or a SIP proxy that is largely transparent to SIP
messages crossing the peering interface. It doesn't make sense to put
SIP requirements on an SBE acting as a firewall. Therefore, added text
to section 3 that expands the definition of SBE slightly (only within
the scope of this document) so that when it is specified as the target
entity of a normative requirement on the SIP/SDP peering interface, the
SBE represents all the SIP entities in the SIP signaling chain that can
effect the SIP/SDP peering interface. Made a similar local definition
change to the DBE.  

--------------------------------------------------

Comment-4:

Align section 4.1 "Extension Negotiation" text with RFC 3261. 

Also, text says that SBE can remove extensions from the Supported
header. Why not exchange Supported headers transparently, and let both
ends negotiate what extensions are used using RFC 3261 procedures? This
would allow operators to deploy new extensions without impacting the
interface. (Comment from IETF#75 Speermint session)

Background:

The reason for having the SBE remove an extension from the Supported
header was to cater to the situation where an endpoint supports an
extension (and puts it in Supported header), but the operator doesn't
want the extension used. For example, an operator deploys SIP endpoints
that support PRACK. However, on receiving an INVITE containing '100rel'
in the Supported header, the terminating peer network always sends
responses reliably, which increases per-call message traffic and affects
scaling. Therefore, the home operator wants to remove '100rel' from
Supported header, so calls are established without PRACK. 

Resolution:

Reworded section 4.1 text as follows...

"The SBE MUST identify all supported SIP extensions in the Supported
header. The SBE MAY support configuration controls to disable certain
extensions based on bilateral agreement between peer networks.  For
example, the SBE could be configured to remove '100rel' from the
Supported header in order to disable the use of reliable provisionable
response (PRACK)."

--------------------------------------------------

Comment-5:

Current text in section 5.1.2 "Basic Call Setup" implies that all
INVITEs MUST contain SDP, which would prevent the use of 3PCC to
establish calls (since 3PCC procedures send INVITE's with no SDP). (John
Elwell)

Resolution:

Agree that 3PCC should be supported. Therefore, added text to 5.1.2 that
says this section covers basic call setup for the non-3PCC case. Added
new section 5.1.5 to cover session establishment using 3PCC.

--------------------------------------------------

Comment-6:

The Media Anchor (section 5.1.2.3.1) and Early Answer (section
5.1.2.3.2) mechanism for providing early media from multi terminating
endpoints is not right (John Elwell, Hadriel Kaplan). Also, 302-Redirect
can be used to support his case (John Elwell).

Resolution:

Sections 5.1.2.3.1 & 2 were added to describe mechanisms currently
deployed to support this use-case. However, these mechanisms basically
hide the issue and make the call look like a normal 2-way call (and
therefore don't impact the peering interface). Therefore, they were
removed, and the overall section was re-organized to reduce section
numbering depth. Also, added a new section 5.1.4.2 to describe the
Redirect mechanism.

--------------------------------------------------

Comment-7:

How is History-Info used to support call-forwarding loop detection?
Also, H-I support may not be sufficiently ubiquitous to serve as a good
solution. Aren't there other mechanisms that can be used, such as
Diversion header, or Max-Forwards header? (Hadriel Kaplan, plus
discussion at IETF#75)

Resolution:

Based on the discussion, there seems to be no good, well understood and
universally supported solution for call-fwd loop detection. However, the
draft authors believe that support of call-forward loop-detection is
critical, and that the draft should provide some guidance on a standard
way to support it at the peering interface. Therefore, added a new
section 5.3.1 that a) mandates that the SBE MUST detect call-fwd loops,
and b) must reject a call that when the number of times it has been
forwarded exceeds a configurable limit. The section then gives some
latitude on how this is done, but describes one way using the
History-Info header. If an SBE supports the H-I mechanism, then it MUST
do it as described in this section. 

Question to Speermint members: is the above approach in the right
direction? Does the described H-I solution solve the problem, and should
we mandate that as the one-and-only standard (possibly with more
detail)? The idea would be - you can track call-forwarding loops using
any mechanism you want inside your network, but at the peering interface
you have to use the H-I header. Or, should the draft describe multiple
solution options, and describe how they interwork?

--------------------------------------------------

Comment-8:

It's not clear how the dialog-even package is used to support
auto-recall/callback. (Hadriel Kaplan)

Response:

The BLISS WG is working on a new draft-ietf-bliss-call-completion that
defines a new event-package for support of auto-recall/callback.
However, this is still a work-in-progress and therefore not ready to be
referenced by this interconnect-guidelines draft. In the meantime, the
authors propose that the already-defined dialog-event package can be
used to provide 90% of the AC/AR functionality. Therefore, text was
added to section 5.6 to more fully describe the dialog-event package
solution.

--------------------------------------------------

Thanks

David