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 <georged...@gmail.com> wrote: >Stupid gmail replying to sender only... > >---------- Forwarded message ---------- >From: George Diamantopoulos <georged...@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 <mico...@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 <georged...@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 ><mico...@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:1234567...@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:1234567...@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. _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users