[SIPForum-techwg] SIPconnect 1.1 - Microsoft proposal andadditional requirements

Wed May 14 16:35:54 EDT 2008

One quick question regarding number two:

Wasn't it the case that IETF was going to deprecate UDP in 3261? What happened to that?

This debate has been going on for years - perhaps the Forum could influence getting resolution there in IETF?

--------------------------------------
Joanne McMillen
Systems Engineer
Converged Communications Division
Avaya Inc.
Phone/Fax: +1.303.538.4060
Email: joanne at avaya.com

  ----- Original Message ----- 
  From: Russell Bennett 
  To: techwg at sipforum.org 
  Sent: Wednesday, May 14, 2008 12:58 PM
  Subject: [SIPForum-techwg] SIPconnect 1.1 - Microsoft proposal andadditional requirements

  All,

  The list has been very quiet since we submitted our proposal, so let me start the discussion.

  First of all, here some clarification / explanation  of the origin of the document.

  This *is* (as many of you will probably suspect) a *largely* neutralized version of a spec that we developed for our own purposes.  We have been working with Service Providers to come up with an interface definition that they and we can support for SIP Trunking.  We have reviewed that document with a number of Service Providers and most (but not all) have found no issue with our approach.

  I was asked by Rich Shockey and Scott Hoffpauir if we would be willing to submit that document to the TWG to "prime the pump" for SC1.1.  Our initial goal is to ease deployment of SIP Trunk solutions for everyone - so we were happy to do this.   The sections of the document that are Microsoft specific will be altered as a natural outcome of this process.

  I have received private feedback internally and externally that the document is incomplete: of this I have no doubt.  We, like everyone else, are limited to a view of the world from our own perspective - this is where collaboration among a group of well informed peers will rapidly drive a clean and easy to deploy standard.   

  I strongly suggest that we don't try to boil the ocean with myriad issues and requirements, albeit valid, that will go much beyond basic "call setup and teardown".   Our objective should be to develop a standard that makes it easy for vendors and service providers to adopt SC1.1.   We can "layer on" additional requirements in later versions of the standard that can be selectively adopted as required.

  That being said, let me comment on particular requirements that have been brought to my attention:

  1)      Definition of network elements:

  I have anonimized the elements that interface between two networks as "Enterprise Proxy" and "Service Provider Proxy".   These are logical elements that are capable of handling signaling and media.   There is no attempt to suggest or limit any capabilities of these elements beyond establishing voice sessions between two networks.  The bundling of additional value in these elements, including security features, is IMHO outside the scope of this effort.  Enterprises, Vendors and Service Providers are at liberty to define their own features and requirements that go beyond the transmission of voice traffic.

  2)      SIP Transport:

  I proposed UDP=MAY, TCP=MUST, TLS=MAY.  While this does not align perfectly with 3261, there is a strong argument for TCP as the base transport based on the fact that SIP messages tend to exceed 1500 bytes these days.  3261 says that a UA offering UDP must also offer TCP, but not vice versa:

  Making TCP mandatory for the UA is a substantial change from RFC 2543.  It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below.  Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.

  Many current SPs deviate from this, offering only UDP on the grounds that TCP is too resource intensive.  I believe that this can be resolved with TCP connection reuse.   Furthermore, "service provider proxies" in deployment today are capable of B2B'ing TCP to UDP - so this issue can be overcome via a choice that they are well able to implement.

  IMHO, it is too early to make TLS (or SRTP for that matter) a MUST, although this is a desirable longer term goal.  There are many issues to be worked out with respect to this, and we can layer communications security requirements onto the standard later.  For now, most (all?) SPs offer SIP Trunking on a closed data connection with a VPN, so resolving that issue is not urgent.

  3)      911/emergency calling, including provision of location information

  This is a regulatory requirement in some jurisdictions but not others, therefore it should be optional and arguably, covered in a later spec.  The advent of mobile IP communications has made this a difficult requirement to resolve 'automagically'.   There are vendors who attempt to resolve it but there is no clear standard.  At Microsoft, we are working on this, but have nothing to contribute to a standard at this time.

  4)      FAX

  This is an area that c/should be added to the discussion.

  5)      List of codecs to be offered

  Based on discussions with SPs, we understand that G.711 is not universally acceptable due to bandwidth utilization concerns and that G.722.1 (for example) would be a better choice.   I suggest that we limit the mandatory set of codecs to the minimum set of universally acceptable codecs and not mandate codecs that have onerous IP/royalty conditions attached to them.

  6)      Privacy

  This is a hot topic and various RFCs address this.  We take a very strict view of privacy that is implemented within our infrastructure, regardless of what is sent in the SIP message.  However, what is under consideration in this initiative is the definition of private SIP/RTP connection between a SP and an Enterprise (i.e. the sessions do not traverse untrusted intermediary network elements or public networks).  Therefore, I suggest that we defer privacy issues to a later version of the spec and assume for now that privacy is addressed in the trust relationship between those two entities.   

  7)      Other features, e.g. Transfer, Call History, etc.

  These are 'nice-to-haves' that can be dealt with later in order to speed completion of this initiative.  I suspect that support of these mechanisms is spotty and this will be an adoption blocker in the short term.  Per above, we should address the uber issue of SC1.0 non-adoption by making SC1.1 easy to adopt.  For example: it is not clear to me that Transfer is mandatory requirement in a SIP Trunk: this function should be handled by elements behind the Enterprise and Service Provider Proxies.   If Alice at x.com is in a call with Bob at y.com, she is unlikely to want to transfer Bob to Carol at y.com.

  Russell

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

  Russell Bennett

  Partner Program Manager

  Office Communications Group

  Microsoft Corporation

  One Microsoft Way

  Redmond, WA 98052-6399

  mailto:  russben at microsoft.com

  sip:         russben at microsoft.com

  tel:        +1 (425) 706-3622

  http://www.microsoft.com/uc/

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

  _______________________________________________
  techwg mailing list
  Send mail to: techwg at sipforum.org
  Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20080514/4dd81d16/attachment-0001.html 