[OpenSIPS-Users] Mediaproxy wrong port, bug?

Remco . remconl87 at gmail.com
Tue Jan 22 00:59:53 CET 2013


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/users@lists.opensips.org/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 . <remconl87 at gmail.com> 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 . <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
>>
>>
>



More information about the Users mailing list