[standards-jig] more thoughts on voip

Vapor vapor at 66oc.org
Wed Feb 12 02:32:57 UTC 2003


I have been thinking a bit more on having and XMPP based protocol for VoIP.  Here is one of my ideas why.  I think it would be useful if the jabber server had the option, or if the client had the option to use the jabber server as a man-in-the-middle for VoIP communications.    If or when initiating the call the client can select to use a server as a relay point for the RTP stream.  This doesnt have to be handled on a single server but could be offloaded to a server dedicated for voice communications.

Here is my thinking.  ClientA sends a chat request to ClientB, in it is the desire to communicate using either P2P OOB or a central relay for the OOB voice communication.  ClientB can accept or deny, or let the request timeout.  In the request is the ip address of the man-in-the-middle server and the ports available to connect on.  Both then initiate voice communications with the server and the server handles relaying the voice between the two.

The server could then specify the bandwidth avaible for each conversation, and the total number of man-in-the-middle sessions allowed.  The server could then inform the clients if there is space available, and then reserve that space when a chat request is made.  This could satisfy the problem of not enough bandwidth, as well as allowing for p2p voice.  It could potentially satisfy the concerns on both sides.  Clients can do peer to peer or if they are behind NAT they can just use the man-in-the-middle server.

Even security could be set on the jabber server to allow, deny, or require man in the middle voice.

AKAIK this kinda capability is not allowed in sip or h.323 but I honestly havent really looked into it.  The voice could be built as a separate component, but it would be nice to have it officially JEPd.

Vapor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030211/55b4eb14/attachment.html>


More information about the Standards mailing list