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

[Christer Holmberg <[e-mail]>]

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