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

[Steve Kann]

On Jan 20, 2005, at 8:13 PM, Andrew Kohlsmith wrote:

> On January 20, 2005 07:07 pm, Steve Kann wrote:
>> To play devil's advocate against my own suggestion (I've thought about
>> this a bit since I wrote that), the problem is that you now have two
>> choices:
>
>> 1) Put the timestamps at the beginning of the frame:
>>       This will likely end up meaning copying stuff around when we 
>> send,
>> because we won't know how big the timestamp stuff is.    But, it's 
>> easy
>> for the receiver to deal with..
>
>> This could be solved if there's a writev-equivalent way to send 
>> packets
>> from discontinuous areas of memory...
>
>> Or, we could just eat the memmove :)
>
> Well the entire basis behind Zaptel (and asterisk in general) is that 
> CPU
> power is cheap.  While we can't be flippant about it, I really don't 
> think
> that a simple memmove or few per trunk frame is going to be all that
> terrible.
>
>> 2) Put the timestamps at the end of the frame:
>>      This is easy to send, but then the receiver needs to walk through
>> all the meta entries to the end, to see _if_ there's timestamps there,
>> and then read them, before processing all the meta entries..
>
> My personal opinion is that #2 is better.  The receiver would copy the 
> trunk
> frame's "master" timestamp to each demuxed channel and then, upon 
> finding the
> meta entry could copy the "per channel" timestamp from the meta entry 
> to the
> appropriate channel's timestamp.  That should not be any different 
> from the
> normal operation unless a meta entry is detected.
>

Normally, though, I think we end up processing a frame at a time in the 
"detrunking" code, but this way, we'd need to keep around all the 
frames in the "detrunker", until the end, and then, if we find 
timestamps for them, go and change all the timestamps.

Overall, though, this might be more efficient, because if the 
timestamps are last, we don't have the memmove stuff to worry about 
when we create timestamps, and we just keep a bunch of pointers as 
we're detrunking.

Also, on a different note, I think that this "trunk meta" stuff might 
be useful for video, as there's presently no way to trunk video frames, 
and we could use this other meta type for that as well  (although, the 
bandwidth savings here would probably be of less benefit :)).

Finally, I think if we did this, I might even implement trunk mode in 
libiax2, so that I could trunk together a single call, and make 60ms 
frames, and save a bunch of bandwidth even for a single call.

-SteveK