Re: [Sipping] Conference speaker control

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 29 November 2004 15:26 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01080 for <sipping-web-archive@ietf.org>; Mon, 29 Nov 2004 10:26:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnVS-000476-Oa for sipping-web-archive@ietf.org; Mon, 29 Nov 2004 10:32:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnH5-0006O7-6V; Mon, 29 Nov 2004 10:17:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnBn-0004I5-J5 for sipping@megatron.ietf.org; Mon, 29 Nov 2004 10:11:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28832 for <sipping@ietf.org>; Mon, 29 Nov 2004 10:11:41 -0500 (EST)
Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnGY-0003iE-Kl for sipping@ietf.org; Mon, 29 Nov 2004 10:16:49 -0500
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iATFBVh5021547 for <sipping@ietf.org>; Mon, 29 Nov 2004 16:11:31 +0100 (MET)
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 16:11:29 +0100
Received: from [147.214.34.68] (E-A75D10B0ED7B4.ki.sw.ericsson.se [147.214.34.68]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WHLTSHHR; Mon, 29 Nov 2004 16:11:29 +0100
Message-ID: <41AB3C20.3090706@ericsson.com>
Date: Mon, 29 Nov 2004 16:11:28 +0100
X-Sybari-Trust: 3f0939ab a5e9b67f 2b3f5727 00000139
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: sv, en-us, en
MIME-Version: 1.0
To: "Even, Roni" <roni.even@polycom.co.il>
Subject: Re: [Sipping] Conference speaker control
References: <144ED8561CE90C41A3E5908EDECE315C5C6ACF@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C5C6ACF@IsrExch01.israel.polycom.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Nov 2004 15:11:29.0283 (UTC) FILETIME=[B3DB1530:01C4D625]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Cc: sipping <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit

Hi Roni,

Sorry if I do not have a full picture of the architecture of the 
conferencing. Please enlighten me if I overstep any previous agreements.


Even, Roni wrote:

> Brian,
> I am sorry to continue to argument. I thought the view in my reply was
> clear. I think that since SIP has a dialog between two endpoint and not
> just an RTP session, and since the meaningful information that needs to
> be displayed to the user is who is speaking and not what is the ssrc of
> the stream that it received, it will make more sense to have this
> information coming from a SIP conference bridge as the speaker
> indication.

RTP with RTCP does have the mechanism to provide a receiver with the 
name or at least the CNAME for all SSRCs that are used in all media 
streams. That way one can identify the actual media senders. It might be 
beneficial depending on the conferencing side functions to bind the 
CNAME to some RTP/RTCP external user identification. Thus including 
CNAME in the state package may be beneficial, instead of needing to 
provide SSRC for all participants in all media streams. It would reduce 
the data  points with a factor equal to the number of media.

Is the issue that you don't think media reception from a specific SSRC a 
good indication that the source is active? Otherwise I don't see the 
reason to not utilize the functionality present in RTP/RTCP.

In regards to RTP mixer I would like to point out that the conference 
bridge must not necessarily be a mixer, it could be a relay. If the 
bridge simply forwards all packets from all participants RTP and RTCP to 
  everybody, no mixing is necessary. The downside is that the media 
amount gets increased every time more than one transmits data. This of 
course has its issue with users that has a limited bandwidth. The higher 
the bit-rate of the media the more sensible it seems to do mixing. But 
mixing T.140 conference text seems rather unnecessary.

cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

_______________________________________________
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