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

Steve Kann stevek at stevek.com
Sun Feb 6 07:59:37 MST 2005


On Feb 6, 2005, at 1:11 AM, Steve Underwood wrote:

> steve at daviesfam.org wrote:
>
>> On Sun, 6 Feb 2005, Steve Underwood wrote:
>>
>>
>>> Think plesiochronous :-) [if you don't know what that means, look it 
>>> up]. T1s and E1s come from the days of plesiochronous telecoms (PDH 
>>> - the plesiochronous digital heirarchy). SDH - the synchronous 
>>> digital heirarchy - replaced that, and the complexity of 
>>> multiplexing and demultiplexing dropped dramatically.
>>>
>>> What goes into an IAX trunk packet is a bunch of plesiochronous 
>>> streams. They each have their own timing. A common timestamp for the 
>>> whole group doesn't cut it.
>>>
>>
>>
>> Just before Astrican I tried to convince Mark that the timestamps had 
>> to be there, but couldn't.  Perhaps someone else will be more 
>> successful.
>>
>> Steve
>>
> OK. Think more than plesiochronous. Think plesiochronous digital 
> heirarchy :-) Because the streams are plesiochronous (unless one of 
> the sources has a really screwy clock), you can just encode how much 
> ahead or behind the group an individual stream is, which is a tiny 
> value. That is basically how PDH does it.
>
> In PDH, the higher order muxing (everything above T1/E1) forces the 
> lower streams into a single synchronous stream, which is a little 
> faster than the sum of the streams it carries. This allows some slots 
> for carrying extra bits, when an incoming stream is a little fast, and 
> tagging that bits are missing when an incoming stream is a little 
> slow. The amount of fudging data you need to handle is very small, 
> because the worst case mismatch in speeds in small (100ppm in the case 
> of PDH). For IAX2 trunking, just one or two bits per channel per 
> packet could do the job. Without a bit of work, I'm not sure how messy 
> the software might look, but in terms of dense coding on the wire its 
> makes sense.

I have no doubt that you could use somewhat fewer bits if you made the 
code more complicated, but I don't think you'd probably find you need a 
variable number of bits to do it effectively.

There's a number of properties of (present) IAX2 and VoIP streams and 
IAX2 trunks that are different than TDM telephony streams:

1) The loss rate is (potentially) much higher;
2) packets may arrive out-of-order.
3) There's jitter.
4) There's discontinuous transmission of frames.

Now, you can potentially de-jitter each of the sub-streams before 
putting them together on an iax2 trunk, but then you would need to also 
de-jitter them _again_ after they've been been sent across the trunk.  
If you have multiple hops, this all adds to latency in an expensive 
way.

IAX2 streams presently have a number of "issues" that make this more 
difficult, especially problems where timestamps are sent pretty screwed 
up (i.e. the case where you have a call that gets bridged, either 
natively or not, and you switch you timing source from the local box, 
to the bridged channel, often there's a 2-4 second jump in timestamps). 
  I guess this is really a separate issue to solve, though..


-SteveK





More information about the asterisk-dev mailing list