[Asterisk-video] h324m_handshake (was: app_mp4 fixed video playback)

[Klaus Darilion]

Hi Sergio!

The more I think about it I think it better you choose your approach by 
not modifying app_h324 but instead having a generic Asterisk application 
WaitForMedia().

This application answers the call (if not already answered) and waits 
for at least one video frame (or a certain control frame, this should be 
configurable by options). Then the function returns. Of course it would 
be good if this first video frame will be forwarded too.

What do you think about it?

regards
klaus


Sergio Garcia schrieb:
> ---------- Original Message ----------------------------------
> From: Klaus Darilion <klaus.mailinglists at pernau.at>
> Reply-To: Development discussion of video media support in Asterisk<asterisk-video at lists.digium.com>
> Date:  Fri, 31 Aug 2007 08:11:02 +0200
>>
>> Sergio Garcia schrieb:
>>  > The problem is that I don't want to answer the phone without knowing
>>> if there is anyone at the other side. The idea I have is implment an
>>> h324m_gw_answer that answer the channel and wait for a control
>>> command (probably AST_CONTROL_VIDUPDATE) to return control..
>> What about options for h324m_gw, e.g.:
>>  'a': answer the incoming call immediately. This is
>>       useful in video applications where the incoming
>>       call will be answered for sure.
>>
>>  'w': wait for H245 channel negotiation. When using this option,
>>       h324m_gw starts the pseudo channel after H245 handshake. Thus,
>>       the pseudo channel can start playback of audio and video
>>       immediately without loosing frames. Note: 'w' implies 'a'
> 
> That could be another option, but the  I don't see "a" option it. 
> I mean, I don't see in which case you would like to answer the phone without
> waiting for the h245 to finish. 
> The only case I would be if you have something that is not instant in the local
> channel (like for example grabbing caller user data) that would take a few seconds
> so you want to run the h245 negotiation and the user data process in parallel.
> But then you'll have to synchronize both channels for waiting each other..
> 
> Perhaps a mixed solution could be good here.. and implementing a AST_CONTROL_VIDUPDATE
> to signal the 3g phone is also somehting that we need.. 
> 
> BR
> Sergio
>  
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-video