Message-ID: <5447C0E8.2080604@alum.mit.edu>
Date: Wed, 22 Oct 2014 10:36:24 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, 
 "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
References: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com>
 <5445C65B.6040804@alum.mit.edu>
 <E1FE4C082A89A246A11D7F32A95A17828E5EA998@US70UWXCHMBA02.zam.alcatel-lucent.com>
 <54469E76.1010806@alum.mit.edu>
 <E1FE4C082A89A246A11D7F32A95A17828E5EAC01@US70UWXCHMBA02.zam.alcatel-lucent.com>
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17828E5EAC01@US70UWXCHMBA02.zam.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QbGyDVrX11HvEDJerGtFmObuH60
Cc: IETF MMUSIC WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01
Precedence: list

On 10/21/14 2:50 PM, Makaraju, Maridi Raju (Raju) wrote:
> Hi Paul,
>
>> Hi Raju,
>>
>> On 10/21/14 1:04 PM, Makaraju, Maridi Raju (Raju) wrote:
>>> Hi Paul,
>>>
>>> Thanks for the detailed and thorough comments.
>>> Please see my inline responses below.
>>>
>>>> This is in much better shape now - having caught up with changes in the
>>>> related drafts. Here are a few comments and suggestions:
>>>>
>>>> * Section 5.1.1.1:
>>>>
>>>> Rather than using 'unordered=1' for unordered, and 'unordered=0' for
>>>> ordered, it would be more obvious to simply use 'ordered' and
>> 'unordered'.
>>> <Raju>
>>> Though I am ok with this style, but to my knowledge, so far none of the
>> SDP properties are defined this way. The related properties are always
>> defined as prop=value style (e.g. AMR octet-align=0/1, OPUS usedtx=0/1).
>>
>> For attributes there are: sendrecv / sendonly / recvonly / inactive
>> rather than sendrecv={0/1/2/3} or
>> direction={sendrecv/sendonly/recvonly/inactive}.
>>
>>> If unordered is confusing, how about using ordered=0 or 1 and make 1 as
>> the default value?
>>
>> That would be an improvement. It is similar to boolean callee
>> capabilities. ('isfocus' is short for 'isfocus=true'.)
>>
>> IMO this is mostly an esthetic choice. I'd appreciate hearing what
>> others think.
>
> <Raju2>
> Sure, let's wait for comments. If no major objections we want to keep ordered=0/1 syntax.
> </Raju2>

OK

>>> </Raju>
>>>
>>>>
>>>> Are all combinations of max_retr, max-time, unordered, [ordered]
>>>> allowed? (There are 8 such combinations, but there are only 6 data
>>>> channel types in rtcweb-data-protocol.)
>>>>
>>>> (The syntax for the dcmap attribute suggests that all combinations are
>>>> valid.)
>>>
>>> <Raju>
>>> Agreed. We will add text to indicate the combinations should be allowed
>> per rtcweb-data-protocol spec.
>>> </Raju>
>>
>> The two excluded ones are those that have both max-retr and max-time
>> (ordered or unordered). Does SCTP exclude those combinations? (I don't
>> think so.)
>
> <Raju2>
> I believe max-retr and max-time are application level concepts but not SCTP transport.
> In both the cases retransmissions of SCTP data chunks does happen but the point at which retransmissions are stopped is different; for "retransmit" type they are stopped when # of retransmissions exceed 'max-retr' value; for "timed" typed are stopped when total elapsed time reaches 'max-time'.
> So, they are mutually exclusive.
> </Raju2>
>
>>
>> Is there a reason to exclude those? Perhaps simply note that webrtc
>> doesn't support those two combinations.
>
> <Raju2>
> As mentioned, by definition max-retr and max-time are mutually exclusive.
> Section "5.1.2 Methods" of http://w3c.github.io/webrtc-pc/ says:
>> 5. If both the maxPacketLifeTime and maxRetransmits attributes are set (not null),
>> then throw a SyntaxError exception and abort these steps.
>
> So, I think rejecting such an SDP offer is acceptable here.

OK. You have convinced me. So there should be some text stating that 
max-retr and max-time are mutually exclusive. (It isn't feasible to 
impose such a constraint in the ABNF. I could do it, but it would be ugly.)

	Thanks,
	Paul