[Standards-JIG] RE: Standards-JIG Digest, Vol 13, Issue 8

[Jean-Louis Seguineau]

Well as someone said in the thread, doing real voice (or video)
communication requires a lot of work... And this work has already been done
by the folks that have come up with the current VOIP implementations.

There are two approaches, one which consist in discarding the current state
of the art as being irrelevant or not invented here, and XMPP will never be
a player in the VOIP space, or leverage the existing technology and come up
with a faster and simpler implementation of the signaling that is MANDATORY
to create a proper voice service. 

As to the advantage of moving the signaling to XMPP, it is straightforward:
if we have an XMPP session, we have already an established connection
between any two endpoints present in one's roster. In this case, why would
you use anything else to transport the signaling? Do we want to have the
same client open a SIP connection in addition to the XMPP one just for the
sake of transporting SDP and negotiate a call? In the end, the voice will be
carried over RTP/UDP, not XMPP or SIP. The goal is to negotiate and create
that connection. If XMPP already provides a communication link, then just
use it. And look at the opened possibilities when adding this negotiation to
MUC. SIP is years out of having a proper conference set-up. If we were to
add SDP SI negotiation inside MUC, we could turn any MUC text server into a
voice conference negotiator.

Hope this helps picture out the possibilities

Best

Jean-Louis

-----Original Message-----

Message: 5
Date: Wed, 9 Feb 2005 10:14:02 -0500
From: "Stephen Pendleton" <spendleton at movsoftware.com>
Subject: RE: [Standards-JIG] VoIP Jabber
To: <standards-jig at jabber.org>
Message-ID: <002401c50eb9$fd45b5f0$6401a8c0 at movsoftware.com>
Content-Type: text/plain;	charset="us-ascii"

Yes, I agree with the URI point. There is no new protocols needed in this
scheme, just a URI exchange (you mentioned this about a year ago I think).

<iq id="1" to="foo at bar.com/resource" type="set">
<query xmlns="jabber:iq:oob">
<url> 
callto:fred 
</url>
</query>
</iq>

I also read Jean-Louis input on the topic and he is suggesting moving the
signaling into XMPP using SDP as a basis for implementation and RTP for the
datastreams. I am not familiar with the underpinnings VoIP so I cannot
comment. 

A question I have is what is the advantage of moving the signaling into
XMPP, when the VoIP client/module software already handles all that? Does it
make it more interoperable with other systems, or are there additional
benefits?

Thanks

-----------------
> I am saying that you can do it now with the current protocols (use 
> either disco or use a custom IQ namespace query to obtain the endpoint 
> address and then launching an external VoIP client).

Exactly but the point I am trying to get across is if all this new fangled 
protocol is going to do is send a voip uri then there is no need to even 
create it as we have that capability now without anything new, we have 
jabber:iq:oob and jabber:x:oob for transferring URI's, so I still fail to 
understand the need for a new protocol unless it is going to do something 
else for us over and above something we can already do anyway.