TCP/UDP hack for idiot network service providers

What steps will reproduce the problem?
1. Attempt to make/receive call over TCP

What is the expected output? What do you see instead?
Bidirectional RTP. Instead data is blocked at the network provider's firewall.

Explanation: idiot network provider. They like SIP/VoIP just fine, but have
a nutty firewall configured to analyze sip packets on port 5060/UDP only
and use the media description to selectively open their firewall for the
RTP data. UDP is bad for battery and bad for incoming call reliability. SIP
over TCP works just fine, but their firewall can't handle it.

What version of the product are you using? On what device/operating system?
1.4.7, HTC DREAM, Android 2.1u1.

Which SIP server are you using? What happens with PBXes?
pbxes.org

Which type of network are you using?
3G.

Please provide any additional information below.
The goal here is to run a TCP SIP session, but when a call is made or
received, run a separate FAKE UDP SIP session initiated by the CLIENT to
get the service provider's firewall to behave.

Outgoing calls are obviously not an issue here since frequent registration
isn't required -- exclusive UDP can be used for outgoing.

For an incoming call, there is a TCP connection -- steps as follows;
Server initiated prompt/invite/notification/etc. over existing TCP connection.
Client receives this prompt, OUTGOING SIP INVITE over UDP.
Server responds to this invite over UDP.
Firewall responds appropriately, RTP works, call happens.

Original issue reported on code.google.com by droidhac...@gmail.com on 18 May 2010 at 2:06

yuan- / sipdroid

TCP/UDP hack for idiot network service providers #464