[OpenSIPS-Users] Mediaproxy wrong port, bug?

[Remco .]

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 . <remconl87 at gmail.com> 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 <dotnetdub at gmail.com> wrote:
>
>> On 8 January 2013 09:49, Remco . <remconl87 at gmail.com> 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
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130114/711e6f25/attachment.htm>