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 . <[email protected]> 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é > <[email protected]> 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/[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. >>> >> >> 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 >> [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
