jigar-joshi / libjingle

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

STUN ping failure #175

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Use two accounts. Login one into gmail and another logs in using the "call" 
example. Use the rtpdump samples included with libjingle as video/voice inputs.
2. Initiate a video/voice call from gmail and "accept" from call.

What is the expected output? What do you see instead?
The video call does not start. I don't see video sample on gmail. But if I 
reverse the order, that is, call from the "call" sample and accept in gmail, 
then the call goes through.

I've delved into the code a bit and I notice the following:
- In the failing case, STUN pings are sent endlessly from "call" but receive no 
response. In the working case, (call in the reverse direction), STUN pings 
receive appropriate responses.
- The failure is also account dependent. I can use another older gmail account 
to log into gmail and thne things work fine in both directions.

What version of the product are you using? On what operating system?
libjingle 0.5 and 0.5.6
Mac OSX 10.6.7

Please provide any additional information below.

Can you please help by telling me what might be going wrong here? What are the 
conditions under which STUN pings stop working. Is there some authentication 
needed with the server? Why does it work in the reverse direction (calling from 
"call" example TO gmail)?

Would really appreciate your help on this!!

Original issue reported on code.google.com by explorer...@gmail.com on 10 Jun 2011 at 11:41

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
As I mentioned above, the failure will happen when you log into gmail with some 
accounts and not others.

Interestingly, when you make a call from gmail to the running example "call" 
with libjingle 0.5 using a "bad" account, the "session-initiate" looks like 
this:

