W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2012

RE: OfferToReceive in CreateAnswer

From: Hutton, Andrew <andrew.hutton@siemens-enterprise.com>
Date: Fri, 26 Oct 2012 20:04:08 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01318DBE@MCHP04MSX.global-ad.net>
Hi Harald,

I was looking at this just today and came to the conclusion that the constraints are not yet well defined.

The options in section 11.1 don't currently reflect what an application might want to do with the offer or the answer with regarding to the direction.

Even in the offer an application should also have the option to offer to send audio/video and not receive it (i.e. a=sendonly) and it should also have the option to offer audio/video but make it inactive.

All options should also be available in the answer but constrained by the RFC 3264 rules regarding responding to the offer. So if the offer indicates a=sendonly the options in the answer are a=recvonly or a=inactive.

This applies to both the initial offer and any subsequent offer/answer during the session.

Regards
Andy




> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: 26 October 2012 12:47
> To: public-webrtc@w3.org
> Subject: OfferToReceive in CreateAnswer
> 
> Wearing my implementor's hat, reporting on a discussion:
> 
> The text in section 11.1 about OfferToReceiveAudio and
> OfferToReceiveVideo talks about offers, but doesn't say what should be
> done with answers. If the language was interpreted exactly as it
> stands,
> the result of doing a CreateAnswer without adding any streams would be
> to create an SDP that rejected the Audio and Video m-lines - which
> doesn't make much sense.
> 
> A reasonable interpretation should be this (all refer to the responding
> RTCPeerConnection):
> 
> - When no OfferToReceive* is present, and no streams are added, all m=
> lines from sender are accepted. (Query: should they be accepted in
> a=recvonly mode?)
> 
> - When OfferToReceive* is nandatory false, and no streams are added,
> the
> corresponding m= line is rejected (by setting the port number to 0).
> 
> - I don't think we can add m= lines in an answer, so when the incoming
> offer has no video line, and the OfferToReceiveVideo is true, the
> answerer fires negotiationneeded immediately after returning to the
> no-outstanding-offer state, so that the answerer can offer an upgrade
> to
> add video.
> 
> Does this make sense? If so, can it be added?
> 
>                Harald
> 
> 
> 
Received on Friday, 26 October 2012 20:04:37 UTC

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