SV: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03

[Gunnar Hellstrom <[e-mail]>]

Cullen,
While waiting for a new media-content draft to appear, I remembered one more
reference that could be suitable for the reader who want to learn more about
text telephony.

That is RFC2833bisdata.
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisdata-08.txt
In its section 2.7 there is a brief description of the text telephone
systems and its use of various modems.

rfc2833bisdata is approved.It will likely become a quite well known RFC.
However it is not as clear as V.18, ETSI EG 202 320 and RFC 2805 about the
use of the half duplex mode.

I think it would be best with a reference to ETSI EG 202 320 for text
telephony background info. But RFC 2805, rfc2833bisdata, H.248.2  and ITU-T
V.18 also give similar info.

Gunnar


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


-----Ursprungligt meddelande-----
Fran: Gunnar Hellstrom [mailto:[e-mail]]
Skickat: den 25 juni 2006 19:24
Till: Cullen Jennings; Arnoud van Wijk
Kopia: 'IETF MMUSIC WG'; 'Colin Perkins'; 'Gonzalo Camarillo'
Amne: SV: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03


Cullen,

First a small addition: The "human user" mentioned in the middle of the new
text should be extended to read: "the human user of the IP terminal"

Then, you asked for references for better understanding of the limitations
in PSTN textphone protocols.

ITU-T V.18 "Modem operation in the text telephone mode."
is the traditional source. Even if it mainly deals with modem
discrimination, it also tells for each legacy type if it is half duplex or
full duplex.


But more words around what to do when converting between the legacy types
and full duplex, simultaneous real-time text and voice is found in a couple
of other documents:

ITU-T H.248.2 Facsimile, text conversation and call discrimination packages.
Describes gateway procedures between PSTN textphones and SIP.

ETSI EG 202 320 Duplex Universal Speech and Text.
Has all standardised legacy textphone methods briefly described and also SIP
real-time text and gateway procedures between them.

If you want to stay within IETF, you may refer to RFC 2805, where section
11.2.4 gives a very brief insight in the requirements for interworking with
legacy textphones with the following words:

>From RFC 2805:
"11.2.4.  Trunking/Access Gateway with text telephone access ports

   An access gateway with ports capable of text telephone communication,
   must provide communication between text telephones in the SCN and
   text conversation channels in the packet network.

   Text telephone capability of ports is assumed to be possible to
   combine with other options for calls as described in section 11.2.6
   (e.) on "Adaptable NASes".

   The port is assumed to adjust for the differences in the supported
   text telephone protocols, so that the text media stream can be
   communicated T.140 coded in the packet network without further
   transcoding [7].

   The protocol must be capable of reporting the type of text telephone
   that is connected to the SCN port. The foreseen types are the same as
   the ones supported by ITU-T V.18:  DTMF, EDT, Baudot-45, Baudot-50,
   Bell, V.21, Minitel and V.18. It should be possible to control which
   protocols are supported. The SCN port is assumed to contain ITU-T
   V.18 functionality [8].

   The protocol must be able to control the following functionality
   levels of text telephone support:

   a.   Simple text-only support: The call is set into text mode from
        the beginning of the call, in order to conduct a text-only
        conversation.

   b.   Alternating text-voice support: The call may begin in voice mode
        or text mode and, at any moment during the call, change mode on
        request by the SCN user. On the packet side, the two media
        streams for voice and text must be opened, and it must be
        possible to control the feeding of each stream by the protocol.

   c.   Simultaneous text and voice support: The call is performed in a
        mode when simultaneous text and voice streams are supported. The
        call may start in voice mode and during the call change state to
        a text-and-voice call.

   A port may implement only level a, or any level combination of a, b
   and c, always including level a.

   The protocol must support:

   d.   A text based alternative to the interactive voice response, or
        audio resource functionality of the gateway when the port is
        used in text telephone mode.



Greene, et al.               Informational                     [Page 28]

RFC 2805            MG Control Protocol Requirements          April 2000


   e.   Selection of what national translation table to be used between
        the Unicode based T.140 and the 5-7 bit based text telephone
        protocols.

   f.   Control of the V.18 probe message to be used on incoming calls.
"

Since RFC 2805 refers to V.18, I suggest that you include a reference to RFC
2805.

/ Gunnar


-----------------------------







-----Ursprungligt meddelande-----
Fran: Cullen Jennings [mailto:[e-mail]]
Skickat: den 25 juni 2006 19:30
Till: Arnoud van Wijk
Kopia: 'Gunnar Hellstrom'; 'Colin Perkins'; 'Gonzalo Camarillo'; 'IETF
MMUSIC WG'; 'Jani Hautakorpi (JO/LMF)'
Amne: Re: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03



On Jun 25, 2006, at 2:55 AM, Arnoud van Wijk wrote:

>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> +++++
>>    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
>>       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.
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> ++++++

Ok - if this is the best we can define it, I'm ok with that as it is.
If there is an good document that we could provide an formational
referfrece to that defined a textphone, that would be good but if not
we don't have to have a reference for this.



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



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