sounds good.
-Tim
Peter Saint-Andre wrote:
On 06/04/2008 10:47 AM, Tim Julien wrote:
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.
Maiku meant (1) -- he's trying to figure out how to design the UI in Pidgin.
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.
Right, that's what I'm suggesting -- if you share presence with someone
via presence subscription (which gets reflected in the rosteR), you
probably think it's ok to share IP addresses with that person for the
purpose of call setup.
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.
Where "clicked accept" means (1) from above.
However I would not necessarily restrict sending transport candidates to
situations where you have a presence subscription.
For instance in XMPP you can exchange messages with someone even if you
don't have a presence subscription. So you and I might have a message
chat like that. And then as we chat away, one of us says "hey let's
upgrade this message chat to voice chat". You know my full JID and I
know your full JID because we've been chatting, so if you send me a
voice chat request my client might automatically start sending
candidates to you because we have a live message chat going. And I think
that might be fine!
Now, I happen to think it is a best practice to share directed presence
(in the absence of a presence subscription) when you have a message chat
with someone who's not in your roster, so in XEP-0176 we could say that
it's OK to share candidates (and therefore IP addresses) before clicking
the big "accept this call" button with someone you share presence with
either through a formal subscription or through dynamic sharing of
directed presence.
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.
Tying this to presence sharing (formal or dynamic) seems OK to me.
Peter
