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

[Paul Kyzivat <[e-mail]>]

WFM

On 1/27/20 3:07 PM, Christer Holmberg wrote:
> Hi,
> 
>      >>      >>>> 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.
>      >>      >>
>      >>      >> That is normally what we say.
>      >>      >>
>      >>      >> However, if more text is needed I think it belongs to the data channel sdpneg draft. I don't think that each data channel usage draft shall have to describe how it is done.
>      >>      >
>      >>      > Then I think the best path might be to update sdpneg with some specific
>      >>      > language, and then update this draft to refer to that.
>      >>
>      >> We can do that. However, we don't need to wait for that until we progress this draft. It is anyway not going to be published until sdpneg is done.
>      >
>      > The only concern is that I think there ought to be a reference to
>      > whatever sdpneg will say on the subject. But perhaps it is possible to
>      > craft a reference that works assuming that sdpneg will be updated,
>      > without waiting for that update to be made.
> 
> I suggest that we add the following text to the T140 data channel draft:
> 
>            "The offerer and answerer MUST NOT include the max-retr or the max-time
>            attribute parameters in the 'dcmap' attribute. If any of the
>            attribute parameters is received in an offer, the answerer
>            MUST reject the offer.
> 
>            If any of the attribute parameters is received in an answer the offerer
>            MUST NOT accept the answer. Instead, the answerer MUST take appropriate
>            actions, e.g., by sending a new offer without a T.140 data channel, or by terminating
>            the session."
> 
> Similar text can be added to sdpneg, but at least then we are not dependent on it.
> 
> Regards,
> 
> Christer
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>