[SR-Users] FW: Client site NAT negotiation with no STUN.

Rob Moore Rob.Moore at Aeriandi.com
Fri Feb 14 10:18:07 CET 2014


Hi there.

So I'm fighting what must be a bit of a common problem here but the usual googling isn't really helping me out.

A bit of background:

Classic Nat scenario of a sip handset behind a NAT firewall over the internet to VoIP SBC setup using Kamailio 3.3 and RTPProxy and Freeswitch as the registrar / calls server behind kamailio.

(please excuse the beautiful ASCI art)
                                                                                                                    --------------
                                                                                                  ---- ----|  RTPproxy |-------
---------------              ------------                                       |               --------------            |      ---------------
|SIP Phone|--------|Firewall |---------internet-------------|  kamailio   |-----------|Freeswitch|
---------------              ------------                                                        --------------                    ---------------

SIP Phones can register fine (over TCP or TLS, Kam offloads TLS if used) however when establishing  a call the SIPPhone sends its local network IP address within the SDP instead of the firewalls external address. Causing media to me miss directed by the RTP Proxy.

I've put a phone in with STUN to check that this is the only issue and that phone works fine .Usually in this situation  we would just use STUN or TURN / ICE to get around the issue however the handsets that we are working with (and have to work with for other reasons) do not support any of these technologies. So I've been forced to try and find another solution.

I was hoping to find some method within kamailio / RTPproxy to resolve this. I could just rewrite the SDP in certain situations but that feels a little bit brutal if I'm honest. I've heard of  RTPproxy being able to do some sort of rtp latching where it can correct its destination ip address after it receives its first rtp packets from the SIP Phone after being forwarded by the onsite firewall but other than this 'word of mouth' suggestion I've not managed to find  any detail of this functionality in the usual online resources.

Can anyone suggest any other potential methods for getting around this problem?

Many Thanks

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140214/369a612d/attachment-0001.html>


More information about the sr-users mailing list