-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, February 25, 2004 13:11
To: Paul Kyzivat
Cc: hisham.khartabil@nokia.com; Miguel.An.Garcia@nokia.com;
simple@ietf.org; aki.niemi@nokia.com
Subject: Re: [Simple] Chat sessions
To answer this question, in RTP, the SSRC is used for identification.
The SSRC is mapped to a name through the RTCP SDES packets,
which come
every once in a while, and bind the SSRC to a CNAME. The
CNAME can also
be associated with supplementary data, such as the NAME
parameter, which
basically provides a nickname. Its described in RFC3500 thusly:
6.5.2 NAME: User Name SDES Item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the real name used to describe the source, e.g.,
"John Doe,
Bit Recycler". It may be in any form desired by the user. For
applications such as conferencing, this form of name may
be the most
desirable for display in participant lists, and
therefore might be
sent most frequently of those items other than CNAME.
Profiles MAY
establish such priorities. The NAME value is expected to remain
constant at least for the duration of a session. It
SHOULD NOT be
relied upon to be unique among all participants in the session.
I see the IM nickname as being equivalent; an in-band
identifier of the
user name.
RTP defines the scope of these nicknames as bound to a
session, and does
not require uniqueness. Thats a bit different than what is being
proposed here.
Note that we have always had a problem with SSRC/CNAME that
there was no
easy way to map them to a SIP URI that could be used for
signaling. That
is, the CNAME is not necessarily the SIP URI that one would
want to use
to contact the user. For example, if I'm in a conference and
I want to
have a private call with a user, outside of the conference,
what SIP URI
to use?
I also agree with comments raised by Brian and others that
requirements
for management of nicknames - creation, deletion, and scope - are not
tied to IM. If we need that functionality, we should
introduce them as
requirements in the general conferencing work. Additionally, the
mechanism for this management should not be IM specific. Seems to me
like CPCP would be the ideal way to set them up. I believe
they would be
useful for general conferencing as has been pointed out. The
only thing
thats really IM specific is how such information is conveyed in the
message; usage of From in cpim seems reasonable to me.
One other thing in the draft that I would like to point out, is that
there is a feature that allows for private conversations.
This is done
by allowing a user to address an IM to one or more group
participants,
using To and CC CPIM fields. To me, this is also another conference
function that is not specific to IM. In fact, I dont see how
it differs
from sidebars.
Thanks,
Jonathan R.
Paul Kyzivat wrote:
Hmm. I was wondering about that too. I guess one
possibility would be to
send the mapping from SSRC in RTCP. (I am not very
knowledgable about
RTP, but I think RTCP carries a mapping from SSRC to text names.)
Another way would be for the SSRC to itself be considered a form of
nickname and be published as part of the conference state.
(I guess that
would require a facility for multiple nicknames per participant.)
Paul
hisham.khartabil@nokia.com wrote:
Just out of curiosity: how do you transport the display name (nick
name) for audio or video? In RTP? or does the recipient
have to have
local mapping between SSRCs and display names?
/Hisham
-----Original Message-----
From: simple-admin@ietf.org
[mailto:simple-admin@ietf.org]On Behalf Of
ext Paul Kyzivat
Sent: 23.February.2004 18:56
To: Garcia Miguel.An (Nokia-NRC/Helsinki)
Cc: simple@ietf.org; Niemi Aki (Nokia-M/Espoo)
Subject: Re: [Simple] Chat sessions
Miguel.An.Garcia@nokia.com wrote:
Thanks for your comments. See my comments inline.
From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
Its good to think about things like this. But I think the
goal should
not be to introduce special features for chat conferences. It
should be to learn what features users of chat
conferences expect,
and ensure that comparable features are available via our
conference framework, and available with any media when
that makes
sense. So I think some of these ideas need to flow back
into the
conference framework.
If we want to move things to the conference framework,
then we need to develop a complete solution, based on
requirements that... I dind't see so far. For instance,
I believe all the requirements related to nicknames are
addressing the session based conferences so far.
We may want to extend those requriements, but there
aren't any now.
I agree there aren't. I am suggesting that *where it makes sense*
these should be advanced as requirements against conferences in
general, rather than being focused as requirements only for chat
conferences.
Particularly, I don't know how useful is to use nicknames in
an audio/video conference. The feature is useful in a conference
of instance messages, but not so much in the other...
Still, we may want to extend the conference package so that the
user element can contain a <nickname> sub-element.
This would allow a user to display the nickname of the
conferees,
no matter what the media is.
Exactly. This becomes interesting in multimedia conferences to.
For instance it becomes a tag to use in identifying
current speaker.
It also may provide a better way to deal with anonymous
participants
in all sorts of conferences, by giving them nicknames as
handles to
reference them by.
Then, instead of saying: "Will the anonymous participant with the
deep voice please repeat his question?", you can say:
"Darth, will
you please repeat your question?".
However it is relatively trivial to be more accomodating,
adding and
removing cpim wrappers according to the desires of the
individual
endpoints.
Basically, there are two ideas here: endpoints SHOULD use
message/cpim when addressing a conference.
The focus MUST use message/cpim. The idea is that the focus
should indicate the nickname of the sender of the message,
which is conveyed in the From header of the
message/cpim message.
Endpoints SHOULD use messgae/cpim to relief the focus from
wrapping messages when the focus distributes a copy.
Sounds good to me.
Nickname management is problematic. It seems as though
nicknames will
need to be authenticated and authorized. But it isn't
at all clear
that the focus is the right entity to do so. (The scope
is wrong.)
I don't think a nickname has to be authorized. Users are
authorized,
and once a user is authorized, she can choose any
available nickname.
Is this what you meant?
Regarding the scope of the nicknames, I believe a
nickname should be
unique within a conference server or an administrative domain.
At least I don't see a valid requirement in getting nicknames
valid across difrerent servers or different
administrative domains.
I guess this depends on how large and long lived these scopes are.
It clearly isn't good if the scope is a single conference.
It isn't good if it is a conference server either, if
that is just
one of a large pool of independent servers that are
chosen at random
as hosts for conferences.
When the same group of users join in a number of
conferences over a
period of time, within that scope a nickname should be bound to a
user for as long as that user wants it to remain bound.
I think this would be better served by using real,
routable im: or
sip: uris. As needed, service providers can exist to
host nicknames
and forward requests addressed to them to other addresses.
The point is that a nickname should not let you track
the real user.
Only the conference server is able to map the real SIP
URI to the
nickname,
but not users. For instance, if user B receives an
instant message
(through the conference server) from user A, B should
only see the
nickname, unless A wants to disclose his real URI.
Making nicknames a real URI loose the semantics of the
"nickname".
We don't want that behaviour, we want a nickname to
remain a nickname,
something meaningless.
That depends on how things are administered. There could be
"nickname" servers, that are nothing but specialized
proxies. I would
contract with one of these servers for whatever nicknames I want.
These would be unique usernames within the domain managed by that
server. Each would be configured to forward to an address of my
choice. I would be given control to turn forwarding on and off
selectively, so perhaps it would only work when I was
actively using
a particular nickname in a conference.
Then I could use the nickname as my address when joining a
conference. I could permit the conference server to disclose this
address, and yet my true identity would remain hidden.
The advantage of this is that it decouples the administration of
nickname namespaces from the administration of conference servers.
But I am not necessarily opposed to coupling nickname
namespaces with
conference administration *if* the scoping can be made reasonable.
Paul
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Technology Officer Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple