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/
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; }