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

[Cristian Draghici]

On 10/24/06, Mihai Balea <mihai at hates.ms> wrote:
>
> 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.

I've written a very basic IAX decoder a while back and I remember that
the RFC IAX found on the net are somewhat old; you best bet being
reading the Asterisk sources.
That said, I don't think anyone would mind a new IAX frame.

By the nature of IAX, peers unware of the new IAX frame and its IEs
would just ignore it.

>
> 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

I think it would make sense but if I'm the only one thinking it, tough
luck, eh :-)

>
> >
> > 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.

But this is somewhat related to what i call codec negociation.
Imagine this:

- peer A says I can handle ulaw
- peer B says I can handle ulaw, h264
- peer A calls peer B audio call
- user at peer A starts camera
- peer A notices peer B accepts h264 frames and is able to encode them
so starts sending them over

At this point a 2 way ulaw call turned into a 2 way ulaw + 1 way h264 call.

>
> 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.

I think easy is better as I don't see any functional difference in
between the two.

--
Cristi