<iq type="set" to="###username2###@gmail.com/mytestabcdD59FB5AD" 
id="17311D1B052B29E8" 
from="###username1###@gmail.com/gmail.63CE2501"><jin:jingle 
action="session-initiate" sid="c868037114" 
initiator="###username1###@gmail.com/gmail.63CE2501" 
xmlns:jin="urn:xmpp:jingle:1"><jin:content name="video"><rtp:description 
media="video" xmlns:rtp="urn:xmpp:jingle:apps:rtp:1"><rtp:payload-type id="99" 
name="H264-SVC"><rtp:parameter name="width" value="320"/><rtp:parameter 
name="height" value="200"/><rtp:parameter name="framerate" 
value="30"/></rtp:payload-type><rtp:payload-type id="96" 
name="H264-SVC-draft-02"><rtp:parameter name="width" 
value="320"/><rtp:parameter name="height" value="200"/><rtp:parameter 
name="framerate" value="30"/></rtp:payload-type><rtp:payload-type id="97" 
name="H264"><rtp:parameter name="width" value="320"/><rtp:parameter 
name="height" value="200"/><rtp:parameter name="framerate" 
value="30"/></rtp:payload-type><rtp:payload-type id="98" 
name="H263"><rtp:parameter name="width" value="320"/>
RECV >>>>>>>>>>>>>>>> : Fri Jun 10 18:31:19 2011
<rtp:parameter name="height" value="200"/><rtp:parameter name="framerate" 
value="30"/></rtp:payload-type><rtp:encryption/></rtp:description><p:transport 
xmlns:p="http://www.google.com/transport/p2p"/></jin:content><jin:content 
name="audio"><rtp:description media="audio" 
xmlns:rtp="urn:xmpp:jingle:apps:rtp:1"><rtp:payload-type id="103" name="ISAC" 
clockrate="16000"><rtp:parameter name="bitrate" 
value="32000"/></rtp:payload-type><rtp:payload-type id="104" name="ISAC" 
clockrate="32000"><rtp:parameter name="bitrate" 
value="56000"/></rtp:payload-type><rtp:payload-type id="119" name="ISACLC" 
clockrate="16000"><rtp:parameter name="bitrate" 
value="40000"/></rtp:payload-type><rtp:payload-type id="99" name="speex" 
clockrate="16000"><rtp:parameter name="bitrate" 
value="22000"/></rtp:payload-type><rtp:payload-type id="97" name="IPCMWB" 
clockrate="16000"><rtp:parameter name="bitrate" 
value="80000"/></rtp:payload-type><rtp:payload-type id="9" name="G722" 
clockrate="16000">
RECV >>>>>>>>>>>>>>>> : Fri Jun 10 18:31:19 2011
<rtp:parameter name="bitrate" 
value="64000"/></rtp:payload-type><rtp:payload-type id="102" name="iLBC" 
clockrate="8000"><rtp:parameter name="bitrate" 
value="13300"/></rtp:payload-type><rtp:payload-type id="98" name="speex" 
clockrate="8000"><rtp:parameter name="bitrate" 
value="11000"/></rtp:payload-type><rtp:payload-type id="3" name="GSM" 
clockrate="8000"><rtp:parameter name="bitrate" 
value="13200"/></rtp:payload-type><rtp:payload-type id="100" name="EG711U" 
clockrate="8000"><rtp:parameter name="bitrate" 
value="64000"/></rtp:payload-type><rtp:payload-type id="101" name="EG711A" 
clockrate="8000"><rtp:parameter name="bitrate" 
value="64000"/></rtp:payload-type><rtp:payload-type id="0" name="PCMU" 
clockrate="8000"><rtp:parameter name="bitrate" 
value="64000"/></rtp:payload-type><rtp:payload-type id="8" name="PCMA" 
clockrate="8000"><rtp:parameter name="bitrate" val
ue="64000"/></rtp:payload-type><rtp:payload-type id="117" name="red" 
clockrate="8000"/>
RECV >>>>>>>>>>>>>>>> : Fri Jun 10 18:31:19 2011<rtp:payload-type id="106" 
name="telephone-event" 
clockrate="8000"/><rtp:encryption/></rtp:description><p:transport 
xmlns:p="http://www.google.com/transport/p2p"/></jin:content></jin:jingle><ses:s
ession type="initiate" id="c868037114" 
initiator="###username1###@gmail.com/gmail.63CE2501" 
xmlns:ses="http://www.google.com/session"><vid:description 
xmlns:vid="http://www.google.com/session/video"><vid:payload-type id="99" 
name="H264-SVC" width="320" height="200" framerate="30"/><vid:payload-type 
id="96" name="H264-SVC-draft-02" width="320" height="200" 
framerate="30"/><vid:payload-type id="97" name="H264" width="320" height="200" 
framerate="30"/><vid:payload-type id="98" name="H263" width="32
0" height="200" framerate="30"/><rtp:encryption 
xmlns:rtp="urn:xmpp:jingle:apps:rtp:1"><vid:usage/></rtp:encryption>
RECV >>>>>>>>>>>>>>>> : Fri Jun 10 18:31:19 2011<pho:payload-type id="103" 
name="ISAC" bitrate="32000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="104" 
name="ISAC" bitrate="56000" clockrate="32000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="119" 
name="ISACLC" bitrate="40000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="99" 
name="speex" bitrate="22000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="97" 
name="IPCMWB" bitrate="80000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="9" 
name="G722" bitrate="64000" clockrate="16000" xmlns:pho="h
ttp://www.google.com/session/phone"/><pho:payload-type id="102" name="iLBC" 
bitrate="13300" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/>
RECV >>>>>>>>>>>>>>>> : Fri Jun 10 18:31:19 2011<pho:payload-type id="98" 
name="speex" bitrate="11000" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="3" 
name="GSM" bitrate="13200" c
lockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="100" 
name="EG711U" bitrate="64000" clockrate="8000" 
xmlns:pho="http://www.google.com/se
ssion/phone"/><pho:payload-type id="101" name="EG711A" bitrate="64000" 
clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="0" 
name="PCMU" 
bitrate="64000" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="8" 
name="PCMA" bitrate="64000" clockrate="8000" xmlns:pho="http://www
google.com/session/phone"/><pho:payload-type id="117" name="red" 
clockrate="8000" xmlns:pho="http://www.google.com/session/phone"/>RECV 
>>>>>>>>>>>>>>>> : Fri Jun 10 18:31:19 2011<pho:payload-type id="106" 
name="telephone-event" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><rtp:encryption 
xmlns:rtp="urn:xmpp:jingle:apps:rtp:1"><pho:usage 
xmlns:pho="http://www.google.com/session/phone"/></rtp:encryption></vid:descript
ion></ses:session></iq>

When you call from gmail using a "good" account, the session initiate looks 
like the following.

