Re: [Speermint] New Draft: SIP Interconnect Guideline

["Elwell, John" <john.elwell at siemens.com>]

> -----Original Message-----
> From: David Hancock [mailto:D.Hancock at CableLabs.com] 
> Sent: 05 March 2009 21:29
> To: Elwell, John; Daryl Malas; speermint at ietf.org
> Subject: RE: [Speermint] New Draft: SIP Interconnect Guideline
> 
> Thanks for the comments, John.
> 
> Additional comments inline below.
> 
> David
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell at siemens.com]
> > Sent: Thursday, March 05, 2009 7:37 AM
> > To: Daryl Malas; speermint at ietf.org
> > Cc: David Hancock
> > Subject: RE: [Speermint] New Draft: SIP Interconnect Guideline
> > 
> > Daryl, David,
> > 
> > I like the initiative, and I was wondering whether it could apply
> > between two enterprise networks as well as between two service
> provider
> > networks. However, I think it might be too restrictive 
> (e.g., limiting
> > just to a single audio medium).
> 
> [dch] I think the scope of this work is open to discussion. 
> The idea was
> to start smaller rather than larger in terms of scope; provide
> guidelines for basic voice services as a doable first step, and then
> layer on more advanced capabilities as a future activity.
> 
> > 
> > One particular concern is that it is specified in terms of 
> "networks",
> > whatever that might mean, whereas endpoints (SIP UAs) will be
> > responsible for many aspects, e.g., anything to do with 
> SDP, provision
> > of local ringback tone, etc..
> 
> [dch] Our intention was to use the terminology and 
> architecture already
> defined for speermint. Although I notice that
> draft-ietf-speermint-terminology doesn't define the term "networks" so
> we may need to tighten up the terms in our draft to ensure there's no
> ambiguity in what we're talking about. As far as what entities must
> comply with these guidelines, I've been thinking of it like 
> this - these
> guidelines define the SIP signaling procedures as they appear on the
> interface between two peering networks. In other words, this draft
> places requirements on a peer network (using speermint terminology).
> Whether this requirements are met by a SIP endpoint served by that
> network, or an SBE (speermint term) at the peer interface point, is
> out-of-scope. 
> 
> > 
> > One item of interest is section 5.1.2.3 "Early media with multiple
> > terminating endpoints". The correct way of achieving this in SIP is
> the
> > third method (5.1.2.3.3), i.e., using multiple early 
> dialogs. Another
> > way, not mentioned here, is to use redirection as a means 
> of creating
> a
> > new dialog. I am concerned about the media anchor method 
> (5.1.2.3.1),
> > because that would constrain the call to using whatever attributes
> > (e.g., codec) are negotiated between the calling UA and the anchor,
> and
> > would deny the possibility of using a superior codec end-to-end if
> > supported by both UAs. Also it would prevent end-to-end 
> security using
> > security descriptions (say), since the security context negotiated
> with
> > the anchor would be used throughout the call. The early 
> answer method
> > (5.1.2.3.2) is likely to mislead the calling side as to what is
> actually
> > happening.
> 
> [dch] I agree that the forking option in 5.1.2.3.3 is the preferred
> option. We added the other media-anchor and early-answer options to
> reflect what's happening in the field today. Should these 
> other options
> be ruled out as not supported, or allowed as long as operators are
> willing to live with their inherent limitations? 
> 
> I hadn't thought of the using redirect in this context, but I agree it
> would work for some use cases (like call-forwarding 
> no-answer, where the
> called user identity changes). But I think there are some use cases
> where it wouldn't work (where the called user identity 
> doesn't change);
> e.g., user-A in peer network-1 calls user-b in peer network-2, and
> user-B has solicitor call blocking with pin override. The 
> call is first
> routed to a media server in network-2 to prompt for and 
> collect the PIN
> from user A (via a 2-way early-media session), and then delivered to
> user B which sends a 180 response with no SDP (on a new dialog) to
> instruct user-A's endpoint to provide local ringback tone. Does this
> line up with your understanding?
[JRE] I think it could be made to cover that situation too, by including
some sort of cookie in the 3xx contact URI or an embedded Route header
field, so that the new INVITE request can be linked to state in the
downstream SP.

John


> 
> > 
> > There seems to be a whole lot missing in the area of transport,
> > authentication, etc..
> 
> [dch] Agreed, am open to expanding the scope of this initial draft to
> cover other common interworking issues, as long we're pragmatic about
> what can be accomplished in a reasonable timeframe.
> 
> > 
> > John
> > 
> > 
> > 
> > ________________________________
> > 
> > 	From: speermint-bounces at ietf.org
> > [mailto:speermint-bounces at ietf.org] On Behalf Of Daryl Malas
> > 	Sent: 04 March 2009 23:38
> > 	To: speermint at ietf.org
> > 	Cc: David Hancock
> > 	Subject: [Speermint] New Draft: SIP Interconnect Guideline
> > 
> > 
> > 	All,
> > 
> > 	We have submitted a new draft beginning a process for defining a
> > SIP interconnect guideline for peering.   Of the operators I have
> spoken
> > with regarding their experiences with peering, SIP 
> interworking is the
> > most challenging process to work through.  Establishing a guideline
> will
> > be a fundamental step in enabling SSPs to peer quickly, efficiently,
> and
> > dynamically.
> > 
> > 	A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > 
> > 	    Title           :
> > draft-hancock-sip-interconnect-guidelines-00
> > 	    Author(s)       : D. Hancock, D. Malas
> > 	    Filename        :
> > draft-hancock-sip-interconnect-guidelines-00.txt
> > 	    Pages           : 25
> > 	    Date            : 2009-03-04
> > 
> > 	As Session Initiation Protocol (SIP) peering becomes more widely
> > 	accepted by service providers the need to define an interconnect
> > 	guideline becomes of greater value.  This document takes into
> > 	consideration the SIP and commonly used SIP extensions, and it
> > 	defines a fundamental set of requirements for SIP Service
> > Providers
> > 	(SSPs) to implement within their signaling functions (SFs) or
> > 	Signaling Path Border Elements (SBEs) for peering.
> > 
> > 	A URL for this Internet-Draft is:
> > 
> >
> http://www.ietf.org/internet-drafts/draft-hancock-sip-intercon
> nect-guide
> > lines-00.txt
> > 
> > 	Regards,
> > 
> > 	Daryl
> > 
> > 	-----------------
> > 	Daryl Malas
> > 	CableLabs
> > 	(o) +1 303 661 3302
> > 	(f) +1 303 661 9199
> > 	mailto:d.malas at cablelabs.com
> > 
> > 
> 
>