Re: [Speermint] New Draft: SIP Interconnect Guideline

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

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).
 
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..
 
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.
 
There seems to be a whole lot missing in the area of transport,
authentication, etc..
 
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-interconnect-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