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.
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:
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:
Over and out....
/zool
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 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