Closed GoogleCodeExporter closed 9 years ago
The potential problem might be after
state == cricket::Session::STATE_RECEIVEDINITIATE
The "ACK" has been already sent. I need some more time looking into the source
code to confirm this. Meanwhile, I would suggest to implement this stanzas
construction code into the function/method. Then call it using the "call.exe
-d" to capture the log. You can see if the ACK has been sent before the redirec.
Original comment by jun...@google.com
on 3 Feb 2011 at 1:43
What you mean by "Meanwhile, I would suggest to implement this stanzas
construction code into the function/method."? The log using -d is attached. I
think that the ACK is sent after my redirect stanza. An interesting information
in the log is "Destroyed channel" just after the stanza that I think to be the
ACK. I appreciate any help.
Original comment by diego.cd...@gmail.com
on 4 Feb 2011 at 12:29
Attachments:
I've already seen that there is a method called SendStanzaError, from
XmppEngineImpl, that sends a wide range of errors, including the redirect
error. However you need to pass to original stanza and i don't know how to get
it. Is it possible to use this function? When and how call it?
Original comment by diego.cd...@gmail.com
on 7 Feb 2011 at 6:57
I discovered an issue in the libjingle sdk. I've filed an internal ticket to
track this issue. I'll keep you posted as soon as we get any progress. For your
reference, here is the ticket number:
3430685 Implement Call redirect functionality in libjingle (pub version)
Original comment by jun...@google.com
on 7 Feb 2011 at 9:56
I really appreciate that but can't you give me a tip so i can try by myself
while the update is not released?
I've read in
http://code.google.com/intl/pt-BR/apis/talk/libjingle/voice_chat.html that the
first signal that's sent on an incoming call is
PhoneSessionClient::SignalCallCreate that is handled in
CallClient::OnCallCreate(cricket::Call* call). There you can't know if the call
object in the argument is related to a incoming or outgoing call and the only
way to discover that is connecting to the new call object's SignalSessionState
signal that is handled in CallClient::OnSessionState(cricket::Call* call,
cricket::Session* session, cricket::Session::State state). And finally, if you
are receiving a call, the state will be STATE_RECEIVEINITIATE. You said that
the problem might be i send the redirect error stanza after this state but is
only after it that i know i am receiving a call. That's the problem. Another
doubt, as i posted, is: Is possible use the SendStanzaError method? Again, I
already thanks your attention and appreciate any help.
ps: Can I see this ticket so I can be aware of updates? (You said internal
ticket and after said pub version, so it not became clear to me)
Original comment by diego.cd...@gmail.com
on 8 Feb 2011 at 11:04
The ticket is in an internal bug database. You don't have access to it.
However, this is the external ticket that you can use to track this issue.
Due to this bug, you won't be able to make it working. We are actively working
on resolving issues, so I hope to get into this issue sooner. I'll update this
ticket as soon as we get any progress.
Thank you for your patience.
Original comment by jun...@google.com
on 8 Feb 2011 at 5:08
I've just discovered that libjingle only allow redirection to another resource
of the same account, per the text in XEP-0166. Is that true? If yes, Is there
any specification to do what I want (wich is, if somebody calls me, I want to
redirect this call to another user)? Actually, I don't know the correct word to
describe that, if is call redirect, call fowarding, or call transfer. What are
the differences? Or are they synonyms? Maybe what I need is XEP-0251? Does
libjingle support (or intend to support) that? Thanks.
Original comment by diego.cd...@gmail.com
on 10 Feb 2011 at 7:58
Is this issue fixed in newer release of libjingle ?
Original comment by chandaku...@gmail.com
on 15 Dec 2011 at 1:58
I don't think so
Original comment by diego.cd...@gmail.com
on 15 Dec 2011 at 3:58
Original comment by jun...@google.com
on 26 Mar 2012 at 6:36
Original comment by jun...@google.com
on 26 Mar 2012 at 6:39
Original comment by juberti@google.com
on 31 May 2013 at 8:33
Original issue reported on code.google.com by
diego.cd...@gmail.com
on 2 Feb 2011 at 5:48