[asterisk-users] IAX2 and INVAL packets
Sebastian
shop at open-t.co.uk
Thu Nov 18 18:38:51 CST 2010
On 11/18/2010 10:38 PM, Tilghman Lesher wrote:
> On Thursday 18 November 2010 14:01:49 Sebastian wrote:
>> > Is anybody here familiar with the meaning of INVAL packets for IAX2?
>> >
>> > Every few days I get a dropped outgoing call in the middle of the
>> > conversation (the outgoing call has been connected for few minutes) when
>> > an incoming call comes in. The log reads the following when this
>> > happens:
>> >
>> >
>> >
>> > [Nov 17 15:25:04] DEBUG[5138] chan_iax2.c: Immediately destroying 2963,
>> > having received INVAL
>> > [Nov 17 15:25:04] DEBUG[5138] chan_iax2.c: Destroying call 2963
>> > [Nov 17 15:25:04] DEBUG[11242] chan_iax2.c: We're hanging up
>> > IAX2/ihs_trunk_out-2963 now...
>> > [Nov 17 15:25:04] VERBOSE[11242] chan_iax2.c: -- Hungup
>> > 'IAX2/ihs_trunk_out-2963'
>> >
>> >
>> >
>> > And more setup details, for those who still have the will to live:-)
>> >
>> > Asterisk version: 1.6.2.13
>> > Internal externsions: everything on SIP - 3 Grandstream GXP-2000, 2
>> > analog phones on a pci OpenVox card and 2 Linphone softphones
>> > Trunks: IAX2
>> > Trunks provider: Gradwell
>> > Asterisk machine: 800Mhz Intel Pentium, 512MB of RAM
>> > Internet connection: Tiscali business ADSL
>> >
>> > I am happy to post here any config files and logs you might think would
>> > be relevant.
>> >
>> > This is not consistent - and I've managed to have 4 concurrent calls
>> > which held 30 minutes (before I hung them up) when I tried. So not easy
>> > to replicate.
> An INVAL response basically means that the remote Asterisk box received
> a packet for a call that it did not think existed. So likely, something
> else caused the call to hangup (such as an unrelated error crashing a
> process, and the replacement process had no record of such a call, so it
> sent an INVAL response to any subsequent packet).
>
> Technically, this could also be done as a MITM attack. If something were
> to see even a single packet related to the call, it is able to fake an
> INVAL packet. BTW, this is not unique to IAX2; a MITM attack can also fake
> a SIP CANCEL.
Hi Tilghman and thank you for replying. I have been working on narrowing
this down for a few months now - without much success.
Do you have any suggestions on taking further steps to find the cause?
In case it helps:
1. I use iptables to only allow in IAX2 connections from the IP
addresses of the VoIP provider (Gradwell).
2. I also restrict incoming connections in iax.conf only to the same ip
ranges.
The drops occur randomly, once every few days normally (but there have
been some cases of few drops in one day).
Again, not sure if it is relevant - but here is the same log - only
including few extra earlier lines. The strange thing is that, just
before hanging up the call I'm interested in (2963), it seems to be
hanging up another call - it reads "destroying 706" - but I can't find
any reference to a call "706" anywhere earlier in the log. So I can't
understand what call is that, and why does it get hung-up:
[Nov 17 15:25:01] DEBUG[5137] chan_iax2.c: Determining if address
212.11.91.202 with username xxxxxxxxx_in requires calltoken validation.
Optional = 1 calltoken_required = 0
[Nov 17 15:25:01] DEBUG[5137] chan_iax2.c: ip callno count incremented
to 1 for 212.11.91.202
[Nov 17 15:25:01] DEBUG[5132] chan_iax2.c: Immediately destroying 706,
having received hangup
[Nov 17 15:25:01] DEBUG[5132] chan_iax2.c: schedule decrement of callno
used for 212.11.91.202 in 60 seconds
[Nov 17 15:25:04] DEBUG[5138] chan_iax2.c: Immediately destroying 2963,
having received INVAL
[Nov 17 15:25:04] DEBUG[5138] chan_iax2.c: Destroying call 2963
[Nov 17 15:25:04] DEBUG[11242] chan_iax2.c: We're hanging up
IAX2/ihs_trunk_out-2963 now...
[Nov 17 15:25:04] VERBOSE[11242] chan_iax2.c: -- Hungup
'IAX2/ihs_trunk_out-2963'
Any suggestion to help take this further is much appreciated.
Sebastian
>
> -- Tilghman Lesher Digium, Inc. | Senior Software Developer twitter:
> Corydon76 | IRC: Corydon76-dig (Freenode) Check us out at:
> www.digium.com & www.asterisk.org
> -- _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE
> or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
More information about the asterisk-users
mailing list