[SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)
Russell Bennett
Russell.Bennett at microsoft.com
Fri May 23 18:23:41 EDT 2008
As Eric predicted, Asterisk is available *with* TCP, as of 10/19/07, according to this:
http://blog.brickaloch.com/index.php/2007/10/19/sip-tcp-support-in-asterisk/
But, once again, the table was indicative, not exhaustive.
Russell
-----Original Message-----
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Eric Burger
Sent: Friday, May 23, 2008 3:06 PM
To: techwg at sipforum.org
Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)
Does anyone care what Asterisk supports? If so, isn't the model that
someone will contribute TCP support for their SIPconnect 1.1-compliant
version?
On May 23, 2008, at 3:24 PM, Peter Dunkley wrote:
> Has your research found any information on the cost of these upgrades?
>
> If a customer has a choice between buying/using/connecting piece of
> equipment X and Y, the only significant (to them) difference being
> that to use X they will have to pay to replace or upgrade existing
> piece of equipment Z, they will choose Y every time.
>
> Isn't Asterisk still UDP only? This is in use as a PBX and Media
> Server at many, many, Enterprises, and being free probably has a
> larger install base than products from many of these vendors, and
> being free is going to be difficult to get accurate numbers for.
> Further, a large number of different bits of smaller vendors
> equipment (if they were taken cummulatively) that only supported UDP
> could have a larger total install base than products from one bigger
> company.
>
> Some, more adventurous, service providers have developed their own
> systems to do clever, bespoke, things. Where will they get upgrades?
>
> I am not proposing that the recommendation be based just around the
> capability of Asterisk - just pointing out that the table you have
> provided is not comprehensive, it does not provide any indication of
> the size of installed base (and what proportion may/do need
> upgrades), and does not give any indication of likely upgrade costs.
>
> Depending upon how freely, easily, and cheaply, the upgrades are, it
> is quite possible for the experiences of there still being a lot of
> UDP only equipment out there could very well be correct.
>
> I have found myself on the end of a phone to customers and support
> engineers with problems many times before, and the attitude from
> them has almost always been:
> * I don't care what the specification says
> * I don't care that it is the other vendors equipment that is at
> fault
> * This is costing me money/hassle
> * Fix it right now
> Please ensure that UDP will be supported by SIPconnect 1.1 devices
> and that there is no possibility of anyone reading the specification
> thinking that it is not. Please ensure that there is no confusion,
> and ensure backwards compatability, by either:
> * Explicitly mentioning that RFC 3261 compliance is mandatory. Not
> mentioning either TCP or UDP as MUST or MAY (as that is covered by
> the RFC 3261 bit). Indicating that TCP is the recommended default
> (or mandating that a SIPconnect compliant device MUST attempt to use
> TCP first before falling back to UDP).
> * or, Explicitly mentioning that RFC 3261 compliance is mandatory.
> If you need to make TCP a MUST, make UDP a MUST too. Indicate that
> TCP is the recommended default (or mandating that a SIPconnect
> compliant device MUST attempt to use TCP first before falling back
> to UDP).
> If you mentioned one transport as a MUST and do not mention the
> other at all (or only as a MAY) it is inevitable that someone,
> somewhere, will assume that they do not need to use UDP at all.
> Unless explictly indicated otherwise (in the same section of the
> recommendation) they will ASSUME that the SIPconnect recommendation
> overrides the RFC.
>
> I am all for avoiding interoperability issues, but my belief is that
> there are more potential interop issues between SIPconnect and non-
> SIPconnect devices than between just SIPconnect devices. These are
> the ones that will hurt the most - particularly if those devices are
> old/unsupported/bespoke, and anyone who believes things can just be
> upgraded is hopelessly optimistic.
>
> Peter
> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-
> bounces at sipforum.org]On Behalf Of Russell Bennett
> Sent: 23 May 2008 19:54
> To: techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)
>
> This has been a pretty long thread. I think that almost everyone is
> in agreement that both UDP and TCP are both required in SC1.1, with
> a bias towards TCP as a REALLY MUST (or whatever language we choose)
> and UDP for backwards compatibility.
>
> I just wanted to respond to one issue that has been raised several
> times: that only UDP is supported by the majority of SIP deployments.
>
> I did some research on this and, while it is impossible to get data
> on current installed base, I have been able to determine what would
> be deployed today with existing product from the overwhelming
> majority market share vendors. Therefore, even if a customer had
> older equipment from a given vendor that only supported UDP, they
> have the option to upgrade to newer equipment that supports TCP or
> TLS.
>
> So, the notion that anyone is somehow constrained from supporting
> TCP (and even TLS) is invalid.
>
> Russell
>
> Vendor
> UDP
> TCP
> TLS
> Reference
> Microsoft
> N
> Y
> Y
> http://download.microsoft.com/download/d/b/6/db641148-427b-41d3-9f20-7ffbddaf65b8/OCS_VoIP_Guide.doc
> Cisco
> Y
> Y
> Y
> http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/FeatTLS.html#wp1092137
> IBM
> N
> Y
> Y
> http://download.boulder.ibm.com/ibmdl/pub/software/dw/lotus/sametime-sip.pdf
> Nortel
> Y
> Y
> Y
> http://www142.nortelnetworks.com/techdocs/CS1K_5_0/pdf/NN43001-564_01.05_NRS.pdf
> Avaya
> Y
> Y
> Y
> http://www.avaya.com/gcm/master-usa/en-us/products/offers/sip_enablement_services.htm&View=ProdTechSpec
> Alcatel-Lucent
> Y
> Y
> N
> http://www1.alcatel-lucent.com/doctypes/articlepaperlibrary/pdf/ATR2002Q4/T0212-SIP_Technology-EN.pdf
> Siemens
> Y
> Y
> Y
> http://www.enterprise-communications.siemens.com/Products/Phones%20Clients/Desktop%20Phones/
> ~/media/6DAA007008EB4A5CA0212A6D12A49770.ashx
> AudioCodes
> Y
> Y
> Y
> http://www.audiocodes.com/objects/sbc/nCite_4000.pdf
> Nextpoint
> Y
> Y
> Y
> http://www.nextpointnetworks.com/files/NextPoint_SBC_USLTR_2008_hirez.pdf
> Acme Packet
> Y
> Y
> Y
> http://www.acmepacket.com/html/page.asp?PageID={06E4AEBC-24E2-46CC-
> BA95-7C74288FA45B}
> Covergence
> Y
> Y
> Y
> http://www.covergence.com/stuff/contentmgr/files/4adf40f79f81482fff714c46d8e06832/misc/ssesb.pdf
>
>
>
> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-
> bounces at sipforum.org] On Behalf Of Peter Dunkley
> Sent: Thursday, May 22, 2008 6:40 AM
> To: Eric Burger; techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)
>
> That would depend on whether you consider ISDN, and the like, to be
> SIP related or not :-)
>
> On a more serious note there is a requirement for tunnelling UK-ISUP
> within SIP messages. Also, UK-ISUP has recently been extended to
> allow BT-NUP messages to be tunnelled within - specifically so that
> BT-NUP can be passed across a SIP network for legacy interworking.
> This would result in SIP messages that can contain UK-ISUP messages,
> that can contain BT-NUP messages, which may contain DPNSS messages...
>
> What you jokingly mentioned below is absolutely horrible - but
> (within a national context) not as unlikely as it may seem!
>
> I have also heard of some interest in directly tunnelling DPNSS
> within SIP as well.
>
> However, I would be the first to admit that BT-NUP and so on have no
> place in a SIPconnect recommendation.
>
> Peter
>
> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-
> bounces at sipforum.org]On
> Behalf Of Eric Burger
> Sent: 22 May 2008 10:17
> To: techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] TCP vs. UDP (SP adoption of TCP?)
>
>
> I would offer this philosophy would lead us to standardize SIPconnect
> 1.1 to use ISDN, possibly choosing Q.921, Q.sig, or BT-NUP :-)
>
> On May 21, 2008, at 10:24 AM, Peter Dunkley wrote:
>
> > 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.
>
> _______________________________________________
> 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
>
> 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
More information about the techwg
mailing list