26 Aug
2017
26 Aug
'17
7:39 p.m.
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(a)gmail.com>
wrote:
Stupid gmail replying to sender only...
---------- Forwarded message ----------
From: George Diamantopoulos <georgediam(a)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(a)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(a)gmail.com>
wrote:
-- Alex
--
Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
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(a)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
>>
>>
>