[SR-Users] Fwd: Weird issue with kamailio relaying messages to itself

[George Diamantopoulos]

Stupid gmail replying to sender only...

---------- Forwarded message ----------
From: George Diamantopoulos <georgediam at 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 at 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 at 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 at 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 at 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 at 5.4.3.2:5061>;tag=as491cec82
>> To: <sip:1234567890 at kamailio-server.org>
>> Contact: <sip:2.3.4.5;line=sr-eNC05xhKefQnON1EglFrOkF0OfpzV2s9UzM9UXM
>> NQXMn5-B0Q-s*>
>> Call-ID: 4e5d22c3369704b97d866c8d0f3798f8 at 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 at 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 at 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170827/17a20940/attachment.html>