Subject: RE: [SIP] SIP Conference-Discovering Participants Identities

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 10 Feb 2001 00:41:07 -0500

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, February 04, 2001 9:57 AM
> To: Henry Sinnreich
> Cc: [email-masked]
> Subject: Re: [SIP] SIP Conference-Discovering Participants Identities
> 
> 
> Henry Sinnreich wrote:
> > 
> > Have a problem with the strict requirements that for secure 
> and confidential
> > business conferences, the identity of all authenticated 
> participants should
> > be clearly be known and preferably displayed at all times during the
> > conference.
> > 
> > However, the I-D on "Models for Multi-Party Conferencing in 
> SIP" states:
> > >4.5 Discovering Participant Identities
> > >   The identities of other participants in the conference are
> > >   NOT known through SIP.
> > 
> > Using RTP to display user identities seems broken, since an unwanted
> > listener can have no RTP packets sent.
> > 
http://ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-models-00.t
> xt

This particular problem can also be solved by a somewhat smarter mixer.
Rather than acting as a pure mixer as defined in rfc1889, it generates RTCP
SDES items for all people that have joined the conference at the sip level,
but have not sent RTCP SDES on their own. It can construct the name, to some
reasonable level, from the From field of the INVITE used to join the
conference.

An even smarter mixer might ignore the RTCP SDES sent from the users
entirely, and rather, generate the RTCP SDES using the identity obtained
from any SIP authorization/authentication process used to verify identity
when the user join the conference in the first place.

Since RTP (and RTCP) can be encrypted, you can also get privacy of this data
by encrypting it. This way, only conference participants know the list of
people in a conference; an eavesdropper cannot determine it.

So, I think you can get adequate security features.

If people think this idea is not too much of a hack, I will gladly add it to
the conferencing models draft.

>> Any other solution to display all participants?
>> How could a conference bridge signal to users who else in participating?
>> 
>
>SUBSCRIBE/NOTIFY may be an appropriate mechanism. However, nothing
>prevents a participant from having others listening in, so this isn't a
>foolproof mechanism.

SUB/NOT could work, as we discussed in the interim meeting today. However, I
still maintain that there is a lot of other things you might want here, and
they are part of a broader conference control protocol, for which one
component is notifications of lists of subscribers. Rather than have a SIP
mechanism for SUB/NOT for the subscriber list, and a SEPARATE protocol for
managing those subscribers (consider the case where I get notified that a
user joined, and then I want to mute them. Its a bit harder as this
operation now spans two separate protocols; there may be issues with that),
I'd rather specify out a conference control protocol that does everything.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 10 Feb 2001 12:37:06 -0800

> the conferencing models draft.

To some extent a mixer already has to generate its own RTCP messages,
either copying the RTCP from incoming streams or generate its own set,
so this is standard behavior for a mixer. If the conference server acts
as an RTP translator, i.e., simply replicates packets, it can do
something similar.

> component is notifications of lists of subscribers. Rather than have a SIP

In many cases, for a central conference server, you really don't need
much more than that. We are controlling permissions and media
replication via a web interface in our server, which seems to work
pretty well.

The one advantage of SUB/NOT is that's easier to divorce media from such
notifications. For example, you can imagine long-running chat rooms
where I want to be notified whenever a certain person shows up (or
leaves, depending on my particular preferences). That's pretty natural
for the subscription model.

> I'd rather specify out a conference control protocol that does everything.

This fictitious protocol has been around for so long, that I'm somewhat
concerned to keep useful functionality from being deployed.

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 11 Feb 2001 07:49:33 -0600

>If people think this idea is not too much of a hack,

It does not appear to be a hack, but rather a normal task for the
application.

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
Sent: Friday, February 09, 2001 11:41 PM
To: Henning G. Schulzrinne; Henry Sinnreich
Cc: [email-masked]
Subject: RE: [SIP] SIP Conference-Discovering Participants Identities

-Jonathan R.

---