Re: [MMUSIC] FW: I-D Action: draft-schwarz-mmusic-t140-usage-data-channel-03.txt

["Schwarz, Albrecht (Nokia - DE)" <[e-mail]>]

Hello Gunnar,

like to reply on two aspects:

1) Which reliability mode?
We had also the "reliable mode" in mind, understood that you are indicating some follow up aspects which need to be specified.

2) Event of "channel break" and option of "reconnection"
Our understanding: such an event would be tight to the (temporary) interruption of a lower layer connection oriented protocol, i.e., the SCTP Association or the DTLS connection. Such a lower layer event would impact ALL WebRTC data channels, i.e., wouldn't be exclusive to T140 data in our understanding.

Any comments?
Albrecht

From: Gunnar Hellström [mailto:[e-mail]]
Sent: Freitag, 2. September 2016 11:51
To: Schwarz, Albrecht (Nokia - DE) <[e-mail]>; [e-mail]
Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-mmusic-t140-usage-data-channel-03.txt


I see in this mail that the t140-usage-data-channel is on hold.

I would like to open a discussion on topics not related to the reason for the hold.

I see that I am mentioned in two unresolved issues in the draft. It would be good to resolve them. They are located in section 5.1.1.3, sdp examples.

"a=dcmap:1 label="text conversation";subprotocol="t140"; ordered=true;max-time=???;max-retr=??? ; NOTE 1

NOTE 1 - Maximum number of retransmissions = ??? (because FIXTHIS

     <Gunnar>);

              Maximum retransmission timing     = ??? (because FIXTHIS

     <Gunnar>)."

This issue relates back to discussions in RTCWEB about characteristics in case of communication problems for the data subchannel used.
The question is if we shall use the "reliable" mode of the data channel or a "semi-reliable" mode with a maximum time for retries or a maximum number of retries.

It also requires a decision on what to recommend in case of such errors.
If the channel breaks as it does when working in the "reliable" mode, shall we then recommend a reconnection, with an effort to avoid duplication and detect loss, or shall we recommend to break the whole application session?
If the channel sustains but reports error, as it does at least in some cases for the errors in the "semi-reliable" modes, do we then have sufficient information from the underlying protocol for the receiver to avoid duplication and detect loss, or do we need to specify an application level sequence numbering and check?
T.140 requires transmission free of duplication.
EN 301 549 requires marking in the text stream of possible places of loss in case of transmission error.

I would like to be able to recommend to use the reliable mode of the data subchannel, because I expect it to be most commonly well supported and best tested.
The question is if it provides us with suitable characteristics.

We need:
Rapid transfer of small chunks of data at least three times per second.
No duplication of data.
Indication to the receiver of possible loss. ( or no loss ...)
Small or no risk for stallling, waiting for result of retries when it would instead be possible to transmit successfully. (very rare occasional waiting of up to 10 seconds might be allowable (???) )

Regards,
Gunnar





Den 2016-04-04 kl. 10:48, skrev Schwarz, Albrecht (Nokia - DE):

fyi, only keep-alive updates related DC candidate protocols No. 2 and 3 (T.140 & BFCP):

draft-schwarz-mmusic-t140-usage-data-channel-03.txt

draft-schwarz-mmusic-bfcp-usage-data-channel-02.txt



The technical work is currently suspended due to the dependency on "DC protocol No.1 'MSRP'":

draft-ietf-mmusic-data-channel-sdpneg

draft-ietf-mmusic-msrp-usage-data-channel



As you know there is currently a side discussion ongoing related the principle proceeding how the correspondent IANA registry should be architected.

(See agenda: 11:30-11:50 IANA Registry Structure for SDP Attributes (20 mins, Christian Groves & Paul Kyzivat)



Regards,

Albrecht



-----Original Message-----

From: I-D-Announce [mailto:[e-mail]] On Behalf Of EXT [e-mail]<mailto:[e-mail]>

Sent: Montag, 4. April 2016 10:31

To: [e-mail]<mailto:[e-mail]>

Subject: I-D Action: draft-schwarz-mmusic-t140-usage-data-channel-03.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.





        Title           : T.140 Text Conversation over Data Channels

        Authors         : Keith Drage

                          Juergen Stoetzer-Bradler

                          Albrecht Schwarz

   Filename        : draft-schwarz-mmusic-t140-usage-data-channel-03.txt

   Pages           : 19

   Date            : 2016-04-04



Abstract:

   This document specifies how the ITU-T Protocol for multimedia

   application text conversation (Recommendation ITU-T T.140) can be

   instantiated as a data channel sub-protocol, using the SDP

   offer/answer exchange-based external negotiation defined in [I-

   D.ietf-mmusic-data-channel-sdpneg]. Two network configurations are

   documented: a WebRTC end-to-end configuration (connecting two T.140

   over data channel endpoints), and a gateway configuration

   (connecting an T.140 over data channel endpoint with an T.140 over

   RTP/UDP endpoint).





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-schwarz-mmusic-t140-usage-data-channel/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-03



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-schwarz-mmusic-t140-usage-data-channel-03





Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic



--

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

Gunnar Hellström

Omnitor

[e-mail]<mailto:[e-mail]>