[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] Chat sessions
Jonathan:
Thanks for the review. I basically agree with your comments. I got enough comments as for to figure out how to progress this item. I also noticed that Paul agrees with you, so we are becoming closer to consensus.
A couple of comments though:
>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.
I don't think RTP nickname scope is incompatible with the proposal in the draft. We are proposing a more restrictive allocation and management scheme that fulfills the RTP requirements for a nickname to be bound to a session.
Jonathan also mentioned:
>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?
This is a problem we are not addressing in our document, and I would consider that we have the means to solve it today with presence, private instant messages, etc. that can carry the URI of the two participants. It is desirable that mapping of the SSRC/CNAME to SIP URIs will take place in the conference server (mixer, I believe), to fulfill the privacy requirements of those users that don't want to expose their SIP URI.
/Miguel
> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 25 February, 2004 21:11
> To: Paul Kyzivat
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Garcia Miguel.An
> (Nokia-NRC/Helsinki); simple@ietf.org; Niemi Aki (Nokia-M/Espoo)
> 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