[EMAIL PROTECTED] wrote:
I put a call into full hold. Then call sipxConferenceJoin to add it to a conference. It succeeds.
But the call is in held state, and I want to unhold it.
However after calling sipxCallUnhold it goes to bridged state, so local mic/speaker are not engaged.
Subsequent calls to sipxCallUnhold do nothing.

What is the correct behaviour? I didn't find it in sipxtapi.h or in the sipxcalllib/doc manual. Shouldn't that call after sipxCallUnhold be in CONNECTED state instead of BRIDGED?

I think sipxtapi doesn't go to CONNECTED state from BRIDGED as you can see from the log even though you can see LOCAL_START::AUDIO event. After REMOTE_START::AUDIO it goes correctly to BRIDGED. But after LOCAL_START::AUDIO it should proceed to CONNECTED.

log:
HELD::CAUSE_NORMAL
EVENT_CATEGORY_MEDIA::LOCAL_STOP::AUDIO::CAUSE_HOLD
EVENT_CATEGORY_MEDIA::REMOTE_STOP::AUDIO::CAUSE_HOLD

sipxConferenceJoin - Call joined the conference 1
sipxCallUnhold

EVENT_CATEGORY_MEDIA::REMOTE_START::AUDIO::CAUSE_NORMAL
BRIDGED::CAUSE_NORMAL
EVENT_CATEGORY_MEDIA::LOCAL_START::AUDIO::CAUSE_NORMAL

_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

I made a patch for this problem. I described it also in XCL-126:

"When I create a new conference using sipxConferenceCreate, make a call and put it in full hold using sipxCallHold, call sipxConferenceJoin to add it to conference and call sipxCallUnhold, call is put into bridged state, not engaging mic/speaker.

It is probably assumed that the first call will be added to conference without putting it on hold first, thus mic/speaker will already be in focus on the single call in conference, so when 2nd call is added it will be in bridged state after calling unhold on it which should be ok since the 1st conference call is in focus.

But if the 1st call is added to the conference by putting it on hold first, then we cannot unhold it properly anymore. Unhold can put a conference call only into bridged state.

Therefore I added a new bool parameter to sipxCallUnhold, meaning whether we want the call to take focus. It is true by default.
sipxCallUnhold function is also rewritten to be more safe and strict."

With this patch you can put conference call into focus

Jaro

Attachment: sipxtapipatch.tar.bz2
Description: Binary data

_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

Reply via email to