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

[Emil Ivov]

Hey Dizhi,

On 24.03.12 17:15, Dizhi Zhou wrote:
> 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?

Not exactly. ICE is the protocol the allows you to test different
connection possibilities between peers. Jingle Relay Nodes are just one
such possibility and there are many others.

You can use ICE with XMPP with or without Jingle Nodes and vice versa.
In other words, one is not really an alternative to the other.

In case you'd like to learn more about ICE then you may want to have a
look here:

http://tools.ietf.org/html/rfc5245

Hope this helps,
Emil
> 
>>
>>> 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
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho at jitsi.org                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31