Hi Youness<div><br></div><div>Thanks for a prompt reply!</div><div><br></div><div>Basically, I started debugging when my Empathy client is not being able to send files with large size</div><div>(I tried sending a 3.5 MB file to another friend within the NAT), to a Pidgin client. Then we tried transfer</div>
<div>using both Empathy clients, then it worked... In due course, I was stuck with many doubts...</div><div><br></div><div><b>Doubt 1 :</b></div><div><br></div><div>What am keen to know, is according to which XEP is the current 'file transfer' implemented in latest</div>
<div>telepathy-gabble ? I can't assume it is XEP - 0234 ... since from whatever XML stanzas are exchanged,</div><div>between the two clients, no 'Jingle' namespace is found. </div><div><br></div><div>Moreover, 'candidates exchange' is also done differently</div>
<div>compared to what XEP 234 mentions... (candidates are informed in the session-initiate stanza itself). Is it because</div><div>this XEP doesn't talk about the NAT problem ?</div><div><br></div><div>XEP 176 talks about Jingle & ICE-UDP transport, but telepathy-gabble doesn't follow that either...</div>
<div><br></div><div>I see stanzas as below :</div><div><br></div><div><iq type="set" to="<a href="http://my_friend@gmail.com/7e4881de">my_friend@gmail.com/7e4881de</a>" id="2196244687"><session initiator="<meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://my_username@gmail.com/16b4cb7b">my_username@gmail.com/16b4cb7b</a>" id="1515877176" type="initiate" xmlns="<a href="http://www.google.com/session">http://www.google.com/session</a>"><description xmlns="<a href="http://www.google.com/session/share">http://www.google.com/session/share</a>"><manifest><file size="3629067"><name>mybook.pdf</name></file></manifest><protocol><http><url name="source-path">/temporary/72864f06-f547-48fb-8116-3a21ac78de20/</url><url name="preview-path">/temporary/7c887282-e7e1-4beb-820f-f0421d66c693/</url></http></protocol></description><transport xmlns="<a href="http://www.google.com/transport/p2p">http://www.google.com/transport/p2p</a>"/></session></iq></div>
<div><br></div><div>In a series of function calls, I saw that <a href="http://relay.google.com:80">relay.google.com:80</a> has been used. But according to which XEP/Standard</div><div>published, this kind of methodology is used ? Or is it Google's prescribed way at present, which will soon be standardized ?</div>
<div>Because, until you had explained very vividly, I couldn't find that info in any XEP or document related to XMPP.</div><div><br></div><div><b>Doubt 2 :</b></div><div><br></div><div>If Pidgin is not able to do accept file transfer (for large file sizes), am assuming it is because, for an Empathy to Pidgin,</div>
<div>SOCKS5 is used and in that case 'no candidates exchange' happens, so NAT problem isn't solved. And thus directly, the socket</div><div>establishment fails, thereby failing the file transfer (Please correct my understanding)</div>
<div><br></div><div>Thus, Pidgin has not implemented the '<a href="http://relay.google.com:80">relay.google.com:80</a>' style, for fetching credentials & stun ip/ports etc. So this</div><div>implementation isn't a standard right ?</div>
<div><br></div><div><br></div><div>Sorry for pressing on the same topic... jus wanted to clear if I had missed any crucial info on this forum... had been following</div><div>it regularly, but didn't find any post related to file transfer...</div>
<div><br></div><div>Best regards</div><div>Uday Kiran<br><div><br></div><div><br></div><div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br>---------- Forwarded message ----------<br>From: Youness Alaoui <<a href="mailto:youness.alaoui@collabora.co.uk">youness.alaoui@collabora.co.uk</a>><br>To: <a href="mailto:telepathy@lists.freedesktop.org">telepathy@lists.freedesktop.org</a><br>
Date: Wed, 20 Oct 2010 17:09:02 -0400<br>Subject: Re: [Telepathy] Doubt regarding Jingle file transfer over ICE<br>On 10/20/2010 10:10 AM, <a href="mailto:udayjandhyala@gmail.com">udayjandhyala@gmail.com</a> wrote:<br>
> Hi all,<br>
><br>
> I have a doubt about the way telepathy-gabble implements jingle file<br>
> transfer.<br>
> Please correct me if my below understanding is wrong :<br>
><br>
> - Basically for solving NAT problem, libnice is used<br>
> - As part of ICE protocol, for gathering 'candidate' transport<br>
> addresses, we need STUN / TURN servers<br>
> - for this purpose, why should telepathy-gabble trigger "<br>
> <a href="http://relay.google.com:80/create_session" target="_blank">http://relay.google.com:80/create_session</a> " ??<br>
><br>
> inside jingle-factory.c , libsoup APIs are used to make a HTTP GET<br>
> request to the above URL, with headers "X-Talk-Google-Relay-Auth" &<br>
> "X-Google-Relay-Auth"<br>
><br>
> In response, we get a list of TURN/STUN server IPs & Ports etc.<br>
You're right so far.<br>
Although we need STUN for candidate gathering, TURN is only necessary if there<br>
is no way to connect directly (both peers on symmetric NATs).<br>
<br>
><br>
> Instead of this method, why can't we use what the below XML Stanza returns :<br>
><br>
> Request stanza :<br>
> <iq type="get" to="<a href="mailto:user@gmail.com">user@gmail.com</a> <mailto:<a href="mailto:user@gmail.com">user@gmail.com</a>>"<br>
> id="135485202046"><query xmlns="google:jingleinfo"/></iq><br>
><br>
> Response stanza :<br>
> <iq to="<a href="http://user@gmail.com/16b4cb7b" target="_blank">user@gmail.com/16b4cb7b</a> <<a href="http://user" target="_blank">http://user</a>@<a href="http://gmail.com/16b4cb7b" target="_blank">gmail.com/16b4cb7b</a>>"<br>
> from="<a href="mailto:user@gmail.com">user@gmail.com</a> <mailto:<a href="mailto:user@gmail.com">user@gmail.com</a>>" id="135485202046"<br>
> type="result"><query xmlns="google:jingleinfo"><stun><server<br>
> host="<a href="http://stun.l.google.com" target="_blank">stun.l.google.com</a> <<a href="http://stun.l.google.com" target="_blank">http://stun.l.google.com</a>>" udp="19302"/><server<br>
> host="<a href="http://stun3.l.google.com" target="_blank">stun3.l.google.com</a> <<a href="http://stun3.l.google.com" target="_blank">http://stun3.l.google.com</a>>"<br>
> udp="19302"/><server host="<a href="http://stun2.l.google.com" target="_blank">stun2.l.google.com</a><br>
> <<a href="http://stun2.l.google.com" target="_blank">http://stun2.l.google.com</a>>" udp="19302"/><server<br>
> host="<a href="http://stun1.l.google.com" target="_blank">stun1.l.google.com</a> <<a href="http://stun1.l.google.com" target="_blank">http://stun1.l.google.com</a>>"<br>
> udp="19302"/><server host="<a href="http://stun4.l.google.com" target="_blank">stun4.l.google.com</a><br>
> <<a href="http://stun4.l.google.com" target="_blank">http://stun4.l.google.com</a>>"<br>
> udp="19302"/></stun><relay><token>CAESGwoSZjIwMDEwNjdAZ21haWwuY29tENbv0dG8JRoQmHtoMHjFafn/K0opvlnb0A==</token><server<br>
> host="<a href="http://relay.google.com" target="_blank">relay.google.com</a> <<a href="http://relay.google.com" target="_blank">http://relay.google.com</a>>" udp="19295"<br>
> tcp="19294" tcpssl="443"/></relay></query></iq><br>
<br>
That does give us the ip/port for the STUN and TURN servers, yes.. but the TURN<br>
server isn't a "free for all" server, it's a google server and only google users<br>
can use it. In order to use TURN, one must always authenticate to it first. It<br>
is done by adding a username/password to the STUN messages sent to the TURN server.<br>
For security reasons, the username and passwords to be sent must be randomly<br>
generated and have a short life (in short-term credentials mode, which is the<br>
only mode supported by google servers).<br>
In the XML stanza, there is no username/password, so the HTTP request being sent<br>
is in order to get that username/password needed to authenticate with the TURN<br>
server.<br>
If you look at the response we get, it doesn't only include stun and turn<br>
ip/ports, it also includes a username and a password. That U/P combination will<br>
only be valid if the "X-Talk-Google-Relay-Auth" header contains a valid<br>
authentication token (which is the one received in that stanza you mentioned).<br>
That U/P combination will also only be valid for 30 seconds, that's why it needs<br>
to be done right before requesting the TURN server to allocate a port for us.<br>
<br>
><br>
> Kindly point to me, if there is a different way to understand...<br>
<br>
I hope it answers your question. You can't do any different way to achieve this<br>
(the stanza contains the token to be used for the HTTP request, so it is the<br>
normal/expected/only way of doing it). Unless you set up a non-google TURN<br>
server (don't know if it's possible) and configure a username/password and have<br>
the server support long-term credentials authentication methods.<br>
<br>
p.s: why is it bothering you by the way ?<br>
<br>
Youness.<br>
<br>
><br>
> Regards<br>
> Uday Kiran<br>
><br>
><br>
><br>
> _______________________________________________<br>
> telepathy mailing list<br>
> <a href="mailto:telepathy@lists.freedesktop.org">telepathy@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/telepathy" target="_blank">http://lists.freedesktop.org/mailman/listinfo/telepathy</a><br>
<br>
<br>
<br>_______________________________________________<br>
telepathy mailing list<br>
<a href="mailto:telepathy@lists.freedesktop.org">telepathy@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/telepathy" target="_blank">http://lists.freedesktop.org/mailman/listinfo/telepathy</a><br>
<br></blockquote></div><br></div></div>