Some additional information on this one as it turned out that I wasn't running the latest version. I updated to the latest version 2.5.2 of mediaproxy, but the issue still exists. Running kernel 2.6.32-5-amd64 (debian package).
On Tue, Jan 8, 2013 at 4:19 PM, Remco . <[email protected]> wrote: > Hi, > > No Sonicwall involved. There is a Cisco PiX between UA and OpenSIPS. SIP > inspection and helpers have been disabled. > UA is Asterisk PBX. > > > On Tue, Jan 8, 2013 at 3:58 PM, dotnetdub <[email protected]> wrote: > >> On 8 January 2013 09:49, Remco . <[email protected]> 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. >> > >> > Any ideas? >> > Thanks, >> > Remco. >> >> >> >> Sonicwall involved here by any chance? What is the UA? >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
