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

[Gunnar Hellström <[e-mail]>]

Hi,

See a comment at the end of the proposed text:

Den 2020-01-24 kl. 14:09, skrev Christer Holmberg:
> 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?

/Gunnar
>   ---------------------------------------------------------------------------
>   
> Regards,
>
> Christer
>   
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[e-mail]
[phone]