[asterisk-dev] Problems with IAX2 since 1.4.21.2

[Tilghman Lesher]

On Tuesday 09 September 2008 09:56:33 Tim Panton wrote:
> On 9 Sep 2008, at 14:47, Floimair Florian wrote:
> > Hi!
> >
> > We're using IAX2 to establish a trunk connection between our
> > proprietary system and an Asterisk server. However since Asterisk
> > version 1.4.21.2, which fixed the "IAX POKE resource
> > exhaustion" (AST-2008-10), we're having troubles using POKE requests.
> >
> > I am aware that the fixes incorporated in 1.4.21.2 include a change
> > in the call number usage for POKE requests (call number 1). However
> > when sending a POKE from our system to the Asterisk server with
> > destination caller ID 0 we do get a PONG in return from caller ID 1.
> > The problem is that Asterisk does not increase the Inbound Stream
> > Sequence Number from 0 to 1 when responding with a PONG. As a result
> > we run into a timeout after three unsuccessful tries. An ACK would
> > be sent by our system only if the ISeqNo is also increased to 1 in
> > the PONG.
> >
> > My question now is: Is this really a wanted behaviour? According to
> > IAX2 Draft 4 (http://tools.ietf.org/html/draft-guy-iax-04) i would
> > conclude that this issue is a new bug resulting from AST-2008-10.
> > Please correct me if I'm wrong. It would be important for us to
> > clarify that point since we have to know whether the "error" is on
> > our side of the IAX2 connection or on the Asterisk side.
> >
> > With best regards
> >
> > Florian Floimair
> > Technical Support
>
> Yep, sounds like a bug in asterisk. Here's the rule as I understand it:
>
> "When you recieve any fullframe the recieved iseq tells you that the
> transmitter has received _all_ the packets you sent with an oseq
> less than this iseq. Any fullframes you have sent with oseqs greater
> than
> or equal to the most recent received iseq are candidates for retries."

What would be very helpful at some point is a tool designed to test
compatibility with all of these particular requirements.  I am the one at
fault, here, as I developed the fix for this issue.  What I did was to test
the responses against another Asterisk server, to see if it reacted
appropriately.  Since it did work with a previous (unpatched) Asterisk
server, it was assumed (we now know wrongly) that the fix was correct.
So a tool to help us diagnose these protocol issues would be helpful, if
someone would like to develop that.

-- 
Tilghman