[SIPForum-techwg] SIPConnect 1.1 - Microsoft proposalandadditional requirements- TCP

Wed May 14 17:58:22 EDT 2008

I would encourage the group to look at the issue beyond the technical
merits.  In my mind SIPConnect is all about encouraging
interoperability; we all benefit from the rapid adoption of this
paradigm.  Based on my experience, I would suspect that there is a
significant installed base of IP-PBXs that can't support a SIP over TCP
solution without a significant software upgrade and potentially large
hardware investments.  I'm also concerned that some vendors will delay
adoption when they are forced to upgrade portfolio elements to make
their solutions compliant.  Worse, they could burden solutions with
convoluted translation devices.  Making a change like this can have
significant "ripple" effects that we should not discount.  It would seem
that Microsoft has made a wise strategic decision with their
architecture but I think we have to recognize that this is a new design
and we could be unintentionally burdening businesses that took our
advice and moved to a VoIP solution so they would be "ready" for the
future.  I don't want to stop time but I think we'll more likely need a
dual solution that accommodates either in some way.  Perhaps It might
mean two levels of compliance (like b and g in wireless)?  I'm not going
to suggest how but I think the goal needs to be considered.

I would also like to understand Microsoft's plans for RT Codec support?
I'm a big fan of wideband codecs such as G722.1 and RT so I believe such
solutions should be included but it seems that more common narrowband
codecs like G.729 need to be there.  Most of the IP phones older than
14-18 months can't support G.722.1  and most are already licensed for
729.

Cheers,

Greg Zweig

Sonus Networks. Inc

(978) 614-8027

________________________________

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Francois Audet
Sent: Wednesday, May 14, 2008 5:04 PM
To: Joanne McMillen; Russell Bennett; techwg at sipforum.org
Subject: Re: [SIPForum-techwg] SIPconnect 1.1 - Microsoft
proposalandadditional requirements

Right. We talked about defining draft-ietf-sip-outbound to work only
with TCP, but people didn't want to do this.

I don't expect a formal deprecation of UDP until there is a SIP 3.0,
which there are no plans for today.

________________________________

	From: Joanne McMillen [mailto:joanne at avaya.com] 
	Sent: Wednesday, May 14, 2008 14:00
	To: Audet, Francois (SC100:3055); Russell Bennett;
techwg at sipforum.org
	Subject: Re: [SIPForum-techwg] SIPconnect 1.1 - Microsoft
proposal andadditional requirements

	I agree with the proposal as well for mandating TCP in the Forum
- just wanted to know if anyone had the answer to

	the IETF question since we will indeed be "a bit non-compliant"
with 3261 when making the mandate...

		----- Original Message ----- 

		From: Francois Audet <mailto:audet at nortel.com>  

		To: Joanne McMillen <mailto:joanne at avaya.com>  ; Russell
Bennett <mailto:Russell.Bennett at microsoft.com>  ; techwg at sipforum.org 

		Sent: Wednesday, May 14, 2008 1:47 PM

		Subject: RE: [SIPForum-techwg] SIPconnect 1.1 -
Microsoft proposal andadditional requirements

		I dont' think that it will be deprecated anytime soon.

		That being said, there are things like TLS that require
TCP, and things like draft-ietf-sip-outbound (for high availability and
NAT traversal) that work a lot better with TCP than with UDP.

		So I'm thinking that a "slow migration" is more likely.

		I don't think it would be out of the question for SIP
Forum to mandate use of TCP if we wanted to. Or recommend it. Or explain
that it must be use for certain scenarios, etc. We have many options.

________________________________

			From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of Joanne McMillen
			Sent: Wednesday, May 14, 2008 13:36
			To: Russell Bennett; techwg at sipforum.org
			Subject: Re: [SIPForum-techwg] SIPconnect 1.1 -
Microsoft proposal andadditional requirements

			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
<mailto:Russell.Bennett at microsoft.com>  

				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
<mailto:russben at microsoft.com> 

				sip:         russben at microsoft.com
<mailto: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/50d4bec2/attachment-0001.html 