[SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)

Tue May 20 16:27:53 EDT 2008

Adam,

Good to hear that you support TCP. But why do you think UDP is the
dominating protocol today? Is there any rational reason to why most SIP
Trunks are delivered over UDP (besides the obvious fact that most PBXes
only support UDP today)?

/Janne

________________________________

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Uzelac, Adam
Sent: den 20 maj 2008 21:01
To: Dan York; Richard Shockey
Cc: techwg at sipforum.org; Russell Bennett
Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)

Skipping the survey - in our "SIP Trunking" product-line we support TCP
today and would, therefore, be compliant with 1.1 day one. (assuming TCP
is a MUST)  It's in our production network today, though, in vast orders
of magnitude, there's more UDP than TCP .  For what it's worth.  

Adam Uzelac

Global Crossing

Director, Converged Network Architecture and Planning

585-563-4359

________________________________

	From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of Dan York
	Sent: Tuesday, May 20, 2008 2:17 PM
	To: Richard Shockey
	Cc: 'Russell Bennett'; techwg at sipforum.org
	Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)

	I agree as well... but would ask the question that I did in a
response to Greg earlier.  Do we know how many likely candidates for the
SIPconnect 1.1 certification would support TCP & UDP versus UDP-only? 

	If the overwhelming majority of products that would likely go
after the SIPconnect 1.1 certification either already support TCP or
have it on their near-term roadmap to do so (and would provide upgrades
to existing products), then this discussion is really moot.  If on the
other hand the vast majority would only support SIP over UDP in the next
12 months (which I personally don't think is the case), then that is a
good data point to know relative to the potential uptake of the
SIPconnect 1.1 cert.

	Anyone want to run an anonymous surveymonkey.com survey or
something like that?

	Dan

	P.S. Of the products/services currently certified for SIPconnect
1.0, how many of them support SIP over TCP? (Or will in the next 12
months?)

	On May 20, 2008, at 1:21 PM, Richard Shockey wrote:

	Agree 200%  :-)

	From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of Joanne McMillen
	Sent: Tuesday, May 20, 2008 1:05 PM
	To: Russell Bennett; Zweig, Greg; techwg at sipforum.org
	Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)

	Agree 100%

	Joanne

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

		From: Russell Bennett
<mailto:Russell.Bennett at microsoft.com> 

		To: Zweig, Greg <mailto:gzweig at sonusnet.com>  ;
techwg at sipforum.org

		Sent: Tuesday, May 20, 2008 9:20 AM

		Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption
of TCP?)

		Greg et al.

		I have already agreed that we have to accommodate the
past, but we also have to drive the future.  If we "make it OK to just
offer UDP" then that is what people will think that it is acceptable to
do.

		I have been actively engaged with a number of service
providers for quite some time now and, without naming names or providing
timelines, I can assure you that TCP is being deployed by service
providers.

		As for encouraging quick adoption - the issue is not one
of which SIP Transport is best/cheapest/already there; the issue is one
of simple economics: SIP Trunks cannibalize Service Provider revenues
under existing pricing models.  The SPs who offer "UDP only" are seeing
little demand for SIP Trunking - what they don't realize is that it is a
"chicken and egg" problem.

		We must move SP SIP connectivity capability forward such
that SPs can start to deploy revenue generating services and
applications to replace revenue lost by decrementing PRI trunks.  We can
only get to a service federation model by moving rapidly beyond SIP
Voice.  If we can't *even* get to more broadly deployed SIP Voice, then
(some) SPs will remain where they are - stuck in the 20th century.

		Forward looking SPs that I work with have heard this
loud and clear.

		UDP should be a 'MUST' to support older architectures.
TCP MUST be a 'MUST' to support newer architectures.  I don't see how we
accommodate the past and drive the future any other way.

		Russell

		-----Original Message-----
		From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of Zweig, Greg
		Sent: Monday, May 19, 2008 11:39 AM
		To: Peter Dunkley; techwg at sipforum.org
		Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption
of TCP?)

		Agreed -- We also have to consider the capabilities at
the customer
		premise.  I wouldn't want to advocate a solution that
drives end
		customers into a position where their existing equipment
is made
		obsolete.  There are many products in-use that could be
upgraded to
		other facets of a SIPconnect 1.1 implementation but will
never cost
		effectively support TCP.  I want to embrace them, not
disenfranchise
		them.

		We need to accommodate the past while we drive the
future.

		Greg Zweig
		Sonus Networks. Inc
		(978) 614-8027

		-----Original Message-----
		From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org]
		On Behalf Of Peter Dunkley
		Sent: Monday, May 19, 2008 2:23 PM
		To: techwg at sipforum.org
		Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption
of TCP?)

		The danger with this approach is that you will may end
up with a
		wonderful SIPconnect 1.1 recommendation that the
writers/purists love
		but is unpalatable to the industry.

		There needs to be a pragmatic approach taken that
illustrates what SIP
		trunking should be, while still encouraging quick
adoption.

		Making SPs have to choose between changing their
architecture or
		becomming compliant will not encourage them to adopt
SIPconnect (quickly

		or otherwise).

		Russell Bennett wrote:
		> All,
		>
		> I know from trying to work with the SPs on SIP
Trunking that *some*
		SPs are going to take a firm position on the support of
UDP only.   The
		question that Janne poses is:
		>
		>         1) Are we going to define SC1.1 to be what a
SIP Trunk service
		should be (e.g. UDP *and* TCP, among many other things)?
		>         OR
		>         2) Write SC1.1 to be what we think will enroll
more SPs in the
		SC compliance program?
		>
		> I argue strongly against 2 - this would not be a step
forward on
		SC1.0.  3261 is very clear on TCP support.  If SIP Forum
was a
		commercial entity, then we would go for 2 to maximize
revenue.
		>
		> However, SF is a standards body and it is incumbent
upon us to develop
		SC1.1 as a *correct*, albeit pragmatic, document.  The
key is the
		balance between pragmatism and correctness and I, for
one, think that
		accommodating SPs that are mired in the 20th century is
the wrong side
		of that balance.
		>
		> Russell
		>
		>

		_______________________________________________
		techwg mailing list
		Send mail to: techwg at sipforum.org
		Unsubscribe or edit options at:
		http://sipforum.org/mailman/listinfo/techwg

		_______________________________________________
		techwg mailing list
		Send mail to: techwg at sipforum.org
		Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg

		_______________________________________________
		techwg mailing list
		Send mail to: techwg at sipforum.org
		Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg

	_______________________________________________
	techwg mailing list
	Send mail to: techwg at sipforum.org
	Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg

	-- 

	Dan York, CISSP, Director of Emerging Communication Technology

	Office of the CTO    Voxeo Corporation     dyork at voxeo.com

	Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com

	Blogs: http://blogs.voxeo.com
http://www.disruptivetelephony.com

	Build voice applications based on open standards.

	Find out how at http://www.voxeo.com/free

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20080520/135f6585/attachment-0001.html 