Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel-gateway considerations - direction attributes - text based on 3264

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2019 09:33:55 +0000

Hi,

Based on the text in 3264, I drafted some text regarding the offer/answer procedures for the direction attributes with T.140 data channels.

I plan to add it to the pull request, so we don't need to do any e-mail editing, but please let me know if you think the approach is correct, or if you think something is missing.

-----

X. Direction Attributes

The offer/answer rules for the direction attributes are based on the rules 
for unicast streams defined in RFC 3264, as described below. Note that the 
rules only apply to the direction attributes. The generic offer/answer rules 
for data channels are defined in draft-sdpneg.

Note that the direction attributes only apply to the T.140 data channel for which
they are set. They have no impact on other data channels (including other T.140
data channels) realized by the SCTP association.

Session level direction attributes have no impact on a T.140 data channel. An 
offerer and answerer MUST mark the direction of the text by sending a direction
attribute inside ‘dcsa- attribute.

X.1. Generating an Offer

If the offerer wishes to both send or receive text on a T.140 data channel, it
MUST mark the data channel as sendrecv with a ‘sendrecv’ attribute inside a 
‘dcsa’ attribute. If the offerer does not explicitly mark the data channel, a
‘sendrecv’ attribute inside a ‘dcsa’ attribute is implicitly applied.

If the offerer wishes to only send text on a T.140 data channel, it
MUST mark the data channel as sendonly with a ‘sendonly’ attribute inside a 
‘dcsa’ attribute. 

If the offerer wishes to only receive text on a T.140 data channel, it
MUST mark the data channel as sendonly with a ‘sendonly’ attribute inside a 
‘dcsa’ attribute. 

If the offerer wishes to neither send or receive text on a T.140 data channel, it
MUST mark the data channel as inactive with a ‘inactive’ attribute inside a 
‘dcsa’ attribute. 

If the offerer has marked a data channel as sendrecv (implicit or explicit) or recvonly, it MUST be
prepared to receive T.140 data as soon as the state of the T.140 data channel allows it. 

When the offerer receives an answer to the offer, if the answerer has marked a 
data channel as sendrecv (implicit or explicit) or recvonly in the answer, the offerer
can start to send T.140 data as soon as the state of the T.140 data channel allows it.
If the answerer has marked the data channel as inactive or sendonly, the offerer MUST NOT
send any T.140 data.

X.2. Generating an Answer

When the answerer accepts an offer, and marks the direction of the text 
in the corresponding answer, the marking is based on the marking (explicit or implicit) 
in the offer.
 
If the offerer marked the data channel as sendrecv (implicitly or explicitly), 
the answerer MUST mark the data channel as sendrecv, sendonly, recvonly or inactive
with a ‘sendrecv’, ‘sendonly’, ‘recvonly’ respective ‘inactive’ attribute
inside a ‘dcsa’ attribute. If the answerer does not explicitly mark the data channel, a
‘sendrecv’ attribute inside a ‘dcsa’ attribute is implicitly applied.

If the offerer marked the data channel as sendonly, the answerer MUST
mark the data channel as recvonly or inactive with a ‘recvonly’ respective
‘inactive’ attribute inside a ‘dcsa’ attribute. 

If the offerer marked the data channel as recvonly, the answerer MUST
mark the data channel as sendonly or inactive with a ‘sendonly’ respective
‘inactive’ attribute inside a ‘dcsa’ attribute. 

If the offerer marked the data channel as inactive, the answerer MUST
mark the data channel as inactive with a ‘inactive’ attribute inside a 
‘dcsa’ attribute.

If the answerer has marked a data channel as sendrecv or recvonly, it MUST be
prepared to receive data as soon as the state of the T.140 data channel allows
transmission of data. 

X.3 Modifying the direction

If an endpoint wants to modify the direction of the text during an ongoing session, it
will initiate an offer, following the rules in Section X.1. If the answerer accepts the offer
it follows the procedures in Section X.2.

------

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 30 Aug 2019 14:01:21 +0200

> I plan to add it to the pull request, so we don't need to do any e-mail editing, but please let me know if you think the approach is correct, or if you think something is missing.

I think the approach is right.

I think the wording for sendrecv being the default is strange. It says 
that you MUST set 'sendrecv' if you want it, but if you do not, 
"sendrecv " is used.

You have not motivated why you cannot act on the session level direction 
attribute in a T.140 data channel.  The existence of these attributes on 
session level was what trigged me to keep thinking that we would need to 
specify support for them. Why do you not want to let the T.140 data 
channel be influenced by a session level attribute?

I would also want to know from multi-party media server implementers if 
muting/unmuting of media is usually done by these direction attributes, 
or by other methods, so that we know if there is a need for this.

Regards

Gunnar

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2019 12:06:06 +0000

Hi,

The pull request has now been updated with the text below (with a few minor changes).

Regards,

Christer

On 30/08/2019, 12.34, "mmusic on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    -----
    
    X. Direction Attributes

    
    
    X.1. Generating an Offer

    

    

     

    

    
    
    ------
    
    Regards,
    
    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2019 12:14:59 +0000

Hi,

>    that you MUST set 'sendrecv' if you want it, but if you do not, 
  
Good point. I can change to SHOULD.

>    channel be influenced by a session level attribute?
  
Since the SCTP association is not affected, it sounds strange to me that a data channel using the SCTP association would be affected.

In addition, I think it will keep things more simple by mandating the dcsa attributes. That's what they were made for, and we avoid having to describe all kind of situations, e.g., where there the session level attribute does not match with the dcsa level attribute etc.

And, again, session level attribute impacts on data channel belongs to data-channel-sdpneg.

>    or by other methods, so that we know if there is a need for this.

If you are using SDP to do it, this is the only method I am aware of.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Aug 2019 10:48:47 -0400

> I plan to add it to the pull request, so we don't need to do any e-mail editing, but please let me know if you think the approach is correct, or if you think something is missing.

In general this looks good to me. I added a couple of comments below.

> MUST mark the data channel as sendrecv with a ‘sendrecv’ attribute inside a

The MUST above is negated by the default below. Reword to remove it.

> MUST mark the data channel as sendonly with a ‘sendonly’ attribute inside a

I think the MUST in the above sentence is a bit odd. Clearly I can send 
without specifying sendrecv. The actual point of sendonly is that I 
don't want to receive. The "only" says that but doesn't emphasize it. 
Also, this is not about sending and receiving, it is about indicating a 
desire regarding sending and receiving. So perhaps:

"To indicate a desire to send but not receive text on a T.140 data 
channel an offerer ..."

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2019 22:39:05 +0000

Hi,

>> X.1. Generating an Offer
>> 
>> If the offerer wishes to both send or receive text on a T.140 data 
>> channel, it MUST mark the data channel as sendrecv with a ‘sendrecv’ 
>> attribute inside a
>

The text in the pull request now says SHOULD.

>> MUST mark the data channel as sendonly with a ‘sendonly’ attribute 
>> inside a ‘dcsa’ attribute.
>
> I think the MUST in the above sentence is a bit odd. Clearly I can send without 
> specifying sendrecv. The actual point of sendonly is that I don't want to receive. 
> The "only" says that but doesn't emphasize it. 

I am using the wording from RFC 3264 :)

>Also, this is not about sending and receiving, it is about indicating a desire regarding sending and receiving. So >perhaps:
>
>"To indicate a desire to send but not receive text on a T.140 data channel an offerer ..."

The text does say "wishes to send/receive". I think that is more or less the same as "desire".

Regards,

Christer