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

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

> >>>> Q4:
> >>>>
> >>>> I have issues with the max_retr, max_time and unordered parameters.
> >>>>
> >>>> First, they seem to specify SENDING capabilities, rather than RECEIVING
> capabilities.
> >>>>
> >>>> Second, they seem to describe characteristics associated with the
> subprotocol, in which case they could be specified in the associated
> subprotocol specification.
> >>>
> >>> This should be a topic for discussion in London.  As it is currently
> written, these parameters are of the "take it or leave it" variety, i.e.,
> the answerer either accepts the options listed
> >>> in the offer or rejects the data channel outright.  This is true for the
> in-band control protocol (please correct me if I am wrong on this), so we
> adopted the same approach for the
> >>> SDP-negotiated case.  Some have suggested that we should allow more
> flexibility in negotiation of these parameters when using SDP.  If there is
> general agreement that it should be
> >>> done this way, I see no problem with defining parameter negotiation
> rules for SDP in the next version of the draft.
> >> The difference is that your draft is based on Offer/Answer, which is
> about indicating receiving capabilities (yes, I know we have broken that
> rule in the past).
> >
> > There are many examples of attributes that use different negotiation
> models than this.  The only requirement is that the semantics of the
> negotiation be defined in the document defining the attribute.
> 
> I still don't think the information belong to SDP - they define protocol
> characteristics. The protocol specification should define re-transmission
> timers etc.
> 
> Anyway, we can argue about it later. At this moment I think the focus should
> be on whether to move forward with the mechanism to begin with, and the main
> feature of the mechanism - which is about negotiating usage of channels :)

[Raju] Sorry to continue this discussion here instead of London, which I won't be attending.

I also believe that we do need these max_retr, max_time and unordered in the SDP.
These map to the data channel init parameters specified in http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel . In case of DCP these are used by "5.1.  DATA_CHANNEL_OPEN Message" of http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03 
Combination of these parameters will determine the type of 
DATA_CHANNEL_OPEN open that will be sent.

For non-DCP external negotiation use case, these values have to be communicated to the peer. Since we want to closely follow DCP, which allows only one set of these values to be negotiated for both the directions, SDP offer/answer will do that same. Receiving end should accept these values, give it to data channel stack and echo them back to the offerer.
This way in external negotiation case as well, similar to DCP, both the peers will have same set of data channel attributes (reliable or partial reliable, ordered or unordered, timed or # of retransmission).

We will make the following changes, if agreed by others, in the next draft:
1. Add a new "reliable/partial reliable" SDP attribute, which is missing now.
   This is needed to map to the exact data channel type using external negotiation.
2. Map these SDP attributes to relevant DCP and PeerConnection sections.
   Need to make updates to SDP whenever DCP and/or PeerConnection is changed.
3. Specify either max_retr (retransmit data channel) or max_time (timed data channel)   
   present, but NOT both.

Best Regards
Raju