[asterisk-dev] AST_FRAME_DIGITAL

[Steven Critchfield]

On Wed, 2007-09-12 at 08:25 +0200, Klaus Darilion wrote:
> Russell Bryant schrieb:
> > I can tell you right now that you will not be able to convince me that we should
> > add an opaque frame type for this situation.  It is completely against the
> > Asterisk architecture.  As you said, the stream you are handling is in fact
> > voice and video.  Asterisk has explicit handling for voice and video, and the
> > streams should be passed into Asterisk using those frame types.
> 
> Hi Russel!
> 
> A simple scenario: A Asterisk server is used as PBX and is connected to 
> the PSTN with a PRI (zap). Further, it has a BRI card to connect to 
> in-house BRI devices.
> 
> Asterisk bridges calls between BRI and PRI, and sometimes this is a 
> digital call. As digital calls do not have proper treating yet, it will 
> happen that Asterisk thinks that PRI uses ulaw and BRI uses alaw and 
> starts transcoding - which is a very bad thing for digital connections.

Not all BRIs are alaw. If there needs to be a conversion, it should
happen. Your scenario proves why it should even happen. What if I was
using European ISDN phones in my office here in the US where I need ulaw
PRI. I need these calls to be transcoded if it is a voice call.

The problem I see here is when does the channel driver determine if the
data in the channel should be handled differently? Especially on the PRI
line. 

Back a while ago, we used zapras a little for a backup BRI connection
from a remote site into our network. Why should and how could the
chan_zap driver know when I am getting a data ppp connection and when I
am getting a data 3g video conference. 

While doing a quick look into how zapras was handled, I realize it could
have been dealt with differently had there been a digital frame.
Specifically, we could have handled this without modifying pppd, but
rather redirecting the digital frames to STDOUT and recoding STDIN to
digital frames for transmission.

Problem I still see is that even if you get a digital frame up from the
channel driver, how do you know what app you need to decode it. For
instance, if a 64k link was requested for digital transmission across
the PRI line was submitted to asterisk, what app would handle it? The 3g
video conference, modified zapras, or what? If you are relying on a
extension to trigger services, that would be better, but would unlikely
deal well with miss dialed extensions.

Thinking of it from the otherside now, I could see some use in a data
method for IAX. While I am not sure of there still being ISDN services
in the this area, if there where I would love a way to write a pipe that
behaved like a modem via IAX to my asterisk instance that then put my
data directly on the clear channel to a ISDN TA on the other side. I
could see the app on asterisk side looking for and interpreting a
minimal hayes AT command set to fool any terminal app. That would then
let me point minicom or similar to a pipe and let it fly. Granted, the
whole UDP and droped packets would cause some interesting problems for
this over any saturated links.


I see a couple of things we might want to address. Native bridging
obviously doesn't concern us. But what if we are bridging between
different channels. How would you basically set up a application or
other to act as a filter on the incoming channel to properly split the
data into the frames necessary. So far as I know, the only way to do
that now would be to claim the data was a codec, and to write a codec
that properly decoded the data into the proper frames. 

HMM, this has some interesting side effects. For instance, if we had a
data codec, we could pass the AST_FRAME_VOICE from the PRI into the data
codec and get out a AST_FRAME_TEXT to them be passed to a application
such as zapras for direct handling to and from the pppd. Similarly we
could get a h223 codec and then let it do the proper demuxing of the
data sources into the various frame types needed by asterisk. 

This approach seems to get away from the channels needing to know what
data they are carrying and back to a (albeit munged) asterisk centric
way of doing things.

Things needed to accomplish this would be codecs written for the
different data types we want to accomplish and a way from the dialplan
or other to set the codec we are expecting from a channel.

Hopefully I didn't muddy the water more than I cleared it up. 
-- 
Steven Critchfield <critch at basesys.com>