Re: [MMUSIC] Draft new version: t140-data-channel-usage-03 -buffering

Hi, see comment on buffering below.

--------------------------------------------------------------------

Hi,

>The changes made in -03 seem fine to me.
>
>Then I realized that I have only been looking at diffs for awhile, and haven't carefully reviewed the full document for awhile.
>So I did that, and found some other thing that I think are worthy of consideration:
>
>* Section 4:
>
>s/proceudres/procedures/

I'll fix that (however, I think that could be considered a WGLC comment).

---

>* Section 4.2:
>
>The subsections 4.2.n describe some specific SDP attributes that may be used with T.140 data channels. But it isn't definitive about
>other attributes. I think you should be explict whether other attributes maybe included. In any case, I think it would be prudent to
>specify that if other attributes are *received* and are not understood then they are to be ignored, in order to be consistent with SDP treatment of attributes.

I think SDPNEG shall (unless it already does) define generic procedures for receiving non-supported SDP attributes in dcsa. I assume it would be the same as for non-supported SDP attributes in general - ignore them.

---

>* Section 4.2.1:
>
>This section is a little hard to follow. The use of fmtp with data channels is complicated, since the value part of fmtp is dependent on
>the fmt in the m= line. You do reference RFC4103, but it is still a leap to put this all together.
>
>I suggest you first discuss the general use of fmtp with data channels - that the value syntax of fmtp is to follow RFC4103.
>
>*Then* you can move on to discuss the use of 'cps'.
>
> It isn't clear to me if there are any other meaningful or permitted fmtp parameters. I suggest you make a definitive statement about this.

Ok, I can have a look at that.

>* Section 5:
>
>These examples are good. But there is no example for CPS, and it would be nice to have one. Rather than having a separate example for each,
>I think it would be sufficient to fold multiple attributes into a single example.

CPS is used in the second SDP example.

But, I guess I can remove the SDP examples everything, and include everything in O/A example(s).

---

* Section 5.3:

>In the following:
>
>    As described in [T140], buffering can be used to reduce overhead,
>    with the maximum buffering time being 500 ms.  It can also be used
>    for staying within the maximum character transmission rate
>    (Section 4.2), if such has been provided by the peer.
>
> it is unclear to me whether the 500ms max time is applicable when using buffering to stay
>within the max transmission rate. I presume not. Can you be more explicit?

I will let Gunnar give his opinion on that.

Personally I would assume that it is an implementation issue when it comes to buffering in order to stay within the max transmission rate, and at some point an implementation may simply choose to terminate the session due to buffer overload
[GH] The 500 ms max time between transmissions still apply when one participant produces more text than the cps value allows. You keep on transmitting from the buffer, but do not take more than allowed.  Rfc 4103 says that the mean cps is over any 10 second period. It might be good torepeat that in thi draft.

Regards
Gunnar

---

* Section 5.4:

>It isn't clear to me whether this is talking about failure and re-establishment of individual data *channels*, or of the
>containing SCTP association. I guess you mean both. But it would be good to be explicit, since the process for doing
>so is a bit different.

As far as the T.140 procedure is concerned, it doesn't matter only the data channel or the whole association went done - the procedure describes what happens once the data channel has been re-established.

But, I can add text clarifying that individual data channels, or the whole SCTP association, mail fail.

---

* General:

>Perhaps replace the references to RFC4566 throughout with references to RFC4566bis. It is already in the editor's queue
>so shouldn't cause a delay. Since you have no dependency on the updates in RFC4566bis this isn't an essential change. It is just a nice-to-have.

I can do that. After all, SDPNEG also references 4566bis, so..

Regards,

Christer

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic