Jaroslav Libak - 2007-02-19 18:13 The first patch had a bug with pCallData->bInFocus, it was always set to true.

Jaroslav Libak - 2007-02-20 04:49 I should also add that sipxCallUnhold with true should be called only for the first conference call, for other calls it should be called with false, in case we have more conferences and don't want to switch focus. Application needs to decide whether it wants to switch focus or not.

Dan Petrie - 2007-03-09 14:09 If I understand this correctly, call 1 is part of conference A which is in focus. call 1 is put on hold and then joined to conference B which is in bridged mode. call 1 is then taken off hold and becomes in a BRIDGED state. This is the correct behavior. Conference A has focus and as such B cannot have focus it must stay in bridged mode until conference B is explicity put in focus using sipxConferenceUnhold. Please clarify if I have misunderstood this problem. The best way to illustrate the problem is to provide a unit test.

Jaroslav Libak - 2007-03-09 15:22 No you misunderstood it. There is only 1 conference A in this scenario and only 1 call. 1.) you create new conference A 2.) you make a call and connect it 3.) you put call into full hold 4.) you join the call into conference 5.) you try to unhold the call directly 6.) call ends up in bridged state You cant change this bridged state by calling unhold on the call, you must use sipxconferenceunhold. (this is according to .h file, so this isnt a bug, but weird behaviour at least) This behaviour of hold makes it more difficult for user to talk to single participant in a conference. Lets assume you have 3 people in conference and you want to talk to 1 of them only. You might try to put the whole conference on hold, and then unhold the single call. This will not work. Call will stay in bridged state. Or you might just put individual calls on hold, except the one you want to speak to. This will succeed, you can talk to single participant only, but then, unhold on those individual calls wont work, and they will end up in bridged state (instead of connected). You will have to use unhold on the whole conference (but how do you want to realize this with a toggle button? conference wasnt put on hold before, so it will look like you are putting it on hold and then on unhold again, which looks like a bug in software). This is weird behaviour, if user puts a call into hold, he expects the same function / button to enable it again, and not some other button. If enabling unhold taking focus in a conference doesnt break something in the code it should be enabled even if it can cause focus shift between conferences.