Stupid gmail replying to sender only...
---------- Forwarded message ---------- From: George Diamantopoulos georgediam@gmail.com Date: 27 August 2017 at 02:29 Subject: Re: [SR-Users] Weird issue with kamailio relaying messages to itself To: Daniel-Constantin Mierla miconda@gmail.com
Hello all,
I've figured out what was going on, so I'm sharing here in case anyone else runs into this. I guess it should be a fairly common situation under certain circumstances when using the dispatcher module...
The problem was that no destinations in the dispatcher set used were available for these requests. So $du was not set by ds_select_next. Which meant that when t_relay() was called later in the script, it would route based on R-URI, and the RURI's uri was kamailio itself.
As to the reason why I was left with no dispatcher destinations available, well, I would mark destinations offline for 500 "server error" responses coming from them, and asterisk (which is the receiving application for all of dispatcher's destination sets) will send out a 500 to the B-leg when it receives a 480 to an A-leg. Getting a single 480 to one of the asterisk boxes would cause this to happen across all destinations, as kamailio would retry the next destination after a 500 failure and would receive a 500 from all of them in the end (because all of them would get the 480 in such small time frame).
BR, George
On 31 July 2017 at 21:52, George Diamantopoulos georgediam@gmail.com wrote:
Hello Daniel,
Thanks for the reply. That is correct, looping was not my intention, I'm trying to figure out what's causing it...
BR, George
On 31 July 2017 at 17:29, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
usually you should not loop requests locally, unless a very special case -- do you do the loop routing because of a need or just happens but you don't know why?
Cheers, Daniel
On 31.07.17 13:46, George Diamantopoulos wrote:
Hello all,
I have been toying with kamailio lately, and I thought I had gotten to the point where I had a mostly working (tm) prototype. I gave it a test drive with some real calls, however, and an issue manifested at least once, where homer received packets originating from the kamailio host, and whose destination was also the kamailio host.
The dialog this manifested in is a generally problematic one, with many retransmissions occurring because of slow database access (I haven't implemented htable caching yet). No packet capture over the network is actually taking place, I'm copying everything to homer with "trace_mode"set to 1.
Homer shows these messages like in the screenshot: https://imagebin.ca/v/3VGJAmovRBmo. Here's an example of a packet:
2017-07-28 14:32:29 +0300 : 2.3.4.5:5060 -> 2.3.4.5:5060 INVITE sip:1234567890@kamailio-server.org SIP/2.0 Record-Route: sip:2.3.4.5;lr;ftag=as491cec82 Via: SIP/2.0/UDP 2.3.4.5;branch=z9hG4bK0cf.0779 9e3eb71f33a9ef91178ac760ebd2.0 Via: SIP/2.0/UDP 2.3.4.5;branch=z9hG4bKsr-BnCVy rWoUladI14pU7Pry-Pzy-ONy-VSQ74NU7HzeYazq2nFU2Oc5FIWiGIKq-HXe x1oONpam-C6IrIXkr4FQxZRh7sM Max-Forwards: 69 From: sip:subscriber@5.4.3.2:5061;tag=as491cec82 To: sip:1234567890@kamailio-server.org Contact: sip:2.3.4.5;line=sr-eNC05xhKefQnON1EglFrOkF0OfpzV2s9UzM9UXM NQXMn5-B0Q-s* Call-ID: 4e5d22c3369704b97d866c8d0f3798f8@192.168.201.2:5061 CSeq: 103 INVITE User-Agent: Asterisk PBX 11.13.1~dfsg-2~bpo70+1 Date: Fri, 28 Jul 2017 11:32:24 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Remote-Party-ID: "9876543210" sip:9876543210@192.168.201.2 ;party=calling;privacy=off;screen=yes Content-Type: application/sdp Content-Length: 500
v=0 o=root 242468242 242468243 IN IP4 172.17.130.13 s=Asterisk PBX 11.13.1~dfsg-2~bpo70+1 c=IN IP4 172.17.130.13 t=0 0 m=audio 59426 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:50 a=sendrecv a=rtcp:59427 a=ice-ufrag:hffIoy6x a=ice-pwd:nXB8ip7Qz8ZG5yyZRr97kGJbej a=candidate:igct4zWHEzhGCjWc 1 UDP 2130706431 <21%203070%206431> 172.17.130.13 59426 typ host a=candidate:igct4zWHEzhGCjWc 2 UDP 2130706430 <21%203070%206430> 172.17.130.13 59427 typ host
Can something like this be triggered by misconfiguration in the routing scripts? Should it worry me and should I dig into it more? Could it be a bug of the siptrace module and nothing bad actually took place? I'm not sure where to start with this, so any input would be greatly appreciated. Thanks!
Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com