Peter Saint-Andre wrote:
On 06/03/2008 2:14 PM, Maiku wrote:
In XEP-0176, Jingle using the ICE-UDP transport method, it says for
the initiator to send out the transport candidates either as soon as
getting the ACK from the session-initiate message or just as soon as
sending the session-initiate message, but I can't seem to find any
place that mentions where the responder's client would wait for the
responder to actually click to accept the session. Where would this
happen? Would the responder wait to send transport-info packets until
the user actually accepts? If not, wouldn't that be a security issue,
sending out your IP address to anyone who tries to start a session
with you?
Maiku and I chatted about this via IM just now. I think it would make
sense for the client to have a configuration setting such as "it's OK to
share my personally identifying information (such as my network
location) with people who can see my presence" [yeah yeah yeah that's
long, shorten it as necessary!]. So if you share presence, your client
will ack the session-initiate, return a ringing message, and start
sending candidates. If you don't share presence, you would ack and send
ringing but not share candidates until the user accepts the negotiation.
Thoughts?
One meta point that I think will help me understand (and Paul Witty, I
think) is:
When you say "The user accepts the session", do you mean:
1) user clicks an "accept" button b/c the phone is ringing.
2) the session-accept message is sent.
3) both 1) and 2)
That question aside, a few thoughts.
Could we have a compromise where if someone is in your roster we assume
a certain amount of trust, and go ahead and exchange transport-info
before the call is accepted. And in the case where an incoming call is
from someone not in your roster, you delay sending transport-info until
the user has clicked accept. This would cut down on options / config.
It feels like this option won't be understood by your average user, plus
it seems like the only benefit is to slightly optimize transport
negotiation. Is it really worth the cost in spec. complexity,
implementation complexity, and user mind-share to configure the option?
I would say no, and if it really is a security concern, lets just err
on the side of being more secure and pick one way of doing it.
-Tim
Peter
