[asterisk-dev] IAX internet draft (draft-guy-iax-00)
Dimitri E. Prado
dprado at e3c.com.br
Sun Mar 5 15:35:21 MST 2006
Hello Derek,
thanks for the explanation, this was one of the things that the spec was not
very clear about (seqno on acks) . Ed Guy is currently revising the next
version of the iax spec, I sent him an email yesterday with a few other
questions I had on this subject. Since it might interest others on this list I
will copy the msg below, although it was sent also to the
iaxclient-devel list.
regards
Dimitri
-----------
Hello Ed,
in regards to registration, it is not clear on the spec if upon sending
a REGACK the server must close the current call, and registration
refreshs must
be made through a new callno/session. It seems that asterisk and iaxclient do
it this way (Steve, correct if i am wrong ). On the other hand I
assumed that I
could keep refreshng registrations using the same callno with asterisk. So the
question is, upon successfully registering MUST I close the current call and
use a new call when refreshing registrations? I personally would like to have
the
current registration call permanently active and be able to use it to
send text
frames on top of it to provide enhanced functionality between client and
registration server (simiar to Firefly ).
Another question, codec negotiation is done primarily though format IE on
ACCEPT. It in theory sets the codec for both incoming and outgoing streams. On
the other hand Full voice frames cary also codec info and as specified on the
spec:
"The first
voice frame of a call SHOULD be sent using the codec agreed upon in
the initial codec negotiation. On-the-fly codec negotiation is
permitted by sending a full voice frame specifying the new codec to
use in the subclass field."
theoretically I could have incoming and outgoing streams using
different codecs.
Is this valid? If it is, the codec negotiation done thorough NEW/ACCEPT
does not
allow for different incoming outgoing codecs. If it isn't a valid
scenario maybe
it should be explicitly mentioned on the spec. I believe yate currently
accepts
different incoming/outgoing codecs.
One last question ( for now :) ), I couldn't find how one could send text
messages between clients outside of a established voice call. Is there a
planned mechanism for sending text frames in a authenticated way? I believe
integration with other IM networks could be a plus for iax softphones, but in
order to do this I must be able to send text frames outside of a voice call. I
understand I can probably implement this in any way it fits me, but if
there is
some planned specification on this matter, I would rather wait.
These are a few issues that I noticed. Maybe they are not that relevant
but for
me at least they caused some confusion.
UTF-8 as well as encryption are welcome additions.
Thanks for all the work!
Dimitri
Quoting Derek Smithies <derek at indranet.co.nz>:
> Hi,
> well, I guess this forum is as good a place as any..
>
> the doc says:
>
> OSeqno
>
> The 8-bit OSeqno field is the outbound stream sequence number.
> Upon initialization of a call its value is 0. It increases
> incrementally as full frames are sent. When the counter
> overflows, it silently resets to 0.
>
> ISeqno
>
> The 8-bit ISeqno field is the inbound stream sequence number.
> Upon initialization of a call its value is 0. It increases
> incrementally as full frames are received. At any time the ISeqno
> of a call represents the next expected inbound stream sequence
> number. When the counter overflows, it silently resets to 0.
>
>
> Not quite.
> The iseqno increases by 1 as each full frame is received.
> However, it is not altered by receiving an ACK frame.
>
> We need this distinction - ack frames are a full frame.
>
> The iseqno and oseqno of an ack frame are determined by
> (from memory, something like this)
> oseqno is the same as the iseqno of the iseqno of the packet being
> acknowledged
> iseqno is the next expected oseqno. Thus, the ack transmission
> mechanism has to keep track of the oseqnos that have arrived.
> On receiving an ack packet, you can look at the iseqno, and
> know what packets the other end has received.
>
> the timestamp of the ack frame is the same as that of the frame being
> acked.
> Consequently, there are times when the timestamp (on the sending side)
> has to be "tweaked" high by 3, to differentiate between two different
> frames. A lagrq frame does not increase the oseqno at the sending
> side.
>
> Kenny Schumard sent me an email on this topic, here is a snippet:
>
>> If you are sending an ack packet, the outseqno is the same as the
>> inseqno of the packet you are acking.
>
> This is one of the parts of the protocol that I'm not as comfortable
> with. But I know that the ack isn't supposed to send an outseqno as an
> echo of the received inseqno -- it maintains its own outseqno and
> compares the received inseqno with the ready-to-send outseqno. If they
> don't match, then that's a clue that a message has been lost and a
> VNAK should be sent to indicate this (as I understand it).
>>
>> If you are sending an ack packet, the timestamp of the ack packet is the
>> same as that of the incoming packet.
>
> Right, which makes sure that both ends know which packet is being
> acked (as the seqnos could be off in the case of a dropped packet).
>
>>
>> Exceptions: When you send a new packet, you get an accept back. The
>> accept packets is a "ack" like packet. However, the seqnos of the accept
>> packet have no relation to the new packet. the timestamp of the accept
>> packet has no relation to the new packet.
>
> This is also right. The accept isn't an explicit ack of a new. There
> can be an authreq sent in response to the new instead, in which case
> the accept is independent of the new as far as packet-acknowledgment
> goes. The accept implicitly acknowledges the new. Timestamp echoing
> used as acknowledgment is only necessary for explicit acknowledgments.
>
> ========================================================================
>
> The sentence::
> A timestamp MUST also be assigned for the
> call, beginning at 0 and incrementing each millisecond
> is unclear.
> Incrementing by what value??
>
> In fact::
> The timestamp has units of milliseconds.
> Thus, the maximum timestamp in a 16bit field is 65.535 seconds.
>
>
>
> Derek.
>
>
> On Sat, 4 Mar 2006, Tim Panton wrote:
>
>>
>> On 4 Mar 2006, at 20:46, Dimitri E. Prado wrote:
>>
>> >
>> > Hello All,
>> >
>> > what is the best forum to discuss issues regarding the IAX spec? More
>> > specifically, there is some conflicting info on the current spec
>> > ( at least I
>> > believe it is the current one) that I would like to clear up. There
>> > is also,
>> > some places that I believe it would be usefull for the
>> > specification to be a
>> > little bit clearer in order to avoid incompatible IAX
>> > specifications that still
>> > comply to the same spec. I am currently implementing a IAX stack
>> > based on the
>> > internet draft, and I already took a few different routes that made my
>> > implementation not work with asterisk even though I believe it
>> > still follows
>> > the spec.
>>
>> If you find a suitable forum, please let me know, we'd be happy to
>> contribute
>> our views on this draft too.
>>
>> Tim Panton
>> tim at mexuar.com
>>
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
> --
> Derek Smithies Ph.D. Any fool can write code that
> IndraNet Technologies Ltd. a computer can understand.
> Email: derek at indranet.co.nz Good programmers write code
> ph +64 3 365 6485 that humans can understand.
> Web: http://www.indranet-technologies.com/ Martin Fowler
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
More information about the asterisk-dev
mailing list