[Telepathy] telepathy Digest, Vol 59, Issue 17

Thu Oct 21 21:55:23 PDT 2010

Hi Youness

Thanks for a prompt reply!

Basically, I started debugging when my Empathy client is not being able to
send files with large size
(I tried sending a 3.5 MB file to another friend within the NAT), to a
Pidgin client. Then we tried transfer
using both Empathy clients, then it worked... In due course, I was stuck
with many doubts...

*Doubt 1 :*

What am keen to know, is according to which XEP is the current 'file
transfer' implemented in latest
telepathy-gabble ? I can't assume it is XEP - 0234 ... since from whatever
XML stanzas are exchanged,
between the two clients, no 'Jingle' namespace is found.

Moreover, 'candidates exchange' is also done differently
compared to what XEP 234 mentions... (candidates are informed in the
session-initiate stanza itself). Is it because
this XEP doesn't talk about the NAT problem ?

XEP 176 talks about Jingle & ICE-UDP transport, but telepathy-gabble doesn't
follow that either...

I see stanzas as below :

<iq type="set" to="my_friend at gmail.com/7e4881de" id="2196244687"><session
initiator="my_username at gmail.com/16b4cb7b" id="1515877176" type="initiate"
xmlns="http://www.google.com/session"><description xmlns="
http://www.google.com/session/share"><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="http://www.google.com/transport/p2p"/></session></iq>

In a series of function calls, I saw that relay.google.com:80 has been used.
But according to which XEP/Standard
published, this kind of methodology is used ? Or is it Google's prescribed
way at present, which will soon be standardized ?
Because, until you had explained very vividly, I couldn't find that info in
any XEP or document related to XMPP.

*Doubt 2 :*

If Pidgin is not able to do accept file transfer (for large file sizes), am
assuming it is because, for an Empathy to Pidgin,
SOCKS5 is used and in that case 'no candidates exchange' happens, so NAT
problem isn't solved. And thus directly, the socket
establishment fails, thereby failing the file transfer (Please correct my
understanding)

Thus, Pidgin has not implemented the 'relay.google.com:80' style, for
fetching credentials & stun ip/ports etc. So this
implementation isn't a standard right ?

Sorry for pressing on the same topic... jus wanted to clear if I had missed
any crucial info on this forum... had been following
it regularly, but didn't find any post related to file transfer...

Best regards
Uday Kiran

>
> ---------- Forwarded message ----------
> From: Youness Alaoui <youness.alaoui at collabora.co.uk>
> To: telepathy at lists.freedesktop.org
> Date: Wed, 20 Oct 2010 17:09:02 -0400
> Subject: Re: [Telepathy] Doubt regarding Jingle file transfer over ICE
> On 10/20/2010 10:10 AM, udayjandhyala at gmail.com wrote:
> > Hi all,
> >
> > I have a doubt about the way telepathy-gabble implements jingle file
> > transfer.
> > Please correct me if my below understanding is wrong :
> >
> > - Basically for solving NAT problem, libnice is used
> > - As part of ICE protocol, for gathering 'candidate' transport
> > addresses, we need STUN / TURN servers
> > - for this purpose, why should telepathy-gabble trigger "
> > http://relay.google.com:80/create_session " ??
> >
> > inside jingle-factory.c , libsoup APIs are used to make a HTTP GET
> > request to the above URL, with headers "X-Talk-Google-Relay-Auth" &
> > "X-Google-Relay-Auth"
> >
> > In response, we get a list of TURN/STUN server IPs & Ports etc.
> You're right so far.
> Although we need STUN for candidate gathering, TURN is only necessary if
> there
> is no way to connect directly (both peers on symmetric NATs).
>
> >
> > Instead of this method, why can't we use what the below XML Stanza
> returns :
> >
> > Request stanza :
> > <iq type="get" to="user at gmail.com <mailto:user at gmail.com>"
> > id="135485202046"><query xmlns="google:jingleinfo"/></iq>
> >
> > Response stanza :
> > <iq to="user at gmail.com/16b4cb7b <http://user@gmail.com/16b4cb7b>"
> > from="user at gmail.com <mailto:user at gmail.com>" id="135485202046"
> > type="result"><query xmlns="google:jingleinfo"><stun><server
> > host="stun.l.google.com <http://stun.l.google.com>" udp="19302"/><server
> > host="stun3.l.google.com <http://stun3.l.google.com>"
> > udp="19302"/><server host="stun2.l.google.com
> > <http://stun2.l.google.com>" udp="19302"/><server
> > host="stun1.l.google.com <http://stun1.l.google.com>"
> > udp="19302"/><server host="stun4.l.google.com
> > <http://stun4.l.google.com>"
> >
> udp="19302"/></stun><relay><token>CAESGwoSZjIwMDEwNjdAZ21haWwuY29tENbv0dG8JRoQmHtoMHjFafn/K0opvlnb0A==</token><server
> > host="relay.google.com <http://relay.google.com>" udp="19295"
> > tcp="19294" tcpssl="443"/></relay></query></iq>
>
> That does give us the ip/port for the STUN and TURN servers, yes.. but the
> TURN
> server isn't a "free for all" server, it's a google server and only google
> users
> can use it. In order to use TURN, one must always authenticate to it first.
> It
> is done by adding a username/password to the STUN messages sent to the TURN
> server.
> For security reasons, the username and passwords to be sent must be
> randomly
> generated and have a short life (in short-term credentials mode, which is
> the
> only mode supported by google servers).
> In the XML stanza, there is no username/password, so the HTTP request being
> sent
> is in order to get that username/password needed to authenticate with the
> TURN
> server.
> If you look at the response we get, it doesn't only include stun and turn
> ip/ports, it also includes a username and a password. That U/P combination
> will
> only be valid if the "X-Talk-Google-Relay-Auth" header contains a valid
> authentication token (which is the one received in that stanza you
> mentioned).
> That U/P combination will also only be valid for 30 seconds, that's why it
> needs
> to be done right before requesting the TURN server to allocate a port for
> us.
>
> >
> > Kindly point to me, if there is a different way to understand...
>
> I hope it answers your question. You can't do any different way to achieve
> this
> (the stanza contains the token to be used for the HTTP request, so it is
> the
> normal/expected/only way of doing it). Unless you set up a non-google TURN
> server (don't know if it's possible) and configure a username/password and
> have
> the server support long-term credentials authentication methods.
>
> p.s: why is it bothering you by the way ?
>
> Youness.
>
> >
> > Regards
> > Uday Kiran
> >
> >
> >
> > _______________________________________________
> > telepathy mailing list
> > telepathy at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/telepathy
>
>
>
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20101022/f080e790/attachment.html>