Subject: RE: [Simple] Chat sessions

From: [email-masked]
Date: Tue, 24 Feb 2004 10:52:48 +0200

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: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Paul Kyzivat
> Sent: 23.February.2004 18:56
> To: Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: [email-masked]; Niemi Aki (Nokia-M/Espoo)
> Subject: Re: [Simple] Chat sessions
> 
> 
> 
> 
> 
> [email-masked] wrote:
> > Thanks for your comments. See my comments inline.
> > 
> >>From: ext Paul Kyzivat [mailto:[email-masked]]
> >>
> >>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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2004 11:23:17 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2004 11:23:17 -0500

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 14:10:51 -0500

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:

>> 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
>>
>>
>>>>> 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.
>>>>
>>>>
>>> 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.
>>>
>>>
>>> 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?".
>>>
>>>
>>>>> removing cpim wrappers according to the desires of the individual 
>>>>> endpoints.
>>>>
>>>>
>>>>> 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.)
>>>>
>>>>
>>> > and once a user is authorized, she can choose any available nickname.
>>> > Is this what you meant?
>>>
>>> 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.
>>>
>>> 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.
>>>>
>>>>
>>> > We don't want that behaviour, we want a nickname to remain a nickname,
>>> > something meaningless.
>>>
>>> "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.
>>>
>>> conference. I could permit the conference server to disclose this 
>>> address, and yet my true identity would remain hidden.
>>>

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 14:10:51 -0500

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Feb 2004 14:30:15 -0500

Jonathan,

I agree in full with what you say.

	Paul

Jonathan Rosenberg 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.)
>>
>> nickname and be published as part of the conference state. (I guess 
>> that would require a facility for multiple nicknames per participant.)
>>
>>     Paul
>>
>>>>>> sip: uris. As needed, service providers can exist to host 
>>>>>> nicknames and forward requests addressed to them to other addresses.
>>>>>
>>>>>
>>>>>
>>>> "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 
>>>> But I am not necessarily opposed to coupling nickname namespaces 
>>>> with conference administration *if* the scoping can be made reasonable.
>>>>
>>>>     Paul
>>>>
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Feb 2004 14:30:15 -0500

Jonathan,

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Thu, 26 Feb 2004 14:32:15 +0200

Inline.

> I see the IM nickname as being equivalent; an in-band identifier of the 

I agree that we're dealing with the same issues here.

> not require uniqueness. Thats a bit different than what is being 

If I understand correctly, the CNAME is similar to a display name of a 
To/From in message/cpim? We're not requiring display names to be unique 
either, but the URI part needs to be unique. In a voice conference, you 
won't direct RTP packets towards a particular CNAME, but in MSRP, you 
need to be able to distinguish which "BeerLover" you want the private 
message to go to.

> have a private call with a user, outside of the conference, what SIP URI 

I believe you would get it via conference-info. Of course, mapping that 
information to the CNAME is still problematic, since they are not 
required to be unique.

The functionality that we want is that a user is able to join the 
conference using its asserted ID. But it wants to be seen in the 
conference as someone else - lets call it a nickname - if the conference 
policy allows this. This other ID would be sent out in the 
conference-info, and also in the message/cpim From field.

Surely I can put my asserted ID + a display name in both of these 
places, but that's really not a nickname with anonymity anymore (even if 
the ID is in fact an alias). In our draft, a nickname is really a 
temporary ID that doesn't reveal any real-life ID. This is made explicit 
using the .invalud TLD. Every client will know the URI is useless 
outside the conference.

And I think this is where the confusion lies - for clarity's sake, we 
should probably denote a 'nickname' as an identity other than the ID 
used to join a conference; a temporary nickname would be one that is 
only valid inside a specific conference (uses the .invalid).

> message; usage of From in cpim seems reasonable to me.

I agree. It seems nicknames are generic enough to apply to all 
conferences. I don't know if CPCP is the correct tool for management of 
nicknames. In fact, couln't this be set in the SDP at the time a 
participant is joining a conference? Something like:

a=nickname:Darth Vader <im:[email-masked]>

or

a=nickname:Darth Vader <sip:[email-masked]>

This nickname would be used in conference-info instead of the 
authenticated ID, used as CNAME in RTCP packets, or From/To in 
message/CPIM, or even a display name in a video stream.

> function that is not specific to IM. In fact, I dont see how it differs 

The main difference is as I see it, that to allow the same user 
experience as that of private messages, one would have to by default 
have a full mesh of one-to-one sidebars set up (plus the combinatorics 
involved when sending a private message to many).

I think private messages are a media feature, and it can actually be 
easily combined with sidebars. I could imagine sending private messages 
within a conference sidebar as well...

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Thu, 26 Feb 2004 14:32:15 +0200

Inline.

or

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Feb 2004 00:28:36 -0500

> only valid inside a specific conference (uses the .invalid).

I am stil not clear on the precise functionality you are after. On one 
hand you say that the display name is the nickname, and that it doesn't 
have to be unique. On the other hand you say that you are using both the 
display name (that doesn't have to be unique) and an invalid id, that 
apparently is intented to provide uniqueness. And you talk about the 
scope of these being a server rather than an individual conference, so 
apparently they must be configured in some way, rather than simply being 
dynamically determined at the time a participant joins a conference.

When I participate in a conference (say a chat conference), I don't want 
to be confused about who I am talking to. I want the names that are 
displayed to me to be unique. If display names are not guaranteed to be 
unique, then I want my client to display more than the display name in 
order to guarantee uniqueness.

In general I think this is best served by using the actual address and 
display name provided by the participant as long as anonymity isn't 
requested. When it is requested, I think the conference server can 
provide a *valid* surogate that is only valid while the conference is 
active. If the focus is sip:[email-masked], then it could 
assign names like: sip:[email-masked]. (Or pick any 
scheme you like.)

These surogate addresses would act however the conference server wishes. 
Requests to them could always be rejected with an error. Or they could 
be proxied to the actual participant while the conference is active.

A conf server could also assign surogate addresses with a longer 
lifetime, so that you would get the same one whenever you were in a 
conference hosted by that server, and nobody else would be assigned that 
one. (E.g. something like sip:[email-masked].) Then I would 
be able to tell that you were the *same* BeerLover that I saw at a 
conference yesterday. Of course you lose part of your anonymity when you 
use such an address. Because of this I'm not sure there is value in 
providing this service.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Feb 2004 00:28:36 -0500

Paul