[SR-Users] Kamailio for NATted users with ICE and TURN

Daniel Pocock daniel at pocock.com.au
Mon Jan 30 13:13:27 CET 2012



On 30/01/12 09:08, Klaus Darilion wrote:
> 
> 
> On 29.01.2012 12:21, Daniel Pocock wrote:
>>
>>
>>
>> There are now a number of TURN implementations available:
>>
>> http://www.resiprocate.org/ReTurn_Overview
>> http://turnserver.sourceforge.net/
> 
> http://www.creytiv.com/restund.html

Thanks for that - I notice the web site is very bare, how does it
compare with the other open source solutions?

>> and for many purposes TURN relays and ICE are much better than relying
>> on NAT helper and rtpproxy
>>
>> When clients use ICE:
>> - the client gets upset if Kamailio mangles the SDP to use rtpproxy
>> - it is actually not necessary for the SDP to have addresses tweaked -
>> because ICE deals with it anyway
>>
>> In practice, it still appears necessary for the registration server to
>> deal with NATted contact addresses though
> 
> Yes. ICE and TURN are purely for media NAT Traversal. For SIP NAT
> traversal either "fix" it in the server or use SIP "outbound":
> http://tools.ietf.org/html/rfc5626

My ICE clients are configured for outbound proxy via Kamailio over TLS.
 However, I need to look more closely to see if they attempt to comply
with RFC 5626.

I noticed that this config, on it's own, was not sufficient.  Kamailio
would store the 192.168 addresses as contact addresses, and would not
send the SIP packets back over the existing TLS connection - it would
try to start a new TLS connection back to the 192.168 address.

Therefore, it seems that both fixing the contact header and having an
outbound proxy architecture are needed together - at least, that is what
is working for me.

>> Can anyone clarify how Kamailio should be configured for ICE clients?
>> In other words, is it possible to have Kamailio dealing with NATted
>> contact addresses, but not touching the SDP?
> 
> Sure. There are different functions for NAT traversal. Some mangle the
> Contact header, some mange the SDP and activate the media relay. Thus,
> just remove all the "rtpproxy" function calls.

I'm using the default kamailio.cfg from 3.2

I have simply gone into the

route[NATMANAGE]

section and commented the line:

#rtpproxy_manage();

and my ICE clients seem happy.

I'm also contemplating some variation of the code below to politely
decline NAT clients with no ICE support (using SIP response code 606):

# RTPProxy control
route[NATMANAGE] {
#!ifdef WITH_NAT
        if (is_request()) {
                if(has_totag()) {
                        if(check_route_param("nat=yes")) {
                                setbflag(FLB_NATB);
                        }
                }
        }
        if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
                return;

        #rtpproxy_manage();
	if(is_request() && is_method("INVITE") &&
                   !search_body("^a=ice")) {
                   sl_send_reply("606", "Private IP detected in SIP
message.  You must use a UA supporting ICE, a router with SIP NAT
support, or a public IP address");
        }
	

        if (is_request()) {
                if (!has_totag()) {
                        add_rr_param(";nat=yes");
                }
        }
        if (is_reply()) {
                if(isbflagset(FLB_NATB)) {
                        fix_nated_contact();
                }
        }
#!endif
        return;
}



More information about the sr-users mailing list