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. q5...@unb.ca
Homepage: www.cs.unb.ca/~q5frc/
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@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. q5...@unb.ca
Homepage: www.cs.unb.ca/~q5frc
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
_______________________________________________
