[jdev] GSoC 2012 XMPP-Jitsi project: JingleNodes and PseudoTCP

Dizhi Zhou q5frc at unb.ca
Sat Mar 24 16:15:16 UTC 2012


Hi Emil,

Thanks for your reply!  The further discussion is shown below:

On 2012/3/24 11:06, Emil Ivov wrote:
> Hey Dizhi,
>
> On 22.03.12 20:58, Dizhi Zhou wrote:
>> Dear mentors,
>>
>> I'm very interested for the JingleNodes and PseudoTCP projects in
>> XMPP-Jitsi becaues both of project are very close to my current
>> research area -- TCP optimization for video delivery in wireless
>> network.
> Glad to hear about your interest!
>
>> In the past few days, I read lots of
>> background documents about these two projects and here are some ideas I
>> have now.
> That's the spirit!
>
>> 1, JingleNodes
>> Here are my reading list in the past week: XMPP core framework(RFC
>> 3920), Jingle(XEP-0176), ICE-UDP(XEP-0278),
>> Jingle ICE-UDP transport protocol(RFC 3920), STUN (RFC 5389) and TURN
>> (RFC 5766).
> You'd probably want to have a look at the Jingle Relay Nodes XEP as well:
>
> http://xmpp.org/extensions/xep-0278.html
>
>> Based on this, I have a deeper understanding about XMPP and Jingle
>> structure. My understanding is that Jingle relay node
>> can be seen as the XMPP version of TURN/STUN relay server.
> That's the idea yes.
>
>> Therefore,
>> XMPP client can do the NAT traversal without STUN/TURN
>> support.
> Not quite. Ideally clients would first try to connect directly or
> through things like STUN. Jingle Relay Nodes (as well as any other form
> of relaying) would only be used as a fallback.
>
>> In other words, Jingle relay node implement NAT traversal
>> function within XMPP, but keep the media data transmission
>> out of XMPP which follows the design goal of Jingle.Also, because
>> transport address gathering is down in Jingle relay node scheme,
>> can we say that Jingle ICE-UDP transport method  and Jingle relay node
>> together implement a XMPP version of ICE UDP protocol?
> I am not sure I understand this question. If you are asking whether
> Jingle Nodes could be used together with XEP-0177, then yes, that's
> possible.
The question is: if a XMPP client uses Jingle ICE-UDP transport method 
and Jingle UDP relay node
together, can this XMPP client achieves functions as same as IETF ICE 
UDP protocol. In other words,
the XMPP version of ICE UDP protocol is consisted of two parts, Jingle 
ICE-UDP transport method
and Jingle UDP relay node. Is that the current relationship between 
those conepts?

>
>> Follow this logic, I have a rough idea for developing JingleNode:
>>    1), first, we need to develop Jingle ICE-TCP transport method
>> extension for XMPP, just like the Jingle ICE-UDP transport method for UDP
>>         traffic in XMPP.  With this month, ICE-TCP became an IETF RFC(
>> http://tools.ietf.org/html/rfc6544 ). I'm not sure whether XMPP
>>        has the plan for combining this new transport method into its
>> extensions.  If it doesn't, I think we need to do this first before
>>        developing Jingle relay node.
>>
>>    2), second, we can extend the current JingleNode for UDP to TCP. I
>> will check  details of this part from code in jinglerelay.org
>>
>> I will very appreciated if you can give further comment on this rough idea.
>>
>> 2, PseudoTCP:  this is another project I'm interested to. Right now, I'm
>> the documents on this part. The question here is whether I
>>      can apply two projects for one orgnization under GSoC or not? If
>> not, I will select one project which I have most clear idea to apply.
> That's interesting. We'll be looking forward to seeing your suggestions
> on google-melange, once the application period opens, and we'll then
> continue the discussion there.
>
> Cheers,
> Emil
>> Looking forward for your reply.
>>
>> Best regards
>> Dizhi
>>
>> -- 
>> Dizhi Zhou
>> Ph.D. Candidate
>> Faculty of Computer Science
>> University of New Brunswick
>> 540 Windsor Street
>> Fredericton,New Brunswick,Canada
>> E3B 5A3
>>
>> E. q5frc at unb.ca
>> Homepage: www.cs.unb.ca/~q5frc/
>>
>>
>>
>> _______________________________________________
>> JDev mailing list
>> Info: http://mail.jabber.org/mailman/listinfo/jdev
>> Unsubscribe: JDev-unsubscribe at jabber.org
>> _______________________________________________

Best regards
Dizhi

-- 
Dizhi Zhou
PH.D Candidate
Faculty of Computer Science
University of New Brunswick
540 Windsor Street
Fredericton,New Brunswick,Canada
E3B 5A3

E. q5frc at unb.ca
Homepage: www.cs.unb.ca/~q5frc




More information about the JDev mailing list