Stupid gmail replying to sender only... ---------- Forwarded message ---------- From: George Diamantopoulos <[email protected]> Date: 27 August 2017 at 02:29 Subject: Re: [SR-Users] Weird issue with kamailio relaying messages to itself To: Daniel-Constantin Mierla <[email protected]>
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 <[email protected]> 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 <[email protected]> > 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:[email protected] 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:[email protected]:5061>;tag=as491cec82 >> To: <sip:[email protected]> >> Contact: <sip:2.3.4.5;line=sr-eNC05xhKefQnON1EglFrOkF0OfpzV2s9UzM9UXM >> NQXMn5-B0Q-s*> >> Call-ID: [email protected]: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:[email protected]> >> ;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 >> [email protected]https://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 >> >> >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
