linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] lots of bugs resolution and multicalls improve


From: Simon Morlat
Subject: Re: [Linphone-developers] lots of bugs resolution and multicalls improvements
Date: Thu, 03 Feb 2011 14:52:31 +0100

Hi Aurélien and Maxim,

As we decided to postpone the new release to monday, I worked on these
scenarios today and I can say now both are fully working.

I finally did not introduced any supplementary states.

When A pauses B and then B pauses A too, A call keeps the paused state,
and B's call goes from PausedByRemote to Paused.
If A resumes B, then A's call goes to to PausedByRemote.

Everything is on git right now.

Best regards,

Simon


Le mardi 01 février 2011 à 10:12 +0000, Aurelien Bouin a écrit :
> Hi Simon,
> I agree that the correct behaviour would be as fallows:
> 
> A pauses B (thus B listens to music)
> B pauses A (thus the call is totally inactive)
> B resumes A (this B listens to music again)
> A resumes B (the call is now full duplex).
> 
> and it also could be :
> 
> A pauses B (thus B listens to music)
> B pauses A (thus the call is totally inactive)
> A resumes B (this A listens to music again)
> B resumes A (the call is now full duplex).
> 
> Regards,
> 
> Aurelien
> 
> --- En date de : Mar 1.2.11, Simon Morlat <address@hidden> a écrit :
> 
> > De: Simon Morlat <address@hidden>
> > Objet: Re: [Linphone-developers] lots of bugs resolution and multicalls 
> > improvements
> > À: address@hidden
> > Date: Mardi 1 février 2011, 10h54
> > Hi Aurélien, Maxim,
> > 
> > I agree that the correct behaviour would be as follows:
> > 
> > A pauses B (thus B listens to music)
> > B pauses A (thus the call is totally inactive)
> > B resumes A (this B listens to music again)
> > A resumes B (the call is now full duplex).
> > 
> > It would be a bad thing if B resumes A changes the call in
> > full duplex.
> > A must always decide whether it can send and listen real
> > audio.
> > 
> > Everybody agrees with that ?
> > 
> > Simon
> > 
> > Le mercredi 26 janvier 2011 à 07:56 +0000, Aurelien Bouin
> > a écrit :
> > > Hi Simon
> > > 
> > > > De: Simon Morlat <address@hidden>
> > > > Objet: Re: [Linphone-developers] lots of bugs
> > resolution and multicalls improvements
> > > > À: address@hidden
> > > > Cc: "Aurelien Bouin" <address@hidden>
> > > > Date: Mardi 25 janvier 2011, 21h35
> > > > Hi Aurélien,
> > > > 
> > > > Thanks for the patches, it took some time to
> > review them.
> > > Yeah I guess it's quite a lot of work while you are
> > probably very busy ... sorry for that . . .
> > > 
> > > > I merged the one concerning mediastreamer2,
> > however I feel
> > > > more
> > > > unconvinced by the one in liblinphone, especially
> > with the
> > > > multiple new
> > > > LinphoneCallState that it introduces.
> > > > 
> > > > It leads to big complexity, I hope there is a
> > more simpler
> > > > way to solve
> > > > the problem you were attempting to solve. Could
> > you
> > > > describe a 
> > > > bit more the actual problems you were facing ?
> > > Yes you are right it's really too complicate too
> > handle multicalls with this kind of implementation...
> > > The problem is easy to be reproduced between two
> > Linphone... :
> > > Call each other
> > > The streaming should be running 
> > > Execute a pause in one side
> > > Execute a pause on the other side
> > > Here it should be OK each one is in Pause status
> > > But when one ff them Resume the call the call will
> > restart while the other is still in Pause...which is a
> > problem... The new states help to handle those cases...but
> > it's really complex to implement...
> > > Give it a try whenever you have the time, if you have
> > a better implementation I would appreciate it...
> > > 
> > > > 
> > > > Concerning the ability to start several calls on
> > hold, I'm
> > > > ok with that.
> > > > However the terminology in liblinphone is
> > "paused" to refer
> > > > to putting a
> > > > call on hold, so I would suggest the new
> > parameter in
> > > > LinphoneCallParams
> > > > would use the same terminology.
> > > > Also, I think there is no reason to modify the
> > sal_call()
> > > > prototype,
> > > > since the nature of the call (paused or not) is
> > only the
> > > > SalMediaDescription describing the offer, that
> > would
> > > > contain send-only
> > > > streams instead of sendrecv ones.
> > > No problem I will change hold by pause when I will
> > have the time though...
> > > 
> > > 
> > > > 
> > > > Best regards,
> > > > 
> > > > Simon
> > > > 
> > > Thank you Simon for your precious time, do not
> > hesitate to ask anything ...
> > > Regards,
> > > 
> > > Aurélien BOUIN
> > > 
> > > > 
> > > > 
> > > > Le mercredi 19 janvier 2011 à 10:11 +0000,
> > Aurelien Bouin
> > > > a écrit :
> > > > > Hi all,
> > > > > I have not been able to work on linphone for
> > such a
> > > > lot of time, but we have seen some problems since
> > multiple
> > > > calls are implemented...
> > > > > Here is a non exhausting list of features
> > implemented
> > > > in the attached patchs :
> > > > > ->resolve problem of bipartite hold
> > on/off, some
> > > > states have been added, but makes the callbacks
> > hard to be
> > > > understood ...
> > > > > ->instability into thread joined into
> > msv4l2 and
> > > > msthread
> > > > > ->being able to do multiples calls with
> > the
> > > > possibility of doing them hold on...
> > > > > ->being able to receive DTMF from any
> > call
> > > > process...
> > > > > ->sal_media_description_has_dir seems to
> > not being
> > > > functional like it was
> > > > > ->improvements with the plugins use under
> > windows
> > > > > 
> > > > > I hope that you will have the time to
> > consider those
> > > > changes, do not hesitate to ask ...
> > > > > Thank you for your time spent to work on
> > that ...
> > > > > 
> > > > > Aurélien BOUIN
> > > > > 
> > > > > 
> > > > >       
> > > > >
> > _______________________________________________
> > > > Linphone-developers mailing list address@hidden
> > > > http://lists.nongnu.org/mailman/listinfo/linphone-developers
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > >       
> > > 
> > > _______________________________________________
> > > Linphone-developers mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/linphone-developers
> > 
> > 
> > 
> > _______________________________________________
> > Linphone-developers mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/linphone-developers
> > 
> 
> 
>       
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]