Hi, After some hair pulling, and going over a number of examples I established some sort of pattern in this issue:
Session establishes, one party starts sending RTP. Lets say A (asterisk) sends to B (proxy) C (proxy) sends to D (asterisk). B and C are both on the same machine / same interface. The first couple of packets (10-20) are relayed just fine on the correct ports. Then, a return packet arrives, from D to C, which is correctly relayed to A using the right ports. Then a new packet comes in from A to B, again using the correct ports and is then relayed using 1024/udp (always this portnumber, although configured to use 40k to 60k!) as source port. The issue is, D starts replying to 1024/udp. Streams are not detected, and no conntrack rule is inserted. The following post seems to describe exact the same behaviour: http://www.mail-archive.com/[email protected]/msg12703.html nat=no is specified for the peer, however media is proxy'ied on a different IP address than SIP is received from (could that explain something?). I hope this rings a bell to someone, as apart from this issue mediaproxy is functioning perfect and I don't feel like replacing it. Thanks, Remco. On Mon, Jan 14, 2013 at 5:29 PM, Remco . <[email protected]> wrote: > 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
