Hi,<br><br>No Sonicwall involved. There is a Cisco PiX between UA and OpenSIPS. SIP inspection and helpers have been disabled.<br>UA is Asterisk PBX.<br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 3:58 PM, dotnetdub <span dir="ltr"><<a href="mailto:dotnetdub@gmail.com" target="_blank">dotnetdub@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 8 January 2013 09:49, Remco . <<a href="mailto:remconl87@gmail.com">remconl87@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I seem to experience a strange issue regarding Mediaproxy running on<br>
> OpenSIPS The following scenario:<br>
><br>
> A. UA (asterisk) <=> OpenSIPS <=> UA (asterisk) B.<br>
><br>
> I verified the following:<br>
><br>
> - Both UA's have nat=never, no re-invite is taking place (verified by<br>
> capture).<br>
> - Ports in SDP are rewritten, and match the ports Mediaproxy opens.<br>
> - Call has audio, in both directions.<br>
><br>
> After 60 seconds mediaproxy logs a conntrack_timeout, and the call loses<br>
> audio in both directions.<br>
><br>
> The following port schema is negotiated:<br>
><br>
> A. 11496 <=(capture)=> 30600 OpenSIPS 30602 <=> 17026 B.<br>
><br>
> The RTP stream is captured at (capture) between A and the proxy.<br>
><br>
> The first 3 RTP packet traverse from B => A on the correct ports over the<br>
> relay.<br>
> Then a packet is sent the other way A => B on the corect ports over the<br>
> relay.<br>
><br>
> Then the strange thing happens, the next packet going B => A is sent with a<br>
> source port of 1024 by the relay.<br>
> All subsequent packets in the stream are exchanged between A (11496/udp) and<br>
> OpenSIPS (1024/udp).<br>
><br>
> I think the loss of the call is explained by the leg between the relay and B<br>
> torn down, because of the conntrack timeout on leg A (mediaproxy sees no RTP<br>
> on the expected ports).<br>
> Also, port 1024 is not allowed by firewalls as it's not expected for media<br>
> to pass over this port.<br>
><br>
> I observe this on quite a number of calls, all being torn down after 60<br>
> seconds. Doing a random selection on them, they all seem to use port 1024<br>
> for RTP as described in the scenario above.<br>
><br>
> Any ideas?<br>
> Thanks,<br>
> Remco.<br>
<br>
<br>
<br>
</div></div>Sonicwall involved here by any chance? What is the UA?<br>
<div class="HOEnZb"><div class="h5"><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" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br>