[asterisk-dev] AST_FRAME_DIGITAL

[Sergio Garcia Murillo]

From: "critch" <critch at basesys.com>
> On Fri, 2007-09-14 at 13:41 +0200, Klaus Darilion wrote:
> > Russell Bryant schrieb:
> > Probably the difference isn't that much if the 324m_gw is stable. But
> > for development it is much better to have it in a separate application.
> > Further libh324m is GPL thus it can not be included in Asterisk channeö
> > driver sources. But having a dedicated application it can be easily
> > added to asterisk-addons for example.
>
> Ahh, but it could still be an add-on with it being a transcoder module.
>

I agree with you that the trnascoder module seems a very interesting path,
but I'll have to admit that I don't know which posibilities does they offer.

I'll try to explain all the things we would require to handle correctly 3g
videocalls
(note that all of the following requirements are posible, needed and
currently
working with the app_h324 and hacks.. ;)

On dialplan and call type:
-We need to be able to differenciate a call from a 3g videocall in the
dialplan
(made to the same number and isdn channel) to route to different
applications.
For example an ivr and video ivr.
-Be able to set up the q931 call type when dialing out so the call is a
videocall
Currently this can be done by setting/cheking the user layer information 1
variable
with Klaus pathc.

On call setup:
-When the 3g call is received we have different scenarios, the call is
received
by a local application (mp4play for example) or we dial an external
softphone.
This is important because the once the videocall is received there is a h245
negotiation that needs to be done, and it's not quick, so making the user
wait
more seconds than necesary it's not desirable.
Also there is a problem with video depending on when and how do you answer
first. Currently in asterisk there is not a way of dialing a sip client,
receive the
200 OK, answer the isdn channel and wait for the h245 neg to finish and then
send the ACK to the sip client to set up both channels simultaneously.
If you don't wait for the h245 negotiation, the first IFrame is going to be
lost
and the 3g phone won't get the correct video (I try to send a vid update to
the
sip client, but i don't think it's implemented in chan sip or even in all
the sip
clients).
So currently what we have done is implementing an application (h324m_answer)
that aswer the local demuxed channel created from the h324m_gw and waits
a video update request. Then the h324m_gw answer the isdn call and starts
the h245 negotiation, when it finishes it send an control frame with a video
update
request so the dialplan can continue it's like that:

[from-isnd]
exten=> X,1,h324m_gw(s at videoivr)

[videoivr]
exten=> s,1,h324m_answer
exten=> s,n,mp4play(/tmp/welcome.3gp)

Note that if you change the h324m_answer with an Answer the video would be
played
before the negotiation has even started and the media channels opened with
the mobile
handset and it will be lost.

So in resume, we need to be able to send and receive the ast_frame_controls
within the translator,
for video update and also for dtmf handling.

On h223 data handling and media handling:
-As i need to feed the write to the b channel with a correct timing, I
mux/demux simultaneously.
I mean when I receive a frame of h223 data i demux it, send the demuxed
audio/video/dtmf frame
to the other end, and mux the video/audio/dtmf pending to send to the mobile
handset.
I know it could be done in another thread, but anyway we need to be able to
send custom frames
in each channel direction.

Best regards
Sergio