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

Alex Balashov abalashov at evaristesys.com
Sun Aug 27 01:39:46 CEST 2017


Hi George, 

You should check if ds_select_dst() returns a falsey value, and reject the call in such a case, rather than continuing onward to t_relay() with this kind of result. 

On August 26, 2017 7:30:48 PM EDT, George Diamantopoulos <georgediam at gmail.com> wrote:
>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
>>>
>>>
>>


-- Alex

--
Principal, Evariste Systems LLC (www.evaristesys.com)

Sent from my Google Nexus.



More information about the sr-users mailing list