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

Wed May 21 10:24:26 EDT 2008

Quite possibly.

But the point I was trying to make is that UDP is not only well established, but preferred over TCP by many people (whether their reasons for preferring it are good and valid or not, they prefer it).

In my opinion any recommendation needs to take into account not just best practice, but actual practice.  Vilifying, or making life difficult, for those who have pragmatically chosen something different, and invested time and money in making it work, is not going to contribute to the success of any recommendation.

One reason for a small packetisation interval is to try and make the call quality as indistinguishable from the current PSTN as possible.  Remember that the UK is quite a small landmass (though densely populated) with a highly meshed telephone network.  So, currently, there is not a lot of delay in PSTN calls (and no need echo cancellation in the PSTN for national calls either).

Peter

-----Original Message-----
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]On
Behalf Of Uzelac, Adam
Sent: 21 May 2008 14:48
To: Peter Dunkley; techwg at sipforum.org
Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)

With all due respect to the architects of the BT21CN, they also are
mandating a 10ms packetization interval for all SP to SP RTP
interconnections - which begs the question - why?  I believe one
motivating factor was the lack of a national number porting database,
and therefore calls get "forwarded" through numerous networks in
sequence of where the number was ported from, versus a nation LNP
database that is in existence in North America.   The point being that
folks across the world take into account numerous factors that are
simply questionable within world-wide (or maybe even real-world)
context(s).

Adam

> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of Peter Dunkley
> Sent: Wednesday, May 21, 2008 4:24 AM
> To: techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)
> 
> Within a UK context the 21st Century Network programme is 
> intending to build a national next generation network.  The 
> primary transport that will be used in this network is SCTP.  
> SCTP was chosen because the network architects want PSTN 
> replication and need not just a reliable, but a resilient 
> transport, that duplicates the features provided by MTP.
> 
> At one point, and I am not sure what the state of play today 
> is, the situation in the UK (for inter-working between 
> networks and enterprise access) was going to be:
> * RECOMMEND (and in some contexts MUST) use SCTP
> * MAY use UDP (if you really have to)
> * but, MUST NOT use TCP (under any circumstances)
> 
> I am not sure how or why this particular situation arose, but 
> on a national scale UDP was seen as acceptable (though not 
> preferred) and TCP was out of the question.
> 
> I would not be surprised if this mindset exists elsewhere to 
> a greater or lesser extent.
> 
> Regards,
> 
> Peter
> 
> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org]On
> Behalf Of Elwell, John
> Sent: 20 May 2008 20:15
> To: Hiers, David; Russell Bennett; Zweig, Greg; techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)
> 
> 
> Yes, this has always been the thing that puzzled me. A lot of 
> vendors and service providers have tried to reproduce PSTN 
> capabilities with SIP. Yet PSTN signalling protocols always 
> ran over a reliable transport, so the obsession with UDP 
> seems to be a contradiction.
> 
> John 
> 
> > -----Original Message-----
> > From: techwg-bounces at sipforum.org
> > [mailto:techwg-bounces at sipforum.org] On Behalf Of Hiers, David
> > Sent: 20 May 2008 18:28
> > To: Russell Bennett; Zweig, Greg; techwg at sipforum.org
> > Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)
> > 
> > All,
> > As a service provider using an expensive mix of best-of-breed SIP 
> > implementations that service a fair number of endpoints and 
> minutes, I 
> > see the ability to use UDP as one of SIP's primary weaknesses.
> > 
> > The attempt to supplant the TDM PSTN five-nines reliability is not 
> > particularly well facilitated by running the entire show over an 
> > unreliable transport protocol whose primary benefit is reduced HW 
> > resource requirements.
> > 
> > When shopping for future peering partners, I would tend to 
> prefer one 
> > who's engineering philosophy happily embraces the deterministic 
> > control of TCP rather than the fire-and-forget nature of UDP.
> > 
> > Best regards,
> > 
> > 
> > David Hiers
> > 
> > CCIE (R/S, V), CISSP
> > ADP Dealer Services
> > 2525 SW 1st Ave.
> > Suite 300W
> > Portland, OR 97201
> > o: 503-205-4467
> > f: 503-402-3277
> > 
> > 
> > 
> > -----Original Message-----
> > From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org]
> > On Behalf Of Russell Bennett
> > Sent: Tuesday, May 20, 2008 9:21 AM
> > To: Zweig, Greg; techwg at sipforum.org
> > 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
> > 
> > 
> > This message and any attachments are intended only for the 
> use of the 
> > addressee and may contain information that is privileged and 
> > confidential. If the reader of the message is not the intended 
> > recipient or an authorized representative of the intended 
> recipient, 
> > you are hereby notified that any dissemination of this 
> communication 
> > is strictly prohibited.
> > If you have received this communication in error, please notify us 
> > immediately by e-mail and delete the message and any 
> attachments from 
> > your system.
> > 
> > _______________________________________________
> > 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
> 
> 
> NOTICE & DISCLAIMER
> This email including attachments (this "Document") is 
> confidential and may contain legally privileged information.  
> If you have received this Document in error please notify the 
> sender immediately and delete this Document from your system 
> without using, copying, disclosing or disseminating it or 
> placing any reliance upon its contents.  We cannot accept 
> liability for any breaches of confidence arising through use 
> of this Document.
> 
> The information contained in this Document is provided solely 
> for information purposes on an "as is" basis without warranty 
> of any kind, either express or implied, including without 
> limitation any implied warranty of satisfactory or 
> merchantable quality, fitness for a particular purpose or 
> freedom from error or infringement.  The user relies on the 
> information contained herein, and its accuracy or otherwise, 
> entirely at their own risk.
> 
> Any opinions expressed in this Document are those of the 
> author and do not necessarily reflect the opinions of Telsis. 
>  We will not accept responsibility for any commitments made 
> by our employees outside the scope of our business.
> 
> 
> 
> 
> _______________________________________________
> 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