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

From: [email-masked]
Date: Fri, 17 Feb 2006 18:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: The SDP (Session Description Protocol) Content Attribute
	Author(s)	: J. Hautakorpi, G. Camarillo
	Filename	: draft-ietf-mmusic-sdp-media-content-01.txt
	Pages		: 11
	Date		: 2006-2-17
	
This document defines a new Session Description Protocol (SDP) media-
level attribute, 'content'.  The 'content' attribute defines the
content of the media stream in more detailed level than the media
description line.  The sender of an SDP session description can
attach the 'content' attribute to one or more media streams.  The
receiving application can then treat each media stream differently
(e.g., show it on a big screen or small screen) based on their
content.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-content-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-sdp-media-content-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-media-content-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 18 Feb 2006 08:16:05 +0100

Gonzalo and all,

I saw that you now have two accessibility related features described in the
sdp-media-contents specification. I am glad that you have picked up these
needs.
It is the "sl" token for sign language and the "txp" token for textphone
media.

I think the draft is good. I just have one terminology question and one
timing question, and a general usage discussion:

Terminology:
------------
You use "TDD" as a term for an analogue text telephone. In my view, TDD is a
US term for a specific type of text telephone.
I suggest that you adopt the same terminology as RFC 3351, and simply call
it a "textphone".

This is how RFC 3351 defines it:

"Textphone: Sometimes called a TTY (teletypewriter), TDD (telecommunications
device for the deaf)
or a minicom, a textphone enables a deaf, hard of hearing or speech-impaired
person to place a call to a telephone or another textphone."

In order to not confuse the reader we could avoid using the term "textphone"
for IP based terminals with full text presentation capabilities. I suggest
to use the clumsy but more general "real-time text capable terminal".

Thus, my proposal is to change the definition of "txp" in section 5 to:

txp: This indicates that the media stream is originated from a textphone,
      and it requires special behavior from the receiving application.
      Typical use case for this is e.g., a connection where one endpoint
      is an analog textphone, and the other one is a native IP based real
      time text capable terminal.

And the use of it in section 10 to:

   txp                          RFC xxxx  Media originated from a textphone

Timing
------
The idea is to define detailed usage of the media content attributes in
other RFC:s
and hook them into the IANA sub-register for the media-content attribute, as
described in section 10.
For the "txp" detailed definition, we could take it into the on-going work
with ietf-draft-sipping-toip , but that gives us an external dependency for
timing of the approval of the sdp-media-content specification.
Do you recommend to make the definition of "txp" in the sipping-toip
specification or in a small separate specification dedicated for that
purpose?

Usage
-----
You have pushed the usage concerns to the specifications listed in section
10, so even if I start a discussion here I realize that you can go on and
finalizing this draft without too much concern over usage.
Anyway, here are some initial thoughts about usage of the "txp" value.
I know that the idea for usage of this parameter is for indicating
limitations in presentation and communication capabilities of the analogue
textphones behind a gateway. We assume that the real-time text capable
terminal on the IP side has full duplex text capability, rich character set
and a speed of transmission that is much more than human input produces.
There may be a need to indicate the limitations when in contact with an
analogue textphone.

But I would like to warn for too much automatic action. The variations
between different analogue textphones may be too wide for that:

-Some textphones are strictly half duplex. Only one can transmit at a time.
Users apply strict turn-taking rules.
-Some textphones have a way for the receiver to indicate a desire to type.
"Interrupt"
-Some textphones communicate in full duplex, but merge transmitted text and
received text in the same line in the same display window.
-Some textphones communicate in full duplex and separate display from
reception and transmission so that the full duplex capability can be used
fully.
-Most textphones allow alternating between voice and text during a call.
Some are text only and some can handle simultaneous voice and text.
-Most textphones use national character sets. 7-bit or even more restricted.
Only a few use Unicode.
-Some textphones can only transmit around 4 characters per second, while
others can transmit 120 characters per second.
Conclusion: The parameter is good, it can be used at least for a indication
in the user interface that there may be restrictions in the presentation and
transmission capabilities of the other terminal. sipping-toip can define
this if timing of progress of the two drafts are favourable.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of [email-masked]
Sent: Saturday, February 18, 2006 12:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Multiparty Multimedia Session Control
Working Group of the IETF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-content-01.t
xt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Send a message to:
	[email-masked].
