[asterisk-dev] [IAX2] Question on unrecoverable race condition and VNAK's Oseq

[Alex Hermann]

Hello all,


I'm sometimes seeing a race condition in the IAX2 protocol, from which 
the protocol isn't able to recover. UnThe below table shows the packet flow. 
(as it is the result of a race condition, I haven't been able to reproduce 
it in a labtest, so I have no debug log available)


Communication is as seen on a 1.4.21 * being called from a 1.2.26 *.


Dir time  type    Oseq Iseq

; Until the ANSWER, all is ok.
Tx  5260  ANSWER  6    3
Rx  5260  ACK     3    7

; I don't know why this packet is here
Tx  6263  (14)    7    3
Rx  6263  ACK     3    8

; Here the trouble starts, as both ends send a LAGRQ at the same time
Rx 10018  LAGRQ   3    8
Tx 10016  LAGRQ   8    3
Rx 10016  LAGRP   4    9

; And now this node tries to sync from long gone sequence numbers
Tx 10035  VNAK    3    3

; From here this sequence continues endlessly:
Rx 10018  LAGRQ   3    8
Tx 10016  LAGRQ   8    3
Rx 10016  LAGRP   4    9
Tx <incr> VNAK    3    3



Any idea what might be going on here? Which host is at fault?



To me, the VNAK's look suspicious, why would it want to sync those very 
early packets? Should that have been:
Tx 10035  VNAK    8    3

Tracking the source, the following function is responsible for that seqno 
in the last parameter. Shouldn't it be iaxs[callno]->oseqno, OR the iseqno 
from the iax_peercallno_pvts variable?

static int iax2_vnak(int callno)
{
	return send_command_immediate(iaxs[callno], AST_FRAME_IAX, IAX_COMMAND_VNAK, 0, NULL, 0, iaxs[callno]->iseqno);
}

Can an IAX2 guru give his/her opinion on the correctness of the VNAK and/or 
the above function.

-- 
Greetings,

Alex Hermann