Wednesday, August 29, 2007

NAT and STUN..

Threading is almost like done now, and the synchronization of the GUI, the voice threads and the protocol backend seems to work out fine now.
Actually we have been looking at the NAT/STUN area for a while now. Most of it in theory we have been looking at NAT traversal techniques etc.

  • STUN (for getting the public IP and port)
  • UPnP (xml webservice from and to the router)
  • TURN
  • ICE (which is a specific combination of some of the techniques above)
But for the code matters, we have been trying to use the already implemented STUN API in pidgin (stun.c, stun.h, network.c, network.h). We found that some of the stuff have the possibility to get the public IP and the ability to listen and maybe punch hole from inside out of the router. Right now we have patched it go set and get the port for the STUN server when connecting to it. At the original implementation it was hardcoded to the "normal" STUN server port (UDP port 3478). Googles STUN servers listening on UDP port 19xxx.

But when we find out if we should expand and patch the pidgin STUN API or not (I think we shall), then we should be able to get voice through our pidgin, even if they are behind NAT!. This means that we will get the correct IP addresses to send via. XMPP, to have punched a hole in the NAT and finally also have advertized the correct public IP and port. We also made the XMPP/GTalk implementation of STUN discovery, which is documented here:

  • http://code.google.com/apis/talk/jep_extensions/jingleinfo.html
  • http://www.xmpp.org/extensions/xep-0215.html

This worked fine, we got all the google STUN servers when requesting. We also here found out, that they used another port, than the usual STUN servers (look earlier statement).

Damn I am looking forward to these coming weeks!...

But when this "small" problem is fixed we still have a long way to go, we still need the functionality of:

  • Be able to see a busy signal of the line (and a busy dial tone, ha ha).
  • To hold a line through the GUI (if you dont have time just now)
  • Implement OTR (of the record, and store a voice mail in google mail)
  • implement ID in the xmpp/gtalk. We need this in order to have complete control, if more than one is calling etc.

  • fix small bugs, when hanging up, making more than one call
  • make detailed description (XEP-xxx) of new voice conferingcing. This is not a XEP yet. We have to make it.
  • make video implementation! ;-)
  • A lot more, I cant remember..

Over and out....
/zool

Friday, August 24, 2007

Threading

The last to days have been spent on studying and implementing pthreads to our code. We need this to open a voice connection - while the rest of Pidgin keeps running.

Since it can be attempted to open several calls, or people can attempt to call you while in conversation, we must control the threading.
For now we have decided to spawn a maximum of 1 voice_client thread and 1 voice_server thread. That means we must make sure that we do not spawn to many threads, and that we notify where appropiate when a new call can not be done... (But what about calls on hold and conferencing... save that for later ;o) )

It seems to be working and synchronized using signals with the core of the plugin.

Wednesday, August 22, 2007

Sounds better

Besides all the official work (see previous post) - we have worked a lot on the code lately.

- We have incorporated our GStreamer code into our plugin. And we have got some sound voice through on our local network using hardcoded ip addresses. On the way we have had some include file problems, which seems to be over for now.
We have some bugs in GStreamer which we have to attend to and we still need to look at those IP-address problems. The GStreamer code is currently being synchronized with the XMPP code using signals.
- Lately we have researched NAT a lot, to address the IP problems.
- We have split up the GUI from the rest of the code even more - using signals. More is still to be done here...

Delivery Date

Now it has been settled. The 14th of March we have to be done with this master thesis.
Actually we aim to finish before the Winter holiday mid February.

(Before) Next week we will set up some milestones for the project.

Sunday, August 12, 2007

Some Problems solved..

Hey Again,

The problems we had with gstreamer and using its elements are now solved. We had problems with the voice comming through the RTP protocol. That was actually because that the RTBbin that we used was been obsolete and deprecated. Now we use udpsrc etc. (see the source code), which acutally make the voice go through over RTP!. *GREAT!*
Now we are only missing to incoorporate it into our plugin code. This is not done yet because of some heavy research regarding NAT and getting the public IP address.

As I (zool) spend last week of researching how to bypass the NAT, I have found some mechanisms which I only will mention briefly here. I have also writte a section in the report about the same area:

*STUN
*TURN
*UPnP
*ICE
....

But better yet I found that google (gtalk) and xmpp finally have something in common now. This is pretty new I think:

http://www.xmpp.org/extensions/xep-0215.html
http://code.google.com/apis/talk/jep_extensions/jingleinfo.html

These links show how STUN servers are found via. XMPP. After we have found the server list, we can connect (Via. a STUN client) with one of them. The one thing I dont get is that I have seen many places that states that gtalk is using ICE. I have to investigate further than this. **13/8-2007* The day after (today), I already found out of the context of ICE. ICE is the technique for using STUN for getting the public IP addr. and using TURN for data traversal through nat.

I talked (via. IRC, #pidgin) with a lot of the developers for the pidgin platform, which have connections to the xmpp organization (Sean Egan, utopia etc), and found out that no standard or draft papers are available for conferencing of voice or video. There for now I am involved in making findings of already available software in this area, and find out what kind of demands that can be put. After this I will write a XEP-### for the draft papers.!!! Jubiii, we can be official xmpp developers.. .*GREAT*!...

Well thats all for now!

10-4
/zool (Steffen)