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

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 21 Jul 2006 20:44:10 +0100

Colin,
I am seaching in the draft amended V.151 Annex D for what is misleading you
to believe that the IP terminal shall go half duplex.

Can it be the proposed use of the duplex parameter from RFC 3840
Contact: <uri>;text;duplex="half"

That may be where I have not used parameters properly. My intention is that
this parameter value shall be used just to indicate the capability on the
presentation level. On transport level between the IP terminal and the
gateway the communication needs to be full duplex and not influenced by
these parameters. What is your view on this use of the duplex parameter?

One reason for the need to be full duplex between IP terminal and gateway is
that there are more variations in simultaneous media handling of the far end
PSTN terminal than we want to describe with parameters. It should rather be
left for the users to adapt to the degree of simultaneity that is possible
for the PSTN terminal we are connected to through the gateway.

The V.21 textphones are full duplex in transport, but has varying handling
of the presentation. Some merges the two sources in one window. Some have a
kind of irc-like display with labels in front of the parties text. And yet
some do a split in two windows of real-time text from each direction. There
is no difference in call setup, so the gateway have no way to know the
suitable level of simulaneity.

And even if it is not suitable to write long stories from both ends
simultanously when you have the one-window solution, you are very glad that
there is a possibility to type $$$$$$ to ask for the floor while the other
party is typing along.

So, please do not ask us to complicate the IP implementation to try to adapt
to the too limited and varying functionality of the PSTN textphones. Just
warn the user, as can be done by using the discussed parameters.

I have not before completely understood the intended use of the user-floor
parameter. I thought it had something to do with control protocols for
asking for the floor, but now I see that it is a close match to what we want
to accomplish for text users. We want to tell the user that in this session
you need likely to use the formal turntaking habits from PSTN text
telephony, that is different from different country to country. Some use a *
as turn indicator, some use a + and some use the letters GA.

So, please let us have this way to simply give the user a coarse indication
of the habits in the session.

Do you want to delete also the user-floor parameter?

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

-----Original Message-----
From: Arnoud van Wijk [mailto:[email-masked]]
Sent: Friday, July 21, 2006 7:04 PM
To: 'Colin Perkins'
Cc: 'Gunnar Hellstrom'; [email-masked]
Subject: RE: [MMUSIC] I-D
ACTION:draft-ietf-mmusic-sdp-media-content-04.txt

Hi Colin,
This "device capability" as you say has actually no impact and no
consideration at all on the call setup at all.
It is only information of the type of text stream, which is a legacy
textphone.

I hope some others will give their point of view here.

Cheers

