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. > 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 > _______________________________________________ -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi em...@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
