Re: [MMUSIC] AD Review: draft-ietf-mmusic-t140-usage-data-channel

[Gunnar Hellström <[e-mail]>]

Hi,

Den 2020-01-26 kl. 17:54, skrev Christer Holmberg:

Hi Gunnar,

    >>>>      §4.1:
    >>>>
    >>>>       The offerer and answerer MUST NOT include the max-retr and max-time
    >>>>       attribute parameters in the 'dcmap' attribute.
    >>>>
    >>>>      Ideally, this would include text that indicates what a recipient of such
    >>>>      messages would do (with the obvious choices being ignoring them or treating
    >>>>      them as an error). I suggest the easiest thing to specify is that recipients
    >>>>      of either attribute for a T.140 section MUST ignore them.
    >>>>
    >>>> Just to note:
    >>>>
    >>>> - The draft defines that the T.140 data channel is reliable.
    >>>> - max-retr and max-time are used to indicate that a data channel is partially reliable, so there would be a conflict.
    >>>>
    >>>> So, the question is whether it is ok to just ignore, or whether it is a protocol error and the m- line therefore should be rejected.
    >>>>
    >>>> If *both* attribute parameters are included in an offer (which would also create a conflict), draft-channel-sdpneg says that the offer must be rejected.
    >>>
    >>> Given this last fact, it seems that the best approach would be to treat
    >>> the presence of either parameter in this context as an error. The key
    >>> here is that the behavior should be spelled out.
    >>
    >> I suggest the following:
    >>
    >> OLD:
    >>
    >>     The offerer and answerer MUST NOT include the max-retr and max-time
    >>     attribute parameters in the 'dcmap' attribute.
    >>
    >>
    >> NEW:
    >>
    >>     The offerer and answerer MUST NOT include the max-retr and max-time
    >>     attribute parameters in the 'dcmap' attribute. If any of the
    >>     attribute parameters are included in an offer or answer, the receiver
    >>     MUST take the proper actions to reject the SDP.
    >>
    > In RFC 3264, there are only ways for the answering party to reject an
    > SDP specified.
    >
    > If you mean that the offering party should reject the SDP, how should it
    > behave? Make a re-invite without the subchannel in error? Can that
    > really be called "reject the SDP"?  Or is a rapid close of the whole
    > session and all connections with an error indication the proper action?

We don't specify HOW an answer is rejected, because that is a generic procedure that 3264 is supposed to specify. We only say "take the proper actions".

Or, if there are some data channel specific procedures for rejecting offers and/or answers, those should be specified in draft-sdpneg.

What I mean is that after the offer-answer procedure has been performed, it is too late to say that the SDP shall be rejected.

sdpneg has the following wording in 6.2 for the error case when both parameters are included in the answer:

  "If an SDP answer contains both
   of these parameters then the offerer MUST treat the associated SDP
   offer/answer as failed."

We should use similar wording.
Proposal for the NEW wording:
   "The offerer and answerer MUST NOT include any of the max-retr or max-time
    attribute parameters in the 'dcmap' attribute. If any of these
    attribute parameters are included in an offer, the answering part
    MUST take the proper actions to reject the SDP. If an SDP answer contains any
    of these parameters then the offerer MUST treat the associated SDP
    offer/answer as failed."

Then we get language and logic matching sdpneg.
/Gunnar




Regards,

Christer





--

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[e-mail]<mailto:[e-mail]>
[phone]