Arnoud

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

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: vrijdag 21 juli 2006 12:43
> To: Arnoud van Wijk
> Cc: 'Gunnar Hellstrom'; [email-masked]
> Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-
> 04.txt
>
> 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
>
>
>
>
> On 21 Jul 2006, at 11:08, Arnoud van Wijk wrote:
> >> 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.
> >
> > [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.
> >
> >>
> >> To avoid these problems, I again suggest you define a new SDP
> >> attribute with the required semantics, and well defined offer/answer
> >> behaviour.
> > [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]
> >
> >
> >
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 24 Jul 2006 08:18:07 +0100

Colin,
I assume that it was the talk about half-duplex in the V.151 Annex that made
you hesitate about the appropriateness of the content parameter "txp".

That was taken from PSTN text-telephony jargon. I have adjusted the V.151
Annex proposal below to properly describe the use of the "txp" parameter in
that application in plain user terms.

So, I instead now say
"The line "a=content:txp" is sent from the gateway as an indication to the
ITD user that there is a likely need for the user to apply the formal
turntaking habits that are common between PSTN text telephone users. "

The second place where it is referenced now says:
"There is a parameter also for use in the text media description:
a=content:txp
It should be used to indicate to the ITD user that there is a likely need to
use the traditional formal turn-taking habits that are common among PSTN
text telephone users."

If you want, we can again refine the description of the "txp" parameter in
the media-content draft, section 5.

Current wording is:

   txp: This indicates that the media stream is originated from a
      textphone that is incapable of handling simultaneous two-way
      communication.  This limitation requires special behavior from the
      user of a terminal receiving the indication.  The indication
      should be used for an indication in the user interface.

      A typical use case is a connection where one endpoint is an analog
      textphone of a kind that cannot handle two-way simultaneous text
      communication, and the other one is a native IP based real time
      text capable terminal.  The human user of the IP terminal need to
      change behaviour when this indication is received, and apply
      formal turn-taking habits.  They may also need to figure out to
      what extent it is possible to interrupt the other party if the
      need arises.

My suggestion, if you find it better:

   txp: This indicates that the media stream is originated from a
      textphone with some presentation limitation.
      This limitation makes it probable that the user should apply formal
      turntaking habits that are common among text telephone users in the
      PSTN.  The indication
      should be used for an indication in the user interface.

      A typical use case is a connection where one endpoint is an analog
      textphone of a kind that merges text from both ends in the same
window,
      and the other one is a native IP based real time
      text capable terminal.  The human user of the IP terminal need to
      change behaviour when this indication is received, and apply
      formal turn-taking habits.  They may also need to figure out to
      what extent it is possible to interrupt the other party if the
      need arises, because that possibility varies between textphone types.

----------------------Proposed alternative to ITU-T V.151 Annex D, using
caller and callee capabilities and preferences and media-contents to control
gateway - IP text capable terminal
communication---------------------------------------------------------------
---------

Alternative proposal for V.151 Annex D.
ANNEX D2
Interworking IP Text Devices with V.151 Gateways.
Connect text channel when usage of real-time text is likely.

D.1 Introduction
Some non-Gateway IP devices in the network not having a means of modulating
or demodulating PSTN textphone signals, such as IVR systems, voicemail
systems, IP phones, Multimedia telephones or other devices, may support the
transmission of real-time text over IP networks and, ideally, interwork with
V.151-compliant Gateways in order to provide a means through which users of
PSTN textphone devices can communicate with those IP devices.  This class of
devices is referred to herein as an "IP Text Device" (ITD).  This Annex
defines the procedures that may be used in order to allow for such
interworking between V.151 Gateways and ITDs. The main principle is to use
RFC 4103 as the default text transport method between gateways and ITD:s,
and open text channels only when it is likely that the text channel will be
used.
D.2 Exchanging capabilities and opening media streams
When establishing a call, an ITD may advertise support for real-time text
in accordance with IETF RFC 4103.
In general, ITDs also transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.  However, since V.151
PSTN gateway devices interleave audio and text data when used for Gateway -
to - gateway operation, V.151 gateways need to support both RFC 4103 to
interwork with ITDs and RFC 4351 for communicating with other PSTN gateways.
As such, V.151 gateways are Recommended to indicate support for both
transport methods initially when exchanging capability information. However,
relatively few calls use real-time text in the PSTN, and therefore it may be
desirable for the gateway to not open the text channel until either party in
the call explicitly acts to use real-time text.
According to normal procedures in IP multimedia systems, it is allowable to
indicate capability for other transport protocols for real-time text as well
as RFC 4103 and connect such alternatives.
D.2.1    SDP based systems
Similar logic follows for SDP-based systems.
In SIP-based systems, the terminal and gateway shall announce support for
text in the Contact field according to RFC 3840, and may indicate preference
for text according to RFC 3841.
Contact: <uri>;text
A calling SIP terminal who does not put priority to text may indicate an
interest to use text by:
Accept-Contact: *;text
A calling SIP terminal who want to put priority to establishing a text
connection shall indicate that by:
Accept-Contact: *;text;require
Most commonly, PSTN text telephones support alternating text and audio
during the call, but not simultaneous text and audio. If the gateway only
supports alternating text and audio during the PSTN text session, it may be
beneficial to make the ITD user aware of this limitation. It is proposed to
use the Duplex parameter of RFC 3840 for this purpose.
Contact: duplex="half"
There is a parameter also for use in the text media description:
a=content:txp
It should be used to indicate to the ITD user that there is a likely need to
use the traditional formal turn-taking habits that are common among PSTN
text telephone users..

Note that while the use of RFC 2198 redundancy or other fault tolerance
scheme is not shown in the abbreviated examples below, appropriate
mechanisms should be employed to protect the transmission of the text stream
in accordance with the text transport specifications.

D.2.1.1 Call from PSTN
Consider the following abbreviated example SDP that might be found in an
offer sent by a V.151 Gateway not offering RFC 4103 support initially, but
indicating text support and that the text support is alternating with audio:
      Contact: <uri>;text;duplex="half"
       m=audio 7200 RTP/AVP 0 98
       a=rtpmap:98 t140c/8000
       a=fmtp:98 cps=20
If the gateway at that time already knows that text will be needed in the
call, a requirement for text shall be included, and a media line for text.
The decision to include text when offering the call may be because textphone
tones have already been detected on the PSTN line, the gateway may be
configured to be a dedicated text gateway, or it may be known by
subscription or any other external means that either user has preference for
text.
      Accept-Contact: *;text;require
      Contact: <uri>;text;duplex="half"
       m=audio 7200 RTP/AVP 0 98
       a=rtpmap:98 t140c/8000
       a=fmtp:98 cps=20
       m=text 7202 RTP/AVP 99
       a=rtpmap:99 t140/1000
      a=content:txp

If the answering device is an ITD, with no specific indication that text
would be used,  it would accept only the G.711 audio.
      Contact: <uri>;text
      m=audio 7200 RTP/AVP 0

If the answering device is an ITD where the user has indicated a preference
for text, it would accept the text/t140 medium and optionally G.711 audio.
      Contact: <uri>;text
       m=audio 7200 RTP/AVP 0
       m=text 7202 RTP/AVP 99
       a=rtpmap:99 t140/1000
Note that this response is only possible when the gateway had included
text/140 in the offer. For other cases, the terminal needs to do a reinvite
to add text to the call.
D.2.1.2 Call from IP terminal
A calling ITD could give a strong indication that it requires text support
in the call by an INVITE according to this example:
      Contact: <sip:[email-masked]>;text
      Accept-Contact: *;text;require
       m=audio 7200 RTP/AVP 0
       m=text 7202 RTP/AVP 99
       a=rtpmap:99 t140/1000

The network would make efforts to connect to a text capable gateway, that
may acknowledge the text channel initially, because of the indication that
text is required. The gateway should also start text channel connection
procedures on the PSTN side.
      Contact: <gwy-uri>;text;duplex="half"
       m=audio 7200 RTP/AVP 0
       m=text 7202 RTP/AVP 99
       a=rtpmap:99 t140/1000
       a=fmtp:99 cps=20
      a=content:txp

If on the other hand, the ITD user is not depending on text, but want to
have it available for occasional use, the ITD can be configured to make its
INVITE as follows:

      Contact: <sip:[email-masked]>;text
      Accept-Contact: *;text
       m=audio 7200 RTP/AVP 0
       m=text 7202 RTP/AVP 99
       a=rtpmap:99 t140/1000
       a=fmtp:99

The network would try to connect to a text capable gateway, but may connect
through a non capable. The gateway may decide to not acknowledge the text
channel initially, but indicates its text capability in the Contact header.
      Contact: <gwy-uri>;text;duplex="half"
       m=audio 7200 RTP/AVP 0

D.2.1.3 Text channel establishment during a call
If at a later stage in the call, either party in the call starts text
activity, and no text channel was set up initially, a text channel should be
added to the session by a REINVITE. .
This is an example of how it would be expressed from the gateway,
       Contact: <uri>;text;duplex="half"
       m=audio 7200 RTP/AVP 0
        m=text 7202 RTP/AVP 99
        a=rtpmap:99 t140/1000
        a=fmtp:99 cps=20
       a=content:txp
The other party should answer with a similar sdp.

If instead it is the ITD user who starts text activity, a text channel
should be added to the session by a REINVITE from the ITD according to the
following example. .
       Contact: <uri>;text
       m=audio 7200 RTP/AVP 0
       m=text 7202 RTP/AVP 99
       a=rtpmap:99 t140/1000
       a=fmtp:99 cps=20

The gateway should answer with
       Contact: <uri>;text;duplex="half"
       m=audio 7200 RTP/AVP 0
       m=text 7202 RTP/AVP 99
       a=rtpmap:99 t140/1000
       a=fmtp:99 cps=20
       a=content:txp
.
The line "a=content:txp" is sent from the gateway as an indication to the
ITD user that there is a likely need for the user to apply the formal
turntaking habits that are common between PSTN text telephone users.

D.3 Procedure for terminals including both RFC 4103 and RFC 4351 support
In the case when a terminal implements both RFC 4103 and RFC 4351 for text
transport, the following procedures should be applied in the terminal.
When establishing a call, an ITD may advertise support for ToIP in
accordance with Annex B or Annex C, with one notable important exception:
the ITD shall not include a list of supported modulations.  Absence of the
list of modulations shall be used as an indicator to the V.151 Gateway that
the remote side is an ITD.
Further, ITD devices shall not utilize SSEs in order to control state
transition to ToIP.  Rather, once a media flow is established to transport
T.140 characters, either the Gateway or the ITD may transmit text
immediately and without further negotiation.  Payload type switching is used
to transition between AUDIO and Text Relay modes.

D.4 State transition and text handling
The following description assumes that a V.151-compliant Gateway is in
communication with an ITD and media flows have been established to transport
text over IP in accordance with RFC 4103.
When the gateway compliant to this annex detects a PSTN textphone that it
supports using text relay, it shall autonomously connect to the textphone.
After connection on the PSTN side, the gateway shall open the text channel
to the ITD. It shall decode the characters received and transmit those to
the ITD, giving proper respect to the maximum character-per-second (CPS)
parameter advertised by the ITD.  Determining the type of PSTN textphone
device in use is the responsibility of the Gateway and the ITD need not
concern itself with what kind of PSTN textphone device is connected to the
Gateway.
Likewise, when the ITD first has characters to send to the Gateway using
text/140 payload type, the ITD opens the text channel if it was not opened
before. Then the ITD transmits the characters to the Gateway. The Gateway
shall perform a probing, as necessary, to determine the type of PSTN device
connected, if any.  While probing, the Gateway shall buffer any characters
received and transmit those when probing completes and the gateway is
connected to the text phone.  The size of the character buffer is a matter
of implementation, but should support the reception and buffering of
characters for at least 60 seconds at the specified maximum
character-per-second (CPS) value signaled to the ITD.
If the Gateway does not support the modulation used by the PSTN textphone
device, the Gateway may transmit the received textphone signals via VBD or
the audio stream, depending on the capabilities of the ITD.  Further, the
Gateway may simply discard characters received from the ITD or transmit them
to the PSTN textphone device using a pre-provisioned modulation.

/
OK Now?

Gunnar

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Jul 2006 09:03:37 +0100

On 21 Jul 2006, at 20:44, Gunnar Hellstrom wrote:
> I am seaching in the draft amended V.151 Annex D for what is  
> misleading you to believe that the IP terminal shall go half duplex.
>
> That may be where I have not used parameters properly. My intention  
> is that this parameter value shall be used just to indicate the  
> capability on the presentation level. On transport level between  
> the IP terminal and the gateway the communication needs to be full  
> duplex and not influenced by these parameters. What is your view on  
> this use of the duplex parameter?

I have insufficient experience with SIP to comment.

> One reason for the need to be full duplex between IP terminal and  
> gateway is that there are more variations in simultaneous media  
> handling of the far end PSTN terminal than we want to describe with  
> parameters. It should rather be left for the users to adapt to the  
> degree of simultaneity that is possible for the PSTN terminal we  
> are connected to through the gateway.
>
> The V.21 textphones are full duplex in transport, but has varying  
> handling of the presentation. Some merges the two sources in one  
> window. Some have a kind of irc-like display with labels in front  
> of the parties text. And yet some do a split in two windows of real- 
> time text from each direction. There is no difference in call  
> setup, so the gateway have no way to know the suitable level of  
> simulaneity.
>
> simultanously when you have the one-window solution, you are very  
> glad that there is a possibility to type $$$$$$ to ask for the  
> floor while the other party is typing along.
>
> So, please do not ask us to complicate the IP implementation to try  
> to adapt to the too limited and varying functionality of the PSTN  
> textphones. Just warn the user, as can be done by using the  
> discussed parameters.

I am not asking you to complicate anything on the IP side: you are  
the one introducing this parameter. All I am asking is that you  
introduce it in a way that is compatible with SDP semantics.

As I have said repeatedly: I have no problem with the use-case,  
however the content label attribute is not the right place to signal  
this. Define a new SDP parameter, with exactly the semantics you desire.

> Do you want to delete also the user-floor parameter?

Perhaps. I haven't considered it in detail, but one could certainly  
make that argument.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Jul 2006 09:05:30 +0100

On 24 Jul 2006, at 08:18, Gunnar Hellstrom wrote:
> I assume that it was the talk about half-duplex in the V.151 Annex  
> that made you hesitate about the appropriateness of the content  
> parameter "txp".
>
> Annex proposal below to properly describe the use of the "txp"  
> parameter in that application in plain user terms.

None of this addresses my comment, which is that txp should not be a  
content label, for all the reasons I have explained, but should  
instead be a separate attribute.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Jul 2006 21:07:43 +0100

On 24 Jul 2006, at 20:55, Gunnar Hellstrom wrote:
> And we (Arnoud and me) think that we have adjusted for your  
> comments and made it clear that we are not handling negotiation,  
> but just an indication about the characteristics of media contents  
> that needs to be detected by the receiving UA and displayed to the  
> user, just as the other indications about main speaker, alternate,  
> sign language and the others.

There is a significant difference: the txp parameter requires the  
user to change their behaviour due to device capabilities. None of  
the others do.

> The only concerns you have uttered have been around your  
> misperception that we wanted to change the media flow between the  
> terminals.

No, it has nothing to do with that. You are negotiating device  
capabilities, as I explained previously.

> That is corrected now, so nothing should be left bothering you.

For the record, I disagree that the changes suggested are sufficient,  
for the reasons I have explained.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Jul 2006 22:30:44 +0100

In an attempt to move this discussion forward, I have written and  
submitted a draft on "The SDP 'txp' Attribute" <draft-perkins-mmusic- 
sdp-txp-00.txt>, to show how the desired semantics can be mapped onto  
a separate attribute, in a manner that does not conflict with the  
documented semantics of content label.

Colin

On 24 Jul 2006, at 21:07, Colin Perkins wrote:

> For the record, I disagree that the changes suggested are  
> sufficient, for the reasons I have explained.
>
> Colin
>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 24 Jul 2006 22:42:35 +0100

Colin,
The device in the far end, on the other end of the PSTN line on the other
side of a gateway MAY have presentation limitations.

But it MAY also have no limitations.

The important thing is that it operates in an environment where there is a
habit to do formal turntaking by text tokens in the text stream. Our user
will have a better chance to use the media properly when knowing that that
is the environment it comes from.

The IP terminal does not need to adapt more than to give this indication in
some way to the user.

Similarly to the other content indicators.
The user-floor is a total analogy. The user needs an indication about how to
behave when using the medium. It is because of a lack in the far end
terminal or in the conference system. The terminal does not adapt more than
give an indication. Similar as for "txp".

For the "sl" indicator, for sign language, it is important to present it big
enough and with proper quality to be perceived. That might influence
terminal, but I suggest we do not use this indication for that purpose, but
rather just for planning the layout on the display and possibly to remind
the user to prepare for a return channel in sign language.

You say: "There is a significant difference: the txp parameter requires the
user to change their behaviour due to device capabilities. None of
the others do."
It is a combination of conversational behaviour culture and far far end
device limitations on some of the terminals.
All parameters have something specific. Why would this be forbidden?
The sl requires video capabilities in the far end terminal.
The user-floor indicates a lack of conferencing tools.
The slides indicate a capability to send pictures.

New extensions may add yet other parameters that indicate specific
characteristics of the terminals transmitting them combined with an
indication of the resulting medium.

How about to add a new value "subtitles" to be used as an indication for the
receiving application to plan the layout to present it as text placed under
the main video window.

You say "For the record, I disagree that the changes suggested are
sufficient,
for the reasons I have explained."

I understand this as  "OK, let it be accepted but remember I was not totally
happy with it".

Thanks

Gunnar

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Monday, July 24, 2006 9:08 PM
To: Gunnar Hellstrom
Cc: Arnoud van Wijk; [email-masked]
Subject: Re: [MMUSIC] I-D

Colin

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Jul 2006 23:15:28 +0100

Gunnar,

On 24 Jul 2006, at 22:42, Gunnar Hellstrom wrote:
> The important thing is that it operates in an environment where  
> there is a habit to do formal turntaking by text tokens in the text  
> stream. Our user will have a better chance to use the media  
> properly when knowing that that is the environment it comes from.
>
> The IP terminal does not need to adapt more than to give this  
> indication in some way to the user.

You have said that before, and I have previously explained that it is  
a form of device capability negotiation, and therefore outside the  
scope of a content label.

> The user-floor is a total analogy. The user needs an indication  
> about how to behave when using the medium. It is because of a lack  
> in the far end
> terminal or in the conference system. The terminal does not adapt  
> more than give an indication. Similar as for "txp".

That is a problem with user-floor.

> For the "sl" indicator, for sign language, it is important to  
> present it big enough and with proper quality to be perceived. That  
> might influence
> terminal, but I suggest we do not use this indication for that  
> purpose, but rather just for planning the layout on the display and  
> possibly to remind the user to prepare for a return channel in sign  
> language.
>
> You say: "There is a significant difference: the txp parameter  
> requires the user to change their behaviour due to device  
> capabilities. None of
> the others do." It is a combination of conversational behaviour  
> culture and far far end device limitations on some of the terminals.

Because the other parameters, with the possible exception of user- 
floor, do not require changes in user behaviour.

> indication of the resulting medium.

No, they may not. This is your fundamental misunderstanding: they  
label the content of the stream, not the characteristics of the  
terminal. There is an important difference, which you do not seem to  
understand.

> How about to add a new value "subtitles" to be used as an  
> indication for the receiving application to plan the layout to  
> present it as text placed under the main video window.

Sure, that makes sense, since it labels the content of the stream,  
and does not describe the capabilities of the device.

> sufficient, for the reasons I have explained."
>
> I understand this as  "OK, let it be accepted but remember I was  
> not totally happy with it".

No, it means that the changes you have proposed ignore my concerns,  
and hence I object to the publication of the draft as it stands.

Colin

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 24 Jul 2006 20:55:30 +0100

And we (Arnoud and me) think that we have adjusted for your comments and
made it clear that we are not handling negotiation, but just an indication
about the characteristics of media contents that needs to be detected by the
receiving UA and displayed to the user, just as the other indications about
main speaker, alternate, sign language and the others.

The only concerns you have uttered have been around your misperception that
we wanted to change the media flow between the terminals.

Gunnar

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Monday, July 24, 2006 9:06 AM
To: Gunnar Hellstrom
Cc: Arnoud van Wijk; [email-masked]
Subject: Re: [MMUSIC] I-D

Colin

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 24 Jul 2006 17:19:29 -0700

The definition of "User-floor" doesn't appear to be really capturing the
content of the stream. It looks like a way of signaling the application
behavior, which should probably be not done using "content" attribute.

>From the description (previous and newly proposed one), it does not look
like "txp" is capturing the content of the stream. "txp" is giving an
impression that "content" attribute is overloaded. It is not impacting
any call negotiation and at the same time it is not really capturing the
content of text stream.

"content" attribute should not be overloaded to achieve a specific
behavior at the UI/Application level. And I think that "user-floow" and
"txp" are are not capturing the content.

Examples of meaningful text stream content description which I can think
of: Stock ticker, breaking news headlines, subtitilse in spanish,
subtitiles in french.

- - - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[email-masked]

> Sent: Monday, July 24, 2006 3:15 PM
> To: Gunnar Hellstrom
> Cc: [email-masked]
> > The device in the far end, on the other end of the PSTN line on the 
> > other side of a gateway MAY have presentation limitations.
> >
> > The important thing is that it operates in an environment 
> where there 
> > is a habit to do formal turntaking by text tokens in the 
> text stream. 
> > Our user will have a better chance to use the media properly when 
> > knowing that that is the environment it comes from.
> >
> You have said that before, and I have previously explained 
> that it is a form of device capability negotiation, and 
> therefore outside the scope of a content label.
> 
> > The user-floor is a total analogy. The user needs an 
> indication about 
> > how to behave when using the medium. It is because of a lack in the 
> > far end terminal or in the conference system. The terminal does not 
> > adapt more than give an indication. Similar as for "txp".
> 
> > For the "sl" indicator, for sign language, it is important 
> to present 
> > it big enough and with proper quality to be perceived. That might 
> > influence terminal, but I suggest we do not use this indication for 
> > that purpose, but rather just for planning the layout on 
> the display 
> > and possibly to remind the user to prepare for a return channel in 
> > sign language.
> >
> > capabilities. None of the others do." It is a combination of 
> > conversational behaviour culture and far far end device 
> limitations on 
> > some of the terminals.
> Because the other parameters, with the possible exception of 
> user- floor, do not require changes in user behaviour.
> 
> No, they may not. This is your fundamental misunderstanding: 
> they label the content of the stream, not the characteristics 
> of the terminal. There is an important difference, which you 
> do not seem to understand.
> 
> indication 
> > for the receiving application to plan the layout to present 
> it as text 
> > placed under the main video window.
> 
> Sure, that makes sense, since it labels the content of the 
> stream, and does not describe the capabilities of the device.
> 
> > I understand this as  "OK, let it be accepted but remember 
> I was not 
> > totally happy with it".
> 
> No, it means that the changes you have proposed ignore my 
> concerns, and hence I object to the publication of the draft 
> as it stands.
> 
> Colin
>

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Tue, 25 Jul 2006 15:03:44 +0200

So Colin...
The issue is not txp or use-floor.
It is more or less WHAT is exactly the goal and use of the content label.

This label is to add information to the media stream what the content is.
So, when you receive 2 video streams using the same codecs, how do you know
one is signlanguage and one is the normal video telephone call? That is one
thing the content label solves.
But that does require user interaction or client interaction to ensure the
signlanguage stream is positioned correctly on the screen.

If you then look at the txp content label. The media stream gets labelled
that it is from a PSTN textphone.
PSTN textphone is a different content then subtitles or plain vanilla ToIP.

The user or the user client will be used in a different way based on the
content label. That is up to the user and the services he or she uses.

I totally fail to see your point that txp is different then sl or left
microphone or mainslides.

We both have a different view on what is content label and what is ok to use
it.
I appreciate the fact that you want to solve this and publish a draft on
that. I will surely study that when I see it floating on the MMUSIC mailing
list.

But maybe we should also focus on WHAT is the correct use of the content
label. Decide on that before saying txp is not allowed.

Arnoud

Arnoud A. T. van Wijk
AnnieS New Technology
www.AnnieS.nl

> Sent: dinsdag 25 juli 2006 0:15
> To: Gunnar Hellstrom
> Cc: [email-masked]
> > other

---

From: Colin Perkins <[email-masked]>
Date: Tue, 25 Jul 2006 15:20:04 +0100

On 25 Jul 2006, at 14:03, Arnoud van Wijk wrote:
...
> PSTN textphone is a different content then subtitles or plain  

No, it is not -- this is disconnect. A PTSN text phone is a device  
with only limited capabilities. That the device has limited  
capabilities is orthogonal to the content of the media stream  
produced by the device. I can use a text phone to send subtitles, or  
I could use it for the main speaker in an event, for example. The  
content can change; the fact that it is a text phone cannot.

One is metadata describing WHAT is being sent ("this is the main  
speaker"), the other is metadata describing mechanics of HOW it is  
being sent ("the main speaker is using a PTSN text phone via a  
gateway"). They're not the same type of information, and they  
shouldn't be confused at the signalling level.

> that. I will surely study that when I see it floating on the MMUSIC  

It simply takes the text from the current draft which defines  
"a=content:txp" and uses it to define an "a=txp" attribute instead.  
All the other mechanisms you and Gunnar have described to signal PTSN  
text phones can be used in their currently defined manner. I simply  
wish to separate the description of a stream's contents from the  
description of the capabilities of the device producing that stream,  
at the SDP level.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 25 Jul 2006 21:47:33 +0100

On 24 Jul 2006, at 22:30, Colin Perkins wrote:
> submitted a draft on "The SDP 'txp' Attribute" <draft-perkins- 
> mmusic-sdp-txp-00.txt>, to show how the desired semantics can be  
> mapped onto a separate attribute, in a manner that does not  
> conflict with the documented semantics of content label.

This is now available in the archives.

Colin

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 28 Jul 2006 21:54:06 +0100

I have re-read the intention of the content attribute and cannot find that
there is any apparent difference between the currently included values that
make any of them contribute to "overloading".

This is what the draft says:
"The 'content' attribute is needed, so that the
   receiving application can treat each media stream appropriately based
   on its content."

One example taken is to place the main video stream in a big video window.

It does not say exactly what feature of the content that shall be expressed
by an attribute, and the already coded examples show various features:

"slides" /  indicates that the medium contains images. Hints the user to
view this window in combination with the speaker or main view.

 "speaker" / Indicates that this is a view or sound or typing of the
speaking part in a call or conference. Hints a user to concentrate on
language output from it.

 "sl" /     indicates type of language used.  A user gets a hint that sign
language capability is expected to understand it. If it is a conversational
session, sign language capability may be required to respond as well.

 "main"     indicates some kind of level of importance or position in
session structure. Hints the user to pay a lot of attention here.

/ "alt" /   indicates also some kind of level of importance or other way to
express things.
            gives a hint to the user that it is of lower priority but may be
very useful if you have any problems with the main.

 "user-floor" / Indicates that all see each other or hear each other or see
each other?s typing intermixed, and hints the user that formal turntaking
habits are required in the media channel.

"txp" Indicates that transmission to the party will be intermixed with media
coming from the party, and hints the user that formal turntaking habits are
required in the media channel.

Are they not all a suitable mixture of indications of source of contents,
media format of the contents, expectations on UA treatment of the contents
and expectation of the user receiving the contents?

And the idea being that they are a set of registered values so that they can
be discriminated by the UA and acted on consistently.

"subtitles" could be a suitable extension. I do not propose that at the
moment, but would support it if anyone wanted. It would mean text
translating spoken content in a streaming video/audio combination. No
interaction would be expected from the user.

Your examples "subtitles in french" and "subtitles in spanish" would instead
use a combination of "subtitles" and the "language tag" attribute in order
to maintain the goal of being decodable by automata.

Agree?

Gunnar

---

From: "Frank Shearar" <[email-masked]>
Date: Mon, 31 Jul 2006 12:01:51 +0200

>From the draft's section 1:

   The 'content' attribute is needed, so that the
   receiving application can treat each media stream appropriately based
   on its content.

The word "user" isn't mentioned here. So I figure that, from reading the
draft, the "content" attribute doesn't tell users what to do, or suggest
appropriate behaviour.

Thus, it seems like txp and user-floor are in the same boat: both hint that
users might require turn-taking, or other behavioural changes.

I thus submit that if txp goes (and is written up in a separate draft, like
Colin's "strawman" draft), then user-floor must go too, again into a
separate draft. (Or maybe "behavioural hints" attributes could go together
in their own draft or something.)

frank

---

From: Colin Perkins <[email-masked]>
Date: Mon, 31 Jul 2006 12:59:47 +0100

> in their own draft or something.)

A "behavioural hints" draft seems like a good idea to me.

Colin

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 31 Jul 2006 23:00:53 +0100

I know it is very late in the process for the media-content draft. It is in
AD evaluation state.
But I have a couple of comments that I hope can be considered while it is
still discussed.

1. In section 10, IANA Considerations, there is this line:

"speaker  RFC xxxx  Image from the speaker"

I think it should be:

"speaker  RFC xxxx  Media from the speaker"

The reason is to make it match the statement in section 5:

"All of these values can be used with any media type."

2. Is the statement "All of these values can be used with any media type."
really needed?
Today, with some flexible mind you can imagine all current content types be
used with all media types. Even for "slides" I can imagine an audio stream
describing the slides, a series of images, a video, and a set of text lines
being the slides.
But if a new extension shall be registered, is there really something in the
logic of the use of the attributes that make it important that it can be
used with any media?
If I want to register "colour correction chart", it is very hard to imagine
an audio representation of it.
What is your view, should that sentence in section 5 be changed to:
"The ambition is to express general content values so that they can be used
with any media type."

3. Is the extension possibilities enough described?
In the evaluation comments it is requested to improve the description about
how IANA is expected to handle registrations of new values.
I do not see anything mentioned in section 10 about the extesnion mechanism.
I suggest that a sentence about that is added.

Gunnar

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Monday, July 24, 2006 11:15 PM
To: Gunnar Hellstrom
Cc: [email-masked]
Subject: Re: [MMUSIC] I-D

Gunnar,

Colin