SIP over TCP

[Bink]

Any chance we’ll see this in the near future? The reason I ask is because, particularly with “smartphones” and 4G becoming more prolific, there are many advantages to SIP over TCP. These include, but are not limited to, the following:

• More reliable call reception (mostly due to aggressive UDP state timers by mobile providers)
• Improved battery life for mobile devices as they do not have to wake to send keep-alives as often and, consequently, they use their radios less
• Reduced server overhead due to reduced keep-alive signaling and response
• More firewall friendly
• Improved NAT traversal (will only get worse until IPv6 becomes more prolific)
• Required for possible SIP over TLS

Thanks.

[claganga]

If you really needed it, why not run asterisks at your house and use it as trunk to VOIPO and as gateway to your mobile. My um "friend" does this and it works really well esp when in foreign countries where voice costs money but you can typically find free wifi

[VOIPoTim]

We don't really have any plans for TCP at this time.

[Bink]

We don't really have any plans for TCP at this time.

Okay Tim—thanks for chiming in/the official response.

[Bink]

If you really needed it, why not run asterisks at your house and use it as trunk to VOIPO and as gateway to your mobile. My um "friend" does this and it works really well esp when in foreign countries where voice costs money but you can typically find free wifi

I’m aware of this, but this is not an ideal solution (a home Internet connection is generally not business class, latency and jitter will likely go up, a single Asterisk box is not fault tolerant and etcetera).

[claganga]

I’m aware of this, but this is not an ideal solution (a home Internet connection is generally not business class, latency and jitter will likely go up, a single Asterisk box is not fault tolerant and etcetera).

the only point I can agree with you here is the fault tolerance and it being a single point of failure.

With any home voip service your internet connection is the limiting factor, so you already have this QOS factor in place. Plus the mobile networks are more more jittery and have a higher latency then your home service could ever dish out.

If you were concerned about your home service you could configure asterisk to not act as your media server and instead would be used for signaling the media would be point to point from your mobile to "voipo"

If you were more concerned about the quality of your mobile provider you could configure asterisk to act as a media server and transcode to GSM/729/ILBC/ect and provide buffering between the two services.

If excellent voice quality, no jitter, and no latency were your goals then you wouldn't even consider 4g connectivity

[Bink]

the only point I can agree with you here is the fault tolerance and it being a single point of failure.

With any home voip service your internet connection is the limiting factor, so you already have this QOS factor in place. Plus the mobile networks are more more jittery and have a higher latency then your home service could ever dish out.

If you were concerned about your home service you could configure asterisk to not act as your media server and instead would be used for signaling the media would be point to point from your mobile to "voipo"

...

If excellent voice quality, no jitter, and no latency were your goals then you wouldn't even consider 4g connectivity

I guess you have a point here/I didn’t realize Asterisk could be used for signaling only. I might revisit my options here and the idea of setting up a small Asterisk VM on my ESXi box at home.

Thanks for chiming in.

[usa2k]

I believe TCP has too much overhead for practical real-time conversation - or at least that was true as VoIP was developed.
It used to be code had to be small because memory and processing power was limited. Now code can be ponderous, but
fast to build the app. Still, I don't think voice technology is ready for bloat.

[claganga]

I believe TCP has too much overhead for practical real-time conversation - or at least that was true as VoIP was developed.
It used to be code had to be small because memory and processing power was limited. Now code can be ponderous, but
fast to build the app. Still, I don't think voice technology is ready for bloat.

Well TCP would be just for signalling, not RTP. SCCP/SKINNY uses only TCP or TLS for signalling never supported UDP, as far as I know.

TCP could be an advantage esp over wireless networks, not counting 802.11, since the invite could be lost esp in a ring group scenario.