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/[EMAIL PROTECTED]" . 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 server.
* 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 it.
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='[EMAIL PROTECTED]/balcony' to='[EMAIL PROTECTED]/orchard' id='info1'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
2) Your client responds including voip feature in the response
<iq type='result' from='[EMAIL PROTECTED]/orchard' to='[EMAIL PROTECTED]/balcony' id='info1'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='client' type='pc' name='Exodus'/> <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'/> </query> </iq>
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='[EMAIL PROTECTED]/balcony' to='[EMAIL PROTECTED]/orchard' id='neg1'> <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'> <option><value>h323</value></option> <option><value>sip</value></option> <option><value>callto</value></option> </field> </x> </feature> </iq>
2) Responding entity sends preferred values (this is telling the requestor which uri format to use).
<iq type='result' id='neg1' from='[EMAIL PROTECTED]/orchard' to='[EMAIL PROTECTED]/balcony'> <feature xmlns='http://jabber.org/protocol/feature-neg'> <x xmlns='jabber:x:data' type='submit'> <field var='http://jabber.org/protocol/voip'> <value>callto</value> </field> </x> </feature> </iq>
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='[EMAIL PROTECTED]/balcony' to='[EMAIL PROTECTED]/orchard' id='oob1'> <query xmlns='jabber:iq:oob'> <url>callto:192.168.103.77+type=ip</url> <desc>VoIP call</desc> </query> </iq>
4) Recipient Informs Sender of Success.
<iq type='result' from='[EMAIL PROTECTED]/orchard' to='[EMAIL PROTECTED]/balcony' id='oob1'/>
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 clients.
Richard
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mail.jabber.org/mailman/listinfo/jdev
