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

[Aurelien Bouin]

Hi Simon,

I don't have much time to try and test your new version... Because without the 
new states that I implemented I have to change my upper API about the distant 
call status...
You have not implemented the bugs I attached with the patch too like :
=> ringing are not sent when multi call in callbacks.c in the function 
call_ringing...
=> the fact that the upper API could handle the refer
=> the DTMF reception whatever the call it received it
=> the fact that the call do not handle video but it do not change the params 
(linphone_call_start_media_streams)
=> ... 
Such a lot of work for me again to implement... that will result in sending you 
a new patch that afterward i will have to check again...
Sorry but I can't handle this load for the moment...

Regards,

Aurélien

--- En date de : Jeu 3.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: Jeudi 3 février 2011, 14h52
> 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
> 
> 
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers
>