29 Jan
2012
29 Jan
'12
1:21 p.m.
There are now a number of TURN implementations available:
http://www.resiprocate.org/ReTurn_Overview
http://turnserver.sourceforge.net/
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
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?
To limit the scope of the question:
- assume non-ICE clients do not need to be supported at all (just ignore
them, although a nice cfg would scan all SDP and send a helpful error
back if it sees a 192.168 address and no a=ice* attributes)
- assume clients are connecting with TLS over TCP, so there is no risk
that some intermediate device like a router is mangling the SIP headers
or SDP
30 Jan
30 Jan
10:08 a.m.
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
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
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.
regards
klaus
To limit the scope of the question:
- assume non-ICE clients do not need to be supported at all (just ignore
them, although a nice cfg would scan all SDP and send a helpful error
back if it sees a 192.168 address and no a=ice* attributes)
- assume clients are connecting with TLS over TCP, so there is no risk
that some intermediate device like a router is mangling the SIP headers
or SDP
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:13 p.m.
On 30/01/12 09:08, Klaus Darilion wrote:
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.
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;
}
On 29.01.2012 12:21, Daniel Pocock wrote:
Thanks for that - I notice the web site is very bare, how does it
compare with the other open source solutions?
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 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 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.
4680
days inactive
4681
days old
2 comments
2 participants
participants (2)
-
Daniel Pocock -
Klaus Darilion