[SIPForum-discussion] SIP over TCP

Rohan Almeida almeida.rohan at gmail.com
Sat Aug 13 05:00:22 UTC 2011


TCP and UDP are transport layer protocols.whereas SIP is a n application
layer protocol.
so TCP does not acknowledge the SIP INVITE or any other SIP message. the TCP
ack is infact an acknowledgement for the TCP packet that containds the SIP
message i.e. this acknowledgement is at transport layer.

when using UPD, there is no guarantee that the SIP messages will be received
in order. TCP will gurantee the orderd delivery of the messages.

the reason why UDP is preferred over TCP for VoIP communication is that
there is overhead of ordering the packets in TCP which is not suitable for
realtime requirements as in case of voice calls.

PS: thanks Sebastien for sharing the links to the articles.
On Wed, Aug 10, 2011 at 6:25 AM, Sebastien BOIRE-LAVIGNE <
Sebastien.Boire-Lavigne at sagemcom.com> wrote:

>  When I did some research on SNMP over UDP or TCP I found this article (
> http://www.ietf.org/proceedings/72/slides/opsarea-2.pdf), it seems that
> TCP was working well for ideal and slightly impaired network, but under
> heavy impairment, UDP was more reliable. That being said, who would do VoIP
> on a network with 40% packet loss…****
>
> ** **
>
> Also an interesting article discusses (**
> http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/) how the TCP congestion avoidance algorithm can be misguided by “buffers”
> in today’s telecom equipment. Again may not apply to the situation, but
> makes you wonder that the simplicity of the “unreliable” UDP has its
> advantage.****
>
> ** **
>
> *SBL*****
>
> ** **
>
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *Gast, Jim
> *Sent:* Tuesday, August 09, 2011 16:58
> *To:* 'senthil k'; 'Raghul Prasanna'
> *Cc:* 'discussion at sipforum.org'
>
> *Subject:* Re: [SIPForum-discussion] SIP over TCP****
>
> ** **
>
> Hi, Raghul –****
>
> ** **
>
> The choice of UDP (best effort) versus TCP (reliable) is a classic choice
> that has been around for years:****
>
> **-          **TCP does a much more timely job of retransmissions (and it
> does them as part of TCP) if the underlying infrastructure loses packets.
> If you use SIP over UDP, discovering the fact that a packet was lost happens
> when SIP times out.****
>
> < ![if !supportLists]>-          **TCP numbers each packet and presents
> each of them exactly once and exactly in order (asking for TCP-level
> retransmissions, if needed).  At the SIP level, it will appear that no
> packets were lost.  All packets are delivered to SIP in the or der the
> sender sent them.  Although SIP can timeout, it is much less likely to take
> THAT long. ****
>
> **-&nbsp ;         **TCP handles packets larger than an unfragmented UDP
> packet (typically 1500 bytes) and it is a natural part of TCP.  In UDP, if
> you need big packets, you have to make sure all the devices properly handle
> UDP fragmentation.****
>
> **-          **Because TCP acknowledges each packet, there are more
> packets and more round-trip delays than just using UDP.****
>
> ** **
>
> Take a look at REGISTER, NOTIFY and INVITE packets (any packets that can
> get potentially big).  If your SIP packets are larger than 1,300 bytes, you
> may have trouble with certain SBCs that want to reserve 200 bytes to do
> header manipulation.  Those SBCs reject large UDP packets because they are
> afraid that they might not have enough room to do the “header ma nipulation
> rules“.  ****
>
> ** **
>
> If you do lots of call forking (e.g. Shared Call Appearances) or have large
> packets for things like Busy Lamp Fields . . . do a packet capture.  Compare
> the packet leaving the phone to the packet arriving at your registrar or
> server (and the reverse).  If, using UDP, you see packet losses or packets
> getting truncated or discarded . . . switch to TCP.   SIP ladder diagrams
> can be surprisingly hard to follow if a significant fraction of UDP packets
> are randomly lost.  And it isn’t just you that gets confused . . . SIP
> phones, SIP proxies and SIP registrars are easily confused if lots of
> packets are lost.****
>
> ** **
>
> I hope that helps,****
>
> ** **
>
> *Jim Gast* ****
>
> TDS Telecom****
>
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *senthil k
>
> *Sent:* Monday, August 08, 2011 11:06 AM
> *To:* Raghul Prasanna
> *Cc:* discussion at sipforum.org
> *Subject:* Re: [SIPForum-discussion] SIP over TCP****
>
> **&nbsp ;**
>
> Hi ****
>
> ** **
>
> TCP needs to ack all the SIP messages like INVITE to BYE... other than that
> its similar to UDP. ****
>
> ** **
>
> if u want i can send u the logs taken ****
>
> On Fri, Aug 5, 2011 at 2:28 PM, Raghul Prasanna <raghul82 at yahoo.co.uk>
> wrote:****
>
> Hello All,****
>
> ** **
>
> Has anyone in this forum got experience working on SIP over TCP please?***
> *
>
> ** **
>
> Because I p osted a question sometime ago, there was no response, I updated
> again to see if  someone can respond, but my update never appeared on this
> forum at all.****
>
> ** **
>
> Thanks,****
>
> Raghul****
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion<http://sipforum.org/mailman/listinfo/disc%0d%0a%20ussion>
> Post to the list at discussion at sipforum.org****
>
> ** **
>
> #****
>
> " Ce courriel et les documents qui lui sont joints peuvent contenir des****
>
> in
>  formations confidentielles ou ayant un caractère privé. S'ils ne vous sont****
>
> pas destinés, nous vous signalons qu'il est strictement interdit de les****
>
> divulguer, de les reproduire ou d'en utiliser de quelque manière que ce****
>
> soit le contenu. Si ce message vous a été transmis par erreur, merci d'en****
>
> informer l'expéditeur et de supprimer immédiatement de votre système****
>
> informatique ce courriel ainsi que tous les documents qui y sont attachés."****
>
> ** **
>
> ** **
>
>                                **********
>
> ** **
>
> " This e-mail and any attached documents may contain confidential or****
>
> proprietary information. If you are not the intended recipient, you are****
>
> notified that any dissemination, copying of this e-mail and any attachments****
>
> thereto or use of their contents by any means whatsoever is strictly****
>
> prohibited. If you have received this e-mail in error, please advise the****
>
> sender immediately and delete this e-mail and all attached documents****
>
> from your computer system."****
>
> #****
>
> #
> " Ce courriel et les documents qui lui sont joints peuvent contenir des
> informations confidentielles ou ayant un caractère privé. S'ils ne vous sont
> pas destinés, nous vous signalons qu'il est strictement interdit de les
> divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
> soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
> informer l'expéditeur et de supprimer immédiatement de votre système
> informatique ce courriel ainsi que tous les documents qui y sont attachés."
>
>
>                                ******
>
> " This e-mail and any attached documents may contain confidential or
> proprietary information. If you are not the intended recipient, you are
> notified that any dissemination, copying of this e-mail and any attachments
> thereto or use of their contents by any means whatsoever is strictly
> prohibited. If you have received this e-mail in error, please advise the
> sender immediately and delete this e-mail and all attached documents
> from your computer system."
> #
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20110812/6f9857cf/attachment-0002.html>


More information about the discussion mailing list