Subject: RE: [Sipping] Conference speaker control

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

Brian,
I know it is SIPPINg and I mentioned that we may extend the conference package in XCON.
I am still not sure about the ssrc. Does SIP allows only RTP sessions. As far as I know there is no such assumption in SDP. 
Roni Even

________________________________

From: [email-masked] on behalf of Brian Rosen
Sent: Tue 11/30/2004 4:02 PM
To: Even, Roni; 'Magnus Westerlund'
Cc: 'sipping'
Subject: RE: [Sipping] Conference speaker control

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

> -----Original Message-----
> 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,
> 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
>

_______________________________________________
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

_______________________________________________
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: David R Oran <[email-masked]>
Date: Tue, 30 Nov 2004 13:56:24 -0500

On Nov 30, 2004, at 12:59 PM, Even, Roni wrote:

> I am still not sure about the ssrc. Does SIP allows only RTP sessions. 
> As far as I know there is no such assumption in SDP.

That's not the point. The point is whether we assume that the media 
sessions are "self-describing" in terms of providing the identity 
(directly or indirectly) of the source of the data arriving *now*. RTP 
does that, both directly and through mixers. MSRP does that, both 
directly and through relays/chat rooms. A separate PSTN stream arriving 
at a POTs phone does not.

If we make this "self-describing media sessions" assumption then we 
reach a different set of requirements for speaker 
identification/control than if we do not.

I would argue that this is a very good assumption to make since it 
simplifies a number of things and makes the system less sensitive to 
whether there are centralized media processing resources or not (as 
opposed to centralized control plane focus which XCON explicitly is 
restricted to).

For better or worse this means that media streams that aren't 
themselves self-describing need some kind of "helper" element. This 
could be in the control plane, of course, and might be simpler there. 
On the other hand, for symmetry with the way the rest of the system 
works, I'd argue that keeping this a media plane function is a good 
idea, even if complicates the legacy bridges.

Dave.

> Roni Even
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 30 Nov 2004 14:18:54 -0500

Brian

There is no requirement to use RTP, there is merely no existing alternative.

Brian

> From: Even, Roni [mailto:[email-masked]]
> Sent: Tuesday, November 30, 2004 12:59 PM
> To: Brian Rosen; Magnus Westerlund
> Cc: sipping
> I am still not sure about the ssrc. Does SIP allows only RTP sessions. As
> far as I know there is no such assumption in SDP.
> Roni Even
>