RE: Conference speaker control
Even, Roni <roni.even <at> polycom.co.il>
2004-12-03 08:39:04 GMT
Hi,
This is from the comedia draft, is it RTP, it does not say so.
m=image 54111 TCP t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
Roni
-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of David R Oran
Sent: Thursday, December 02, 2004 10:23 PM
To: Even, Roni
Cc: Magnus Westerlund; sipping
Subject: Re: [Sipping] Conference speaker control
Huh? There's a spec for RTP over TCP.
On Dec 2, 2004, at 8:06 AM, Even, Roni wrote:
> Hi,
> What about sending media over tcp based on the comedia draft, this is
> not RTP.
> Roni
>
> -----Original Message-----
> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] 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:roni.even <at> polycom.co.il]
>> 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: sipping-bounces <at> ietf.org 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: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] 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:magnus.westerlund <at> ericsson.com]
>>> 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: magnus.westerlund <at> 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 <at> cs.columbia.edu for questions on current sip
>>> Use sip <at> 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 <at> cs.columbia.edu for questions on current sip
>> Use sip <at> 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 <at> cs.columbia.edu for questions on current sip
> Use sip <at> 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 <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran <at> cisco.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 <at> cs.columbia.edu for questions on current sip
Use sip <at> 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 <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
RSS Feed