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

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 Jan 2020 20:57:16 +0000

Hi,

    >>>>>      §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."

I think the text could be improved, but I order to be aligned I can live with it.

Regards,

Christer