Unholding a Call in Alerting or RemoteAlerting state

3 views
Skip to first unread message

Marcin Głowacki

unread,
Jul 14, 2011, 10:55:30 AM7/14/11
to sipx...@googlegroups.com
Hi,

It seems that sipxtapi has problems with this situation. We have a call limit on our asterisk set to 1 so when trying to call someone the first call enters RemoteAlerting state, then I try to call some other number and the first call state changes to Bridged. The second call gets disconnected immediately and the first one remains.

Now, when I try to unhold the call nothing changes while sipxCallUnhold() returns 0. I can however answer the call so its not that bad.
I think its a bug.

--
Marcin Glowacki

Jaroslav Libak

unread,
Jul 14, 2011, 1:51:33 PM7/14/11
to sipx...@googlegroups.com, marcin.k...@gmail.com
Hello

Which version are you using?

Bridged call state means that the call doesn't have access to audio input/output and is therefore "silent". This is natural when making 2nd call and using takeFocus = SIPX_FOCUS_ALWAYS in sipxCallConnect. But unholding the 1st call should work. What do you mean that its not that bad? Do you get audio from the 1st call even in bridged state?  When invoking sipxCallUnhold I assume you specify bTakeFocus=1.

sipxCallUnhold is asynchronous operation, so it is unfortunately still possible for it to fail in theory even if sipxCallUnhold returns 0.

Perhaps you could investigate if you get to:
XCpCallStack::gainFocus - "ptrLock->postMessage(gainFocusCommand);" should execute
then XCpAbstractCall::handleGainFocus should be executed
then MpMediaTask::handleSetFocus

Regards,

Jaroslav

Marcin Głowacki schrieb:
--
You received this message because you are subscribed to the Google Groups "sipxtapi" group.
To post to this group, send email to sipx...@googlegroups.com.
To unsubscribe from this group, send email to sipxtapi+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sipxtapi?hl=en.

Reply all
Reply to author
Forward
0 new messages