30 Jan
2012
30 Jan
'12
9: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