[asterisk-dev] AST_FRAME_DIGITAL

Klaus Darilion klaus.mailinglists at pernau.at
Tue Sep 18 14:21:07 CDT 2007


Matthew Fredrickson wrote:
> Klaus Darilion wrote:
>> Thus, to summarize:
>>
>> I see two options for adding digital/3G video types to Asterisk:
>>
>> 1. AST_FORMAT_H223. This will only be used if the incoming call is 
>> digital AND signals H.223&H.245.
>>
>> + with this option it is for sure that the digital call is a 3G video call
>> - there is no standardized way to forward this to other Asterisk server
>> - does not help us handling other non-3G-video calls
>>
>> 2. AST_FORMAT_CLEARMODE. This will be used for any incoming digital 
>> call. Thus, from the frametype it is not deriveable which application is 
>> inside the CLEARMODE.
>>
>> + by adding CLEARMODE to rtp.c we have a standard conform way to forward 
>> digital calls to other Asterisk servers
>> + more generic and flexible
>> - requires a little bit more dialplan logic to detect 3G video calls
>>
>> Thus, is there a chance to get AST_FORMAT_CLEARMODE into Asterisk (which 
>> I would prefer instead of AST_FORMAT_H223)?
> 
> Although it probably sounds very attractive, functionally this is the 
> same thing as the proposal to use AST_FRAME_DIGITAL as an opaque 
> container.  So if you were using AST_FORMAT_CLEARMODE, you are not going 
> to be able to tell the other end of the IAX connection about what it is 
> terminating, so if it needs to bridge the call to a non ISDN endpoint 
> (such as a videophone) this will not be possible.  AST_FORMAT_CLEARMODE 
> is not the answer, at least for the H.223 and H.245 data problem that we 
> are discussing.
> 

Of course I know _CLEARMODE would be the same as _DIGITAL. I just 
thought that (by choosing method 2) maybe CLEARMODE might be a better 
name with defined meaning.

klaus



More information about the asterisk-dev mailing list