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@gmail.com wrote:
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
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
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.