[OpenSER-Users] mediaproxy server NEW FEATURE!!!
Folks, I developed a new feature in the Media Proxy project of AG-Proyect. With this new feature the Media Proxy Server is now able to manage the problem of the NAT IP change in an established call. It is currently in production and working without any problem. Somebody wants to test it? I would like to know what to do to make this feature available to everybody. Does anybody know? Regards, ------------------------------ Details: ------- Supose that there is an established rtp connection between two endpoints and the media proxy is in the middle doing the relay of the rtp streams, let´s say (MP = mediaproxy) EP A <--------->[NAT with IP1]<-----------> MP <--------------------> EP B EP A sends rtp to MP_IP:MP_PORT passing through the NAT box. EP B sends rtp to MP_IP:MP_PORT without passing through a NAT box. The MP know that the caller = NAT_IP1:NAT_PORT1, and the called = EP_B_IP:EP_B_PORT Now, supose that the NAT box change their PUBLIC IP from IP1 to IP2, so this escenary EP A <------->[NAT with IP1]<---------> MP <-------------> EP B will change to this EP A <------->[NAT with IP2]<---------> MP <--------------> EP B so the MP should detect that change of IPs and continue relaying the rtp streams but now to IP2:PORT2 instead of IP1:PORT1. Well, that was the situation y have experienced. To fix this, I developed this solution, changing rtphandler.py file: 1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called. 2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved. Note: SSRC (RFC 3550 RTP), (from the rfc: "The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session ") -------------------------------- -- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo.sambucaro@mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina -- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo.sambucaro@mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina
Hello, nice feature, i know the problem, because our local ISP´s are disconnecting DSL lines every 8 hours. But the DSL line needs nearly 8 seconds, to be up and running again(PPP dialup), if i can´t hear my partner for a few seconds i will disconnect the line and redial, my opinion. Same in mobile environments, when the handover doesn´t work, saying "hello? - hello?" -> hangup -> redial. But i´m willing to try, leave me a note, where i can download your version. regards, Andreas M. Gonzalo J. Sambucaro schrieb:
Folks, I developed a new feature in the Media Proxy project of AG-Proyect. With this new feature the Media Proxy Server is now able to manage the problem of the NAT IP change in an established call. It is currently in production and working without any problem.
Somebody wants to test it?
I would like to know what to do to make this feature available to everybody. Does anybody know?
Regards,
------------------------------
Details: ------- Supose that there is an established rtp connection between two endpoints and the media proxy is in the middle doing the relay of the rtp streams, let´s say
(MP = mediaproxy)
EP A <--------->[NAT with IP1]<-----------> MP <--------------------> EP B
EP A sends rtp to MP_IP:MP_PORT passing through the NAT box. EP B sends rtp to MP_IP:MP_PORT without passing through a NAT box.
The MP know that the caller = NAT_IP1:NAT_PORT1, and the called = EP_B_IP:EP_B_PORT
Now, supose that the NAT box change their PUBLIC IP from IP1 to IP2, so this escenary
EP A <------->[NAT with IP1]<---------> MP <-------------> EP B
will change to this
EP A <------->[NAT with IP2]<---------> MP <--------------> EP B
so the MP should detect that change of IPs and continue relaying the rtp streams but now to IP2:PORT2 instead of IP1:PORT1.
Well, that was the situation y have experienced.
To fix this, I developed this solution, changing rtphandler.py file:
1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called.
2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved.
Note: SSRC (RFC 3550 RTP), (from the rfc: "The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session ")
--------------------------------
-- g, Andreas M.
Andreas, our local ISP´s are disconnecting DSL lines more ofthen but it renews the IP almost instantaneously. Regards, Gonzalo.
Hello, nice feature, i know the problem, because our local ISP´s are disconnecting DSL lines every 8 hours. But the DSL line needs nearly 8 seconds, to be up and running again(PPP dialup), if i can´t hear my partner for a few seconds i will disconnect the line and redial, my opinion.
Same in mobile environments, when the handover doesn´t work, saying "hello? - hello?" -> hangup -> redial.
But i´m willing to try, leave me a note, where i can download your version.
regards, Andreas M.
Gonzalo J. Sambucaro schrieb:
Folks, I developed a new feature in the Media Proxy project of AG-Proyect. With this new feature the Media Proxy Server is now able to manage the problem of the NAT IP change in an established call. It is currently in production and working without any problem.
Somebody wants to test it?
I would like to know what to do to make this feature available to everybody. Does anybody know?
Regards,
------------------------------
Details: ------- Supose that there is an established rtp connection between two endpoints and the media proxy is in the middle doing the relay of the rtp streams, let´s say
(MP = mediaproxy)
EP A <--------->[NAT with IP1]<-----------> MP <--------------------> EP B
EP A sends rtp to MP_IP:MP_PORT passing through the NAT box. EP B sends rtp to MP_IP:MP_PORT without passing through a NAT box.
The MP know that the caller = NAT_IP1:NAT_PORT1, and the called = EP_B_IP:EP_B_PORT
Now, supose that the NAT box change their PUBLIC IP from IP1 to IP2, so this escenary
EP A <------->[NAT with IP1]<---------> MP <-------------> EP B
will change to this
EP A <------->[NAT with IP2]<---------> MP <--------------> EP B
so the MP should detect that change of IPs and continue relaying the rtp streams but now to IP2:PORT2 instead of IP1:PORT1.
Well, that was the situation y have experienced.
To fix this, I developed this solution, changing rtphandler.py file:
1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called.
2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved.
Note: SSRC (RFC 3550 RTP), (from the rfc: "The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session ")
--------------------------------
-- g, Andreas M.
_______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo.sambucaro@mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina
"Gonzalo J. Sambucaro" <gonzalo.sambucaro@mslc.com.ar> writes:
[...] 1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called.
2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved.
An attacker would have to guess/sniff the SSRC and then could take over the rtp session? (maybe could be fixed by only allowing to take over after some timeout) On the other hand if he can sniff ...
Jens, yes, if an attacker guess/sniff the SSRC then could take over the rtp session. A timeout would work fine but right now I don't have the time to do it, if somebody else wants to do it I can send the source code. Regards, Gonzalo.
"Gonzalo J. Sambucaro" <gonzalo.sambucaro@mslc.com.ar> writes:
[...] 1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called.
2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved.
An attacker would have to guess/sniff the SSRC and then could take over the rtp session? (maybe could be fixed by only allowing to take over after some timeout) On the other hand if he can sniff ...
_______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo.sambucaro@mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina
Hi, By the timeout implementation in now more secure the support of the NAT IP change. To change the Caller/Called address the mediaproxy waits for two seconds that the Caller/Called doesn't send any rtp/rtcp packet and checking the SSRC. This change was tested and in production working well. Also I found a bug in the asymmetric RTP UA support. This file contains the fix of the bug, the solution to the bug is very simple. How can I do to report the bug and the solution? Regards
"Gonzalo J. Sambucaro" <gonzalo.sambucaro@mslc.com.ar> writes:
[...] 1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called.
2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved.
An attacker would have to guess/sniff the SSRC and then could take over the rtp session? (maybe could be fixed by only allowing to take over after some timeout) On the other hand if he can sniff ...
-- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo.sambucaro@mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina
Hi Gonzalo, The current mediaproxy will be replaced by MediaProxy 2.0 that addresses this issues. Regards, Adrian On Apr 24, 2008, at 8:58 PM, Gonzalo J. Sambucaro wrote:
Hi, By the timeout implementation in now more secure the support of the NAT IP change. To change the Caller/Called address the mediaproxy waits for two seconds that the Caller/Called doesn't send any rtp/rtcp packet and checking the SSRC. This change was tested and in production working well.
Also I found a bug in the asymmetric RTP UA support. This file contains the fix of the bug, the solution to the bug is very simple. How can I do to report the bug and the solution?
Regards
"Gonzalo J. Sambucaro" <gonzalo.sambucaro@mslc.com.ar> writes:
[...] 1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called.
2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved.
An attacker would have to guess/sniff the SSRC and then could take over the rtp session? (maybe could be fixed by only allowing to take over after some timeout) On the other hand if he can sniff ...
-- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo.sambucaro@mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina<rtphandler.py.tgz>__________________________________________ _____ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Hi Adrian, The MediaProxy 2.0 supports the change of NAT IP in an established call?. Regards, Gonzalo.
Hi Gonzalo,
The current mediaproxy will be replaced by MediaProxy 2.0 that addresses this issues.
Regards, Adrian
On Apr 24, 2008, at 8:58 PM, Gonzalo J. Sambucaro wrote:
Hi, By the timeout implementation in now more secure the support of the NAT IP change. To change the Caller/Called address the mediaproxy waits for two seconds that the Caller/Called doesn't send any rtp/rtcp packet and checking the SSRC. This change was tested and in production working well.
Also I found a bug in the asymmetric RTP UA support. This file contains the fix of the bug, the solution to the bug is very simple. How can I do to report the bug and the solution?
Regards
"Gonzalo J. Sambucaro" <gonzalo.sambucaro@mslc.com.ar> writes:
[...] 1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called.
2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved.
An attacker would have to guess/sniff the SSRC and then could take over the rtp session? (maybe could be fixed by only allowing to take over after some timeout) On the other hand if he can sniff ...
-- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo.sambucaro@mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina<rtphandler.py.tgz>__________________________________________ _____ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
-- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo.sambucaro@mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina
On Thursday 24 April 2008, Gonzalo J. Sambucaro wrote:
By the timeout implementation in now more secure the support of the NAT IP change. To change the Caller/Called address the mediaproxy waits for two seconds that the Caller/Called doesn't send any rtp/rtcp packet and checking the SSRC. This change was tested and in production working well.
Also I found a bug in the asymmetric RTP UA support. This file contains the fix of the bug, the solution to the bug is very simple. How can I do to report the bug and the solution?
Hi Gonzalo, just use the project bug tracker: https://sourceforge.net/tracker/?group_id=139143&atid=743020 You could also attach your patch there. Cheers, Henning
participants (5)
-
Adrian Georgescu -
Andreas M. -
Gonzalo J. Sambucaro -
Henning Westerholt -
Jens Thiele