<iq type="set" to="###username1###@gmail.com/mytestabcd12E5B9C4" 
id="B26BC9A80A3A4FB0" 
from="###username2###@gmail.com/gmail.6369A7BD"><ses:session type="initiate" 
id="c1290798912" initiator="###username2###@gmail.com/gmail.6369A7BD" 
xmlns:ses="http://www.google.com/session"><vid:description 
xmlns:vid="http://www.google.com/session/video"><vid:payload-type id="99" 
name="H264-SVC" width="320" height="200" framerate="30"/><vid:payload-type 
id="96" name="H264-SVC-draft-02" width="320" height="200" 
framerate="30"/><vid:payload-type id="97" name="H264" width="320" height="200" 
framerate="30"/><vid:payload-type id="98" name="H263" width="320" height="200" 
framerate="30"/><rtp:encryption 
xmlns:rtp="urn:xmpp:jingle:apps:rtp:1"><vid:usage/></rtp:encryption>
RECV >>>>>>>>>>>>>>>> : Fri Jun 10 19:09:44 2011
<pho:payload-type id="103" name="ISAC" bitrate="32000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="104" 
name="ISAC" bitrate="56000" clockrate="32000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="119" 
name="ISACLC" bitrate="40000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="99" 
name="speex" bitrate="22000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="97" 
name="IPCMWB" bitrate="80000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="9" 
name="G722" bitrate="64000" clockrate="16000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="102" 
name="iLBC" bitrate="13300" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/>
RECV >>>>>>>>>>>>>>>> : Fri Jun 10 19:09:44 2011
<pho:payload-type id="98" name="speex" bitrate="11000" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="3" 
name="GSM" bitrate="13200" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="100" 
name="EG711U" bitrate="64000" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="101" 
name="EG711A" bitrate="64000" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="0" 
name="PCMU" bitrate="64000" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="8" 
name="PCMA" bitrate="64000" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><pho:payload-type id="117" 
name="red" clockrate="8000" xmlns:pho="http://www.google.com/session/phone"/>
RECV >>>>>>>>>>>>>>>> : Fri Jun 10 19:09:44 2011
<pho:payload-type id="106" name="telephone-event" clockrate="8000" 
xmlns:pho="http://www.google.com/session/phone"/><rtp:encryption 
xmlns:rtp="urn:xmpp:jingle:apps:rtp:1"><pho:usage 
xmlns:pho="http://www.google.com/session/phone"/></rtp:encryption></vid:descript
ion></ses:session></iq>

This second format is similar to what libjingle would send when it does 
"session-initiate". 

Is there a new modified protocol or XML stanzas that gmail is using now for 
some users?

Please help.

Original comment by explorer...@gmail.com on 11 Jun 2011 at 2:25

GoogleCodeExporter commented 9 years ago
To see this issue in action on your own, please follow these steps:

1. Create a brand new gmail account, say account1.
2. Invite account1 to be a gmail contact of an existing account, say account2.
3. Log into gmail using the new account1 and log into the "call" example using 
existing account2.
4. Call FROM GMAIL using account1 to account2 in "call" and "accept" from 
there. (use voice.rtpdump, video.rtpdump).
5. You will notice that the call does not start. (No STUN ping responses from 
gmail or pings requests from gmail, no RTP data transferred).

Original comment by explorer...@gmail.com on 13 Jun 2011 at 1:22

GoogleCodeExporter commented 9 years ago
The different stanzas you see are the stanzas of XEP-166 and XEP-167.  In other 
words, we've recently turned on support for speaking the XMPP standard call 
signalling protocols.  You see it behave differently on different accounts 
because the rollout does not happen all at once.  Soon, all accounts will be 
speaking the standard protocol.

Libjingle 0.5.6 should be completely compatible with the standard protocols, 
and I've tested it extensively to verify that it is.  However, if you are using 
a version of libjingle prior to 0.5.3, there may be issues, due to a bug that 
was present in libjingle until we fixed it in 0.5.3. For example, we recently 
learned of a product using libjingle 0.5.2 that was effected and had an issue 
similar to the one you have reported.

What version of libjingle are you using in the product mentioned?  

Also, if you could provide an entire log (with the session-initiate, 
session-accept, and trasnport-info messages), that would help debug the issue.

Original comment by pthatc...@gmail.com on 13 Jun 2011 at 5:04

GoogleCodeExporter commented 9 years ago
I am attaching logs for:
1. When a call is initiated from gmail and accepted by the libjingle 5.0 stack.
2. When a call is initiated from gmail and accepted by the libjingle 5.6 stack. 

Basically, in the first case, gmail sends an initiate which is accepted by the 
libjingle stack but STUN pings sent by libjingle don't get any response.

In the second case (version 5.6 of the stack), the libjingle stack does not 
even accept the inititate but sends a session terminate outright. Not sure why.

Both of endpoints (libjingle comandline and gmail) were on the same computer.

Thanks for your help!

Original comment by explorer...@gmail.com on 13 Jun 2011 at 6:15

Attachments:

