Gmail calls to libjingle is not working
GoogleCodeExporter opened this issue · comments
I have an app based on libjingle. Last Thursday, calls from Gmail to my app
suddenly stopped working. I was using libjingle 0.5.6 so I tried to update to
0.6.2. But then I noticed that even the call example is working. It's answering
(session-accept stanza) only with audio. Some log is below. I believe Google
changed something on the Gmail plugin. Has somebody else experienced this
problem? Thanks in advance.
Video is not supported in answer
Created channel
Setting remote voice description
Changing voice state, recv=0 send=0
Created channel
Setting remote video description
Changing video state, recv=0 send=0
Channel enabled
Changing voice state, recv=0 send=0
Channel enabled
Changing video state, recv=0 send=0
Incoming call from 'diego.cdomingos2010@gmail.com/gmail.29B9178F'
Video is not supported in answer
Setting local voice description
Set send ssrc for audio: 1674268667
SRTP activated with negotiated parameters: send cipher_suite
AES_CM_128_HMAC_SHA1_80 recv cipher_suite AES_CM_128_HMAC_SHA1_80
Changing voice state, recv=1 send=0
Set renderer of ssrc 0 to 0x8d788a8.
SEND >>>>>>>>>>>>>>>> : Mon Oct 24 10:37:05 2011
<iq to="diego.cdomingos2010@gmail.com/gmail.29B9178F" type="set" id="8">
<jingle xmlns="urn:xmpp:jingle:1" action="session-accept" sid="c1399364259">
<content name="audio" creator="initiator">
<description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio" ssrc="1674268667">
<payload-type id="9" name="G722" clockrate="16000"/>
<payload-type id="0" name="PCMU" clockrate="8000"/>
<encryption>
<crypto tag="1" crypto-suite="AES_CM_128_HMAC_SHA1_80" key-params="inline:lz84v2OxzcCfMmqYLuE3rSGkIU6WLBMVpRiFNPrg"/>
</encryption>
</description>
<transport xmlns="http://www.google.com/transport/p2p"/>
</content>
</jingle>
</iq>
Original issue reported on code.google.com by diego.cd...@gmail.com on 24 Oct 2011 at 12:50
Sorry: "... even the call example is NOT working ..."
On libjingle 0.5.6 I could solve the problem setting secury_policy to
SEC_DISABLED but the same did not work on 0.6.2. Maybe Gmail plugin is using a
new crypto algorithm?
Original comment by diego.cd...@gmail.com on 24 Oct 2011 at 1:39
Other usefull information: calls from libjingle to Gmail (using the call
example "vcall" command) are fine. The problem happens only when Gmail calls
the call example.
Original comment by diego.cd...@gmail.com on 25 Oct 2011 at 1:15
I could get it working on 0.6.2. It seems like the problem is that a new file
was added (mediasession.h), where is defined a struct (MediaSessionOptions) and
the default value of has_video is false. I believe call example should also set
has_video of cricket::CallOptions to true when accepting an incoming call (it
is doing this only when making calls). Altough I could get it working, it just
worked with secuty_policy set to SEC_DISABLED, so I still want to know what
happened at google's side regarding to cryptography.
Original comment by diego.cd...@gmail.com on 25 Oct 2011 at 7:48
I tested your scenario with build 0.6.2 and not able to reproduce the issue.
Calls from both directions works, except that I discovered an audio issue when
calling from the Gmail side, but this is a separate issue though.
Could you please attach the full xmpp stanza if you still run into the same
issue with libjingle 0.6.2?
Original comment by jun...@google.com on 26 Oct 2011 at 12:26
- Changed state: Started
Thanks for answering. The requested logs are attached. Jun, don't you think
that my comment #3 makes sense?
Original comment by diego.cd...@gmail.com on 26 Oct 2011 at 11:30
Attachments:
- [not working incoming call](https://storage.googleapis.com/google-code-attachments/libjingle/issue-234/comment-5/not working incoming call)
- [working outgoing call](https://storage.googleapis.com/google-code-attachments/libjingle/issue-234/comment-5/working outgoing call)
I just realized that I misunderstood the issue you reported. Now I understand
what you mean in the comment #3.
I have reproduced the same issue and is working on the fix. I can send you a
patch if this is urgent, otherwise, the fix will be in 0.6.3.
Original comment by jun...@google.com on 26 Oct 2011 at 3:59
- Changed state: Accepted
Ok, no problem, I already could get it working. Altough it seems the call
example is working with SEC_ENABLED, my app (that was based on call example) is
working only with SEC_DISABLED. If you get to know something about it please
let me know. Thanks.
Original comment by diego.cd...@gmail.com on 26 Oct 2011 at 4:22
The "no video" issue has been fixed and will be in the next release 0.6.3.
The "SEC_Enabled" issue is a known issue. We will roll out the secure call to
external gmail accounts in the near future. Meanwhile, even though the "call
example" works with "sec_enabled" flag, but essentially it's not a secure call.
Original comment by jun...@google.com on 27 Oct 2011 at 8:37
- Changed state: Fixed
What's the known issue? To be honest, I didn't understand your explanation very
well.
I could print libjingle logs on my app and I get this when SEC_ENABLE is ised:
SRTP activated with negotiated parameters: send cipher_suite
AES_CM_128_HMAC_SHA1_80 recv cipher_suite AES_CM_128_HMAC_SHA1_80
and then:
Error(channel.cc:308): Failed to protect audio RTP packet: size=172,
seqnum=13726, SSRC=2114243016
Warning(srtpfilter.cc:328): Failed to protect SRTP packet: The buffer length
172 is less than the needed 182
I saw in the code that this error is printed when there is not enough capacity
on the packet to append an auth tag on it. I also noted that the size needed is
always 10 bytes longer than the packet capacity. Do you have any ideia about
it? Thanks.
Original comment by diego.cd...@gmail.com on 28 Oct 2011 at 5:37
About the error I mentioned on comment #9 I discovered that my app didn't
reflect an old modification on RtpSenderReceiver (that I used as reference to
construct my RTP Sender Receiver class). Changing the line
talk_base::Buffer buffer(data, len);
to
talk_base::Buffer buffer(data, len, kMaxRtpPacketLen);
Solved the "lack of space in the RTP packet" problem.
Also I saw that you have fixed the problem on call example that I mentioned on
comment #3 so you can close this ticket. Thanks.
Original comment by diego.cd...@gmail.com on 31 Oct 2011 at 4:55