[asterisk-dev] [Code Review] IAX2: VNAK loop caused by signaling frames with no destination call number

[David Vossel]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/413/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

--- The Issue ---
It is possible for the pbx thread to queue a signaling frame (such as DTMF) before the other side has allocated a call number. This results in our side logging a sequence number for that control frame while the other side will not receive it (they do receive it, but they drop it because the destination call number is zero). Now our outbound sequence number doesn't match the other side's inbound sequence number and a VNAK occurs. Since we store those signaling frames with no destination call number in our frame queue, they are retransmitted and the same problem occurs all over again creating a loop. To make matters worse since we don't receive an ACK for those frames, they keep getting retransmitted regardless of the VNAK.

Example:
-> NEW    src: 4 dest: 0 iseq: 0 oseq: 0
-> DTMF   src: 4 dest: 0 iseq: 0 oseq: 1
<- Accept src: 5 dest: 4 iseq: 1 oseq: 0

In the above example we send two frames out, but the other side only processes the NEW.  We can tell this because the Accept message has a iseq of 1 rather than 2.

--- The Fix ---
First, we shouldn't send frames with a destination call number of zero unless they can start an IAX dialog (NEW, REGREQ, REGREL, etc....)  I've done this by creating a separate queue for frames coming in from the pbx thread while we are waiting for a destination call number.  Once the destination call number is received, all the items in the queue are sent out.  This is an incredibly rare occurrence, but without the destination call number these frames will cause a VNAK loop with any version of Asterisk that requires accurate destination call numbers on all Full Frames.

Second, we only need to force accurate destination call numbers for ACKs.  This prevents call setup from occurring if an endpoint doesn't know the correct destination call number.  There was a discussion requiring accurate destination call numbers in the past that can be read here: http://lists.digium.com/pipermail/asterisk-dev/2008-May/033217.html With the introduction of calltoken validation, this really isn't an issue anymore.


Diffs
-----

  /branches/1.4/channels/chan_iax2.c 224849 

Diff: https://reviewboard.asterisk.org/r/413/diff


Testing
-------

forced DTMF frames to be sent from pbx thread before receiving a destination call number, verified those frames were queued as expected and not sent out with a destination call number of 0.


Thanks,

David