*Hello John: I actually like where this thread has led us to - and I do appreciate this technical input. Keep it coming, as I think this is extremely valuable and VERY good to know when it comes to debugging and trouble shooting issues. In my experience of having hundreds of accounts on a single server, most clients in Toronto are within the 20-30 ms range.
What you have just outlined is important in terms of latency. If new accounts were to go with SIP over TCP, I think a latency of upto 150ms would not matter much and not easily detectable to the untrained mind and ear. I actually have an office in Malaysia interconnected with here in Toronto with a latency of 450ms. As long as we are not arguing, the conversation and connectivity is pretty flawless and more than acceptable without confusion. Having said that - theoretically a 450ms is something pretty darn bad, but realistically this seems to be acceptable in voice communications. However to ensure the quality of service, I would agree with you whole heartedly that lower the latency, the better the service and the lesser chance for dropped packets. These stats are in a hosted model. Now realistically, taking into account my worst client in terms of latency of 50ms, would add as per your calculation, a latency of 150ms for SIP over TCP. In this 150ms range, I would say the voice would still be pretty darn close to perfect. Now within my prospects offices who are running Microsoft and 3CX, the latency between their phones and their MS.comm.server. -- the latency is less than 1 ms. So over all, when I provide them with Virtual PRIs I think this should be fine (theoretically speaking). Since I don't have real numbers and real stats, I've extended my offer to the TAUG group offering free SIP trunks (origination and termination) -- to anyone who is using 3CX, MSCS, or anything SIP over TCP, to do some testing prior to my commitment to prospects on hold wanting to purchase termination and origination for their SIP o/TCP servers. Kind regards, Reza. * On Fri, Nov 19, 2010 at 1:01 AM, John Lange <j...@johnlange.ca> wrote: > I don't question the business requirement. That's a given. > > Strictly form a technical perspective; the setup of the TCP session > requires a 3-way handshake and thereafter each packet requires a > syn-ack. While that's going on, SIP is doing the same thing except now > it's trying to layer it on top of TCP. Since TCP introduces delay > waiting for the handshake to complete, the window where-by SIP will > wait for it's own 'ack' is shortened by that amount. > > By default the SIP t1 timer is set to 500ms. If your latency is 50ms, > then TCP will take a minimum of 150ms (3 ways times 50ms) to setup the > handshake before it SIP packet will even be sent thus shortening the > window for the t1 timer by between 150-200ms. > > Assuming everything is going smoothly this will work fine since you > still make it under the 500ms timer but why shorten your window and > there-by your reliability by 30% for no benefit? > > If any one of those 3-way packets gets lost, then the process waits > for the TCP timeout and the whole thing falls down since you've now > timed out the SIP T1 timer. So SIP starts over, this time it doubles > T1 and tries again. This would initiate a new TCP 3-way handshake. In > the mean time, it's likely the first TCP process has retransmitted the > lost packet and is just getting rolling so now the SIP stack receives > the original request and replies which confuses the hell out of the > process since the other end has already gave up on that packet. > > Anyhow, I'm probably off on some of the technical details but you get > the idea how messy it is. > > Since SIP is a signaling protocol it needs to be reliable but it needs > to operate on a much shorter schedule than TCP which is why the > designers built the reliability into SIP and used UDP. On the other > hand, if SIP over TCP removes all the reliability from SIP and just > relies on TCP to make the connection reliable then it makes sense (but > AFAIK it doesn't). > > In the end this really isn't that important but sometimes it's worth > thinking about these things at the lowest possible level just to get a > fell for whats going on. > > John > -- Toronto based VoIP / Asterisk Trainer, I.T. Consultant and Hosted PBX Solutions Provider. +1-647-476-2067. http://www.linkedin.com/in/seminar
