[asterisk-dev] AST_FRAME_DIGITAL

[Klaus Darilion]

critch schrieb:
> On Thu, 2007-09-13 at 14:55 +0200, Klaus Darilion wrote:
>> Tilghman Lesher schrieb:
>>> On Thursday 13 September 2007 05:14:40 Klaus Darilion wrote:
>>>> Do you transcode IP packets from ulaw to alaw when sent from US to
>>>> Europe? No - because it is digital.
>>> Yes, you do, because it is a different codec.
>> Is this IPv7?
> 
> Someone must transcode ulaw to alaw or you don't get any usable audio
> out the otherside. 


I know - but in the previous example I was talking about IP (Internet 
Protocol) - not ISDN
> 
> <joke>Could this be the communications problem we are having right
> now</joke>

It is good that you can still laugh about it :-)

> Any of the VoIP protocols would have told one side or the other what
> codec they are using, and the otherside will have decided they can deal
> with the incoming or not. That descision is based on knowing what it is
> that they are to be getting on the wire.
> 
> Asterisk needs to treat the data it receives in a standard way because
> we need to hand this information off to many differing technologies. So
> having the base data converted into something that asterisk can then
> pass around and know what it is, is important. 

Yes. Currently we have g729 pass through - no need for Asterisk to 
transcode - Asterisk only knows this is something I do not understand 
thus I pass it through. The same applies for T.38.

I think one problem is that Asterisk is still focused very much on 
voice. For example if we have 2 channels drivers which only support 
AST_FRAME_TEXT asterisk still tries to find the best voice codec when 
bridging.

Thus, my idea, to just introduce the voice format AST_FORMAT_DIGITAL. 
This can be used by any channel_driver which supports raw data delivery 
(I think Cisco calls it "clear channel" for VoIP). I will add it to core 
and chan_zap and later it can be added to other channel drivers too.

> How much effort is truly involved in splitting the original data stream
> into the 3 constituent streams, and then remerging them? Is this really

I do not know it exactly - it is H.223 decoding (which depends on the 
used mobility level. Level 0 is just HDLC whereas higher levels are very 
robust to bit errors but are complex to decode).

> too much load to handle? Yes it may seem unnecessary to you, but for the
> same reasoning we shouldn't packetize the audio coming off of a
> streaming channel driver then. Asterisk tries to handle everything as
> generically as possible. Hand it packets of audio, and it will pass
> those on to whatever channel driver needs it and then those drivers can
> start from a simple known starting point and provide the proper output.
> Get your data to simple known spec, and most channel drivers will be
> able to get it out to the otherside.

One more reason to have the 3G video decoding in an application is the 
current state of the application. I guess we need to fix lots of things 
to make it stable and more robust and applying the fixes to each ISDN 
channel drivers is very time consuming.

regards
klaus