26 Aug
2017
26 Aug
'17
7:30 p.m.
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:
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
26 Aug
26 Aug
7:39 p.m.
New subject: Fwd: Weird issue with kamailio relaying messages to itself
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
>>
>>
>
2679
days inactive
2679
days old
1 comments
2 participants
participants (2)
-
Alex Balashov -
George Diamantopoulos