Hi, On Jan 8, 2013, at 10:49 AM, Remco . wrote:
> 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. > Can you send the syslog output from mediaproxy and a SIP trace of the call? Regards, -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
