[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