W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2011

RE: Additional requirement - audio-only communication

From: Elwell, John <john.elwell@siemens-enterprise.com>
Date: Wed, 24 Aug 2011 11:12:56 +0200
To: Randell Jesup <randell-ietf@jesup.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <A444A0F8084434499206E78C106220CA0B00FDB56D@MCHP058A.global-ad.net>
 

> -----Original Message-----
> From: public-webrtc-request@w3.org 
> [mailto:public-webrtc-request@w3.org] On Behalf Of Randell Jesup
> Sent: 24 August 2011 08:53
> To: public-webrtc@w3.org
> Subject: Re: Additional requirement - audio-only communication
> 
> On 8/23/2011 1:32 PM, Stefan Håkansson LK wrote:
> 
> >>>> A18  It MUST be possible for an initiator or a responder 
> Web application
> >>>> to indicate the types of media he's willing to accept 
> incoming streams
> >>>> for when setting up a connection (audio, video, other). 
> The types of
> >>>> media he's willing to accept can be a subset of the 
> types of media the
> >>>> browser is able to accept.
> >>> When do you think this should be indicated? I guess that 
> in most cases
> >>> the establishment of a connection is foregone by some signaling (I
> >>> would like to communicate, would you?). Perhaps what 
> media you would
> >>> be willing to receive can be agreed in this phase, and the sending
> >>> application would react by sending only the desired 
> media. This way
> >>> there would not be a need to have specific APIs for this purpose.
> >> I think the PeerConnection will have to be told before it 
> sends off its
> >> SDP Offer.
> > I agree. I was referring to signaling between the web apps 
> happening before the creation of PeerConnection. One way to 
> solve this would be to have such signaling ("I would like to 
> communicate, would you?", "yes, but I only want audio") 
> happening before creating the PeerConnection objects, using a 
> mechanism outside the scope of this standard. That way the 
> applications would have this knowledge when doing "addStream" 
> (or even "getUserMedia").
> 
> I'm confused: why would not this be handled in the Offer/Answer phase?
> (either within SIP if we use it, or within Offer/Answer if we 
> don't use SIP).
[JRE] When a side initiating a communication sends an SDP offer, there is an implicit assumption that only media that the user wants to use are included in that offer. Somehow, via the user interface used to establish the communication, the user indicates a desire for audio only, audio plus video, etc..

So if the SDP offer is to be generated from the browser (I think this is still under discussion), I can see that the browser API needs a means, prior to the offer being generated, for the application to indicate the media to be offered.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: john.elwell@siemens-enterprise.com
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.
Received on Wednesday, 24 August 2011 09:13:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC