[Standards-JIG] VoIP Jabber

[Justin Karneges]

I believe iChat just exchanges IP address information over Jabber and then 
does a direct SIP request.  To answer Richard's question: there is no support 
for reverse initiations as far as I can tell (I had to poke some holes in my 
firewall to receive a stream), and both sides must be open in order to get 
bi-directional streaming.

-Justin

On Tuesday 08 February 2005 03:20 pm, Stephen Pendleton wrote:
> 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). Let the VoIP client worry about
> the negotiation and VoIP details and bytestreams. I am not sure how apple
> implemented theirs, but I am assuming that they only interoperate with
> their VoIP module (which they already had developed). I am also not sure if
> what people are suggesting that we move an entire VoIP architecture into
> XMPP, or just the signaling part. If you just move the signaling part in,
> what is going to do the VoIP (bytestream, QoS? I am not sure of all the
> VoIP issues to be honest.) Does anyone know exactly how Apple does it?
>
> Thanks
>
>
> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Richard Dobson
> Sent: Tuesday, February 08, 2005 5:35 PM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] VoIP Jabber
>
>
> The problem with this that I can see is that if all it will be providing is
> a voip address then whats the point of defining a new protocol to do that
> when we can already do that now (jabber:iq:oob/jabber:x:oob), to be worth
> creating a new protocol it needs to do a bit more than simply returning an
> voip IMO.
>
> The solution apple developed (or a derivation there of) that Rachel and
> others have mentioned sounds far more promising and useful to me, hopefully
> they have solved the negotiation problems where say only one of the 2 users
> in a conversation can accept incoming connections (and reverse the
> connections so a connection can be established by either party, which the
> simple address scheme does not solve on its own), we might even conceivably
> be able to add bytestreams support to their protocol.
>
> Richard
>
> ----- Original Message -----
> From: "Stephen Pendleton" <spendleton at movsoftware.com>
> To: "'Jabber protocol discussion list'" <standards-jig at jabber.org>
> Sent: Tuesday, February 08, 2005 6:33 PM
> Subject: RE: [Standards-JIG] VoIP Jabber
>
>
> I agree with the overall approach and think that using disco to discover
> the destination address (IP/port, skype address, etc) is the right way to
> go for the long term. Trying to (re)implement an entire VoIP architecture
> seems pointless to me. There are plenty of software components that already
> do the VoIP part. For the short term, the IQ query method works well. Thats
> actually how I originally implemented it, because disco wasn't available.
>
> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Heiner Wolf
> Sent: Tuesday, February 08, 2005 12:28 PM
> To: Jabber protocol discussion list
> Subject: RE: [Standards-JIG] VoIP Jabber
>
>
> Hi,
>
> Since we hear the question every other week, maybe it is time to make up an
> answer that might even evolve into a JEP some day.
>
> ...
> We should now define protocol elements to request a VoIP address from a
> peer. I don't know yet whether it is: 1. a new part of old vcard 2. a
> disco-ed pubsub node 3. a new iq namespace 4. a message with x-tension and
> namespace 5. something else
>
> To set things in motion:
> My favorite is good old public xml storage. I propose to invent a namespace
> for an <iq>-<query/>, like:
>   <iq type='get' to='juliet at capulet.com'>
>     <query xmlns='http://jabber.org/protocol/voip' />
>   </iq>
>
> This works with jabberd1.4, is easy to implement in clients and can easily
> be added to jabberd2 and ejabberd, just to mention some. The result would
> be a list of connection addresses (probably URIs) in the order of
> preference. Maybe formatted in JEP-0068: Field Standardization for Data
> Forms. ...
>
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mail.jabber.org/mailman/listinfo/standards-jig
>
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mail.jabber.org/mailman/listinfo/standards-jig
>
>
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mail.jabber.org/mailman/listinfo/standards-jig