CODEWITHSUNDEEP
androidsipvoip
Junfei Wang
Junfei Wang

Reputation: 578

How does SIP work on cellular network?

I'm just confused about how SIP works but mine doesn't. I made a simple android server which open up a server socket and listen to incoming connection on 3G/4G network. Then I made a client that connect to the server, the connection was blocked by my carrier's firewall(AT&T).

After this, I downloaded an open source VOIP app based on SIP, and register these 2 phones on SIP proxy, let them call each other, this works perfectly.

I'm just so confused about how SIP works on cellular network, SIP is a p2p protocol, SIP proxy is just for redirecting. How does these 2 phones connect to each other in VOIP session? Why is this connection not blocked by carrier? Can someone explain to me? Thank you in advance!

update: I just tried sending a UDP packet between AT&T and SPRINT network, it does not work ;(

Upvotes: 4

Views: 3553

Answers (1)

Shane Powell
Shane Powell

Reputation: 14148

In basic SIP the endpoints media traffic generally communicate directly between each other in a P2P fashion like you said. They do this be giving each others address/port in the SIP SDP negotiation.

In a "perfect" network world this works fine as all endpoints can talk directly between each other.

As we know, this is not the case.

In most cases, the main barrier in the IPv4 world is NAT.

The first solution people came up with is STUN. STUN will give you your "public" IP address that you are using from behind a NAT and the SIP stack will use that IP address in the SIP/SDP packets. This works as long as hole punching works.

The next solution people came up with is TURN. TURN is a UDP proxy and allows a client (e.g. a SIP client) to allocate and use a IP address/port on a private network from a public network (i.e. the internet). It should work in all cases but can put a lot of network overhead on the TURN server. It will not be as efficient as P2P connections tho. The upside of using TURN is that not both sides need to support it for it to work. So it's good when you are talking between a softphone on the internet to a hardware SIP device on a internal network.

The next solution people came up with is ICE. ICE needs to be supported on both SIP endpoints. It works by extending the SDP protocol to allow it to add all possible connections in the SDP negotiation (all local network adapters, public addresses provided by STUN and TURN allocated addresses in priority order). Then one side goes through the listed connections and tries to make a connection. This allows both connections to be "try" to connect P2P and fallback to a TURN connection if nothing else works. It should also work in any networked environment to any networked environment and find the most efficient network path between the SIP endpoints. The downside of ICE is that both SIP endpoints need to support ICE for it to work. (As a aside, ICE/TURN/STUN is now a requirement for the WEBRTC protocol for web browsers to talk between each other for the same reason)

Other possible solutions would be for you to have some sort of "smart" sip proxy in the middle that maybe fakes ICE on one side if the other side doesn't support it. Another is to have some sort of media gateway or B2BUA if transcoding is required, this would have the same problems as TURN tho.

I would suggest that you setup your SIP client with STUN, TURN and ICE if possible and that will increase the likelihood of the SIP call actually working.

As to why your case doesn't work now, it would require network and/or SIP logs to understand what the exact impediment is.

Upvotes: 7

Related Questions