[OpenSIPS-Users] Mediaproxy wrong port, bug?

[Remco .]

Hi all,

I found the cause of this issue: asterisk. For future reference, this
is what caused this kind of behaviour:

SIP proxy: 1.1.1.1
Media proxy: 1.1.1.2
Media proxy: 1.1.1.3

Asterisk has a peer (opensips) defined as 1.1.1.1 with nat=no. Global
setting:  nat=yes. Changing this to global nat=never and enable it
explicit for peers who need it does solve the problem. Somehow,
asterisk does not seem to recognize audio streams to 1.1.1.2 and
1.1.1.3 to belong to a session going to 1.1.1.1 and does something to
confuse Mediaproxy. I did not further look into the exact cause of
this issue.

Regards,
Remco.

On Tue, Jan 22, 2013 at 4:04 PM, Remco . <remconl87 at gmail.com> wrote:
> Hi Saúl,
>
> I have sent you the information you asked for by e-mail. For the
> interest of others, who might encounter the same problem in the future
> I'll post my findings here as well.
> The streams seem to traverse the mediaproxy somehow (or at least, they
> go over the box). They do so on port 1024/udp (on both ends). An
> update entry is visible in the syslog (level: debug).
>
> Thanks,
> Remco.
>
> On Tue, Jan 22, 2013 at 12:45 PM, Saúl Ibarra Corretgé
> <saul at ag-projects.com> wrote:
>> Hi,
>>
>> Sorry it took me some time. I inspected the traces you sent me privately, see inline.
>>
>> On Jan 22, 2013, at 12:59 AM, Remco . wrote:
>>
>>> 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.
>>
>> Do those packets traverse MediaProxy? The traces didn't show any. Otherwise you would have seen a stream update log line mentioning that RTP was received. Also, the statistics don't account for any received packets (caller_packets, callee_packets).
>>
>>> 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.
>>>
>>
>> Can you send me a trace which includes both SIP and RTP along with the syslog on the dispatcher and the relay machines?
>>
>>
>> Regards,
>>
>> --
>> Saúl Ibarra Corretgé
>> AG Projects
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users