In the body type:

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Tue, 21 Feb 2006 16:43:27 +0200

Hi Gunnar,

> I suggest that you adopt the same terminology as RFC 3351, and simply call

Good comment. I'll change "TDD" to "textphone", as you have indicated.

> timing of the approval of the sdp-media-content specification.

I'm sorry, I don't understand your problem. Do you think that the 
reference from ietf-draft-sipping-toip draft to sdp-media-content draft 
would slow the progress of ietf-draft-sipping-toip draft too much?

> Anyway, here are some initial thoughts about usage of the "txp" value.

I think that your thoughts about usage were fine. If you want, you can 
specify the usage of "txp" value on some other draft, e.g. in 
ietf-draft-sipping-toip.

-- 
Jani H.

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 21 Feb 2006 21:35:23 +0100

Jani,

Thanks for positive reception of the comments.

There is one need for clarification left.
In section 10, IANA considerations, there is a list with references to RFC
xxxx for descriptions of the values
e.g.
    txp      RFC xxxx  Media is originated from a textphone

Explanation 1
----------------
I understand that so that you expect other specifications to appear and take
responsibility for describing the use of each parameter. Their RFC numbers
will be registered in the table.

Explanation 2
---------------
There could be another explanation: The table in section 10 could be the
initial table, and you regard the meaning of the values enough described in
the media-content specification. Then all xxxx would point at the
media-content specification.

What is our intention? It could be suitable with an RFC-editor note about
the meaning of XXXX and how it shall be handled.

Timing
------
Yes, I was thinking that if we bring in a reference to "txp" in the
sipping-toip specification, then we need to wait until media-content is
published and the table of values registered by IANA until we can proceed to
publication.

Regards
Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked] <mailto:[email-masked]>
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se <http://www.omnitor.se>

-----Original Message-----
From: Jani Hautakorpi (JO/LMF) [mailto:[email-masked]]
Sent: Tuesday, February 21, 2006 3:43 PM
To: Gunnar Hellstrom
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Accessibility related parameters
indraft-ietf-mmusic-sdp-media-content-01.txt

Hi Gunnar,

--
Jani H.

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Wed, 22 Feb 2006 08:34:00 +0200

Gunnar,

> Explanation 2

This is the right explanation. We're planning to register the coming RFC 
number of this draft in the table. But if you want to specify the usage 
of "txp" in some other draft, we can make an informational reference 
from this draft to that one.

> the meaning of XXXX and how it shall be handled.

I'll add a note for RFC-editor.

> published and the table of values registered by IANA until we can proceed to

I guess this isn't a serious problem.

-- 
Jani H.

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Wed, 22 Feb 2006 11:53:18 +0100

I think if we say in the ToIP draft that it is advised to use txp label to
indicate a texttelephone in the call, it should not delay the RFC.
The only thing is that when the RFC is released, will it be possible to swap
the reference to the media content draft with the media content RFC? 

Greetz

Arnoud

> Sent: woensdag 22 februari 2006 7:34
> To: Gunnar Hellstrom
> Subject: Re: [MMUSIC] Accessibility related parametersindraft-ietf-mmusic-
> sdp-media-content-01.txt
> 
> Gunnar,
> 
> > Explanation 2
> > ---------------

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 23 Feb 2006 00:24:06 +0100

Jani,
OK, I understand. Your idea was to have the meaning of the values enough
described in the sdp-media-content specification.

Then we should add a few more words to explain suitable behaviour of a
client receiving the "txp" indicator.

