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

[Christer Holmberg <[e-mail]>]

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.

Regards,

Christer