[Serusers] mediaproxy feature request: immediate re-invite

Federico Giannici giannici at neomedia.it
Tue Sep 6 12:34:32 CEST 2005


Klaus Darilion wrote:
> 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?

But anyway we don't want to make RTP relaying, so this cases wouldn't 
work anyway with our sip server (even with STUN).


Bye.



>> 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.
>>>>
>>>
>>>
>>
>>
> 
> 


-- 
___________________________________________________
     __
    |-                      giannici at neomedia.it
    |ederico Giannici      http://www.neomedia.it

         Presidente del cda - NEOMEDIA srl
___________________________________________________




More information about the sr-users mailing list