Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt

Gunnar,

On 20 Jul 2006, at 23:04, Gunnar Hellstrom wrote:
> I do not understand why the discussion has taken this turn.
> As I remember it, the txp parameter was introduced by the authors  
> sometimes
> last autumn. It was a discussion between using the user-floor  
> parameter and
> having one specific and the decision was to have one specific, even  
> if it
> was no big preference.
>
> Arnoud has declared that he has very good use of the parameter  
> already in a
> gateway - terminal implementation.
>
> Then this winter we have been asked to refine the wording, and done  
> so.
>
> And now you start claiming that the whole idea was a mistake and  
> should not
> have been done without really saying what is wrong with having this
> parameter.

I didn't realise the implications of your revision to V.151 Annex D  
until recently. If I had done so earlier, I would have made these  
comments earlier.

> You claim that I have proposed to use it for negotiation in the draft
> amended V.151 Annex D, but I have not.
> The explicit wording about use of the parameter is this:
> "The line "a=content:txp" is sent from the gateway as an indication  
> that
> half duplex procedures should be applied by the users in the text  
> stream."
>
> It is clearly just an indication to the users. It must be shown in  
> the user
> interface.
> It is not used to accept or deny the stream or anything like that.  
> Just
> simply to inform the user about the type of origin for this medium. No
> negotiation.
>
> Accept now?

You are using this parameter to signal that a device which is  
normally full-duplex is now actually half-duplex, but without any  
proper negotiation of that feature. You claim that is acceptable,  
since it's a user interface cue, not intended to be processed by  
automata. That seems to limit users of legacy text phones to  
interacting with other humans, blocking them from access to automated  
response systems (which will be able to tell that half-duplex is  
needed). Alternatively, an automated system must use this parameter  
negotiate the device capabilities, in violation of section 6 of the  
draft. Neither outcome seems desirable.

To avoid these problems, I again suggest you define a new SDP  
attribute with the required semantics, and well defined offer/answer  
behaviour.

Colin

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic