[jdev] Gaim and gnomemeeting using jabber

Richard Dobson richard at dobson-i.net
Thu Dec 2 08:02:43 CST 2004

> I tried it with:
> * patched gaim ;
> * unpatched gaim ;
> * gossip.
> My patched gaim didn't seem to give any headache to either of the
> innocent clients...

Not much of a test, if thats all you tested then you cannot really state 
that you have tested it and it causes no problems, do those clients even 
support JEP-0066 anyway? You need to do a proper test testing all clients 
available to be able to say its tested and doesnt cause any problems, 
certainly the major ones such as Psi, Exodus, Pandion, Trillian and Gabber. 
The problem you will create in any clients that already support URIs in the 
format you are trying to use is that they will probably prompt the user 
asking them if they want to call you when you log on, which is IMO not a 
desirable behaviour.

> Notice that I fail to see the huge security gain between:
> 1) exporting the voip uri right away ;
> 2) exporting the voip feature, and giving the corresponding uri on
> request.

Because only people you are specifically accepting calls from will get the 
URI, whereas with your method just about anybody can yet your URI, including 
other people in chat rooms, why can you not see that as an obvious huge 
difference???, its the difference between giving it to one person and giving 
it to 500, thats a huge difference IMO.

> I don't see very well what should go one way and the other ; could you
> write a mockup (like I did to show what the patch I have does)?

Have a look at the bottom of this email.

> Why do I always have the impression that you think having the voip uri
> gives anything to anyone? You know, a typical voip uri is much like a
> jabber uri: it tells you to which server you have to ask for whom ; for
> example: "h323:ils.seconix.com/that.user at you.know" . That doesn't
> generally give you an ip, but just a mean to find it out.

Because they can find it out when they are someone not in a call with you 
(i.e. someone you have not specifically accepted a call request from) then 
its the same difference as if you had just put the IP right into the URI, I 
find this strange that you cannot see this extremely obvious potensially 
serious security hole which is very easily mitigated.

> Once you have a voip-uri:
> * your client must ask the server for your ip (and the server can
> refuse!) ;

It could but in my experience such servers do not refuse and just give the 
address out to anyone who asks, either that or they just require a logon 
which once you have it allows you to get the addresses of anyone on that 

> * your client must connect to your voip-client (and you may refuse!).

As I have already explained (and you seemed to agree to), once you have the 
IP of the other persons machine the damage is done and no voip client will 
protect you against people hacking your machine, a very simple and extremely 
effective defence against this is to not just simply broadcast your IP to 
everyone and only give it to people when they request to call you, infact 
the solution after thinking it through properly for your example means that 
you never reveal you ip, only the caller does which is IMO the correct way 
around to do it (and even more secure that I have previously mentioned), it 
also has the major benefit of not having to have your voip client running to 
be able to accept voip call requests via jabber, also the correct way to do 

> Yes, a mockup client-client discussion would be nice.

Ok then here you go:

Task 1) Communicating voip capability

1) A client requests your disco info

<iq type='get'
    from='juliet at capulet.com/balcony'
    to='romeo at montague.net/orchard'
  <query xmlns='http://jabber.org/protocol/disco#info'/>

2) Your client responds including voip feature in the response

<iq type='result'
    from='romeo at montague.net/orchard'
    to='juliet at capulet.com/balcony'
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='jabber:iq:time'/>
    <feature var='jabber:iq:version'/>
    <feature var='http://jabber.org/protocol/voip'/>

Simple as that now other clients know that your client is voip capable.

Task 2) agreeing on voip protocol and communicating uri

1) Requesting entity starts voip protocol negotiation, sending a list of 
protocols it supports.

<iq type='get'
    from='juliet at capulet.com/balcony'
    to='romeo at montague.net/orchard'
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='list-single' var='http://jabber.org/protocol/voip'>

2) Responding entity sends preferred values (this is telling the requestor 
which uri format to use).

<iq type='result'
    from='romeo at montague.net/orchard'
    to='juliet at jabber.org/balcony'>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='http://jabber.org/protocol/voip'>

3) Requesting entity then sends the uri for the responding entity to call 
should it wish to, this is far more secure and works in reverse to the way 
your scheme does, only the caller reveals their details. It also means voip 
calling will work if you do not have your voip client running as if its not 
running you can just start it up, whereas with your solution you have to 
have it running the whole time, this solution is far more inline with jabber 
and is far more likely to work with other clients correctly, and possibly 
work with some clients without modification, i.e. some clients already 
support callto URIs.

<iq type='set'
    from='juliet at jabber.org/balcony'
    to='romeo at montague.net/orchard'
  <query xmlns='jabber:iq:oob'>
    <desc>VoIP call</desc>

4) Recipient Informs Sender of Success.

<iq type='result'
    from='romeo at montague.net/orchard'
    to='juliet at jabber.org/balcony'

I would highly urge you to implement voip using this method as it is the 
most likely method to work correctly and be backwards compatible with other 


More information about the JDev mailing list