Hi all,<br><br>I seem to experience a strange issue regarding Mediaproxy running on 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 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 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 relay.<br>
Then a packet is sent the other way A => B on the corect ports over the relay.<br><br>Then the strange thing happens, the next packet going B => A is sent with a source port of 1024 by the relay.<br>All subsequent packets in the stream are exchanged between A (11496/udp) and OpenSIPS (1024/udp). <br>
<br>I think the loss of the call is explained by the leg between the relay and B torn down, because of the conntrack timeout on leg A (mediaproxy sees no RTP on the expected ports).<br>Also, port 1024 is not allowed by firewalls as it's not expected for media to pass over this port.<br>
<br>I observe this on quite a number of calls, all being torn down after 60 seconds. Doing a random selection on them, they all seem to use port 1024 for RTP as described in the scenario above.<br><br>Any ideas?<br>Thanks,<br>
Remco.<br><br>
<br>