<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 21 Jun 2005, at 23:51, Derek Smithies wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Hi,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>Sorry for the long post, but here is some stuff that is going to be<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">useful for the iax-rfc.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>I have been using the iax client QTIAX and firefly to make iax calls to<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">an * box. I have tried a couple of different * boxes, and the calls still<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">get terminated.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Careful packet dumping + ethereal (0.10.10 (which includes iax decoder))<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">has provided some clue, but I wonder if someone can give an authoritative<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">answer..</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>That would be Mark :-)</DIV><DIV>I have been struggling to understand the RFC myself, and</DIV><DIV>I'd failed until I was lucky enough to catch Mark at Astricon in</DIV><DIV>Madrid. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Digium are aware that the lack of IAX2 doc is a problem. They are</DIV><DIV>hiring someone,who starts next month, to push this forward.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In the meanwhile, here's what I learnt, don't </DIV><DIV>take it as gospel....</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>All frames are from the _senders_ prespective,</DIV><DIV>and remember IAX is a stream oriented protocol</DIV><DIV>like tcp, not a send-receive protocol like snmp or</DIV><DIV>http.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Oseq is the current highest seqno sent by the transmitting </DIV><DIV>agent. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Iseq is the number the transmitting party expects to see </DIV><DIV>in the oseq field in the next received fullframe.</DIV><DIV>Note that this isn't the same as +1 for every fullframe or even last +1</DIV><DIV>The difference relates to missing fullframes. If an inbound packet is lost</DIV><DIV>iseq will remain at the value for that fullframe - even after subsequent </DIV><DIV>fullframes arrive - until the missing one (or an appropriate retry) has</DIV><DIV>arrived.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>When you recieve any fullframe the recieved iseq tells you that the</DIV><DIV>transmitter has received _all_ the packets you sent with an oseq</DIV><DIV>less than this iseq. Any fullframes you have sent with oseqs greater than</DIV><DIV>or equal to the most recent received iseq are candidates for retries.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>So all fullframes act as acks, in that they carry an iseq and</DIV><DIV>that tells the recipient what has been seen by the far end.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Ack frames are just used to send a fresh iseq to the far end when</DIV><DIV>there is no prospect of an immediate fullframe to carry it.</DIV><DIV>Acks don't increment the oseq, but they do have the timestamp set</DIV><DIV>to the value in the packet to which they are an ack.</DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">It appears that the iseqno used at each end is increased by 1 on receiving</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">each full frame.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>No, it is always highest_contiguously_recieved_oseq+1 </DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Note that The iseqno and timestamp of a full packet form a unique</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">identifying pair. An iax2 device will keep a record of timestamp and</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">iseqno of packets sent. On receipt of an ack packet, the iax2 device will</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">be able to determine which packet has been acknowledged.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Not exactly. iseqno on it's own is unique it is an ack of all the</DIV><DIV>full frames sent upto but not including iseq. </DIV><DIV>The timestamp is useful in packet traces and filtering</DIV><DIV>because iseq wraps after a few mins in a typical call, so</DIV><DIV>the timestamp can be used to differentiate.</DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">should two packets be transmitted at the same time (say a ping and lagrq)<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">then there is a very good chance that two full frames will be generated<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">with the same iseqno and timestamp. This is an event that is unacceptable.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The timestamp of the second packet is raised by 3 ms, to guarantee<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">uniqueness.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Why would it be unacceptable ?</DIV><DIV>They have different oseqs, and they both convey the same implicit</DIV><DIV>ack info.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm close to having a java implementation of IAX2 available, that</DIV><DIV>will provide a different viewpoint.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Tim.</DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Thanks,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>Derek.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>--<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Derek Smithies Ph.D.<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">IndraNet Technologies Ltd. <SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Email: <A href="mailto:derek@indranet.co.nz">derek@indranet.co.nz</A><SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">ph +64 3 365 6485 <SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Web: <A href="http://www.indranet-technologies.com">http://www.indranet-technologies.com</A>/ <SPAN class="Apple-converted-space"> </SPAN></DIV></BLOCKQUOTE></DIV><FONT class="Apple-style-span" color="#0000DD"><BR class="khtml-block-placeholder"></FONT></BODY></HTML>