[Asterisk-video] Re: [Iaxclient-devel] Video codec negotiation in IAX

[Mihai Balea]

On Oct 24, 2006, at 2:43 AM, Cristian Draghici wrote:
>
> - when testing a SIP echo video call (which works audio and video) I
> see that the SIP client starts off with audio only
> - at some point in the future the client adds video frames to the mix
> (user says - yes, start video)
>
> This does not look like it could be supported by the current version
> of iaxclient.
> iaxclient tries to do the negociation at call set-up time (i.e. when
> IAX NEW and ACCEPT frames are sent and received) and it doesn't change
> it in mid call.
>
> I am wondering if Asterisk is not doing a codec "renegociation" in mid
> call and we're trying to mix apples and oranges by trying to persuade
> chan_iax into doing something it can't...
>
Iaxclient definitely does not support codec re-negotiation right  
now.  As a matter of fact I am not sure if the IAX2 protocol supports  
it (somebody please correct me if I'm wrong).  We could probably  
delay sending/accepting video but the negotiation has to happen at  
call setup.

As an aside, I belive in SIP this is done through reINVITEs.  Not  
many SIP endpoints support codec changes in mid-call correctly.  
Anyway, I don't see a similar mechanism in IAX2

>
> from my point of view, the ideal iaxclient would
> - advertise accepting video frames even if a camera is not present
> - advertise accepting audio frames even if microphone is not present
> (think monitor, i.e. read voice mail where you only input DTMF digits)
This makes sense. Not sure what is the behavior right now, but if we  
don't do it, then it's a bug that need to be fixed

> - if a call from the call list has a ulaw codec set and a (i imagine
> big frame) video frame arrives from the iaxclient remote peer, i think
> the local peer should try and match the codec for the received video
> frame and if it succeeds mask the codec capabilities with this codec
> (this would allow iax peers to turn cameras off and on whilst in mid
> call).

Not sure I get you here, but I believe you're saying that if a video  
frame arrives in the middle of an audio conversation, we should be  
able to process it (provided we have the correct codec, of course).   
We can look into it, this might be something that we could support.

Another related feature would be sending a "holding" frame when no  
video is present (or when the user is in "mute" mode).  There are two  
ways of doing this:
- easy: just keep resending the last frame captured or another raw  
image.
- complicated: use IAX2 Image frame and have iaxclient display that  
static image.

Any comments/suggestions?

Mihai