Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

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

Hi Christer,

Please find my comments inline.

> 
> Especially considering Richard's draft, I thought the whole idea was to be
> able to negotiate the subprotocol using SDP.
> 
> > Also, we still have an open question about what attributes must be present
> in a subprotocol
> > specification. It is at least possible that some subprotocols may work
> with a variety of settings of
> > these attributes.
> 
> Well, in that case the subprotocol specification should define the
> additional SDP attributes needed.
> 
> > This draft should probably say more about this. It could say that:
> >
> > * the SDP MUST be consistent with the attributes specified in the
> subprotocol definition, OR
> >
> > * the SDP MUST NOT specify attributes specified in the subprotocol
> definition, OR
> >
> > * attributes specified in the SDP override those specified in the
> subprotocol definition.
> 
> If people see a need for these attributes, fine. But, I still have not seen
> an example where it would be needed (e.g. the UDP RFC does not specify the
> timers for SIP - RFC 3261 does :)

[Raju] Aren't the attributes we are talking here are data channel properties?
DCP explains the following type of data channel as:
      DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):  The channel provides
         a partial reliable in-order bi-directional Communication
         channel.  User messages might not be transmitted or
         retransmitted after a specified life-time given in milli-
         seconds in the Reliability Parameter.  This life-time starts
         when providing the user message to the Javascript engine.

Fo example,'maxRetransmitTime' value specified by createDataChannel API (SDP's maxtime) here is realized by data channel stack, NOT by the application. The timer value given by the client may be a generic value rather than specific to a subprotocol. To draw comparision to TCP, Linux allows TCP_USER_TIMEOUT sockopt which allows application to specify max timer value for any unacknowledged data. 'maxRetransmitTime' is similar.
The SIP analogy mentioned above is for subprotocol level timers but not for transport level retransmissions timers. A subprotocol could have it's own retransmission timer for lack of response for a req. Lack of subprotocol response could still happen, if the peer application drops the request, even when data channel successfully sent the request. 

So, I think timers (parameters) at both data channel stack and subprotocol have clear semantics and mostly independent of each other.

Best Regards
Raju