search

erichocean / libjingle

Automatically exported from code.google.com/p/libjingle
0 stars 0 forks source link

Gmail calls to libjingle is not working #234

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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