Hi all, I seem to experience a strange issue regarding Mediaproxy running on OpenSIPS The following scenario:
A. UA (asterisk) <=> OpenSIPS <=> UA (asterisk) B. I verified the following: - Both UA's have nat=never, no re-invite is taking place (verified by capture). - Ports in SDP are rewritten, and match the ports Mediaproxy opens. - Call has audio, in both directions. After 60 seconds mediaproxy logs a conntrack_timeout, and the call loses audio in both directions. The following port schema is negotiated: A. 11496 <=(capture)=> 30600 OpenSIPS 30602 <=> 17026 B. The RTP stream is captured at (capture) between A and the proxy. The first 3 RTP packet traverse from B => A on the correct ports over the relay. Then a packet is sent the other way A => B on the corect ports over the relay. Then the strange thing happens, the next packet going B => A is sent with a source port of 1024 by the relay. All subsequent packets in the stream are exchanged between A (11496/udp) and OpenSIPS (1024/udp). 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). Also, port 1024 is not allowed by firewalls as it's not expected for media to pass over this port. 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. Any ideas? Thanks, Remco.
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
