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

"Makaraju, Maridi Raju (Raju)" <> Tue, 25 February 2014 18:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 439061A0126 for <>; Tue, 25 Feb 2014 10:26:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ug4EG0AqsUVo for <>; Tue, 25 Feb 2014 10:26:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5E0271A0111 for <>; Tue, 25 Feb 2014 10:26:32 -0800 (PST)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id s1PIQSF0029700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 12:26:28 -0600 (CST)
Received: from ( []) by (GMO) with ESMTP id s1PIQR7R015876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 13:26:28 -0500
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Tue, 25 Feb 2014 13:26:27 -0500
From: "Makaraju, Maridi Raju (Raju)" <>
To: Christer Holmberg <>, Paul Kyzivat <>, "" <>
Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSND/9sNUAP/taKmw/9rN9bA=
Date: Tue, 25 Feb 2014 18:26:26 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Feb 2014 18:26:34 -0000

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