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 _______________________________________________ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
