<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Erwan,<div><br></div><div>Mediaproxy was not designed to work with a private IP address. The whole NAT traversal logic is based on detection of whether the client is behind a private NAT and this requires the server itself to have a public IP address in the first place.</div><div><div><br></div><div>So if you use MediaProxy with a private IP your will likely have no support from us as you are using the software beyond what it was designed for and we have no plan to support it the way you use it.</div><div><br></div><div>Adrian</div><div><div><br></div><div><br><div><div>On Jun 4, 2009, at 12:09 PM, <a href="mailto:erwan.humez@orange-ftgroup.com">erwan.humez@orange-ftgroup.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><font size="2" face="sans-serif">Hi,</font> <br> <br><font size="2" face="sans-serif">I came across something weird about parallel forking: media information (IP @ received from SDP for RTP) is not properly communicated to media proxy, but only for one of the 2 calls.</font> <br> <br><font size="2" face="sans-serif">Here is the context :</font> <br><font size="2" face="sans-serif">opensips 1.5.1 / mediaproxy 2.3.4 / Centos 5.2, on IP 192.168.2.233</font> <br><font size="2" face="sans-serif">Caller on sip softphone, on IP 192.168.2.223</font> <br><font size="2" face="sans-serif">Called on 2 tdm cisco media gateways, each registered using the same uri <a href="mailto:8003@192.168.2.233">8003@192.168.2.233</a> behind 2 different IP@ : 10.0.0.2 and 10.0.1.1.</font> <br><font size="2" face="sans-serif">Objective is to achieve a call // forked from sip to both tdm called parties.</font> <br> <br><font size="2" face="sans-serif">// sip forking seems to be working fine in the way that when one picks up the other one is properly cancelled. For information, both media gateways send a 183/SDP message and then a 200 OK/SDP upon pick-up. Media proxy sends/forwards 183/SDP messages to caller without modifying IP @ (keeping 10.0.0.2 & 10.0.1.1) and then only sends the modified (with media proxy IP@) 200 OK/SDP message to the caller upon pick-up.</font> <br> <br><font size="2" face="sans-serif">The issue (check below for media proxy traces) is reproductible because each time the same gateway is impacted (no need to precise that basic calls are working fine in both ways for call setup and on both gateways, which should prevent from any network related issue/question).</font> <br> <br><font size="2" face="sans-serif">Of course i got all required traces that i can provide upon request to avoid spamming the list but so far and mainly, here is what i can see from media proxy traces:</font> <br> <br><font size="2" face="sans-serif">Working call:</font> <br> <br><font size="2" face="Courier New">debug: Got traffic information for stream: (audio) 192.168.2.223:5298 (RTP: 192.168.2.223:5298, RTCP: 192.168.2.223:5299) <-> 192.168.2.233:50072 <-> 192.168.2.233:50074 <-> 10.0.0.2:19098 (RTP: 10.0.0.2:19098, RTCP: 10.0.1.1:19163)</font> <br> <br><font size="2" face="sans-serif">=> RTCP IP is not correct here but does not prevent the call to be successfully established.</font> <br> <br><font size="2" face="sans-serif">Non-working call:</font> <br> <br><font size="2" face="Courier New">debug: Got traffic information for stream: (audio) 192.168.2.223:5304 (RTP: 192.168.2.223:5304, RTCP: 192.168.2.223:5305) <-> 192.168.2.233:50080 <-> 192.168.2.233:50082 <-> 10.0.1.1:16910 (RTP: 10.0.0.2:19560, RTCP: 10.0.0.2:19561)</font> <br> <br><font size="2" face="sans-serif">=> RTP 10.0.0.2:19560 information is taken from the 183/SDP message sent by the gateway to wich the forked call is canceled: it should be the RTP information coming from the 183/SDP message sent by the other gateway (10.0.0.1:16910).</font> <br><font size="2" face="sans-serif">=> neither RTP and RTCP are correct here. Network traces confirm that media proxy keeps sending RTP packets towards 10.0.0.2:19560 getting an icmp destination port unreachable of course.</font> <br> <br><font size="2" face="sans-serif">I understand that SDP information received in both 183 messages could cause some troubles in opensips and media proxy communications... Somewhere and somehow, the information should be updated in media proxy...</font> <br> <br><font size="2" face="sans-serif">... but maybe i missed or misunderstood something, so please can someone enlight me on this issue ?</font> <br> <br><font size="2" face="sans-serif">Thanks a lot for help and support,</font> <br> <br><font size="2" face="sans-serif">Erwan.</font> <table><tbody><tr><td bgcolor="#ffffff"><font color="#000000">*********************************<br> This message and any attachments (the "message") are confidential and intended solely for the addressees. <br> Any unauthorised use or dissemination is prohibited.<br> Messages are susceptible to alteration. <br> France Telecom Group shall not be liable for the message if altered, changed or falsified.<br> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.<br> ********************************<br> </font></td></tr></tbody></table>_______________________________________________<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></blockquote></div><br></div></div></div></body></html>