[asterisk-dev] AST_FRAME_DIGITAL/3G video calls

[Sergio Garcia]

Hi Olle, 
it's good to see you arraound here, hope you can bring some peace to 
the mailin list.

Comments inline

---------- Original Message ----------------------------------
From: Olle E Johansson <olle at voop.com>
Reply-To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Date:  Thu, 13 Sep 2007 17:12:57 +0200

>Friends,
>
>To try to summarize, I think we have two different issues on the table.
>
>* 3G video on ISDN - a call that is multiplexed to fit into one
>    ISDN channel, video and AMR audio.
>
>* ISDN data calls is another issue. I don't know how frequent they
>   are any more, but these are not really Asterisk calls and maybe
>    we should look into a Zaptel/MISDN application to handle
>    these, if it can be handled that low. Otherwise tunneling could
>    be a solution for these, maybe.
>    I'll drop this part of the discussion for now.

Yes, i agree that there are two different issues here. And I think
if we could just forget about the 3g case and focus in the genearal
digital case. For the latest, i think that if just one person needs it
asterisk should be flexible to allow it, and no say, hey, you just can't
do that because it's the asterisk way.
I also understand that if the usefullnes of the change is very small
the priority would be small.. 

>
>To handle demultiplexing and multiplexing of multimedia streams
>in an application is a big "no, no" regardless of which Asterisk
>developer you talk to. It might be that we need a new module
>that can hook into various channels to handle this, but so far
>I can only think of misdn and zaptel channels that need this.

I agree, the app was a hack, it was the only way that I could do it
in the current asterisk architecture. I would be happy if i could
dinamically plug it as a filter in any channel and it could have access
 to the frames and modify them.
The same filosofy could be applied to codecs, echo cancellors, demuxers,
transcoders, etc.. the idea is something simillar to the pipe architecture
of gstreamer.

>
>It's unlikely to get a SIP call with a video call not de-multiplexed.
>
But you could do it, and in fact i've done it to test with ratmin sending
form his asterisk box to mine because i dind't have isdn access.

>I don't see any need for tunneling un-multiplexed 324 data,
>since it will cause issues in the architecture with a  lot of
>our  applications and call scenarios.
>
But why you just cann't be able to blindy tunnel data from one channel to 
another as long as they know what are they handling? we already do it
with video and some audio codecs..

>What happens if a video call comes in and is forwarded to an
>audio only device/channel?

It's the same problem that we have already with a sip/isdn call.

>
>We don't really know what the final endpoint will be when
>the call comes in, so it's kind of strange to keep it in multiplexed
>mode.
>
>A big issue with 3G video calls in Asterisk is the licensing
>of the audio part of the call, which is using the AMR codec
>that's not free. Regardless, handling this in third-party
>applications that break the asterisk architecture is not a
>way I would recommend moving forward. I'd rather see
>Digium handling the AMR license issue, which I proposed
>to them many times without any answers. Please help
>me in mailing Digium marketing and sales about this.

And I appreciate a lot your effort. One good advance in this field
is that Klaus talked with Voiceage (the holders of the AMR license)
and they have make clear that as long as we don't decode/encode
we can handle amr data. Even packetize from if1 to if2. So using
app mp4 to play amr content is perfectly legal and you don't need
any kind of license. Also the same when you are just passing it
througth from 3g to a amr capable sip phone (as openwengo by example).


>
>My 10+10c... :-)
>
>Regards,
>/O
>
>PS. Please test videocaps if you're interested in video.
>It adds a lot of video functionality to Asterisk.
>

Yes, I have great expectations about it. The only problem is that
people that plan to deploy the 3g as a comerciall seervice don't like
to play much with developer branches.

Best regards
Sergio