Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01

[Paul Kyzivat <[e-mail]>]

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