Idea: Signalling protocol for SF calls?

The main problem with NAT and establishing the calls in general is the
signalling protocol. (Disclaimer: I am not a telco tech, so my terminology
usage may be inaccurate.)

All we need is to get the two calling parties in contact with each
other, getting them to exchange their IP addresses and eventual other
informations (NAT in use, ports if not default, prefered codecs if not
default, encryption keys, etc).

However, there is complete infrastructure for this purpose already in
place - Jabber network. An open-source IM protocol with clients for every
reasonably possible platform, with distributed architecture, independent
on one central server - everybody can run their own server, and there is a
plethora of public servers out there as well.

What I propose is to offload the call-establishing process into a separate
program (or module), which would be a de-facto Jabber client; a call
request then technically becomes a chat request to the JabberID of the
called party. Which, after receiving the message, tells back if the phone
is already in use (and optionally allows leaving text or voice message),
or announces that the other side is ready to receive the call, what
IP:port it resides on, prefered codec, crypto use, SSL certificate for
identity proof, NAT-piercing strategy to use, etc). After successful
negotiation, the call-handling programs on both sides launch SpeakFreely
as the VoIP engine itself, with the proper parameters.

Optionally, it could be possible to share Jabber ID for both the
SpeakFreely calls and regular chats, if the SpeakFreely client would use a
magic string in its messages, and act as a passthrough proxy for all
others.

The Jabber messages are chunks of text wrapped in XML. We can either ask
for a Jabber protocol extension for this purpose, or use eg. quoted XML
(for structured data) or BASE64-encoding (for binary data, like eg. SSL
certs or D-H key exchange, or encrypted structured data), looking to the
servers like "normal" text.

As another advantage, we have online-offline indication for the phonebook,
answering machine when offline (server-stored messages), and all other
goodies of Jabber protocol, without our own work.

Yet another possibility may be client autoconfiguration. For this, a test
server on a known-good machine is necessary. After requesting connection
over Jabber, the test server responds and the client runs a modified
SpeakFreely engine (actually just a packet generator/receiver, sending out
UDP packets as instructed over Jabber, and reporting over Jabber the
packets received). The test server then runs a set of standardized tests,
determining eventual NAT in place and its capabilities, reporting them
back to the client.

Opinions, comments, why it won't work?


                      * * *

To unsubscribe from this mailing list, send E-mail containing
the word "unsubscribe" in the message body (*not* as the
Subject) to [email protected]