<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Juha<div><br></div><div>Thanks for reporting this. We will look for a solution.</div><div><br></div><div>Regards,</div><div>Adrian</div><div><br></div><div><div><div>On Sep 5, 2008, at 8:18 AM, Juha Heinanen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>i did some tests today with two back-to-back mediaproxies and, indeed, if<br>both of them are mediaproxy 2.0, then deadlock happens, i.e., after<br>receiving rtp packets from nated UAs, both of them are waiting rtp<br>packets from each other and don't forward any packets out to each other<br>even when they both public ip addresses. &nbsp;if i change one of the<br>mediaproxies to version 1.9, the problem disappears.<br><br>below is log at one of the two mediaproxies if it would reveal<br>something. &nbsp;&nbsp;so the question is, has something changed from 1.9 to 2.0<br>regarding this:<br><br> &nbsp;Please note however that if one party is not behind<br> &nbsp;NAT the proxy server is able to send packets to it even before it receives a<br> &nbsp;packet from it, since the IP/port is already known. Because of this, our<br> &nbsp;mediaproxy server is able to work even when chained with another mediaproxy<br> &nbsp;server. There will be no blocking of the media streams because both mediaproxy<br> &nbsp;servers are passive and wait forever for a packet from each other. Instead our<br> &nbsp;mediaproxy server will only be passive and wait for a packet if the party it<br> &nbsp;talks with is behind NAT making it possible to chain as many mediaproxy<br> &nbsp;servers without blocking.<br><br>if back-to-back mediaproxies are not supported anymore, a new module<br>(mediaproxy_old) needs to be included that can control mediaproxy<br>version 1.9.<br><br>i'll cc to ruud and dan in case they are not subscribing to this list.<br><br>-- juha<br><br>Sep &nbsp;5 08:54:12 lohi media-dispatcher[3367]: [OpenSERControlProtocol,7,] Issuing "update" command to relay at 127.0.0.1<br>Sep &nbsp;5 08:54:12 lohi media-relay[3381]: [RelayClientProtocol,client] Received new SDP offer<br>Sep &nbsp;5 08:54:12 lohi media-relay[3381]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50036<br>Sep &nbsp;5 08:54:12 lohi media-relay[3381]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50037<br>Sep &nbsp;5 08:54:12 lohi media-relay[3381]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50038<br>Sep &nbsp;5 08:54:12 lohi media-relay[3381]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50039<br>Sep &nbsp;5 08:54:12 lohi media-relay[3381]: [RelayClientProtocol,client] Added new stream: (audio) 192.168.0.7:8034 (RTP: Unknown, RTCP: Unknown) &lt;-> 192.99.102.4:50036 &lt;-> 192.99.102.4:50038 &lt;-> Unknown (RTP: Unknown, RTCP: Unknown)<br>Sep &nbsp;5 08:54:12 lohi media-relay[3381]: [RelayClientProtocol,client] created new session ifnhmfcgodiaxbt@localhost: <a href="mailto:+35864275274@tutpro.com">+35864275274@tutpro.com</a> (epnjv) --> <a href="mailto:+35865551100@enumin.wirlab.net">+35865551100@enumin.wirlab.net</a><br>Sep &nbsp;5 08:54:14 lohi media-dispatcher[3367]: [OpenSERControlProtocol,2,] Issuing "update" command to relay at 127.0.0.1<br>Sep &nbsp;5 08:54:14 lohi media-relay[3381]: [RelayClientProtocol,client] updating existing session ifnhmfcgodiaxbt@localhost: <a href="mailto:+35864275274@tutpro.com">+35864275274@tutpro.com</a> (epnjv) --> <a href="mailto:+35865551100@enumin.wirlab.net">+35865551100@enumin.wirlab.net</a><br>Sep &nbsp;5 08:54:14 lohi media-relay[3381]: [RelayClientProtocol,client] Received updated SDP answer<br>Sep &nbsp;5 08:54:14 lohi media-relay[3381]: [RelayClientProtocol,client] Got initial answer from callee for stream: (audio) 192.168.0.7:8034 (RTP: Unknown, RTCP: Unknown) &lt;-> 192.99.102.4:50036 &lt;-> 192.99.102.4:50038 &lt;-> 192.98.81.151:50200 (RTP: Unknown, RTCP: Unknown)<br>Sep &nbsp;5 08:54:14 lohi media-relay[3381]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.0.7:8034 (RTP: Unknown, RTCP: 192.99.102.3:8035) &lt;-> 192.99.102.4:50036 &lt;-> 192.99.102.4:50038 &lt;-> 192.98.81.151:50200 (RTP: Unknown, RTCP: Unknown)<br>Sep &nbsp;5 08:54:14 lohi media-relay[3381]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.0.7:8034 (RTP: 192.99.102.3:8034, RTCP: 192.99.102.3:8035) &lt;-> 192.99.102.4:50036 &lt;-> 192.99.102.4:50038 &lt;-> 192.98.81.151:50200 (RTP: Unknown, RTCP: Unknown)<br>Sep &nbsp;5 08:54:17 lohi media-dispatcher[3367]: [OpenSERControlProtocol,6,] Issuing "remove" command to relay at 127.0.0.1<br>Sep &nbsp;5 08:54:17 lohi media-relay[3381]: [RelayClientProtocol,client]<br>removing session ifnhmfcgodiaxbt@localhost: <a href="mailto:+35864275274@tutpro.com">+35864275274@tutpro.com</a><br>(epnjv) --> <a href="mailto:+35865551100@enumin.wirlab.net">+35865551100@enumin.wirlab.net</a><br><br><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></div></blockquote></div><br></div></body></html>