<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 8003@192.168.2.233 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><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></table>