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.07799e3eb71f33a9ef91178ac760ebd2.0
Via: SIP/2.0/UDP 2.3.4.5;branch=z9hG4bKsr-BnCVyrWoUladI14pU7Pry-Pzy-ONy-VSQ74NU7HzeYazq2nFU2Oc5FIWiGIKq-HXex1oONpam-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-eNC05xhKefQnON1EglFrOkF0OfpzV2s9UzM9UXMNQXMn5-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 172.17.130.13 59426 typ host
a=candidate:igct4zWHEzhGCjWc 2 UDP 2130706430 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 List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com