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

["Jean-Francois Mule" <[e-mail]>]

Large msg from Gunnar converted to plain txt.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, July 24, 2006 12:53 AM
To: Jean-Francois Mule
Subject: Forward of moderated message


-----Original Message-----
From: Gunnar Hellstrom [mailto:[e-mail]] 
Sent: Sunday, July 23, 2006 3:27 PM
To: Gunnar Hellstrom; Arnoud van Wijk; 'Colin Perkins'
Cc: [e-mail]
Subject: RE: [MMUSIC] I-D
ACTION:draft-ietf-mmusic-sdp-media-content-04.txt 

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. "
 
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:[e-mail]>;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:[e-mail]>;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





------------------------------------------------------------------------
-----
Gunnar Hellstrom, Omnitor
[e-mail]
Mob: [phone]
Phone: [phone]
www.omnitor.se


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


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
[e-mail]
Mob: [phone]
Phone: [phone]
www.omnitor.se



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