[Asterisk-Dev] IAX2 RFC and retries.

tim panton tpanton at attglobal.net
Fri May 20 08:23:03 MST 2005


On 20 May 2005, at 15:22, Johnathan Corgan wrote:

> Steve Kann wrote:
>
>> tim panton wrote:
>>
>>> I am implementing the IAX2 protocol in pure Java.
>>> I am trying to use the RFC as a protocol description
>>> - not the code!
>>>
>
>
>>> The RFC says:
>>>
>>> An ACK must have both a source
>>> call number and destination call number. It must also increment
>>> the sequence number counters, and return the same timestamp it
>>> received. This allows the originating peer to determine to which
>>> message the ACK is responding.
>>>
>>> But this seems not to be the case. I am seeing acks with timestamps
>>> that are the time they were sent, not that of the original message.
>>>
>
>
>> I think that asterisk _does_ set the timestamp of an ACK to be  
>> equal to the timestamp of the frame it's acknowledging, but it's  
>> redundant.
>>
>
> This is the sort of thing a formal protocol spec should clear up.  
> (Bravo to the developer writing RFC--you'll improve a lot of  
> peoples' productivity!)

Yes, I think it is great to have, I just wish I could make my code  
work :-)

>
> The timestamp does seem to be redundant as a way of correlating the  
> ACK with the original full frame.

Actually in terms of the RFC  I'm not sure it is,
each end tracks the sequence number,
by counting received and sent packets so if you lose a packet
the sequence number will be wrong as compared to the value the other end
currently has.
(At least until the message is retried). In which case you could
ack the wrong packet.
The timestamp is at least unique and the value used is the value sent  
over the
wire.

>
> Tim--is the text above from the first or second draft of the RFC?

It is from:
                          draft-mspencer-iax-01
I started this a while back, I take it there is a newer draft now?


>
> -Johnathan
>




More information about the asterisk-dev mailing list