[Asterisk-Dev] IAX2 trunk really should send timestamps as part of iax2_meta_trunk_entry..

[Steve Kann]

OK, there's two points I'd like to discuss, but I'm not sure which order 
to discuss them...

1) Why should iax2 trunk frames include timestamps for each meta frame,
2) How could we go about making this change.

So, 1:  Presently, iax2 trunk frames presently look like this:

<iax2 trunk preamble>
  trunk timestamp ts
  <iax2 trunk meta entries>
     <iax2 trunk meta entry>
         <short callno>
         <short len>
     </meta entry>
     [...]

There's just one timestamp used to represent all the frames in the trunk 
frame.  There's lots of cases where this is going to break things [even 
leaving my own JB out of this]:

Case A:  there's more than one frame per call in the trunk frame.
   Broken:  All the frames have the same timestamp.
   Fix:  This particular case could be fixed by guessing the timestamp 
offsets, by guessing the duration of each voice frame seen so far..

Case B: The trunk comes _after_ a bridged VoIP system, or between 
bridged VoIP systems.

Graphically, you have a situation like this, which asterisk is pretty 
ideally suited to, and might be a common occurrence:

<lots of VoIP clients> [many separate IAX, SIP, etc connections] 
<asterisk box A> [a single trunked connection] <IAX termination 
provider> -> TDM, or though VoIP to somewhere else..

In this case, we really want to have timestamps placed on frames by the 
VoIP clients, go straight-through to the IAX termination provider, so 
the IAX termination provider can properly process the frames (reorder 
them, dejitter, PLC etc), or even just pass them on to another point, 
which will do the same..

The same thing happens if you have two offices, each with a lot of SIP 
phones, connected by * boxes at each side, and you're using trunking 
between the two to save bandwidth..

But, with the present iax2 trunk setup, the timestamps are going to be 
irreversably lost once the frames end up in the trunk.. 

2) How can we fix this.

If trunking were still on the drawing board today, I'd say we should 
just add 2 bytes to each meta_trunk_entry to represent the actual frame 
timestamp for each trunk entry.    This adds a small amount of overhead, 
but there doesn't seem to be a way I can see to avoid this, and still 
deliver a quality service [unless, of course, you can guarantee network 
conditions everywhere].

But, trunking is already deployed, and changing the meta_trunk_entry 
format now would not be compatible...  So, how can we do this?

a) Introduce a new meta format, trunk2, which is just like trunk, except 
for these timestamps.

b) Can we wedge this in there in some backwards-compatible way?

   b1) iax2_meta_hdr gives us this extra char cmddata, that seems to be 
unused presently; perhaps we can use that as a flag somehow?
           I'm not sure how this will help -- while the present 
implementation ignores this, we can't hide enough data in here to hold 
the timestamps for all the frames in the trunk frame.. 
   b2) what happens if we _add_ a meta_trunk_entry, with callno == 0?
          I haven't tried this yet, but it seems if we put in a 
meta_trunk_entry with callno == 0, we can use that as a way to add 
additional information to a trunk frame.    Then we can define something 
like this:

#define IAX_META_TRUNK_EXTRA_TIMESTAMPS 0x0001

struct ast_iax2_meta_trunk_extra {
       unsigned short zeros;
       unsigned short len;
       unsigned short type;
       unsigned char data[0];
};

And then we can include, as the first entry in a trunk frame, a list of 
timestamps for all subsequent meta_trunk_entries in the trunk frame.  
(wire example, for a trunk frame with 5 trunk entries:

00 00  <- zeros
00 10  <- len == 16
00 01  <- type: timestamps
00 14  <- ts1
00 28  <- ts2
00 14  <- ts3
00 4b  <- ts4
00 28  <- ts5

Present implementations would just throw this away, but compatible 
implementations would store these timestamps, and use them, one at a 
time, to apply to the meta_trunk_entries they see.

This method also allows us to extend this if we want/need to in the future..

=======

So, how much bandwidth would this add?

It would obviously add 6 bytes, plus 2 bytes per frame..   For many 
calls, the 6 bytes kinda goes away, and you end up (2*50*8) 800bps for 
20ms calls, and (33 * 2 * 8) = 532bps for 30ms calls..

If that's too much, I have an idea to cut that in half too, which would 
work for up to 2.5s of jitter, but I think it would be confused by 
timestamp skews..


-SteveK