Subject: RE: [Sipping] Conference speaker control

From: "Even, Roni" <[email-masked]>
Date: Thu, 2 Dec 2004 15:06:32 +0200

Hi,
What about sending media over tcp based on the comedia draft, this is
not RTP.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Rosen
Sent: Tuesday, November 30, 2004 9:19 PM
To: Even, Roni; 'Magnus Westerlund'
Cc: 'sipping'
Subject: RE: [Sipping] Conference speaker control

Brian

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

Brian

> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Tuesday, November 30, 2004 12:59 PM
> To: Brian Rosen; Magnus Westerlund
> Cc: sipping
> Subject: RE: [Sipping] Conference speaker control
> 
> 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

_______________________________________________
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: Magnus Westerlund <[email-masked]>
Date: Thu, 02 Dec 2004 14:49:46 +0100

Hi Roni,

> What about sending media over tcp based on the comedia draft, this is

It may or it may not. Any media over TCP will need some type of framing, 
either if it is a HTTP download of a progressive media stream, or if it 
is RTP over TCP. There is actually a generic RTP over TCP proposal 
including protocol identifier for SDP in:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-framing-contrans-03.txt

Cheers

Magnus Westerlund

---

From: David R Oran <[email-masked]>
Date: Thu, 2 Dec 2004 15:22:43 -0500

Huh? There's a spec for RTP over TCP.

>>>> 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]