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