RE: [Sipping] comment on draft-rosenberg-sip-call-package-01.txt

Orit Levin <orit@radvision.com> Thu, 21 March 2002 20:17 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24046 for <sipping-archive@odin.ietf.org>; Thu, 21 Mar 2002 15:17:35 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08915 for sipping-archive@odin.ietf.org; Thu, 21 Mar 2002 15:17:38 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07475; Thu, 21 Mar 2002 15:01:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07315 for <sipping@optimus.ietf.org>; Thu, 21 Mar 2002 15:00:59 -0500 (EST)
Received: from radvpost.us.radvision.com ([12.44.63.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23580 for <sipping@ietf.org>; Thu, 21 Mar 2002 15:00:45 -0500 (EST)
Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id <G2V5JLLB>; Thu, 21 Mar 2002 14:58:14 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD949459ED8DA@RADVPOST>
From: Orit Levin <orit@radvision.com>
To: "Jonathan Rosenberg (E-mail)" <jdrosen@dynamicsoft.com>
Cc: sipping@ietf.org
Subject: RE: [Sipping] comment on draft-rosenberg-sip-call-package-01.txt
Date: Thu, 21 Mar 2002 14:58:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
X-BeenThere: sipping@ietf.org

There will be many different requirements based on people's different
perception what a Conference is. Based on a specific Conference structure,
the meaning of (almost the same) content may turn out be different.
During our ad-hock "Conferencing BAR", we agreed to prepare a draft
identifying Conferencing structures of immediate interest and identifying
requirements for all of them (hopefuly) and for each one of them (if
required).
I think that this kind of work will help with sorting the requiremets for
the content of the Conferencing Package. The document will "give names" to
specific conferencing structures that could become a part of the
Conferencing Package content.

Orit.

-----Original Message-----
From: David R. Oran [mailto:oran@cisco.com]
Sent: Thursday, March 21, 2002 11:59 AM
To: 'Even, Roni'; sipping@ietf.org
Subject: RE: [Sipping] comment on
draft-rosenberg-sip-call-package-01.txt


> -----Original Message-----
> From: Even, Roni [mailto:roni.even@polycom.co.il] 
> Sent: Thursday, March 21, 2002 11:43 AM
> To: 'David R. Oran'; Even, Roni; sipping@ietf.org
> Subject: RE: [Sipping] comment on 
> draft-rosenberg-sip-call-package-01.txt
> 
> 
> 
> 
> > -----Original Message-----
> > From: David R. Oran [mailto:oran@cisco.com]
> > Sent: Thursday, March 21, 2002 6:32 PM
> > To: 'Even, Roni'; sipping@ietf.org
> > Subject: RE: [Sipping] comment on
> > draft-rosenberg-sip-call-package-01.txt
> > 
> > 
> > > -----Original Message-----
> > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
> > > On Behalf Of Even, Roni
> > > Sent: Thursday, March 21, 2002 11:19 AM
> > > To: sipping@ietf.org
> > > Subject: [Sipping] comment on 
> > draft-rosenberg-sip-call-package-01.txt
> > > 
> > > 
> > > Hi,
> > > I have a comment about the media mixing information. The 
> > > information that interest the participants is if he is being 
> > > heard or seen and who is he getting in his incoming mixing 
> > > stream. 
> > Well, that is certainly part of it. It's actually the 
> hardest part in 
> > the case of distributed rather than centralized mixing.
> > 
> > > I do not think he wants to know the information about
> > > all the streams in the conference. 
> > I disagree here. While no one participant may be interested 
> in ALL the 
> > streams, a participant/moderator/administrator may in fact want a 
> > global topology view of the current media streams.
> This may have privacy implication. Typically the moderator 
> want to know who is in the conference and build the mixing 
> that will be sent to all participants. He will not allow a 
> change by the participant if this is a controlled conference.
>
I agree that it has privacy implications. Where I have a problem is
having a brittle classification scheme that categorizes people into
fixed classes like "participant" and "moderator". We need a general way
for participants to declare who is allowed to see and/or manipulate
their state in the conference, and who has rights to see and/or modify
other participants' state, including those whose streams they my no be
currently receiving. In the classic controlled conference model, this
maps onto the two categories of "moderator" and "participant" but we
need not carry this forward or limit ourselves to this fixed
classification system.

>  I also think one 
> > participant
> > may want to know why he is not hearing/seeing another 
> participant (did 
> > he mute himself, was he put on hold, did the mixer decide he wasn't 
> > active, etc.)
> This information should be for the streams he is receiving 
> not for all of them
See above. I believe the control/observation should be explicitly bound
via authorization and not implicitly bound based on what streams I am
sourcing/sinking.

> > 
> > > As for video mixing the information needs to specify the
> > > window in which the stream is displayed. 
> > Unless I misunderstand, this is both un-necessary and
> > violates privacy.
> > Why should other participants learn the window topology of 
> my private
> > display. Would you advocate reporting whether the earpiece 
> is currently
> > in my left or right ear?
> This is not for the other participants. this is the 
> information about what I currently get from the video/audio mixer.
OK.

> > 
> > What I think you are asking for is in fact something
> > different, which is
> > a mapping from the participant to the video region of the 
> mixed video
> > stream which contains his camera input. Is that in fact what 
> > you meant?
> Yes, what I meant is that when I receive a mixed video stream 
> and I want to know who is in my incoming stream I would like 
> to associate each source with his position on the screen.
>
Agreed. However, we want to be careful to not exclude video processing
which produces avatars from the input video signals rather than the
current simple schemes of just tiling a larger window.

Thanks.

Dave.
 
> > 
> > Dave.
> > 
> > Thanks Roni Even
> > > 
> > > **********************************************
> > > Roni Even
> > > 
> > > Polycom Network Systems
> > > Tel: +972-3-9251200
> > > Mobile: +972-55-481099
> > > Fax: +972-3-9211571
> > > Email: roni.even@polycom.co.il
> > > 
> > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list 
> is for NEW development of the application of SIP Use 
> > > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > > sip@ietf.org for new developments of core SIP
> > > 
> > 
> 


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP