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

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Jul 2006 17:00:09 +0100

Gunnar,

On 20 Jul 2006, at 17:50, Gunnar Hellstrom wrote:
> The textphone with limitations we are talking about is in the PSTN.  
> The
> gateway should not imply any limitations on the IP side.
>
> But we want to give the IP terminal user a hint that the far end  
> user may
> not be able to receive anything while she is typing. So she must  
> take care
> and adopt the old turntaking habits ending typing with GA and  
> waiting for
> the other one to end with GA ( or whatever turntaking token is used  
> in her
> country )

I understand your use case. I just do not think it appropriate for a  
content label.

> That is very similar to using the user-floor parameter giving the  
> user a
> hint that you may not be seen all the time and may need to request  
> the floor and be acknowledged for the others to see you.
>
> We apparently need to enter more words around what terminal it is  
> that has
> the limitations and how it influences the media flow ( = not at all  
> on the
> IP path ).
>
> Would that eliminate your problems with the "txp" parameter?

No. If you make this a separate attribute, I will have no objections,  
but as I have said before, I do not believe such feature negotiation  
belongs in the content label attribute.

Colin

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Gunnar Hellstrom <[email-masked]>
Date: Thu, 20 Jul 2006 23:04:42 +0100

Colin,

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.

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?

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
[email-masked]
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Thursday, July 20, 2006 5:00 PM
To: Gunnar Hellstrom
Cc: [email-masked]
Subject: Re: [MMUSIC] I-D
ACTION:draft-ietf-mmusic-sdp-media-content-04.txt

Gunnar,

Colin

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Jul 2006 09:19:05 +0100

Gunnar,

> have been done without really saying what is wrong with having this

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.

> simply to inform the user about the type of origin for this medium. No

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

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Fri, 21 Jul 2006 12:08:04 +0200

> draft. Neither outcome seems desirable.

[Arnoud van Wijk] 
Umm sorry, but I do not understand that at all. 
The legacy textphone is in most cases half duplex in behaviour. And it has
nothing to do to say that a device is full duplex originally.
The half duplex nature is NOT in media streams etc, it is all in the matter
of waiting for each turn before typing your text.
For IVR, a text IVR then, it has no difference at all, since you see please
select a number for:
1 call tech support
2 call marketing
3 leave a message

Common sense will always have people wait till they see a text message. 

And one of the most common usecase of a legacy textphone to connect with an
IP device is:
PSTN textphone---(V18)----Text gateway----(T140/RTP)-----IP device with
RFC4103 text

The text gateway is full duplex, just as any normal IP to IP SIP
communication. Text can be sent incoming and outgoing.
The text gateway will just transcode the T140 into V18 (or any other legacy
textphone protocol) and send/receive this.

It is that both users must take turns here to avoid that the legacy
textphone end sup with overlapping text from sender and receiver. After all,
most textphones have a single screen where text can be OR what you type OR
what you receive.

So, it has NOTHING to do with negotiations of any capabilities. That has NO
effect on the call setup whichsoever. No legacy textphone users are blocked
in calls and services.
And if the PSTN textphone gets upgraded to become a native IP textphone
without a text gateway inbetween, it can still require turn by turn text
since it still uses a single screen. Or the user prefers it that way.

> attribute with the required semantics, and well defined offer/answer
[Arnoud van Wijk] 
There is NO offer/answer behaviour at all. It has nothing to do with that.
So, there is no need for a new SDP attribute.

This content:txp is already implemented in a Dutch text gateway and it works
very well.
The worst that happens is that a client does not understand the content
label. Then all you get is that the user discovers a bit later that oh
oops..ok I have to wait till the other person is done typing before I do
that. "I wish I had known that before...that would be less embarassing".
You have to look in the concept, IP text users will always have a split
screen and be used to typing and receiving text simultaneously. So a call
from a PSTN textphone will be less common within 2 years. It is then very
much appreciated to know that the text stream is from a PSTN textphone with
almost always turn based behaviour.

If it was really about device capabilities and the call negotiation, I would
perfectly understand your concern and issue here. But this is not the case.

Cheers

Arnoud

PS You can see, miscommunication and misunderstanding each other is not
limited to deaf and hard of hearing people :-)

Arnoud A. T. van Wijk
AnnieS New Technology
www.AnnieS.nl
Mobile textphone (SIP): [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Jul 2006 11:42:33 +0100

Arnoud,

What you are describing is, to my view, exactly device capability  
negotiation (i.e. the device only has the capability to display one  
set of text, so input and output overlap).

Colin