[standards-jig] more thoughts on voip

Vapor vapor at 66oc.org
Wed Feb 12 03:21:45 UTC 2003

That sounds really good.  So maybe I am beating a dead horse, but I just get the feeling that we are inches away from being able to implement voice but we just havent taken that step to actually do it.  The proxy for voice sounds great, but I guess the rest of my idea with bandwidth throttling and informing the client of an available "slot" would be implementation specific, and may be able to be done by the component/proxy sending a message to the clients involved if no "slots" are available so to speak.

For the proxy service, bandwidth may end up presenting a roadblock.  What if the connectivity to the server is setup using a proxy service but they dont want to allow voice through due to bandwidth restrictions.  What if I use NAT to connect to my jabber server but dont have proxy setup.  I guess I should ask, is the current plan to allow oob setting to be specified as to whether it is proxy or not?


----- Original Message ----- 
  >From: Richard Dobson 
  To: standards-jig at jabber.org 
  Sent: Tuesday, February 11, 2003 8:54 PM
  Subject: Re: [standards-jig] more thoughts on voip

  This kind of thing is already being worked on (i.e. proxy connections), there is no point doing special proxying for VoIP since the stuff being worked on should handle it. IMO VoIP support in jabber should be as simple as possible and just be in effect a simple handshake (no point in having any proxy stuff at VoIP level since it doesnt need to be and can be handled by the appropriate mechanisms already mentioned, also the type of link between the two parties should be transparent at the VoIP handshake level, all it needs are the ip:port to connect to wether that be p2p or proxied if designed correctly it shouldnt need to know that).

  On Wednesday, February 12, 2003, at 02:32 am, Vapor wrote:

    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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030211/d66c9051/attachment.html>

More information about the Standards mailing list