SDP Mangle replacing IP with Proxy's IP

Developer
Dec 5, 2013 at 2:09 PM
Hi,

I have a small issue where calls from a sip account to a provider are being mangled incorrectly. The IP in the SDP payload is coming as 192.x.x.x and being mangled to the public IP of the SIP Proxy (which is on AWS), and not the public IP of the sip account.

Any ideas why this would happen?

Thanks
Coordinator
Dec 8, 2013 at 10:43 AM
AWS don't allocate public IP addresses to their instances and instead allocate a private IP address and use a 1-to-1 NAT when sending and receiving internet traffic. The mechanism is a bit annoying for SIP and similar protocols.

The fix for sipsorcery is to put the public IP address allocated to your instance in the sipsorcery app config file in the in the "sipproxy" node and the "PublicIPAddress" key.
Developer
Dec 9, 2013 at 9:02 AM
I tried that already, i set the PublicIPAddress value to that of the public IP of the EC2 instance.
v=0
o=- 144554457 144554457 IN IP4 192.168.3.14
s=-
c=IN IP4 54.194.18.1XX
t=0 0
As you can see Origin is set to the private internal ip of my ip phone, and the connection data address is the proxy...

Any suggestions? I am going to try and setup remote debugging to get a better idea of what's happening during the mangle, but if you're aware of anything else that might need changing please let me know.
Coordinator
Dec 9, 2013 at 9:39 AM
The private IP address in the o= attribute won't matter, it's not used for the RTP socket. The connection attribute, which is the "c=" one, is the critical one and in your snippet is has been mangled correctly.

However I don't think that is going to solve whatever problem you are having since you are never going to have an end SIP device listening for RTP on your EC2 instance's IP address. I use the PublicIPAddress setting for running sipsorcery on my home PC to which I connect my IP phones and soft phones. By mangling the private IP address to the public IP address of my router it helps get RTP through to my SIP devices.
Developer
Dec 9, 2013 at 9:48 AM
Ah, OK. So the problem I am having, all be it a common one is one way audio. I asume this is because the RTP address is either a) being mangled to the public ip of the proxy or b) because the IP in the SDP is the internal ip of the sip phone (192.168.3...).

I understand this is a nat issue, so how does one get sipsorcery to mangle the SDP to the public IP of the 192.168.3... address?

I've just been looking at the SDP mangle function in SIPPacketManger.cs. Should this be able to handle getting the real SDP end-point? I would have thought this would be a common issue, so i assume I am making a mistake somewhere and overlooking something!

Thanks again for your help Arron.
Coordinator
Dec 9, 2013 at 10:24 AM
First thing to try for one way audio is to turn mangling off:

sys.Dial("1234@somewhere.com[ma=false]") The reason being that most providers will handle private IP addresses by switching the RTP socket to whichever one they receive the remote end's RTP from.

Other approaches are to change any private IP addresses to the public IP address the SIP packet came from and in the case where there is a SIP proxy involved, such as sipsorcery, then the substitute RTP socket won't work.

There can be a bit of trial and error involved trying to get RTP working with some providers...
Developer
Dec 9, 2013 at 10:27 AM
OK, Thanks for the pointers.

In the case of some Cisco IP phones i have here for testing, enabling STUN resolved the one way audio issues, but I am going to keep playing to try and find other more general solutions too. Steep learning curve :]
Jan 24, 2014 at 2:56 AM
Hello,

I am also facing the same issue. Is there any way to mangle using public IP of sip account? I noticed that sipsorcery.com is mangling using the public IP of sip account.

Thanks,
Plachira
Coordinator
Jan 27, 2014 at 9:01 AM
I'm sorry I don't understand that question. Do you want to mangle incoming calls by substituting a private IP address with the public IP address of the SIP device it came from?

That should happen automatically provided the request did originate from a non-private IP address and the ma=false dial string option is not being used.
Jan 28, 2014 at 3:16 PM
Hi Aaron,

This issue is solved by commenting STUNServerHostname and PublicIPAddress. Now it is mangling using public address of client instead of server's public address.
<!-- SIP Proxy configuration. --> <sipproxy>
<MonitorLoopbackPort value="10001" />
<ProxyScriptPath value="proxyscript.py" />
<NATKeepAliveSocket value="127.0.0.1:9001" />
<!--<STUNServerHostname value="stun.counterpath.com" />-->
<!--<PublicIPAddress value="0.0.0.0" />-->
<sipsockets>
  <socket>*:5060</socket>
  <socket protocol="tcp">*:5060</socket>
</sipsockets>
</sipproxy>