[OpenSIPS-Users] Parallel forking (using registrar branching) & mediaproxy

[Adrian Georgescu]

Erwan,

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.

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.

Adrian


On Jun 4, 2009, at 12:09 PM, erwan.humez at orange-ftgroup.com wrote:

>
> Hi,
>
> 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.
>
> Here is the context :
> opensips 1.5.1 / mediaproxy 2.3.4 / Centos 5.2, on IP 192.168.2.233
> Caller on sip softphone, on IP 192.168.2.223
> Called on 2 tdm cisco media gateways, each registered using the same  
> uri 8003 at 192.168.2.233 behind 2 different IP@ : 10.0.0.2 and 10.0.1.1.
> Objective is to achieve a call // forked from sip to both tdm called  
> parties.
>
> // 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.
>
> 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).
>
> 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:
>
> Working call:
>
> 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)
>
> => RTCP IP is not correct here but does not prevent the call to be  
> successfully established.
>
> Non-working call:
>
> 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)
>
> => 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).
> => 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.
>
> 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...
>
> ... but maybe i missed or misunderstood something, so please can  
> someone enlight me on this issue ?
>
> Thanks a lot for help and support,
>
> Erwan.
> *********************************
> This message and any attachments (the "message") are confidential  
> and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered,  
> changed or falsified.
> If you are not the intended addressee of this message, please cancel  
> it immediately and inform the sender.
> ********************************
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090608/b592536e/attachment-0001.htm