CODEWITHSUNDEEP
iosiphoneobjective-csippjsip
just ME
just ME

Reputation: 1827

sip header Contact private ip. Is it ok?

I am working on a sip client and i have some question:

In the sip header the : CONTACT field what ip should contain? The private ip of the client or the gateway ip of the client? Currently using siphon from what I see the contact field is:

via: sip/2.0/udp gatewayip;....
Contact: <sip:username@privateIP:port;transport=...>
To: <sip:username22@serverIP;....>
From: <sip:username@serverIP;...>

For some reason the INVITE message when trying to make a call doesn t get to the server. Could this be the reason? Can someone please explain? The registration works ok.

EDIT:

I managed to set the Contact field with public ip. The problem though still presists. Could it be because of the tcp socket?

Upvotes: 1

Views: 4699

Answers (2)

jcm
jcm

Reputation: 2578

As @Axel83 explains, Contact: header defines a contacting point for subsequent requests per session basis, this is, it's valid to provide a different Contact: in REGISTER and INVITE but some systems uses registration as an authentication system, this means, in order to avoid an in-personification attack, any request with a different Contact: would be discarded.

Initially, in this last scenario, you would receive a 403 response but, maybe, you can try to test it.

On the other hand, you can be facing a SIP Application Level Gateway (ALG) that can be altering your scenario, this is possible to know by checking REGISTER request received in the server. Maybe, you can provide a REGISTER screenshot.

More in detail, an ALG usually knows about a SIP message reception because of source and destination ports, this is, if it's sent to or from 5060 port (or 5061).

What is the problem with theses entities? that they put themselves in the middle, like a man-in-the-middle attack, and manipulates several communication aspects, like media streams, connections or request forwarding, by means of unknown criteria. This can affect your keep-alive mechanism, new session establishment and several more things.

Main symptom to know that you're behind an ALG is by sending SIP request with private IP addresses and, checking in the server side, if received messages contains this private information or if it has been replaced by public addresses. In former scenario, you should be behind an ALG.

In case that you actually are behind an ALG, best way to avoid it would be by not using 5060 port neither as source (client port) or destination (server side) port, this is, for example, if you're currently connecting from client A with IP address A.B.C.D:5060 to server F.G.E.H:5060, try to use: A.B.C.D:5161 <--> F.G.E.H:5161.

Main reason for this to work is because, from server side, checking all traffic going through would be too costly and, ALGs, are applied based on source and destination ports been standard ones.

Please note that, in this proposed work-around, you would need to enable a NAT traversal mechanism on server side (e.g. Asterisk already provides it)

Upvotes: 0

Axel83
Axel83

Reputation: 307

The Contact header contains the SIP URI where the client wants to be contacted for subsequent requests. That means that the host part of the URI must be globally reachable by anyone.
If your contact contains a private IP (behind a NAT?) then it is wrong, because other peers cannot reach you with that. However, since the Contact header is used for subsequent requests, that is not the cause of your problem.
When you say that the INVITE doesn't get to the server, do you mean that you don't receive any response from it, or you get an error? What is the request URI of the outgoing INVITE? You could make a Wireshark capture to see if it goes to the expected server address.

Upvotes: 1

Related Questions