I assume the most common case would be in connection with the m=text media
description.

I dislike to drag the variations of PSTN textphones into requirements on
variations in behaviour of SIP clients. But I cannot figure out how a SIP
client shall react on reception of the txp indication. The expected
variation is too wide with:
-half duplex or full duplex or interruptable half duplex,
-split window or common window,
-simultaneous voice and text or alternating voice and text,
-national character set or further limited or Unicode
-4 or 6 or 10 or 30 or 120 characters per second.

It is tempting to ask for a subparameter for the type of textphone that is
commected beyond the gateway.
One architecturally ugly way to do it would be to ask gateway implementors
to generate a
RFC 2833bisdata event in an audio channel giving information on the type of
textphone in contact, and the application would then have knowledge about
what characteristics to use towards them.
See section 2.7.1 in:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisdata-06.txt

We could make it easy for us and just specify : "txp" indicates that the
other party has a textphone, and that the user should be made aware that
presentation and communication restrictions may apply.

So, the phrase in section 5 deascribing txp could be extended to end like
this:

	Typical use case
      for this is e.g., a connection where one endpoint is an analog
      textphone, and the other one is a native IP based text telephone.
	The user should be made aware that presentation and communication
	limitations exist.

?

Gunnar

-----Original Message-----
From: Arnoud van Wijk [mailto:[email-masked]]
Sent: Wednesday, February 22, 2006 11:53 AM
To: 'Jani Hautakorpi (JO/LMF)'; 'Gunnar Hellstrom'
Cc: [email-masked]; [email-masked]
Subject: RE: [MMUSIC] Accessibility related
parametersindraft-ietf-mmusic-sdp-media-content-01.txt

Greetz

Arnoud

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Thu, 23 Feb 2006 13:46:49 +0100

Gunnar, that is exactly what Jani and I mean here.

It has nothing to do with call mechanism/buffering etc. (RFC4103 already
offers changes in character transmission speed).
It is to alert the user that the media stream is originating from a PSTN
texttelephone.

You have to see it as a person who is used to bi-directional ToIP on a split
screen. Both users send and receive text simultaneously.
Then next call originates from a PSTN texttelephone and the user needs to be
aware that they have to wait until the other has finished typing and
indicates that it is the users turn now to type.

The txp label will also allow, depending on the user interface, to go from
split screen to a single screen, more or less behave like a PSTN
texttelephone. (and disallow cut and paste of more then 50 characters to
avoid flooding the PSTN textphone).
But it can just as well be a pop up window alerting the user that he or she
is connected to a PSTN texttelephone.

I am asuming that the callee knows the PSTN texttelephony etiquette.
(wait for turns, indicate GA or * or x when finished typing etc etc).

Greetz

Arnoud van Wijk

> From: Gunnar Hellstrom [mailto:[email-masked]]
> Sent: donderdag 23 februari 2006 0:24
> To: Arnoud van Wijk; 'Jani Hautakorpi (JO/LMF)'
> Subject: RE: [MMUSIC] Accessibility related parametersindraft-ietf-mmusic-
> sdp-media-content-01.txt
> 
> Jani,
> > > initial table, and you regard the meaning of the values enough
> described
> > in

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 23 Feb 2006 15:22:51 +0100

Arnoud,
What I try to tell is that it may be totally wrong to shift the user
interface to
a single window for PSTN textphone communication.

1. If you have a V.18 to V.18 communication, it is full duplex and the
standards require the display to be split in some way between sent and
received text.
It looks as on IP and no strict turn taking etiquette is needed.

2. If you have a V.21 communication it is usually one screen, but fully
possible to interrupt the  other part by just sending text whenever you
want. Turn-taking etiquette is needed.

3. If you have an EDT or DTMF or Baudot-TTY, it is strictly half duplex with
no chance to transmit while you are receiving. Turn-taking etiquette is
needed.

4. If the system happens to support the proprietary US textphones,
communication is in principle half duplex, but there is a specific interrupt
function that causes some action at the other end.

