Re: [rtcweb] SDP lines (JSEP Issue 27)

Harald Alvestrand <harald@alvestrand.no> Thu, 02 April 2015 15:15 UTC

User-Agent: K-9 Mail for Android
In-Reply-To: <5519A5A4.4070205@nostrum.com>
References: <5519753D.1080907@nostrum.com> <30772BF4-B814-4CB2-932F-96885D0BD76E@iii.ca> <5519A5A4.4070205@nostrum.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----2KCJBSZQABPQ3EUJO9H5FX4EHW5GVW"
Content-Transfer-Encoding: 8bit
From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 02 Apr 2015 16:14:50 +0100
To: Adam Roach <adam@nostrum.com>, Cullen Jennings <fluffy@iii.ca>
Message-ID: <BAC4D6B1-06EF-453E-BBEF-1FBE3E89D9B7@alvestrand.no>
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/4scR1hh0NjsZDW4mJW3ijjrfji0>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP lines (JSEP Issue 27)
Precedence: list

The API already exposes the sdp that went into set remote. Those lines should show up there. Otherwise, must ignore seems right to me.

Den 30. mars 2015 20.36.04 GMT+01:00, skrev Adam Roach <adam@nostrum.com>:
>On 3/30/15 14:18, Cullen Jennings wrote:
>>> On Mar 30, 2015, at 10:09 AM, Adam Roach <adam@nostrum.com> wrote:
>>>
>>> i=, u=, e=, p=, z=, r=
>>>   SHOULD NOT send, MUST ignore.
>> I don't think MUST ignore is correct. First to be clear, I'm not
>saying the browser needs to do anything with the info in theses lines.
>>
>> I think MAY ignore or not typically used by a webrtc browser might be
>a better way to say it. For example, if rtcweb device was taking a
>streaming video session via webrtc protocols, it might make sense for
>it to use the i= or u= particularly if the SDP had originally come from
>an RTSP stream that was gatewayed to WebRTC. Similarly if a browser
>reported the full SDP it had received in some stats interface, I would
>expect it not to ignore the lines but actually report what it was it
>received.
>>
>> To be clear, I'm not saying the browser needs to do anything with the
>info in theses lines - it's fine to ignore them. But that's very
>different from all webrtc things must ignore them. (and I agree with
>SHOULD NOT send part)
>
>I think we're in agreement about the principle, but might be at cross 
>purposes regarding the venue: I agree that non-browsers may well have 
>reasons to use these fields, but I don't think this document has much 
>bearing on what those implementations do; at least, not as it currently
>
>describes itself.
>
> From the introduction section, JSEP "describes how the W3C WEBRTC 
>RTCPeerConnection interface is used to control the setup, management
>and 
>teardown of a multimedia session." So, in the context of *this* 
>document, it would *appear* that we're in agreement that the proper 
>normative behavior is to ignore the values in these lines. So I can see
>
>why we might be quibbling about "SHOULD" versus "MUST," but your 
>objection seems much broader than that.
>
>If our difference of opinion here arises from differing views about 
>intended scope for the JSEP document, then we need to start a broader 
>conversation around, minimally, the introduction section of the current
>
>draft.
>
>/a
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[rtcweb] SDP lines (JSEP Issue 27) Adam Roach
Re: [rtcweb] SDP lines (JSEP Issue 27) Cullen Jennings
Re: [rtcweb] SDP lines (JSEP Issue 27) Adam Roach
Re: [rtcweb] SDP lines (JSEP Issue 27) Harald Alvestrand
Re: [rtcweb] SDP lines (JSEP Issue 27) Cullen Jennings (fluffy)
Re: [rtcweb] SDP lines (JSEP Issue 27) Harald Alvestrand
Re: [rtcweb] SDP lines (JSEP Issue 27) Justin Uberti