Hi all,
I think this thread has been a useful discussion on various topics
related to conferencing, chat, anonymity, nicknames, display names,
sidebars and private messages. Let me try to list my opinions on the
different points:
1. "Nicknames" are not specific to MSRP conferences, but can be
applied to any type of conferences. There should be more clarity how
to convey them in conference-info and in various media transports.
Initially RTP and MSRP seem to be enough.
Well, a valid question that Brian has raised is if these nicknames are
scoped to media or a dialog. In other words, can I be "jdr" for audio
and "J.Rosenberg" for IM? I dont see much value in that. So, if we can
use the same nickname across the media, then what we are really talking
about is the way that *I* wish to be identified for this dialog, and
thats the From field.
2. There seem to be different scopes of "nicknames": a) A single
conference instance: I believe the mechanism (or any other mechanism
based on INVITE or SDP) proposed in the draft should only address
this. Negotiation happens when setting up a session with the focus,
and it is thus confusing if it had wider meaning. b) A set of
conferences that are somehow federated (typically run by the same
provider). In this case I believe the reservation of the nickname
should be done with an out-of-band mechanism (I guess an XCAP usage
similar to reserving list URIs would work), and somehow there should
be a "realm" so that it would be possible to determine from a
conference URI whether it belongs to the federation or not. If a user
has a registered nickname within a realm, he probably still uses the
mechanism in a) to announce it within a single conference in this
realm. It is then upto the conference server to authorize the usage
of the nickname. c) Any SIP services. Again some sort of out-of-band
reservation, and then sending each request through a B2BUA that
translates the "real" identity to the "nickname". This could be
actually used simultaneously with the conference specific systems,
i.e. having a "nickname" for a "nickname".
I think we need to define which we want. I dont like "all three". I tend
to think its (b).
3. In each case there is a SIP-element that actually knows the "real"
identity of the user. In cases 2a) and 2b) it is the conference
focus, in 2c) it is the B2BUA. Only the nickname is shown beyond this
element, as intended.
3. As Aki explained, sidebars and private IMs within a conference are
two different things. Sidebars are subconferences, that include a
certain subset of the participants in the main conference. They need
to be explicitly created and deleted. Private IMs within a conference
are also targeted to a subset of the conference participants. But
there is no need to setup a sidebar or any other additional context
to send them. The recipients can simply be signaled within each
message (as proposed by using CPIM To header). This seems to be a
specific property of IM, as this sort of addressing would be
impossible e.g. in RTP. In theory priate messaging facility could be
supported by sidebars, but in this case the focus would need to have
as many sidebars constantly setup, as there are different possible
participant subset combinations. Way too complex and not needed.
I dont think that, functionally, what you are describing is different
from a sidebar. What differs is that the specifics of this media type
allow for a more efficient implementation of the sidebar than would be
possible for another media type, such as audio. Indeed, the same is true
for IM in general - why set up a session (ala msrp) when you can just
send a pager mode?