[asterisk-dev] AST_FRAME_DIGITAL

[Klaus Darilion]

Steven Critchfield schrieb:
> 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.

Yes - transcoding is good if the ISDN transfer capability is SPEECH or 
3.1khz AUDIO. But there must not be transcoding if it is a digital call 
(transfer capability = Unrestricted digital information).

Do you transcode IP packets from ulaw to alaw when sent from US to 
Europe? No - because it is digital. Thus, if you use "unrestricted 
digital information" inside ISDN it is not ulaw, not alaw but digital. 
Thus there must not be transcoding.

> 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. 

It is not about BRI or PRI or US or Europe. If there is an digital ISDN 
call then it is raw digital data - everywhere in the world on every ISDN 
technology and every ISDN channel driver.

> 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. 

a digital call is determined by Transfer Capability = "unrestricted 
digital information".

The data service inside is identified by the user information layer 1 
(defined in Q.931)

> 
> 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.

differing voice calls from video calls can be done user information 
layer 1 (in bearer capability in SETUP message).

Further distinction can be done using a dialplan (like most people have 
a dedicated number for fax or modem dial-up).

> 
> 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. 

For 3G video we do it in an application:

[frompstn]
exten => 1111,1,h324m_gw(1111 at tosip)
[tosip]
exten => 1111,1,Dial(SIP/1111)

the h324m_gw receives the 3G data and decodes audio (AMR) and video 
(h263) it into an pseudo channel which continues dialplan execution at 
1111 at tosip. Asterisk will then automatically transcode from AMR to the 
codec used by the SIp client.

> 
> 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. 

Some more muddy but also some interesting aspects

regards
klaus