[RTPproxy Devel] Automatic bridging for RTP proxy and advertised address for external NAT

[Maxim Sobolev]

Emmanuel BUU wrote:
> Maxim Sobolev a écrit :
>> Emmanuel BUU wrote:
>>   
>>>>   
>>>>       
>>> Hum great, maybe I can help with the NATHELPER module of OpenSIPS if you 
>>> describe me what change have been made to the RTP proxy control protocol 
>>> and provide me access to the source code.
>>>     
>> Yes, it should be possible. I will see what I can do in the next few days.
>>
>>   
> Hello : I made may one crude implementatiion of automated routing. I had 
> indeed to modify the NATHELPER module to pass the requested host.
> So I am a bit more confortable with this piece of code.
> 
> Of course, when the 2.0 will be out, I will migrate to any official 
> solution.

Emmanuel,

The change is in CVS now, you are expected to provide either binding 
address for media or expected remote media address for automatic local 
address determination:

 > sobomax     2009/08/11 01:24:06 CEST
 >
 >   SER CVS Repository
 >
 >   Modified files:
 >     .                    main.c rtpp_command.c rtpp_defines.h
 >                          rtpp_network.c rtpp_network.h
 >   Log:
 >   Introduce automatic bridging functionality. The way it works is that
 >   the RTPproxy expects signalling layer (B2BUA, Sip Proxy etc) to let it
 >   know either local IP for media or remote IP for this particular call
 >   leg. If the local IP is specified, then it will be used verbatim,
 >   otherwise the local address will be determined automatically based
 >   on remote IP and result of dummy connect(2)/getsockname(2) calls.
 >   Both IPv6 and IPv4 addresses are supported.
 >
 >   Internally feature is implemented as an extension to the U/L command.
 >   option "l" should be used for local addresses, or option "r" for 
remote,
 >   with IPv6 address enclosed into square brackets. For example:
 >
 >   Ul[abcd:efgh:0:1] callid remote_ip remote_port fromtag
 >
 >   Lr1.2.3.4 callid remote_ip remote_port fromtag totag
 >
 >   Changes to OpenSIPS, Kamalio/SER and Sippy B2BUA are to follow.

Please let me know if you want to go ahead and make a patch for the 
nathelper. It would involve extracting destination address from the RURI 
for INVITE, and from upper Via for 200 OK.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft