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

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

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>

> 
> > </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.

</Raju2>

Thanks
Raju