[Serusers] mediaproxy feature request: immediate re-invite

[Klaus Darilion]

But how do you know if a client is behind symmetric NAT or a less 
restrictive NAT - that means how will you know if the reINVITE with 
changed SDP will work?

klaus

Federico Giannici wrote:
> Klaus Darilion wrote:
> 
>> If you have symmetric NAT, then this wont work (as you already said).
>>
>> If you have less restictive NAT, you can use STUN so there is no need 
>> for a mediaproxy at all.
> 
> 
> OK, but I'd like to handle the NAT problems on the server side instead 
> of the clients, because:
> 
> 1) It simplifies clients configuration.
> 
> 2) I have found that many STUN client implementations are bugged and 
> even a GREAT number of ALG implementations are bugged too.
> 
> 3) I'd like to solve Hairpin problems too, as it is one of the biggest 
> problem I have encountered.
> 
> With regard of the last point, with the nathelper module I can solve the 
> problem of not knowing the NATted SIP port and with this feature of 
> mediaproxy I could solve the problem of not knowing the NATted RTP port.
> 
> So, making the clients register with their private (not NATted) IP, I 
> could have all the data for normal working, and moreover, having the 
> original (not NATted IP/ports), I could also avoid the hairpin problems 
> (at least for users behind only one level of NAT).
> 
> Bye.
> 
> 
>> Federico Giannici wrote:
>>
>>> As I found no other support email address for mediaproxy, I'm sending 
>>> here this request...
>>>
>>> Is it possible to implement an option in mediaproxy to allow an 
>>> IMMEDIATE RE-INVITE to both UAs as soon as the RTP streams start?
>>>
>>> The idea is to use Mediaproxy only to find out the NATted RTP ports 
>>> of both UAs. Then a re-INVITE is immediately sent to the UAs so that 
>>> the streams are no longer proxied, avoiding all problems of RTP 
>>> relaying: waste of bandwidth, longer delays, bad scalability, etc.
>>>
>>> I know this will not work with symmetric NATs, but I found that they 
>>> are relatively rare and anyway they will neither work with STUN...
>>>
>>>
>>> If anybody knows that this is theoretically impossible to implement, 
>>> please tell me that.
>>>
>>>
>>> Thanks.
>>>
>>
>>
> 
>