So, we cannot force any strict user interface action from the client who
receives the txp indicator. I do not want to cause more work by requiring

> 	The user should be made aware that presentation and communication

In a specific implementation no one can prevent you from taking a shortcut
and implement swap to single screen display for all txp indications, knowing
that most calls will be with textphones that matches that behaviour.

Gunnar

-----Original Message-----
From: Arnoud van Wijk [mailto:[email-masked]]
Sent: Thursday, February 23, 2006 1:47 PM
To: 'Gunnar Hellstrom'; 'Jani Hautakorpi (JO/LMF)'
Cc: [email-masked]; [email-masked]
Subject: RE: [MMUSIC] Accessibility
relatedparametersindraft-ietf-mmusic-sdp-media-content-01.txt

Greetz

Arnoud van Wijk

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Fri, 24 Feb 2006 13:42:34 +0100

Hi Gunnar,
The ToIP client MAY switch from split screen to a single screen. It does not
have to. In the Dutch mobile text telephone platform, we will make it an
option in the client to go from splitscreen to single screen when
communicating with a PSTN text telephone. It is up to the users to choose
it.

The most important part is that the users know that they may have to use the
turn-taking etiquette in the call. As you wrote below, almost all textphone
calls require turn-taking etiquette.

The chance of connecting to a native V.18 is still very slim. 
Maybe we can say if it is native v1.8, that it will not use txp label. That
is more or less to be determined by trials if that is desirable or not.

But for 99% of all texttelephone calls it will require turn-taking etiquette
anyway.

Cheers

Arnoud

> Sent: donderdag 23 februari 2006 15:23
> Subject: RE: [MMUSIC] Accessibility relatedparametersindraft-ietf-mmusic-
> sdp-media-content-01.txt
> 
> Arnoud,
> > ------------------------------------------------------------------------
> --
> > --
> > -

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 24 Feb 2006 17:29:49 +0100

Arnoud,
OK, you are right. The txp content indicator is used for indicating
limitations in media handling. The gateway should know, and send the txp
indicator only in calls where there are limitations.
So for a call with a V.18 capable gateway to a V.18 textphone, the indicator
should not be used and the SIP client should use a user interface that
encourages two way simultaneous typing.

I agree, and then want to ask Jani to take in this extended description of
txp in the media-content specification:

Typical use case for this is when there are presentation or communication
limitations in the capability to handle simultaneous communication in both
directions. This can for example be a connection where one endpoint is an
analog textphone of the common types that requires turn-taking control by
the user, and the other one is a native IP based text telephone.
The user should be made aware that such limitations prevail.

Gunnar

-----Original Message-----
From: Arnoud van Wijk [mailto:[email-masked]]
Sent: Friday, February 24, 2006 1:43 PM
To: 'Gunnar Hellstrom'; 'Jani Hautakorpi (JO/LMF)'
Cc: [email-masked]; [email-masked]
Subject: RE: [MMUSIC] Accessibility

Hi Gunnar,

Cheers

Arnoud

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Tue, 28 Feb 2006 16:25:16 +0200

Hi Gunnar,

> The user should be made aware that such limitations prevail.

Now the text in the draft is:

   txp:
   This indicates that the media stream is originated from a textphone,
   and it requires special behavior from the receiving application.
   Typical use case for this is e.g., a connection where one endpoint is
   an analog textphone, and the other one is a native IP based real time
   text capable terminal.

First you proposed that the following sentence should be added "The user 
should be made aware that presentation and communication limitations 
exist". This is application behavior, and we don't want to standardize 
that. If the application supports "txp" draft, it will do it anyway.

Can you *briefly* answer what is wrong with the current text and why it 
needs to be changed? The reason why I'm asking is that the only 
difference I can see is the "application must inform the user" part.

As I have said before, I encourage you to specify the usage of "txp" 
value on some other draft, if you want.

-- 
Jani