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

[Paul Kyzivat <[e-mail]>]

On 1/26/20 2:25 PM, Gunnar Hellström wrote:
> 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.

I agree. There is no way to *reject* an answer.

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

The tricky part of treating the O/A as having failed is that only the 
offerer knows this, while the answerer thinks it has succeeded. So the 
two sides have differing understandings of the state of the session. 
(Consider that there may also have been changes in another media 
section.) Things will not go well until this is corrected.

I don't know if there is any document that specifies what to do in this 
situation. I think there are only two generic possibilities: drop the 
entire session (i.e., BYE), or start another O/A to try to fix this, 
perhaps by dropping the m= line. When following this latter course, 
there will be an extended period while the two sides are in 
disagreement, and no guarantee that the fix will work.

The simplest solution is to simply say that this is a protocol 
violation, and recovery is an implementation issue. While simple to 
write, this is perhaps not the best solution.

	Thanks,
	Paul

> 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]
> [phone]
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>