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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