GoogleCodeExporter commented 9 years ago
Via those logs, I can tell that the libjingle 0.5 code is failing because of 
the bug in it.  The best route there is to either update to libjingle 0.5.3 or 
greater, or to apply the attached patch.  The patch if against 0.5.2, but 0.5 
should be close enough that you could apply it manually.

As far as why libjingle 0.5.6 is failing, I can't tell, since there's nothing 
else in the log.  Have you tried an audio-only call to see if it's a 
video-specific issue?

Original comment by pthatc...@gmail.com on 13 Jun 2011 at 7:54

GoogleCodeExporter commented 9 years ago
Can you please attach the patch that you mentioned? I'll try to apply the patch 
manually to libjingle 0.5.

With libjingle 0.5.6, I'll try an audio-only call shortly and let you know. 
Thanks!

Original comment by explorer...@gmail.com on 13 Jun 2011 at 8:37

GoogleCodeExporter commented 9 years ago
Whoops.  I forgot to attach.  Sorry about that.  Here it is.

Original comment by pthatc...@gmail.com on 13 Jun 2011 at 10:02

Attachments:

GoogleCodeExporter commented 9 years ago
Awesome! With this patch, a call from gmail to libjingle stack works! Thanks so 
much for this patch. 

So I guess the fix is to use the "sid" attribute in the jingle element (instead 
of "id") in order to be strictly compliant with XEP 166.

Are there any other bugs/issues in libjingle 0.5 that you can think of that 
might be exposed because of the strict compliance that Google is rolling out?

Btw, I tried an audio call from gmail to the libjingle 0.5.6 stack and I still 
see the same failure. (Logs attached).
Am I doing something wrong here or is there an incompatibility between gmail 
and libjingle 0.5.6?
My usage of the call executable is:
./call --secure disable --videoinput video.rtpdump --voiceinput voice.rtpdump 
--videooutput v.rtpdump --voiceoutput a.rtpdump --d <username> <password>

But since I am using libjingle 0.5 for now, I guess this issue isn't too 
important for me right now.

Thanks again!

Original comment by explorer...@gmail.com on 13 Jun 2011 at 11:28

Attachments:

GoogleCodeExporter commented 9 years ago
Glad to hear it's working.  I don't know of any incompatibilities with 
libjingle 0.5, but there have been a number of bug fixes since then that may 
effect you eventually.  I wouldn't recommend staying so far behind in versions 
for very long.

As far as libjingle 0.5.6, I wouldn't be surprised if it's because you're using 
file input/output.  We change some of that code recently and we don't test/use 
it as much, so it's possible we broke something.

To verify that it's unrelated to the protocol changes, you can pass the 
parameter "--protocol gingle".  If that works, it's still related to the 
protocol.  If it doesn't, it must be some regression in 0.5.6, probably related 
to the file input.  Please try that and let me know.

Original comment by pthatc...@gmail.com on 14 Jun 2011 at 2:20

GoogleCodeExporter commented 9 years ago

Original comment by jun...@google.com on 14 Jun 2011 at 7:15

GoogleCodeExporter commented 9 years ago
I have the info that you asked for. Sorry for the delay. Was out for a few days.

I checked the behavior with --protocol gingle and I also notice a terminate 
("reject" in gingle parlance) from the libjingle stack when there is a call 
from a gmail client.

So, with "jingle", the stack responds to an incoming call with:
<iq to=##REMOVED## type="set" id="8">
     <jingle xmlns="urn:xmpp:jingle:1" action="session-terminate" sid="c1109232533"/>
   </iq>

And with protocol "gingle", the stack responds to an incoming call with: 
  <iq to=##REMOVED## type="set" id="8">
     <session xmlns="http://www.google.com/session" type="reject" id="c77378031" initiator=##REMOVED##/>
   </iq>

Is the bug related to the "call" program and not the library itself?
Btw, I also notice the same behavior with libjingle 0.5.3, so this is not 
something that got in with the last release.

Original comment by explorer...@gmail.com on 21 Jun 2011 at 7:44

GoogleCodeExporter commented 9 years ago
Found the issue.

In talk/examples/call/call_main.cc:

voice_codecs.push_back(
      cricket::AudioCodec(9, "G722", 16000, 0, 1, 0));

...should be...

voice_codecs.push_back(
      cricket::AudioCodec(9, "G722", 16000, 64000, 1, 0));

After this change, things work fine

Original comment by explorer...@gmail.com on 21 Jun 2011 at 7:54