One document matched: draft-ietf-megaco-h248f-00.txt
Media Gateway Control (Megaco) Gunnar Hellstrom
Internet Draft LM Ericsson
Document: draft-ietf-megaco-h248f-00.txt July 2000
Category: Standards Track
H.248 Annex F (Pre-Decision White Document)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document reproduces the content of the ITU-T Study Group 16
White Document draft of H.248 Annex F, which is scheduled for
decision in Geneva in November 2000. H.248 Annex F provides
packages for faxsimile, text conversation, and call discrimination.
This document is submitted for IETF comment prior to ITU-T decision,
in accordance with procedures currently being negotiated between
ITU-T Study Group and ISOC on behalf of the IETF.
Hellstrom Standards Track - Expires January 2001 1
H.248 Annex F (White Document draft) July 2000
2. TABLE OF CONTENTS
1. Abstract.......................................................1
2. TABLE OF CONTENTS..............................................2
3. Conventions used in this document..............................5
4. Introduction...................................................5
4.1 Scope.................................................5
5 Definitions...................................................5
5.1 Hexadecimal octet coding.................................5
5.2 Hexadecimal octet sequence...............................6
6. FAX/Textphone/Modem Tones Detection Package....................6
6.1 Properties.............................................6
6.2 Events.................................................7
6.2.1 Additional tone id value.......................7
6.3 Signals................................................8
6.4 Statistics.............................................8
6.5 Procedures.............................................8
7 Text Conversation package.....................................8
7.1 Properties.............................................8
7.1.1 Text buffering time............................8
7.1.2 Text termination connection state..............9
7.1.3 Text User Identity............................10
7.1.4 Text Transport................................10
7.1.5 Text Protocol Version.........................11
7.1.6 Redundancy Level..............................11
7.1.7 Txc request timer.............................11
7.2 Events................................................12
7.2.1 Connection State Change.......................12
7.3 Signals...............................................12
7.4 Statistics............................................12
7.4.1 Characters Transferred........................12
7.4.2 Lost Packets..................................12
7.5 Procedures............................................12
7.5.1 Function......................................13
7.5.2 Informative description.......................13
7.5.3 Total Conversation............................14
7.5.4 Descriptor to use for text conversation.......14
8. Text Telephone package......................................15
8.1 Properties............................................17
8.1.1 Conversation mode.............................17
8.1.2 Communication Mode............................18
8.1.3 Connection Mode...............................20
8.1.4 Action at loss of connection..................21
8.1.5 V18 options...................................21
8.1.6 Character set.................................21
Hellstrom Standards Track - Expires January 2000 2
H.248 Annex F (White Document draft) July 2000
8.2 Events................................................22
8.2.1 Connection mode changed.......................22
8.3 Signals...............................................22
8.4 Statistics............................................22
8.4.1 Number of characters transferred..............22
8.4.2 Number of alternating turns...................23
8.5 Procedures............................................23
8.5.1 Basic operation...............................23
8.5.2 Informative description.......................23
8.5.3 V.18 Modem....................................23
8.5.4 Operation with alternating text and voice mode24
8.5.5 Alternating text and voice mode with legacy,
carrier-less textphones:............................24
8.5.6 Alternating voice and text conversation in
carrier mode:.......................................25
8.5.7 Simultaneous voice and text mode..............25
9. Call Type Discrimination package............................26
9.1 Properties............................................26
9.1.1 Call Types....................................26
9.1.2 Text Call Types...............................26
9.1.3 V8bissupport..................................27
9.1.4 Probe message.................................27
9.1.5 Probe order...................................27
9.1.6 PhasereversalDetect...........................28
9.2 Events................................................28
9.2.1 Discriminating tone detected..................28
9.3 Signals...............................................31
9.3.1 V8Signal......................................31
9.3.2 AnswerSignal..................................32
9.3.3 CallingSignal.................................33
9.3.4 V8bisSignal...................................33
9.3.5 V18probe......................................35
9.4 Statistics............................................35
9.5 Procedures............................................35
9.5.1 Informative description.......................35
9.5.2 Operation.....................................36
9.5.3 Operation for incoming calls..................36
9.5.4 Operation for transit calls, coming from and
going to the switched network.......................36
9.5.5 Operation for calls having one endpoint in the
packet network......................................37
9.5.6 Cases when the call type can not be determined
from the signals....................................37
9.5.7 Scenarios and call flows......................38
9.5.8 Initial characters............................38
9.5.9 Time critical handling........................38
10. Fax package................................................39
10.1 Properties...........................................39
10.1.1 Fax connection state.........................39
10.1.2 Fax Transport................................40
Hellstrom Standards Track - Expires January 2000 3
H.248 Annex F (White Document draft) July 2000
10.1.3 TransmissionSpeed............................40
10.1.4 PSTN Interface...............................40
10.2 Events...............................................41
10.2.1 Fax Connection State Change..................41
10.3 Signals..............................................41
10.4 Statistics...........................................41
10.4.1 Pages Transferred............................41
10.4.2 Train Downs..................................42
10.5 Procedures...........................................42
10.5.1 Function.....................................42
10.5.2 Process of Adding Fax Capable Terminations...42
10.5.3 Process of Ending a Fax Call.................43
11. IP Fax package.............................................43
11.1 Properties...........................................43
11.1.1 Fax connection state.........................43
11.1.2 IPFaxTransport...............................44
11.1.3 TransmissionSpeed............................44
11.1.4 T.38 Capabilities............................44
11.1.5 T38MaximumBufferSize.........................45
11.1.6 T38MaximumDatagramSize.......................45
11.1.7 T38Version...................................45
11.2 Events...............................................45
11.2.1 Fax Connection State Change..................45
11.3 Signals..............................................46
11.4 Statistics...........................................46
11.4.1 Pages Transferred............................46
11.4.2 Train Downs..................................46
11.5 Procedures...........................................47
11.5.1 Function.....................................47
11.5.2 Process of Adding IP Fax Capable Terminations48
11.5.3 Process of Ending a Fax Call.................48
11.5.4 Informative Example:.........................48
12. Security Considerations......................................49
13. References...................................................49
14. Acknowledgements.............................................51
15. Authors' Addresses...........................................51
Hellstrom Standards Track - Expires January 2000 4
H.248 Annex F (White Document draft) July 2000
3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
4. Introduction
This document gathers together packages for fax, text telephone,
call type discrimination and data call detection for use with the
Megaco/H.248 gateway control protocol. The packages in this document
are in conformance with Megaco/H.248 section 12 package definition
guidelines.
4.1 Scope
H.248 Annex F describes packages for the Megaco/H.248 gateway
control protocol related to data or telematic services. With
terminations implementing these packages, a gateway is expected to
handle initial modem negotiations, and the communication in voice,
fax and text telephone call types.
It contains:
Package "ftmd" for general detection of signals on a fixed telephone
line indicating a possible request to enter some data related mode.
Package "ctyp" for general call discrimination to sort out if a call
should be handled as voice, fax , text telephone or modem data, and
perform the initial negotiation.
Package "txp" for communicating with text telephones in the
telephone network.
Package "fax" for communication with facsimile in the telephone
network.
Package "txc" for general text conversation in other environments.
Package "ipfax" for fax transmission in IP networks.
5 Definitions
5.1 Hexadecimal octet coding
Hexadecimal octet coding is a means for representing a string of
octets as a string of hexadecimal digits, with two digits
representing each octet.
Hellstrom Standards Track - Expires January 2000 5
H.248 Annex F (White Document draft) July 2000
Each octet is issued by the DTE or DCE in the same time sequence as
transmitted on the GSTN line, with no intervening characters.
For each octet, the 8-bit sequence is encoded as two hexadecimal
digits. Bit 0 is the first transmitted; bit 7 is the last.
Bits 7-4 are encoded as the first hexadecimal digit, with Bit 7 as
MSB and Bit 4 as LSB. Bits 3-0 are encoded as the second hexadecimal
digit, with Bit 3 as MSB and Bit 0 as LSB.
Examples:
Octet bit pattern Hexadecimal T.50 codes
(time order as coding
specified in V.8 and
V.8 bis)
00011011 D8 4/4, 3/8
11100100 27 3/2, 3/7
10000011 10100010 C1451390 4/3, 3/1, 3/4,
11001000 00001001 3/5, 3/1, 3/3,
3/9, 3/0
5.2 Hexadecimal octet sequence
A hexadecimal octet sequence is an even number of hexadecimal
digits, terminated by a <CR> (T.50 0/13) character.
6. FAX/Textphone/Modem Tones Detection Package
PackageID: ftmd, 0x000E
Version: 1
Extends: tonedet version 1
This package defines an event to detect the presence of data traffic
(fax, textphone or modem) on a line. The main intention of this
event may be used to effect the compression option on the line so
that an audio codec capable of transmitting modem signals can be
invoked to handle the connection when needed. This Package extends
the possible values of tone id in the "start tone detected" event.
Note that there is no discrimination between tones from this
package. If discrimination is desired, the Call Type Discrimination
package should be invoked.
6.1 Properties
None
Hellstrom Standards Track - Expires January 2000 6
H.248 Annex F (White Document draft) July 2000
6.2 Events
Events are defined as for the tone detection package.
6.2.1 Additional tone id value
dtfm, 0x0039
This tone id is generated when any of the following tones are
detected:
"Tone" Description Applicable to
CNG a T.30 fax calling Fax
V21flag a V21 tone and flags Fax
CIV18 a V.8 CI with V.18 call Textphone
function
XCI a V.18 XCI Textphone
V18txp a V.18 "txp" Textphone
Belltone a Bell 103 carrier, either the
high or the low frequency Textphone
channel (as defined in V.18)
Baudot a Baudot initial tone and Textphone
character (as def. in V.18)
Edt an EDT initial tone and Textphone
character (as def. in V.18)
CIdata a V.8 CI with any data call Data
function
CT a V.25 calling tone Text and Data
CIfax a V.8 CI with facsimile call Fax
function
V21tone a V.21 carrier, either the high Text and Data
or the low frequency channel
V23tone a V.23 carrier, either the high Text and data
or the low frequency channel
V8bis a V.8 bis modem handshaking Fax, Text and
signal Data
Hellstrom Standards Track - Expires January 2000 7
H.248 Annex F (White Document draft) July 2000
ANS V.25 ANS, equivalent to T.30 Fax, Text and
CED from answering terminal Data
ANSAM V.8 ANSam Fax, Text and
Data
6.3 Signals
None
6.4 Statistics
None
6.5 Procedures
None
7 Text Conversation package
PackageID: txc (0x00F)
Version: 1
Extends: None
Description:
The Text Conversation package is intended for enabling real time
text conversation between terminals in different networks or
multimedia environments. This package includes the mechanisms needed
to transport T.140 text conversation streams [11] in multimedia
environments. The transport mechanism will be different for each
environment where the package is used.
7.1 Properties
7.1.1 Text buffering time
PropertyID: bufftime (0x0001)
Type: Integer
Possible values: 0-500
Defined in: LocalControl
Characteristics: Read/Write
Description:
This property indicates the time in ms that T.140 [8] data shall be
collected before transmission in order to keep overhead from text
low. In low bitrate IP networks, a value of 500 ms is recommended.
In environments with low overhead or high bitrates this property
should have the value 0 enabling immediate transmission of entered
characters.
Hellstrom Standards Track - Expires January 2000 8
H.248 Annex F (White Document draft) July 2000
7.1.2 Text termination connection state
PropertyID: connstate (0x0002)
Type: Enumeration
Possible values:
Idle (0x0001) for no
connection
efforts
Prepare (0x0002) for being known
in the
termination and
ready to accept
connections.
(The text
capability is
offered in
session
requests.)
Initiate (0x0003) for taking the
initiative to
establish a text
connection
opening a text
channel
Accept (0x0004) for accepting an
incoming request
for a text
session
Deny (0x0005) for denying an
incoming text
connect request
Connected (0x0006) for established
connection in
text mode
Defined in: TerminationState
Characteristics: Read/Write
Description:
The connection state property is used to register text capability,
request a text connection, and reflect details of the achieved text
connection. For transport methods having separate channel control
procedures, managed by the MGC, only a subset of the values is
used: Idle, Prepare, Connected.
Hellstrom Standards Track - Expires January 2000 9
H.248 Annex F (White Document draft) July 2000
7.1.3 Text User Identity
PropertyID: txuserid (0x0003)
Type: String
Possible value: String of up to 64 characters in Unicode
UTF-8 [23].
Defined in: LocalControl
Characteristics: Read/Write
Description:
This parameter holds the optional remote User Identity parameter of
a T.140 [11] text conversation session, retrieved from the session.
7.1.4 Text Transport
PropertyID: trpt (0x0004)
Type: Enumeration
Possible values:
H224 (0x0001) for H.224 Client
ID=2 in H.320
AL1 (0x0002) for AL1 in H.324
TCP (0x0003) for TCP as in
H.323 Annex G
[12]
RTP/T140 (0x0004) for RTP with
T140 [11] as in
H323 Annex G
[12] or IETF SIP
RTP/RED/T140 (0X0005) for RTP with
T140 and
redundancy
coding RED as
in H323 Annex G
or IETF SIP
T134 (0X0006) for T.134 in the
T.120
environment [14]
Unassigned (0X0007) When no
transport
protocol is
assigned
Defined in: LocalControl
Characteristics: Read/Write
Hellstrom Standards Track - Expires January 2000 10
H.248 Annex F (White Document draft) July 2000
Description:
The Transport parameter reflects the transport mechanism selected
for the Text Conversation termination. When the media description
has the full capability of describing sessions including the
transport mechanism, this parameter is implied by the media
descriptor.
7.1.5 Text Protocol Version
PropertyID: TextProto (0x0005)
Type: Integer
Possible values: Any integer
corresponding to a
T.140 version number.
(currently 1)
Defined in: LocalControl
Characteristics: Read/Write
Description:
The version of the T.140 protocol used in the connection.
7.1.6 Redundancy Level
PropertyID: red (0x0006)
Type: Integer
Possible values: 0-6
0=use default or automatic decision on redundancy level
(default)
1=Use no redundancy
2-6=use specified number of generations of data.
Defined in: LocalControl
Characteristics: Read/Write
Description:
The number of generations to use in RTP redundancy coding including
the Primary.
7.1.7 Txc request timer
PropertyID: txctim (0x0007)
Type: integer
Possible values: 0-6000
Default: 0
Defined in: LocalControl
Characteristics: Read/Write
Description:
The txctim property is a timer value in tenths of seconds for the
requested operation. If the requested operation is not completed
within this time, the state is returned to Idle and the result
Hellstrom Standards Track - Expires January 2000 11
H.248 Annex F (White Document draft) July 2000
reported in the connchange event. An initial timer value of 0
indicates that no timer control is requested.
7.2 Events
7.2.1 Connection State Change
Event Id: connchange (0x0001)
EventDescriptorParameters: none
ObservedEventDescriptorParameters:
ParameterName: Connection Change
ParameterID: connchng (0X0001)
Type: Enumeration
Possible Value: As property txc/connstate
Description:
This event will occur when the text connection state for the
termination has changed. Its parameter is the new contents of the
Connection State property.
If a request timed out, the state is returned to Idle.
7.3 Signals
None
7.4 Statistics
7.4.1 Characters Transferred
StatisticsID: chartrans (0x0001)
Units: count
Description:
No of bytes of T140 data transferred through the termination.
7.4.2 Lost Packets
StatisticsID: packlost (0x0002)
Units: count
Description:
Number of T140 packets lost as counted by the receiving T.140
termination.
7.5 Procedures
The following are standard transport mechanisms for text
conversation in different environments.
Hellstrom Standards Track - Expires January 2000 12
H.248 Annex F (White Document draft) July 2000
* In H.320: H.224 with Client ID=2
* In H.324: AL1 channel connected with H.245 procedures
* In T.120. T.134 transport in T.125 communication channel
environment.
* In H.323. RTP/T140 or TCP as selected with H.245 messages.
* In IETF SIP: RTP/T140 as initiated with SDP.
Note that the T140 text media is also used together with V.18 [9]
modems for text telephony, specified in a separate package:
Text_Telephone (txp).
The Text Conversation package is intended to be added to a
multimedia termination, handling appropriate multiplexing and
control.
7.5.1 Function
A termination with Text Conversation adds capability declaration for
a text conversation channel in the call setup according to
procedures defined for each environment. When matching capabilities
exist, a T140 channel can be established according to the transport
protocol used in the current environment. T140 text stream contents
received from one termination is transferred for transmission to
other t140 capable terminations in the context. The T140 contents
may be buffered for a short moment for possible collection of more
text in the same transmission according to the buffer time property.
7.5.2 Informative description
Real time text conversation allows telecom users to carry out a
written conversation. The presentation and coding aspects of
standardised text conversation are defined in ITU-T T.140. Text is
transmitted character by character (or in small blocks ) so that the
users experience a close interaction. The text and basic editing
control is ISO 10 646-1, UTF-8 [23] coded. The figure gives an
example of how a text conversation can be displayed to the user.
ANNE EVE
Hi, this is Anne. Oh, hello Anne, I am glad you
are calling! It was long
since we met!
Yes, have you heard that I will No, that was new to me. What
come to Paris in November? brings you here?
Figure: Possible display of a one to one text conversation.
For each transport environment, a suitable transport protocol must
be selected to carry the text. Currently defined and Recommended
transport environments for T.140 text media streams that can be
supported by this package are:
Hellstrom Standards Track - Expires January 2000 13
H.248 Annex F (White Document draft) July 2000
1. Packet networks, where the procedures described in H.323 Annex G
[12] can be used for setting up and conducting text conversation
sessions, using TCP or RTP/T140 for the transport of T.140.
2. Packet networks, where the IETF Session Initiation Protocol SIP
can be used for setting up and conducting text conversation sessions
using RTP/T140 for the transport of T.140.
3. The H.324 multimedia environment in PSTN, ISDN and Mobile
networks, where an AL1 channel connected by H.245 procedures is used
for T.140.
4. The H.320 multimedia environment, where a H.224 channel with
client ID=2 is specified for transport of T.140.
5. The T.120 data conferencing environment, that can be used alone
or in conjunction with any of the environments above, where T.134
specifies the application entity and T.125 the data channel for
T.140.
A separate Text Telephone package (txp) supports text telephony in
the PSTN using the ITU-T V.18 modem in native and legacy modes and
T.140 for communication with terminations using this package.
Interworking between these forms of Text Conversation can be
achieved through the use of gateways with packages defined here.
7.5.3 Total Conversation
Most text conversation transport environments are part of multimedia
communication systems. With the introduction of text, they enable
conversation in video, text and voice simultaneously, called Total
Conversation. The total set of communication modes that people tend
to use locally can be offered on a distance through Total
Conversation. Since the text part is built on the unified
presentation level T.140, the task to arrange interoperability of
Total Conversation in different network environments through a
gateway is simplified.
Video is optional in the multimedia systems. Therefore compatible
text-and-voice conversation can also be established within the same
framework.
7.5.4 Descriptor to use for text conversation.
One descriptor value is of specific interest for the Text
Conversation and Text Telephone packages. That is the text
conversation media stream. It is described here for information.
Hellstrom Standards Track - Expires January 2000 14
H.248 Annex F (White Document draft) July 2000
Text conversation stream
This descriptor is used for the text conversation stream, according
to ITU-T T.140 [11]. T.140 gives a general presentation level
description for a termination supporting real time text
conversation. The text and basic editing control is UTF-8 coded
[23]. For each transport environment, a suitable transport protocol
must be selected to carry the text.
T140 is a registered MIME text stream name, that can be specified to
be used as it is or in RTP embedding of RFC 2793 [13].
Examples:
From MGC to MG in an ADD command, the T140 stream could be specified
as this example shows:
Media { Stream = 4 { LocalControl {
Mode = ReceiveOnly,
g/NetworkType = RTP/IP4,
g/PreferredCodecs=T140}}}
The MG would return the SDP specification for the media stream:
Media { Stream = 4 {Local = SDP {
v=0
c=IN IP4 125.125.125.111
m=text 1111 RTP/AVP 98
a=rtpmap:96 red
a=fmtp: 98 96/96
a=rtpmap: 96 t140}}}
8. Text Telephone package
PackageID : txp (0x0016)
Version: 1
Extends: None
Description
The text telephone package is used on a line termination in a Media
Gateway, to handle text telephone calls. It includes V.18 [9] text
telephone modem functionality that adapts to different legacy text
telephone systems in the PSTN as well as it provides communication
with V.18 equipped text telephones. The text media stream is UTF-8
coded [23] with a few editing functions as specified in ITU-T T.140
[11]. The text telephone package is intended to be operated together
with the Call Type Discrimination package (ctyp) to perform V.18
automoding functions.
Hellstrom Standards Track - Expires January 2000 15
H.248 Annex F (White Document draft) July 2000
Text Telephony
Text Telephony offers a real time conversation in text between two
parties. It may be combined with voice conversation. Text telephony
in PSTN existed in at least 6 incompatible legacy modes before the
automoding modem Recommendation for text telephony V.18 was
introduced by the ITU. V.18 is suitable for use in PSTN text
telephones, but also in gateways for connection to the PSTN text
telephones. When connected, it can operate in one of its native V.18
modes, or in any of the 6 legacy modes described in V.18 annexes.
The legacy modes are Baudot, EDT, DTMF, V.21, Minitel and Bell103.
The mode detection and adjustment of the transmission to the
selected mode is automatic.
The native modes use ITU-T T.140 for the text coding and control and
V.21 [17] or optionally V.61[22] for the modulation. The legacy
modes use different character coding schemes, but when used in a
gateway, the text stream to and from the textphone termination is
T.140 coded for all modes. The text telephone package described here
includes character conversion, filtering and other adaptation needed
for conversation with the legacy mode text telephones.
Carrier modes and carrier-less modes.
Three of the legacy textphone modes are carrier-less. This means
that they do not send any signal at all when there are no characters
to transmit. Three legacy modes and the native V.18 modes use a
carrier tone transmitted as long as the connection is maintained. If
the carrier stops, it is detected but the line is not disconnected,
because this is normal behaviour during call transfer and
alternating voice and text usage.
Text telephone package considerations above the V.18 modem level.
V.18 only specifies an automoding modem and the requirement to use
T.140 when V.18 native mode is achieved in a connection. When used
in a gateway, there are some general issues that must be handled
above the V.18 level.
Character set.
The legacy modes have limited character sets. For all legacy modes,
appropriate character conversion, filtering and control interception
is included in the package functionality, so that the communication
with other T140 text terminations in the context is equalized to a
T140 text stream.
Embedded termination functionality
There is no need to open all details of the use of V.18 and T.140 to
be accessible from the MGC in a gateway. V.18, T.140, character
conversion methods and other automated methods are therefore
Hellstrom Standards Track - Expires January 2000 16
H.248 Annex F (White Document draft) July 2000
combined in the text telephone package that can be added to suitable
terminations of a gateway. This figure describes the text telephone
package components.
Control Text stream Audio stream
| | |
| | |
| | |
| |_____________________| |
| | | |
|-----> | T.140 | |
| | | |
| |_____________________| |
| | | |
| | | |
| |___________________| |___________________| |
| | | | | |
|->| Transparent text | | T.140 conversion | |
| | transmission for | | for legacy | |
| | native V.18 modes | | textphone modes | |
| | | | | |
| |___________________| |___________________| |
| | | |
| | | |
| |_____________________| |
| | | Simultaneous audio |
|-----> | V.18 |---------------------|
| | Modem | |
| | | |
| |_____________________| |
| | |
| | |
| / \ |
| / \ Alternating audio |
|-------------------->/ \-----------------------------|
\ /
\ /
\ /
|
|
Line interface
Figure : Text telephone package functional view
8.1 Properties
8.1.1 Conversation mode
PropertyID: convmode (0x0001)
Type: Sub-list
Hellstrom Standards Track - Expires January 2000 17
H.248 Annex F (White Document draft) July 2000
Possible values:
Text-only (0x0001) Basic text only mode, not
possible to combine with voice.
Alternating (0x0002) Text and voice may be
alternating.
Simultaneous (0x0003) Simultaneous text and voice
mode.
Defined in: Termination state
Characteristics: Read/Write
Description:
The behaviour of the termination is influenced by this property. By
setting the property to a selection of the possible values, the
number of ways that the conversation can be conducted can be
defined. After connection the property contains the actual
conversation mode used in the call.
The basic text only mode shall always be supported.
The alternating text and voice mode is most often used to enable one
user to speak and read and the other to listen and type. It is used
because there was no technology support for simultaneous voice and
text when text telephony was introduced. It is only supported for
compatibility with the legacy mode text telephone habits.
The simultaneous text and voice mode enables the users to
communicate in any combination and order of the two media. No legacy
mode terminals operate in this mode. V.18 equipped terminals with
V.61 [21] modulation can operate in this mode.
8.1.2 Communication Mode
PropertyID: commode (0x0002)
Type: Enumeration
Possible values:
V18-V21Hi (0x0001) native V.18 mode transmitting
on the high channel for text
only or text and voice
alternatively.
V18-V21Lo (0x0002) native V.18 mode transmitting
on the low channel for text
only or text and voice
alternatively.
V18-V61C (0x0003) native V.18 mode for text and
voice simultaneously,
Hellstrom Standards Track - Expires January 2000 18
H.248 Annex F (White Document draft) July 2000
transmitting in the caller's
channel.
V18-V61A (0x0004) native V.18 mode for text and
voice simultaneously,
transmitting in the answering
part's channel.
V21Hi (0x0005) legacy V.21 mode transmitting
on the high channel
V21Lo (0x0006) legacy V.21 mode transmitting
on the low channel.
DTMF (0x0007) DTMF text telephone mode.
EDT (0x0008) EDT ("European Deaf Telephone")
Baudot 45 (0x0009) Baudot 45.45 bits / s
Baudot 47 (0x000A) Baudot undetermined bitrate
Baudot 50 (0x000B) Baudot 50 bits/s
V23Hi (0x000C) V.23 modulation and Minitel
coding transmitting on the high
channel
V23Lo (0x000D) V.23 modulation and Minitel
coding, transmitting on the low
channel.
BellHi (0x000E) Bell 103, transmitting on the
high channel
BellLo (0x000F) Bell 103, transmittion on the
low channel
None (0x0010) No mode achieved
Defined in: LocalControl
Characteristics: Read/Write
Description:
This property indicates what modulation and mode the V.18 modem is
operating in, reflecting what type of text telephone it is in
connection with. For an explanation of the different modes, see ITU-
T V.18 [9].
Hellstrom Standards Track - Expires January 2000 19
H.248 Annex F (White Document draft) July 2000
If specific mode operation is wanted, this property is set before
the text connection is made. Normally it is set with the outcome of
the V.18 automoding procedure performed with the Call Type
Discrimination package.
When a legacy mode textphone signal is detected by the Call Type
Discrimination package, the connection result is only reported, but
V.18 does not transmit any signal until ordered to do so by setting
this property or when probing is invoked from this package.
8.1.3 Connection Mode
PropertyID: connmode (0x0003)
Type: Enumeration
Possible values:
Idle (0x0001) No connection established and no efforts
to connect
Connecting (0x0002) For request of the native or legacy mode
indicated in the Communication Mode
property.
Connected (0x0003) Connection established in one of the
communication modes
Defined in: Termination State.
Characteristics: Read/Write
Description:
This property indicates in what connection phase and mode the V.18
modem is operating. A connection effort is initiated by setting this
property to connecting, with the desired mode in the Communication
Mode property.
A V.18 modem can be controlled to operate in one of a set of modes
for seeking contact with a counterpart. The modes available are
listed as values of this property. Determination of the mode is made
by the ctype package, possibly combined with the probing action of
thatis package.
Once connected, the termination operates in the selected mode until
the text connection is lost or it is ordered to disconnect. If text
connection is lost for a certain time, the automoding procedure can
be restarted through the ctyp package, or the modem can stay in the
achieved mode trying to reconnect.
The ctyp package may be used on a connected voice line to detect if
the remote user want to enter text mode. It must be noted that for
some of the legacy modes (EDT, DTMF and Baudot), the user has to
push some keys on the textphone to make the connection when V.18 is
Hellstrom Standards Track - Expires January 2000 20
H.248 Annex F (White Document draft) July 2000
set in the automode monitor mode. This is slightly unusual for a
textphone user, who normally waits for the answering side to start
the conversation. Therefore, the explicit automoding modes should be
used when possible, probing as answering and sending V.18 signals as
calling.
If a connection request fails, the property returns to Idle state.
If the connection request succeeds, the property changes value to
Connected.
8.1.4 Action at loss of connection
PropertyID: lossconnection (0x0006)
Type: Enumeration
Possible values:
Keep: (0x0001) keep selected communication mode
Return: (0x0002) return to automoding.
Defined in: Termination State
Characteristics: Read/Write
Description:
This property tells how the V.18 modem handles loss of text
connection. When "Keep" is selected, the conversation is optimised
for the alternating text - voice mode.When "Return" is selected, the
communication is optimised for call forwarding between different
types of text telephones. For that case, ctyp must be invoked for
reconnection.
8.1.5 V18 options
PropertyID: v18opt (0x0007)
Type: Enumeration
Possible values: List of:
V.61 capability (0x0001): indicates the ability to use V.61
modulation[22]
Defined in: Termination state
Charateristics: Read/Write
Description:
This property indicates what optional capabilities the V.18 modem
implementation has and is allowed to use.
8.1.6 Character set
PropertyID: characterset (0x0008)
Type: String
Possible values: ISO registered name for a character set.
Defined in: Termination State
Characteristics: Read/Write
Hellstrom Standards Track - Expires January 2000 21
H.248 Annex F (White Document draft) July 2000
Description:
The legacy modes have limited character sets. For all legacy modes,
appropriate character conversion, filtering and control interception
is included in the package functionality, so that the communication
with other T140 text terminations in the context is equalized to a
T140 text stream. For a user friendly conversion of received
national characters in the limited character sets to ISO 10 646-1
used in T.140, there is a need to specify what national translation
table to use. This is valid for EDT, DTMF, V.21 and Baudot modes.
The Character set parameter is the the registered ISO code for the
national variant of the ITU-T T.50 [24] character set used. Default
is:
* German for EDT,
* Danish for DTMF (suitable also for the Netherlands),
* Swedish/Finnish for V.21 (suitable also for UK),
* International Reference Version for Baudot.
Example: In Norway, the letter "A" (A and E together) is used in the
same location of the 7-bit character table as used for letter "A" (A
with umlaut) in Finland and Sweden. The international reference
version has the character "[" (left bracket) in the same position.
In T140 these characters have unique positions.
8.2 Events
8.2.1 Connection mode changed
EventID: connchng (0x0001)
EventDescriptorParameters: none
ObservedEventDescriptorParameters:
Same as the property txp/commode
Description:
This event reports the change of communication mode, as result of a
connection effort, or a disconnection.
8.3 Signals
None.
8.4 Statistics
8.4.1 Number of characters transferred
StatisticsID: chartrans (0x0001)
Units: count
Description:
Number of bytes of T140 data transferred.(sent and received)
Hellstrom Standards Track - Expires January 2000 22
H.248 Annex F (White Document draft) July 2000
8.4.2 Number of alternating turns.
StatisticsID: altturns (0x0002)
Units: count
Description:
Number of alternating turns when using alternating conversation
mode.
8.5 Procedures
8.5.1 Basic operation
After line connection, the termination where the Text Telephone
package is implemented should be requested to try a text telephone
connection using the functionality of the Call Type Discrimination
Package for the modem signalling according to ITU-T V.18 in a
selected mode. Once the connection is established, the text
telephone package is used for the text communication in the
established mode.
After connection in text mode, the result is a gateway context with
one textphone termination and one voice line termination connected
to the same line. In the same context, the normal case is to have
other terminations with audio and text conversation media.
In the most simple text-only case, the audio streams are not used
and may be released.
Text received through the V.18 modem is converted if necessary to
T.140 [11]. It is embedded in the RTP/T140 format according to the
rules in T.140 and RFC 2793 [13], specifying RTP/T140. Text received
from other text conversation terminations is transmitted through the
text telephone termination after extraction from the RTP packets.
This process continues until any end disconnects.
8.5.2 Informative description
Descriptors to use for text telephony:
Two descriptor values are of specific interest for the Text
Telephone package. That is the text conversation media stream and
the V.18 modem. The text conversation media stream is described in
the Text Conversation package. The V.18 modem descriptor is
described here for information.
8.5.3 V.18 Modem
Modem name V18.
This modem type is intended for communication with text telephones
in the PSTN. Its operational modes are implemented in the textphone
package. The logic for setting and detecting the mode according to
V.18 is handled by the ctyp package. Some properties of the text
telephone package and the Call Type Discrimination package directly
Hellstrom Standards Track - Expires January 2000 23
H.248 Annex F (White Document draft) July 2000
reflect parameters for control of the V.18 modem. V.18 modem
implementations may have different capabilities reflected in the
property values.
A V.18 modem may be operated in automode monitor mode, when it
listens on a voice line for text telephone signals. This mode can be
used to detect that the user wish to transit from voice to text
during a voice call. That is done entirely with the ctyp package.
Alternatively, a V.18 modem may be operated in modes where it
actively tries to establish a text telephone connection. The
procedure includes transmission of text telephone specific signals
on the line. For calling modems, it is done by the CI signal in the
ctyp package. For an answering modem it is done with the ctyp
package combined with probing from the textphone package by setting
the commode property to the probing mode.
When the mode is discriminated, the commode property should be set
to request communication in that mode.
After successful connection in a text telephone mode, the text
session is conducted in the specific mode as controlled with the
commmode property, and the text stream is made available in T.140
format for other text terminations in the context.
The text telephone package only contains the text connection and
text media aspects of the termination. It is supposed to be combined
with appropriate call control packages, line interface packages and
voice channel packages.
8.5.4 Operation with alternating text and voice mode
If the involved gateways have the alternating text and voice
capability, the following procedure can be applied to give the users
a possibility to go back and forth between using text and voice.
Between the terminals in the context, two streams are members of the
context during the call, the text stream and the audio stream.The
procedure is slightly dependent on the terminal type as described in
the following section.
8.5.5 Alternating text and voice mode with legacy, carrier-less
textphones:
For the carrierless types Baudot, DTMF and EDT the following way to
operate should be used: When V.18 detects text, the textphone
termination stops feeding the audio stream into the audio- stream of
the context, and instead inserts the detected and T140 converted
characters into the text-stream. This mode is continued as long as
characters keep coming from the PSTN textphone.
When no more characters arrive, and no textphone signal is received
within 1 second, the audio channel is again fed to the Audio-stream
Hellstrom Standards Track - Expires January 2000 24
H.248 Annex F (White Document draft) July 2000
channel. If new text comes from the V.18 side, the process is
repeated.
It is important that the implementation of V.18 can retrieve
characters from the first detected text telephone signals after each
mode shift. The leading tones before the characters can be as short
as 150 ms.
If text is received from the context through the Text stream, when
V.18 is not active receiving text, the voice path is muted, and the
characters are sent to the V.18 modem for transmission. When all
text is transmitted and no more is received for two seconds, the
audio channels are enabled again.
Since the carrier-less systems are one way alternate transmission
systems, transmission of characters is possible only in one
direction at a time. Once started, reception is given priority.
In the Context, two way simultaneous transmission is possible.
Therefore, characters received from the context while V.18 is busy
receiving should be buffered (up to a reasonable limit).
All these actions after the initial connections are automatic and
are handled within the textphone termination.
8.5.6 Alternating voice and text conversation in carrier mode:
After a carrier mode text connection is established, loss of
carrier can be taken as the indication that the audio stream shall
be connected with audio interface of the line. When the remote end
is a V.21, Bell or V.18 device, the text communication can be full
duplex, so the gateway can just let the text streams flow between
the terminations.
When carrier reappear, or text is received through the text system,
the audio stream shall be muted, and text transmission noted.
Minitel does not support any voice interworking mode.
8.5.7 Simultaneous voice and text mode
In case the simultaneous voice and text method is enabled, the
handling of the voice and text channels is trivial. Once connected,
the text stream can stay connected with the remote text stream all
the time to serve a two way simultaneous text conversation, and the
audio channel can be connected with the remote audio stream to
support a two way simultaneous audio channel. This mode can be
supported by V.18 with V.61 modulation.
Hellstrom Standards Track - Expires January 2000 25
H.248 Annex F (White Document draft) July 2000
9. Call Type Discrimination package
PackageID : ctyp (0x0011)
Version: 1
Extends: none
Description:
This package monitors the termination for signals indicating
presence of a T.30 telefax terminal [5], a V.18 or legacy mode text
telephone [9] or data modem. In co-operation with the MGC and the
remote MG or endpoint, it can perform exchange of signals until the
call type is determined and an appropriate mode for the call can be
established.
The package contain modem negotiation functions of ITU-T V.25 [10],
V.8[7], v.8 bis[8], V.18[9] and T.30[5]
9.1 Properties
9.1.1 Call Types
PropertyID: calltyp (0x0001)
Type: sub-list
Possible values:
FAX (0x0001)
TEXT (0x0002)
DATA (0x0003)
Defined in: Termination State
Characteristics: Read/Write
Description:
The Call Types property selects the types of calls for which the
termination is monitored. Note that the connection is by default
regarded to be capable of handling audio and therefore no specific
value is included for that.
9.1.2 Text Call Types
PropertyID: ttyp (0x0002)
Type: Sub-list
Possible values:
V21 (0x0001)
DTMF (0x0002)
Baudot45 (0x0003)
Baudot50 (0x0004)
Bell (0x0005)
EDT (0x0006)
Minitel (0x0007)
V18 (0x0008)
Hellstrom Standards Track - Expires January 2000 26
H.248 Annex F (White Document draft) July 2000
Description:
This parameter indicates for what text telephone modes the
termination is monitored, used in TEXT mode
9.1.3 V8bissupport
PropertyID: v8bsup (0x0003)
Type Boolean
Possible values:
True V.8 bis is supported by the package
False V.8 bis is not supported by the package
Defined in: Termination State
Characteristics: Read
Description:
Support of the V.8 bis [8]modem negotiating procedure is optional.
The V8bissupport property indicates if V.8 bis is supported. It can
be used in TEXT,FAX and DATA modes.
9.1.4 Probe message
PropertyID: probemsg (0x0004)
Type: String
Possible Value: Any string, not more than 20 characters long.
Defined in: Termination State
Characteristics: Read/Write
Description:
This property holds a short string that the termination transmits as
a stimulating probe message for the carrierless communication modes
in the answering modes. The far end user will see this message when
it is transmitted in the mode matching the counterpart's textphone,
and type a response back, enabling the V.18 modem to detect the type
of carrierless text telephone in the connection.
When issued, it is automatically followed by " GA" in Baudot
probing, and with "+" in EDT and DTMF probing to reflect the
turntaking signal habit in the different user communities. The
string could be customised to briefly inform the called user about
what service that is reached.
Note that the string is not issued in the carrier modes.
9.1.5 Probe order
PropertyID: probeorder (0x0005)
Type: Sub-List
Possible values: (for recommended orders, see V.18)
Any combination of none to six of the type indicators
V21 (0x0001)
DTMF (0x0002)
Baudot (0x0003)
Hellstrom Standards Track - Expires January 2000 27
H.248 Annex F (White Document draft) July 2000
EDT (0x0004)
MINITEL (0x0005)
BELL (0x0006)
in any desired order.
Defined in: Termination state
Characteristics: Read/Write
Description:
This property holds an indication on what modes to probe for, and
the order the probes will be transmitted. Probing is a time
consuming procedure and it is important that the most likely modes
are probed first. The order to select depends on if any legacy mode
textphones are on the market in the area where the gateway is
installed. An optimised order can be composed by enumerating the
desired specific type indicators. Note that leaving out a type from
probing may cause connection problems for connection with textphones
of that type.
9.1.6 PhasereversalDetect
PropertyID: v8bsup (0x0006)
Type Boolean
Possible values:
True Phase reversal detection is supported
False Phase reversal detection is not supported
Defined in: Termination State
Characteristics: Read
Description:
This property indicates support of detection of the phase reversals
within ANS or ANSam signals. If this property has the value "False",
ANS with phase reversals (ANSBAR) will be reported as ANS and ANSam
with phase reversals (ANSAMBAR) will be reported as ANSam in the
dtone event.
9.2 Events
9.2.1 Discriminating tone detected
EventID: dtone (0x0001)
Description:
This event indicates that a signal valid for detection and
discrimination of mode was detected. The signal name is given as a
parameter. Further logic is needed in some cases to discriminate the
call type from this information. The V.8 bis related parameters are
returned only when V.8 bis is supported [8].
Note that some textphones operate with DTMF tones. This package
decodes initial DTMF signals according to the specification for text
telephones in V.18 [9]. DTMF detection may be indicated also from
the "dd" package if that is active.
Hellstrom Standards Track - Expires January 2000 28
H.248 Annex F (White Document draft) July 2000
EventsDescriptor parameters: none
ObservedEventDescriptor parameters:
Discriminating Tone Type
ParameterID: dtt (0x0001)
Type: Enumeration
Possible values:
For FAX
CNG (0x0001) a T.30 fax calling tone
V21flag (0x0002) V21 tone and flags for fax answering
For TEXT
XCI (0x0003) a V.18 XCI
V18txp1 (0x0004) a V.18 txp signal in channel V.21(1)
V18txp2 (0x0005) a V.18 txp signal in channel V.21(2)
BellHi (0x0006) a Bell 103 carrier on the high
channel
BellLo (0x0007) a Bell 103 low channel
Baudot45(0x0008) a Baudot45 initial carrier and
characters
Baudot50(0x0009) a Baudot50 initial carrier and
characters
Edt (0x000A) an EDT initial tone and characters
DTMF (0x000B) DTMF signals
For DATA
Sig (0x000B) Modulation signal from a mode
only used for data. I.e.. not
V.21, V.23 nor Bell 103.
Common to TEXT and DATA:
CT (0x000C) a V.25 calling tone
V21hi (0x000D) a V.21 carrier on the higher
frequency channel
V21lo (0x000E) a V.21 carrier on the low
frequency channel
V23hi (0x000F) a V.23 high carrier
V23lo (0x0010) a V.23 low carrier
CI (0x0011) a V.8 CI with contents in
"dtvalue"
Common to FAX, TEXT and DATA:
ANS (0x0012) V.25 ANS, equivalent to T.30
CED from answering terminal
ANSbar (0x0013) V.25 ANS with phase reversals
ANSAM (0x0014) V.8 ANSam
ANSAMbar(0x0015) V.8 ANSam with phase reversals
Hellstrom Standards Track - Expires January 2000 29
H.248 Annex F (White Document draft) July 2000
CM (0x0016) V.8 CM with contents in
"dtvalue"
CJ (0x0017) V.8 CJ
JM (0x0018) V.8 JM with contents in
"dtvalue"
ENDOFSIG(0x0019) End of reported signal detected
reported for continous or repeated
signals
V8BIS (0x0020) V.8bis signal, with signal type in
parameter V8bistype and value in
"dtvalue"
Discriminating Tone Value
ParameterID dtvalue (0x0002)
Type: string
Possible values:
When used for V.8 and V.8 bis related messages, the following coding
rules applies:
. The transmitted V.8 message is specified as hexadecimal octet
coded string
. The transmitted V.8 bis message frame(s) is specified as
hexadecimal octet coded string (F.3.1.). Additional messages
are delimited by comma characters. Flag generation, flag
transparency 0-bit insertion and FCS generation are performed
by the MG. If no data is provided by the MGC, no V.21 carrier
is generated beyond that used in segment 2. For two
concatenated messages, the MG shall insert the required
preamble between the first and second messages.
If a V.8 bis message is detected without a preceding V.8 bis signal,
the preamble is reported as a 0 <signal> value.
The contents of valid V.8 bis message(s), if detected, are reported
using hexadecimal octet coded string(s) (5.1). Flag detection and
consumption, flag transparency 0-bit deletion and FCS checking are
performed by the MG. The MG shall not report invalid messages (e.g.
bad FCS). If two consecutive messages are detected but the first is
invalid, the MG shall indicate this with a comma in front of the
second message (e.g. ,<2nd message>). Two concatenated V.8 bis
messages are reported with two consecutive <message> indications.
V8bis type
ParameterID v8bist (0x0004)
Type enumeration
Possible values:
ESi (0x0001) V.8bis signal ESi
Hellstrom Standards Track - Expires January 2000 30
H.248 Annex F (White Document draft) July 2000
ESr (0x0002) V.8bis signal ESr
MRe (0x0003) V.8bis signal MRe
MRdi (0x0004) V.8bis signal MRd from initiator
MRdr (0x0005) V.8bis signal MRd from responder
CRe (0x0006) V.8bis signal CRe
CRdi (0x0007) V.8bis signal CRd from initiator
CRdr (0x0008) V.8bis signal CRd from responder
MS (0x0009) V.8 bis message MS with contents
in "dtvalue"
CL (0x000A) V.8 bis message CL with contents
in "dtvalue"
CLR (0x000B) V.8 bis message CLR with
contents in "dtvalue"
ACK (0x000C) V.8 bis message ACK with
contents in "dtvalue"
NAK (0x000E) V.8 bis message NAK with
contents in "dtvalue"
Description: A detected V.8 bis [8] signal. V.8 bis can be used for
all modes.
Initial Characters
ParameterID: ichar (0x0005)
Type: String
Possible values: characters received in the detection process in the
carrierless textphone modes EDT, Baudot and DTMF, intended to be
inserted in txp.
9.3 Signals
9.3.1 V8Signal
SignalID: v8sig (0x0001)
SignalType: OO
Parameters:
Hellstrom Standards Track - Expires January 2000 31
H.248 Annex F (White Document draft) July 2000
V.8 Signal Type
Parameter ID: v8styp (0x0001)
Type: Enumeration
Possible values
CM (0x0001)
CJ (0x0002)
JM (0x0003)
CI (0x0004)
v8nosig (0x0005) no signal _ used to stop the V.8 signal
Default may be provisioned
V8SigCont
Parameter ID: v8scont (0x0002)
Type: string
Possible values: Allowed contents of the signals, coded as
hexadecimal octet coded string.
Default is empty.
Description The V.8 [7] signals carry data for call type and
modulation modes. These parameters can be supplied through the
v8cont parameter. V.8 can be used for FAX, TEXT and DATA modes.
V18XCIEnable
Parameter ID: v18xcien (x0003)
Type: Boolean
Possible values:
True XCI transmission enabled during V.18 CI transmission
False XCI transmission disabled
Default is True
Description: XCI can be sent intermixed with CI transmission as
specified in V.18 to stimulate plainMinitel terminals to respond as
text telephones. Used in TEXT mode.
9.3.2 AnswerSignal
SignalID: ans (0x0002)
Signal Type OO
Parameters:
AnsType
ParameterID: AnsType (0x0001)
Type: Enumeration
Hellstrom Standards Track - Expires January 2000 32
H.248 Annex F (White Document draft) July 2000
Possible values:
ANS (0x0001) V.25 ANS (equivalent to T.30
CED) for all modes
ANSBAR (0x0002) V.25 ANS with phase reversals
for all modes
ANSAM (0x0003) V.8 ANSam for all modes
ANSAMBAR (0x0004) V.8 ANSam with phase reversals
for all modes
V18txp1 (0x0005) a V.18 txp signal played in V.21
channel(1) for TEXT
V18txp2 (0x0006) a V.18 txp signal played in V.21
channel(2) for TEXT
ansnosig (0x0007) no signal _ used to turn off the
signal
Default may be provisioned
9.3.3 CallingSignal
SignalID: callsig (0x0003)
SignalType OO
Parameters
callSigname
Parameter ID cSn (0x0001)
Type Enumeration
Possible values:
CT (0x0001) V.25 Calling Tone used for TEXT and DATA
CNG (0x0002) T.30 Calling tone used for FAX with defined
cadence
callnosig (0x0003) no signal _ used to turn off the signal
Default may be provisioned
9.3.4 V8bisSignal
SignalID: v8bs (0x0004)
Signaltype BR
Parameters:
V8bisSigname
ParameterID: V8bsn (0x0001)
Type: Enumeration
Possible values:
ESi (0x0001) V.8bis signal ESi
ESr (0x0002) V.8bis signal ESr
MRe (0x0003) V.8bis signal MRe
Hellstrom Standards Track - Expires January 2000 33
H.248 Annex F (White Document draft) July 2000
MRdi (0x0004) V.8bis signal MRd from initiator
MRdrh (0x0005) V.8bis signal MRd from responder on
high power
MRdrl (0x0006) V.8bis signal MRd from responder on
low power
CReh (0x0007) V.8bis signal CRe on high power
CRel (0x0006) V.8bis signal CRe on low power
CRdi (0x0007) V.8bis signal CRd from initiator
CRdr (0x0008) V.8bis signal CRd from responder
MS (0x0009) V.8 bis message MS with contents
in signalvalue
CL (0x000A) V.8 bis message CL with contents
in signalvalue
CLR (0x000B) V.8 bis message CLR with contents
in signalvalue
ACK (0x000C) V.8 bis message ACK with contents
in signalvalue
NAK (0x000D) V.8 bis message NAK with contents
in signalvalue
Default may be provisioned
Description:
V.8 bis [8] signals can be used in all modes. Some V.8 bis signals
contain data messages, supplied in V8bisSigContents.
V8bisSigContents
ParameterID: V8bscont (0x0002)
Type: string
Possible values: Valid contents for the V.8 bis signals
Default is empty.
Description:
Some of the V.8 bis signals are messages. Their contents can be
defined with theV8biscont parameter. V.8bis can be used in TEXT,
FAX and DATA modes.
The transmitted V.8 bis message frame(s) is specified as hexadecimal
octet coded string (see section 5). Additional messages are
delimited by comma characters. Flag generation, flag transparency 0-
bit insertion and FCS generation are performed by the MG. If no data
is provided by the MGC, no V.21 carrier is generated beyond that
used in segment 2. For two concatenated messages, the MG shall
insert the required preamble between the first and second messages.
If a V.8 bis message is detected without a preceding V.8 bis signal,
the preamble is reported as a 0 <signal> value.
The contents of valid V.8 bis message(s), if detected, are reported
using hexadecimal octet coded string(s) (see section 5). Flag
Hellstrom Standards Track - Expires January 2000 34
H.248 Annex F (White Document draft) July 2000
detection and consumption, flag transparency 0-bit deletion and FCS
checking are performed by the MG. The MG shall not report invalid
messages (e.g. bad FCS). If two consecutive messages are detected
but the first is invalid, the MG shall indicate this with a comma in
front of the second message (e.g. ,<2nd message>). Two concatenated
V.8 bis messages are reported with two consecutive <message>
indications.
9.3.1.5 V18probe
SignalID: v18prob (0x0005)
SignalType: OO
Parameters: none
Description: This signal transmits the v18 probes in order to
stimulate possible text telephones to transmit connect establishing
signals. The probes are sent according to the specification in
Recommendation V.18. For carrierless probes, the string in the
"probemsg" property is transmitted. The probes are sent in the order
specified in the property "probeorder".
9.4 Statistics
none
9.5 Procedures
The Call Type Discrimination package is invoked for cases when the
network connection is established and the call may enter one of the
types of voice, fax, text telephone and modem. The package contains
functionality to support the decision and connection processes. Once
discriminated and the modem handshaking completed, an appropriate
specific call type package should be invoked to complete the
connection establishment on the modulation level and perform the
session.
When used for active modem negotiation, by means of commands from
the MGC, the termination shall be made to operate according to the
Recommendations for modem negotiation; V.25[10], V.8[7], V.8 bis[8],
V.18[9] and T.30[5]. For probing according to V.18 during the
negotiating process, the probing mechanism may be applied as
defined in this package by turning the signal v18prob ON.
The package may also be used for monitoring and reporting on data
activity on the termination.
9.5.1 Informative description
If the desired call type is known from the beginning, the call type
discrimination package should be invoked in order to actively try
to establish a connection by sending out stimulating signals. By
contrast this package is also used to monitor the line to detect
signals which are to be relayed to the Media Gateway Controller as
Hellstrom Standards Track - Expires January 2000 35
H.248 Annex F (White Document draft) July 2000
input to a discrimination decision. In principle, when tones are
reported to the MGC as events by an MG, the MG should avoid passing
these tones via the media stream where possible, to reduce the
possibility of unwanted duplicate tones. Since the Call Type
Discrimination package can be invoked to initially only monitor the
line, it can be invoked on lines where voice calls are the most
common mode of operation. There may be situations where this
passive way of working results in less efficient or less reliable
connection in fax/text/data mode.
9.5.2 Operation
The package is activated on a termination of a line in an outgoing
or incoming call where fax, text or data mode may be wanted. The
properties are set to the enabled call types.
9.5.3 Operation for incoming calls
The call is answered, the destination is evaluated and the remote
call initiated using packages and gateway functions outside the
scope of this package.
The MGC may order stimulating signals defined in this package to be
sent on the line.
The line is monitored for signals for the selected modes as defined
in the "dtone" event descriptor.
The MGC is expected to evaluate call type indications of all types;
registered type of the destination, offered capabilities of the
endpoint, invoked connection efforts of specific types from the
endpoint and discriminating events from a call type discriminating
package active in setting up the connection with the other endpoint.
As soon as the modem handshaking is complete and a condition is
reached that is valid for only one call type, a package for handling
that call type should be invoked by the MGC, thus placing the MG
into the desired mode of operation.
The package contains components for conducting a negotiation
procedure according to the different connection procedures defined
in recommendations V.25 [10], V.8 [7], V.8 bis [8], T.30 [5], T.38
[6] and V.18 [9]. (V.8 bis support is optional and its availability
can be interrogated through the property V8bissupport).
9.5.4 Operation for transit calls, coming from and going to the
switched network
If no fax/text/data indication is present in the incoming call, the
outgoing call is placed in voice mode, with the Call Type
Discrimination package active.
Hellstrom Standards Track - Expires January 2000 36
H.248 Annex F (White Document draft) July 2000
If a valid tone is detected, it is reported to the MGC as an event.
By actions of the MGC it can be signalled to be replayed at the
other end.
The process continues according to the rules of the connection
procedures until the call type can be determined and the mode of
operation can be established.
9.5.5 Operation for calls having one endpoint in the packet network
If no fax/text/data indication is present in the incoming call, the
outgoing call in the packet network is placed in voice mode.
If a request to open a text channel, a fax channel or a data channel
is made from the packet endpoint, the corresponding call type is
tried on the switched network connection.
If a signal indicating presence of a fax, textphone or a modem is
received from the circuit switched network, and the call type can be
evaluated, a corresponding channel is requested to the remote packet
endpoint. If that request is acknowledged, the connection in the
fax/text/data mode is completed on the switched side.
If the call type can not be evaluated, further signal exchange is
performed on the switched interface until the call type is
determined, and then the channel establishment continues on the
packet side.
9.5.6 Cases when the call type can not be determined from the signals
For cases when the call type can not be determined by the signal
exchange, a decision must be taken by other means, or a transparent
transport can be selected.
The other means to make the decision may be a number analysis and
comparison to registered user preferences or network defaults.
Cases when the decision is not possible by signal analysis but need
to be taken by external means:
V.21: Used both for text telephony and for credit card
transactions. The decision is recommended to be based on
regional preferences and registering preference for data per
destination number in regions where the default preference is
for text telephony.
V.23: Used both for Minitel-based text telephones and for the
Minitel information retrieval system. The conflict is only when
an answering endpoint transmits the v23hi signal. A transparent
data transport is recommended for this case.
Hellstrom Standards Track - Expires January 2000 37
H.248 Annex F (White Document draft) July 2000
9.5.7 Scenarios and call flows
Signal sequence scenarios can be derived from the different
connection protocols, with T.38 being the main protocol for fax,
V.18 for text telephony and V.8 / V.25 for data.
The typical fax scenario is discriminated when CNG is detected from
the calling end and a corresponding CED (ANS) and/or V.21flags are
detected at the answering end. For instances when either a CNG or
ANS is not reported to the MGC, V21flags detection is sufficient for
fax discrimination. Alternatively, a V.8 CM or JM signal with a fax
call type may be detected at either end.
The text telephone scenario is discriminated when a text telephone
call type is detected in V.8, a text telephone function is
negotiated in V.8 bis, or a signal valid for text only is detected.
The data scenario is discriminated when a data call type is detected
in V.8, a data function is negotiated in V.8 bis, or a data mode
(not text) is entered by any part.
In all cases the handshaking protocol should be completed using the
Call Type Discrimination package, before entering the selected data
mode.
9.5.8 Initial characters
For carrierless text telephones of the Baudot, EDT and DTMF types
the text transmission itself is needed for mode determination, and
therefore the characters received during determination shall be
stored. They shall be made available by local actions in the MGto be
used by the txp package as initially received text for a seamless
takeover of a connection.
9.5.9 Time critical handling
The default way of handling connection requests should be to
propagate the connection request to the remote endpoint, and verify
capabilities before positively responding to an incoming connection
request for fax, text or data mode. It can however be very time
consuming to verify the endpoint capabilities, and connect
appropriate channels. The caller may timeout between detection of
off-hook, and receiving a positive signal. Similar time critical
steps exist in the V.8, V.8 bis, V.18, T.30 and V.25 procedures. The
MGC must take action to compromise between the risk of one party
timing out because of long waiting for a signal, and the risk of
connecting a fax/text/data call before the capabilities of the
endpoints are verified and the appropriate channels connected. One
possible way to handle this risk is to define default actions to
take before any party in the call times out. The ctyp package gives
the MGC all necessary control to handle the connection process
including such actions.
Hellstrom Standards Track - Expires January 2000 38
H.248 Annex F (White Document draft) July 2000
10. Fax package
Package Name: Fax
PackageID: fax (0x0012)
Version: 1
Extends: None
Description:
The fax package is intended for enabling fax communication between
terminals/applications in different networks or messaging
environments. This package includes the mechanisms needed to
identify T.30 [5] fax sessions (signals and data).
10.1 Properties
10.1.1 Fax connection state
PropertyID: faxstate (0x0001)
Type: Enumeration
Possible values:
Idle (0x0001) no connection efforts
Prepare (0x0002) known in the termination and
ready to accept connections
Negotiating (0x0003) taking the initiative to
establish a fax connection
TrainR (0x0004) Fax Phase B or later training
as Receiver
TrainT (0x0005) Fax Phase B or later training
as Transmitting
Connected (0x0006) completed connection
EOP (0x0007) Procedures Complete
ProcInterrupt (0x0008) Procedure Interrupt Processing
Disconnect (0x0009) Premature Disconnect
Characteristics: Read/Write
Defined in: TerminationState
Description:
After successful phase A connection with the ctyp package, the
connection state property is used to request a fax connection.
When placing a termination into a fax mode, the initial state shall
be set to "Negotiating".
When this property is interrogated, it shall reflect the state of
the achieved fax connection.
A connection effort can be cancelled by setting the faxstate
property to Idle.
Hellstrom Standards Track - Expires January 2000 39
H.248 Annex F (White Document draft) July 2000
10.1.2 Fax Transport
PropertyID: ftrpt (0x0001)
Type: Enumeration
Possible values:
T30 (0x0001) for T.30 PSTN sessions without ECM
T30ECM (0x0002) for T.30 PSTN sessions with ECM
(non-V.34)
T.30V34 (0x0003) for T.30 PSTN sessions with V.34
(half-duplex)
Characteristics: Read/Write
Defined in: Termination State
Description:
The Transport parameter reflects the transport mechanism selected
for the fax termination.
10.1.3 TransmissionSpeed
PropertyID: trspd (0x0002)
Type: Integer
Possible values: 1200-33600
Defined in: Termination State
Characteristics: Read/Write
Description:
The Transport parameter reflects the transmission speed seen at the
analog interface for the fax relay or the transmission speed used by
the FAX termination (T.30 PSTN).
10.1.4 PSTN Interface
PropertyID: pstnif (0x0003)
Type: Enumeration
Possible values:
NA (0x0001) not applicable
V17 (0x0002)
V27TER (0x0003)
V29 (0x0004)
V21 (0x0005)
V34 (0x0006)
Defined in: Termination State
Characteristics: Read/Write
Description:
The PSTN Interface parameter reflects the interface used to connect
to a physical FAX machine.
Hellstrom Standards Track - Expires January 2000 40
H.248 Annex F (White Document draft) July 2000
10.2 Events
10.2.1 Fax Connection State Change
Event ID: faxconnchange (0x0001)
EventDescriptor Parameters: none
ObservedEventDescriptorParameters:
Fax Connection Change
ParameterID: faxconnchng (0x0001)
Type: Enumeration
Possible Value:
Idle (0x0001) no connection efforts
Prepare (0x0002) known in the termination and
ready to accept connections
Negotiating (0x0003) taking the initiative to
establish a fax connection
TrainR (0x0004) Fax Phase B or later training
as Receiver
TrainT (0x0005) Fax Phase B or later training
as Transmitting
Connected (0x0006) completed connection
EOP (0x0007) Procedures Complete
ProcInterrupt (0x0008) Procedure Interrupt Processing
EOF (0x0009) end of fax session, call
terminating
PI (0x000A) Priority Interrupt ; Switch to
Voice
Disconnect (0x000B) Premature Disconnect
Description:
This event will occur when the fax connection state for the
termination has changed. Its parameter is the new Fax Connection
State. A connection effort that timed out returns the termination to
the Idle state.
10.3 Signals
None
10.4 Statistics
10.4.1 Pages Transferred
StatisticsID: pagestrans (0x0001)
Type: integer
Description:
No of pages of fax image data transferred through the termination.
Hellstrom Standards Track - Expires January 2000 41
H.248 Annex F (White Document draft) July 2000
10.4.2 Train Downs
StatisticsID: traindowns (0x0002)
Units: count
Description:
Number of times FAX trained down during tramsmission.
10.5 Procedures
The following are standard transport mechanisms for fax in different
environments.
* In T.30: Use T.30 [5] procedures with and without ECM
* In T.30 Annex C/F: Use T.30 procedures selected via V.8 (Used for
V.34 fax)
10.5.1 Function
A termination with Fax provides a method for transfer of fax pages
preceded by negotiations in the call setup according to procedures
defined for each environment. When matching capabilities exist, the
appropriate sessions can be established in order to transfer pages
of image or binary data.
Real time fax allows telecom users to transfer fax pages in real
time. The procedural aspects of GSTN fax are defined in ITU-T T.30.
[5] The compression methods used in transporting fax images are
defined in T.4, T.6, T.81, T.82, T.85 and T.44. In traditional
T.30 without error correction, images are transferred in a stream
one page at a time. In T.30 with error correction, images are
transferred in blocks that are also known as partial pages.
Numerous examples of fax sessions are contained in Appendix IV to
T.30.
For each transport environment, a suitable transport protocol must
be selected to carry the image. Currently defined and Recommended
transport environments for T.30 media streams that can be supported
by this package are GSTN networks, where the procedures are defined
in T.30, T.30 Annex A (for error correction), T.30 Annex C (duplex
protocol) and Annex F (half duplex V.34 protocol).
10.5.2 Process of Adding Fax Capable Terminations
The MGs are responsible for detecting fax tones and relaying the
related events to the MGC. The MGC should conduct Call
Discrimination as defined within the Call Type Discrimination
Package in order to determine whether a fax or other mode is
applicable. The MGC may choose to skip this if the MG is not
capable of the Call Type Discrimination Package. Once the MGC
evaluates the tones and determines that the incoming call is fax,
Hellstrom Standards Track - Expires January 2000 42
H.248 Annex F (White Document draft) July 2000
the MGC shall execute appropriate Modify commands to place the
termination into a "Negotiating" state.
10.5.3 Process of Ending a Fax Call
The MGs are responsible for detecting events that would cause the
interruption of a fax call. The MGC is responsible for making the
determination if this switch can be made and instruct the MGs to
switch. It also responsible for switching it back to fax. The MGC
should receive indication that the fax call ends from the MG before
receiving typical call termination indications.
11. IP Fax package
Package Name: IPFax
PackageID: ipfax (0x0013)
Version: 1
Extends: None
Description:
The fax package is intended for enabling real time or store and
forward fax communication between terminals/applications in
different networks or messaging environments. This package includes
the mechanisms needed to transport T.30 fax sessions (signals and
data) in a real time IP environment. The transport mechanism will
be different for each environment where the package is used.
11.1 Properties
11.1.1 Fax connection state
PropertyID: faxstate (0x0001)
Type: Enumeration
Possible values:
Idle (0x0001) no connection efforts
Prepare (0x0002) known in the termination and
ready to accept connections
Negotiating (0x0003) taking the initiative to
establish a fax connection
TrainR (0x0004) Fax Phase B or later training
as Receiver
TrainT (0x0005) Fax Phase B or later training
as Transmitter
Connected (0x0006) for completed connection
EOP (0x0007) Procedures Complete
ProcInterrupt (0x0008) Procedure Interrupt Processing
Disconnect (0x0009) Premature Disconnect
Characteristics: Read/Write
Defined in: Termination State
Hellstrom Standards Track - Expires January 2000 43
H.248 Annex F (White Document draft) July 2000
Description:
After successful phase A connection with the ctyp package,
the connection state property is used to request a fax connection.
When placing a termination into a fax mode, the initial state shall
be set to "Negotiating".
When this property is interrogated, it shall reflect the state of
the achieved fax connection.
11.1.2 IPFaxTransport
PropertyID: ipftrpt (0x0001)
Type: Enumeration
Possible values:
T38UDPTL (0x0001) for T.38 [6]using UDPTL
T38TCP (0x0002) for T.38 using TCP
T37 (0x0003) for T.37 [22]
AUDIO (0x0004) for audio codec (e.g., G.711 over RTP [4])
Characteristics: Read/Write
Defined in: Termination State
Description:
The IP Fax Transport parameter reflects the transport mechanism
selected for the fax termination.
11.1.3 TransmissionSpeed
PropertyID: trspd (0x0002)
Type: Integer
Possible values: 0-33600
Characteristics: Read/Write
Defined in: Termination State
Description:
The Transport property reflects the transmission speed seen at the
IP interface for the fax relay. A value of zero (0) indicates that
there is no speed set.
11.1.4 T.38 Capabilities
PropertyID: T38Capabilities (0x0003)
Type: sub-list
Possible values:
FaxFillBitRemoval (0x0001) indication of fill bit removal
FaxTranscodingMMR (0x0002) for MMR transcoding
availability
FaxTranscodingJBIG (0x0003) for JBIG transcoding
availability
UDPFEC (0x0004) UDP Forward Error Correction
UDPRedundancy (0x0005) UDP Redundancy Error Correction
Hellstrom Standards Track - Expires January 2000 44
H.248 Annex F (White Document draft) July 2000
Characteristics: Read/Write
Defined in: Termination State
Description:
These capabilities describe the T.38 [6] fax termination. They are
defined in Rec T.38 Annex B. Their SDP equivalents are defined in
Rec. T.38 Annex D.
11.1.5 T38MaximumBufferSize
PropertyID: T38MaxBufferSize (0x0004)
Type: Integer
Possible values: 0-
Characteristics: Read/Write
Defined in: Termination State
Description:
This capability describes the T.38 fax termination. They are
defined in Rec T.38 Annex B. Their SDP equivalents are defined in
Rec. T.38 Annex D.
11.1.6 T38MaximumDatagramSize
PropertyID: T38MaxDatagramSize (0x0005)
Type: Integer
Possible values: 0-
Characteristics: Read/Write
Defined in: Termination State
Description:
This capability describes the T.38 fax termination. They are
defined in Rec T.38 Annex B. Their SDP equivalents are defined in
Rec. T.38 Annex D.
11.1.7 T38Version
PropertyID: T38Version (0x0006)
Type: Integer
Possible values: 0-
Characteristics: Read/Write
Defined in: Termination State
Description:
This is the T.38 version number.
11.2 Events
11.2.1 Fax Connection State Change
Event ID: faxconnchange (0x0001)
EventDescriptor Parameters: none
Hellstrom Standards Track - Expires January 2000 45
H.248 Annex F (White Document draft) July 2000
ObservedEventDescriptorParameters:
Fax Connection Change
ParameterID: faxconnchng (0x0001)
Type: Enumeration
Possible Values:
Idle (0x0001) no connection efforts
Prepare (0x0002) known in the termination and
ready to accept connections
Negotiating (0x0003) taking the initiative to
establish a fax connection
TrainR (0x0004) Fax Phase B or later training
as Receiver
TrainT (0x0005) Fax Phase B or later training
as Transmitter
Connected (0x0006) for completed connection
EOP (0x0007) Procedures Complete
ProcInterrupt (0x0008) Procedure Interrupt Processing
EOF (0x0009) - end of fax session, call
terminating
PI (0x000A) - Priority Interrupt ; Switch
to Voice
Disconnect (0x000B) Premature Disconnect
Description:
This event will occur when the fax connection state for the
termination has changed. Its parameter reflects the new state. If a
connection effort times out, it is reported in this event, with the
faxconnchng parameter set to Idle.
11.3 Signals
None
11.4 Statistics
11.4.1 Pages Transferred
StatisticsID: pagestrans (0x0001)
Type: integer
Description:
No of pages of fax image data transferred through the termination.
11.4.2 Train Downs
StatisticsID: traindowns (0x0002)
Units: count
Hellstrom Standards Track - Expires January 2000 46
H.248 Annex F (White Document draft) July 2000
Description:
Number of times FAX trained down during tramsmission.
11.5 Procedures
The following are standard transport mechanisms for fax in different
environments.
* In T.38 Annex B: UDPTL or TCP in T.38 fax only
communication channel environment.
* In H.323 Annex D[25]: UDPTL or TCP as selected with H.245
messages.
* In T.38 Annex D (SIP): UDPTL or TCP as initiated with SDP
* In T.38 Annex E: UDPTL or TCP as initiated with H.248
* In T.37: SMTP (MIME) /TCP
11.5.1 Function
A termination with Fax provides a method for transfer of fax pages
preceded by negotiations in the call setup according to procedures
defined for each environment. When matching capabilities exist, the
appropriate sessions can be established in order to transfer pages
of image or binary data.
Real time fax allows telecom users to transfer fax pages in real
time. For each transport environment, a suitable transport protocol
must be selected to carry the image. Currently defined and
Recommended transport environments for T.30 media streams that can
be supported by this package are:
1. Packet networks, where the procedures described in T.38 Annex B
[6] can be used for setting up and conducting fax sessions, using
TCP or UDPTL for the transport of T.30 signals and data.
2. Packet networks, where the procedures described in H.323 Annex D
[25] can be used for setting up and conducting fax and voice
sessions, using TCP or UDPTL as negotiated via H.245.
3. Packet networks, where the IETF Session Initiation Protocol SIP
can be used for setting up and conducting fax sessions as defined in
T.38 Annex D using UDPTL or TCP for the transport of T.30 signals
and data.
4. Packet networks, where H.248 can be used for setting up and
conducting fax sessions as defined in T.38 Annex E using UDPTL or
TCP for the transport of T.30 signals and data.
5. Packet networks, where the packets of G.711 coded data (with T.30
signals and data embedded) can be transported via RTP.
The Extended Simple Mail Transport Protocol messaging environment
over packet, that can be used alone or in conjunction with any of
Hellstrom Standards Track - Expires January 2000 47
H.248 Annex F (White Document draft) July 2000
the environments above, where T.37 [22], RFC 2301-2305 and RFCs
2530-2532 specify the methods for transporting image/tiff files
using the same compression methods as specified for use in T.30.
Interworking between these forms of fax can be achieved through the
use of gateways with packages defined here.
11.5.2 Process of Adding IP Fax Capable Terminations
The MGs are responsible for detecting fax tones and relaying the
related events to the MGC. The MGC should conduct Call
Discrimination as defined within the Call Type Discrimination
Package in order to determine whether a fax or other mode is
applicable. The MGC may choose to skip this if the MG is not
capable of the Call Type Discrimination Package. Once the MGC
evaluates the tones and determines that the incoming call is fax,
the MGC shall execute appropriate Modify commands to place the IP
fax capable termination into a "Negotiating" state.
11.5.3 Process of Ending a Fax Call
The MGs are responsible for detecting events that would cause the
interruption of a fax call. The MGC is responsible for making the
determination if this switch can be made and instruct the MGs to
switch. It also responsible for switching it back to fax.
The MGC should receive indication that the fax call ends from the MG
before receiving typical call termination indications.
11.5.4 Informative Example:
One possible instruction from an MGC to an MG to modify an existing
context to a T.38 media stream:
MGC to MG:
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 14 {
Context = 2000 {
Modify = RTP/1 {
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
m=image 1111 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38UdpEC:t38UDPFEC
}
}
}
}
}
}
Hellstrom Standards Track - Expires January 2000 48
H.248 Annex F (White Document draft) July 2000
12. Security Considerations
Security considerations regarding media gateway control are
discussed in section 10 of [3].
13. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
3 ITU-T Recommendation H.248, "Gateway Control Protocol", Geneva,
June 2000. Also to appear as RFC xxxx (currently draft-ietf-
megaco-merged-01.txt).
4 Schulzrinne, H., et al, RTP: A Transport Protocol for Real-Time
Applications, IETF RFC 1889, January 1996.
5 ITU-T Recommendation T.30 (7/96) Procedures for document
facsimile transmission in the general switched telephone network.
6 ITU-T Recommendation T.38 (6/98) Procedures for real-time Group 3
facsimile communication over IP networks.
7 ITU-T Recommendation V.8 (2000) Procedures for starting sessions
of data transmission over the public switched telephone network.
8 ITU-T Recommendation V.8 bis (2000) Procedures for the
identification and selection of common modes of operation between
data circuit-termination equipments (DCEs).
9 ITU-T Recommendation V.18 (2000) Operational and interworking
requirements for DCES operating in the text telephone mode.
10 ITU-T Recommendation V.25 (1996) Automatic answering equipment
and/or parallel automatic calling equipment on the general
switched telephone network.
11 ITU-T Recommendation T.140 (1998) _ Text conversation protocol
for multimedia application. With amendment 1 (2000).
12 ITU-T Recommendation H.323 Annex G(2000); Text Conversation and
Text SET (2000).
13 G. Hellstrom, "RTP Payload for Text Conversation", Internet
Engineering Task Force, RFC 2793. (2000)
Hellstrom Standards Track - Expires January 2000 49
H.248 Annex F (White Document draft) July 2000
14 ITU-T Recommendation T.134 (1998) Text Chat Application Entity.
15 ITU-T Recommendation V.17 (02/91) Recommendation V.17 (02/91) - A
2-wire modem for facsimile applications with rates up to 14 400
bit/s.
16 ITU-T Recommendation V.27 ter (11/88) - 4800/2400 bits per second
modem standardized for use in the general switched telephone
network.
17 ITU-T Recommendation V.21 (11/88) - 300 bits per second duplex
modem standardized for use in the general switched telephone
network.
18 ITU-T Recommendation V.23 (11/88) - 600/1200-baud modem
standardized for use in the general switched telephone network.
19 ITU-T Recommendation V.34 (02/91) - A duplex modem operating at
data signalling rates of up to 14 400 bit/s for use on the
general switched telephone network and on leased point-to-point
2-wire telephone-type circuit.
20 ITU-T Recommendation V.90 (09/98) - A digital modem and analogue
modem pair for use on the Public Switched Telephone Network
(PSTN) at data signalling rates of up to 56 000 bit/s downstream
and up to 33 600 bit/s upstream.
21 ITU-T Recommendation V.61 (08/96) - A simultaneous voice plus
data modem, operating at a voice plus data signalling rate of
4800 bit/s, with optional automatic switching to data-only
signalling rates of up to 14 400 bit/s, for use on the General
Switched .
22 ITU-T Recommendation T.37 (6/98) Procedures for the transfer of
facsimile data via store and forward on the internet.
23 ISO/IEC 10646-1: (1993), Universal Multiple Octet Coded Character
Set.
24 ITU-T T.50 (1992), International Reference Alphabet (IRA)
(formerly International Alphabet No. 5 or IA5) _ Information
technology _ 7-bit coded character set for information
interchange.
25 ITU-T H.323 Annex D. (1998) Facsimile.
Hellstrom Standards Track - Expires January 2000 50
H.248 Annex F (White Document draft) July 2000
14. Acknowledgements
The author wishes to recognize the major contributions to this
document made by James Rafferty, Glenn Parsons, and Roy Spitzer.
15. Authors' Addresses
Gunnar Hellstrom (editor)
L M Ericsson
Tel +46 708 204 288
E-mail: gunnar.hellstrom@omnitor.se
Hellstrom Standards Track - Expires January 2000 51
| PAFTECH AB 2003-2026 | 2026-04-24 06:08:38 |