Subject: RE: [Sipping] Conference speaker control

From: "Even, Roni" <[email-masked]>
Date: Tue, 30 Nov 2004 10:45:59 +0200

Magnus,
The problem you stated is correct but this is not what I meant. In XCON
conference server can be composed of a conference/media policy server
and a focus that can be an application server that handle conference
policy and some web collaboration while the mixer is a PSTN bridge. 
A participant in such a conference is using a PSTN phone and a PC for
web collaboration and conference control. The PC can subscribe to the
conference package but since the audio is PSTN there are no RTP or SSRC.
Even for IP conferencing making an assumption that all streams in a
conference are RTP streams is not always right, so ssrc cannot be used
to describe who is sourcing each stream in an application that uses a
mix of RTP and non RTP streams.
Roni Even

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, November 29, 2004 5:45 PM
To: Even, Roni
Cc: sipping
Subject: Re: [Sipping] Conference speaker control

Hi Roni,

Lets see if I understand this correctly. You are worried about PSTN or 
other gateways that are receiving more than one source over the same 
circuit and in which cases the gateway can't separate the different 
sources within the CS to IP gateway. As long as the PSTN gateway 
receives the different circuit switched sources in the same conference 
on different circuits, it is able to assign them different SSRCs and
IDs.

If the above is the case, how would adding any other mechanism help? The

gateway can still not identify the original sources, or am I 
misunderstanding something about the setup?

My understanding of the setup you are concern is:

CS1 --\
        -> CS Bridge -> Gateway ->  IP Conf Bridge -> Client 3
CS2 --/                  ^               ^
                          |               |
                         CS5           Client 4

In this case Client 3 and 4 would not be able to determine that what is 
beyond the gateway is in fact three client. CS1 and CS2 will be bunched 
together under one source identifier? While CS5 can be identified as it 
connects directly with the gateway and uses a separate CS line into the 
gateway, thus allowing the gateway to give them separate IDs.

It should also not be a problem if the protocol used on the CS side 
provides identities, then the gateway can provide different identifiers 
for the different CS side users.

Cheers

Magnus

Even, Roni wrote:

> Magnus,
> I am not saying that RTP using SSRC does not have a mechanism to
> identify the source of the streams. What I am trying to say is that we
> are not talking about a pure RTP mixer but we are talking about a SIP
> based conferencing server and in XCON the scope is even wider, it may
be
> a PSTN bridge bellow.
> So first of all there is no requirement defined that the mixer in SIP
> conferencing or XCON should be a RTP mixer per RFC3550. Even if we do
it
> for SIPPING then we will have a problem for PSTN Bridge (example of
> usage if for audio-graphic conference) and it will break for XCON.
> Roni Even

-- 

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: [email-masked]

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 30 Nov 2004 09:02:36 -0500

Roni

This is SIPPING.  If we have PSTN participants in a conference, they come
from some kind of gateway and use SIP signaling.  AFAIK, there is no way
with current IETF protocols to have a conference where the participants are
anything but SIP endpoints using RTP for media streams.

You might ask over in the XCON list whether anyone thinks trying to use XCON
protocols to control a PSTN mixer without RTP is in scope.  XCON is not
limited to SIP, but I'm not sure such a case is something we should be
worried about.  It's clearly not something in SIPPING's charter.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Even, Roni
> Sent: Tuesday, November 30, 2004 3:46 AM
> To: Magnus Westerlund
> Cc: sipping
> Subject: RE: [Sipping] Conference speaker control
> 
> Magnus,

---

From: David R Oran <[email-masked]>
Date: Tue, 30 Nov 2004 10:35:13 -0500

I tend to agree with Brian, however Roni's use case is interesting and 
should be accommodated if reasonably easy. What is definitely missing 
is a protocol between the the PSTN bridge and either the control plane 
in the focus, or between the PSTN bridge and the SIP participants. If 
we choose the former approach there is protocol work to be done in 
XCON. If we choose the latter approach, we have such a protocol - it's 
RTP. While somewhat artificial, one could have an RTP session from the 
PSTN bridge (or something associated with that bridge (which is 
obviously needed anyway to have the bridge report who is speaking) to 
each participant simply for the purpose of reporting this (and other 
realtime) information.

I don't necessarily advocate any particular approach, but if we do want 
to have PSTN/TDM media paths for audio in scope of XCON or SIPPING, we 
can't just mandate control-plane reporting of active speaker, declare 
victory, and move on. There's work to be done.

Dave.

>>> usage if for audio-graphic conference) and it will break for XCON.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]