[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Media Gateway Control (Megaco)                    Gunnar Hellstrom
Internet Draft                                    LM Ericsson
Document: draft-ietf-megaco-h248f-01.txt          Glenn Parsons
Category: Standards Track                         Nortel Networks
Expires July 2001                                 James Rafferty
                                                  Brooktrout Technology
                                                  Roy Spitzer
                                                  Telogy Networks
                                                  January 14, 2001

              H.248 Annex F (Fax, Text Conversation, and Call discrimination)


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 was decided in Geneva
   in November 2000. It also includes minor corrections made in
   January 2001.
   This document is submitted for IETF in accordance with
   procedures currently being negotiated between
   ITU-T Study Group and ISOC on behalf of the IETF.

   H.248 Annex F describes packages for fax, text telephone, call type
   discrimination, and data call detection for use with the
   H.248 Gateway Control Protocol. As defined in H.248, a "package" is
   an extension to H.248 that supports specific behavior.

   The packages are intended for control over gateway functions for
   transport of facsimile or text conversation between different
   network environments. Extensions can be made for other kinds of data
   transport.

   The Call Type Discrimination package defines control and monitoring
   of a PSTN line for the signaling protocols used in the beginning of
   a session of data transmission for fax, text telephony or data.

Hellstrom/Parsons/Rafferty/Spitzer            Standards track    1

                 H.248 Annex F (Decided and amended)        Jan. 2001

   The Text Telephone package defines control of a PSTN text telephone
   session in any of the modes supported by the automoding text
   telephone Recommendation V.18.

   The Fax package defines control of a PSTN fax transmission.

   The Fax/Textphone/Modem Tones Detection package defines control over
   a termination for detection of any signals from a fax, text
   telephone or data modem during a connection in voice mode.

   The Text Conversation package defines control over a real time
   interactive text conversation session using a universal presentation
   format and transferred with a transport method from a multimedia
   protocol in any network environment.

   The IP Fax package defines control over facsimile transmission in a
   packet network.


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...................................................6
        5.1 Hexadecimal octet coding.................................6
        5.2 Hexadecimal octet sequence...............................6

   6. FAX/Textphone/Modem Tones Detection Package....................7
        6.1   Properties.............................................7
        6.2   Events.................................................8
                6.2.1 Additional tone id value.......................8
        6.3   Signals................................................8
        6.4   Statistics.............................................8
        6.5   Procedures.............................................8

   7   Text Conversation package.....................................9
        7.1   Properties.............................................9
                7.1.1 Text buffering time............................9
                7.1.2 Text termination connection state.............10
                7.1.3 Text User Identity............................11
                7.1.4 Text Transport................................11'
                7.1.5 Text Protocol Version.........................12
                7.1.6 Redundancy Level..............................12
                7.1.7 Txc request timer.............................12

Hellstrom/Parsons/Rafferty/Spitzer            Standards track    2

                 H.248 Annex F (Decided and amended)        Jan. 2001

        7.2   Events................................................13
                7.2.1 Connection State Change.......................13
        7.3   Signals...............................................13
        7.4   Statistics............................................13
                7.4.1 Characters Transferred........................13
                7.4.2 Lost Packets..................................13
        7.5   Procedures............................................13
                7.5.1 Function......................................14
                7.5.2 Informative description.......................14
                7.5.3 Total Conversation............................15
                7.5.4 Descriptor to use for text conversation.......15
   8.   Text Telephone package......................................16
        8.1   Properties............................................18
                8.1.1 Conversation mode.............................18
                8.1.2 Communication Mode............................19
                8.1.3 Connection Mode...............................21
                8.1.4 Action at loss of connection..................22
                8.1.5 V18 options...................................22
                8.1.6 Character set.................................22
        8.2   Events................................................23
                8.2.1 Connection mode changed.......................23
        8.3   Signals...............................................23
        8.4   Statistics............................................23
                8.4.1 Number of characters transferred..............23
                8.4.2 Number of alternating turns...................24
        8.5   Procedures............................................24
                8.5.1 Basic operation...............................24
                8.5.2 Informative description.......................24
                8.5.3 V.18 Modem....................................24
                8.5.4 Operation with alternating text and voice mode25
                8.5.5 Alternating text and voice mode with legacy,
                carrier-less textphones:............................25
                8.5.6 Alternating voice and text conversation in
                carrier mode:.......................................26
                8.5.7 Simultaneous voice and text mode..............26
   9.   Call Type Discrimination package............................27
        9.1   Properties............................................27
                9.1.1 Call Types....................................27
                9.1.2 Text Call Types...............................27
                9.1.3 V8bissupport..................................28
                9.1.4 Probe message.................................28
                9.1.5 Probe order...................................28
                9.1.6 PhasereversalDetect...........................29
        9.2   Events................................................29
                9.2.1 Discriminating tone detected..................29
        9.3   Signals...............................................32
                9.3.1 V8Signal......................................32
                9.3.2 AnswerSignal..................................33
                9.3.3 CallingSignal.................................34
                9.3.4 V8bisSignal...................................34
                9.3.5 V18probe......................................34

Hellstrom/Parsons/Rafferty/Spitzer            Standards track    3

                 H.248 Annex F (Decided and amended)        Jan. 2001


        9.4   Statistics............................................36
        9.5   Procedures............................................36

                9.5.1 Informative description.......................36
                9.5.2 Operation.....................................37
                9.5.3 Operation for incoming calls..................37
                9.5.4 Operation for transit calls, coming from and
                going to the switched network.......................37
                9.5.5 Operation for calls having one endpoint in the
                packet network......................................38
                9.5.6 Cases when the call type can not be determined
                from the signals....................................39
                9.5.7 Scenarios and call flows......................39
                9.5.8 Initial characters............................39
                9.5.9 Time critical handling........................39

   10.   Fax package................................................40
        10.1   Properties...........................................40
                10.1.1 Fax connection state.........................40
                10.1.2 Fax Transport................................41
                10.1.3 TransmissionSpeed............................41
                10.1.4 PSTN Interface...............................42
        10.2   Events...............................................42
                10.2.1 Fax Connection State Change..................42
        10.3   Signals..............................................42
        10.4   Statistics...........................................42
                10.4.1 Pages Transferred............................42
                10.4.2 Train Downs..................................43
        10.5   Procedures...........................................43
                10.5.1 Function.....................................43
                10.5.2 Process of Adding Fax Capable Terminations...43
                10.5.3 Process of Ending a Fax Call.................44
   11.   IP Fax package.............................................44
        11.1   Properties...........................................44
                11.1.1 Fax connection state.........................44
                11.1.2 IPFaxTransport...............................45
                11.1.3 TransmissionSpeed............................45
                11.1.4 T.38 Capabilities............................45
                11.1.5 T38MaximumBufferSize.........................46
                11.1.6 T38MaximumDatagramSize.......................46
                11.1.7 T38Version...................................46
        11.2   Events...............................................46
                11.2.1 Fax Connection State Change..................46
        11.3   Signals..............................................47
        11.4   Statistics...........................................47
                11.4.1 Pages Transferred............................47
                11.4.2 Train Downs..................................48




Hellstrom/Parsons/Rafferty/Spitzer            Standards track    4

                 H.248 Annex F (Decided and amended)        Jan. 2001

        11.5   Procedures...........................................48
                11.5.1 Function.....................................48
                11.5.2 Process of Adding IP Fax Capable Terminations49
                11.5.3 Process of Ending a Fax Call.................49
                11.5.4 Informative Example:.........................49

   12. Security Considerations......................................50

   13. References...................................................50

   14. Acknowledgements.............................................51

   15. Authors' Addresses...........................................51


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.Hellstrom/Parsons/Rafferty/Spitzer            Standards track    5

                 H.248 Annex F (Decided and amended)        Jan. 2001

   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.

   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




Hellstrom/Parsons/Rafferty/Spitzer            Standards track    6

                 H.248 Annex F (Decided and amended)        Jan. 2001

   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

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    Textphone
               high or the low frequency
               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
Hellstrom/Parsons/Rafferty/Spitzer            Standards track    7

                 H.248 Annex F (Decided and amended)        Jan. 2001


   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

   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.







Hellstrom/Parsons/Rafferty/Spitzer            Standards track    8

                 H.248 Annex F (Decided and amended)        Jan. 2001


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.

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


Hellstrom/Parsons/Rafferty/Spitzer            Standards track    9

                 H.248 Annex F (Decided and amended)        Jan. 2001



         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.



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]



Hellstrom/Parsons/Rafferty/Spitzer            Standards track   10

                 H.248 Annex F (Decided and amended)        Jan. 2001



         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

   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

Hellstrom/Parsons/Rafferty/Spitzer            Standards track   11

                 H.248 Annex F (Decided and amended)        Jan. 2001


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


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   12

                 H.248 Annex F (Decided and amended)        Jan. 2001

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.
   * 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.
Hellstrom/Parsons/Rafferty/Spitzer            Standards track   13

                 H.248 Annex F (Decided and amended)        Jan. 2001



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     |
   |Yes, have you heard that I will     |since we met!                 |
   |come to Paris in November?          |                              |
   |                                    |No, that was new to me. What  |
   |                                    |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:

   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.





Hellstrom/Parsons/Rafferty/Spitzer            Standards track   14

                 H.248 Annex F (Decided and amended)        Jan. 2001


   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.

   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}}}


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   15

                 H.248 Annex F (Decided and amended)        Jan. 2001


   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 (0x0010)
   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.

   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.




   Hellstrom/Parsons/Rafferty/Spitzer            Standards track   16

                 H.248 Annex F (Decided and amended)        Jan. 2001


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
   combined in the text telephone package that can be added to suitable
   terminations of a gateway.



















Hellstrom/Parsons/Rafferty/Spitzer            Standards track   17

                 H.248 Annex F (Decided and amended)        Jan. 2001


   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

   Possible values:

Hellstrom/Parsons/Rafferty/Spitzer            Standards track   18

                 H.248 Annex F (Decided and amended)        Jan. 2001

    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,

                               transmitting in the caller's
                               channel.

Hellstrom/Parsons/Rafferty/Spitzer            Standards track   19

                 H.248 Annex F (Decided and amended)        Jan. 2001


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

   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.

   Hellstrom/Parsons/Rafferty/Spitzer            Standards track   20

                 H.248 Annex F (Decided and amended)        Jan. 2001

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



Hellstrom/Parsons/Rafferty/Spitzer            Standards track   21

                 H.248 Annex F (Decided and amended)        Jan. 2001



   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

   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.

Hellstrom/Parsons/Rafferty/Spitzer            Standards track   22

                 H.248 Annex F (Decided and amended)        Jan. 2001

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)

8.4.2 Number of alternating turns.

   StatisticsID:        altturns (0x0002)
   Units:               count
   Hellstrom/Parsons/Rafferty/Spitzer            Standards track   23

                 H.248 Annex F (Decided and amended)        Jan. 2001

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
   reflect parameters for control of the V.18 modem. V.18 modem
   implementations may have different capabilities reflected in the
   property values.

Hellstrom/Parsons/Rafferty/Spitzer            Standards track   24

                 H.248 Annex F (Decided and amended)        Jan. 2001


   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.



Hellstrom/Parsons/Rafferty/Spitzer            Standards track   25

                 H.248 Annex F (Decided and amended)        Jan. 2001

   When no more characters arrive, and no textphone signal is received
   within 1 second, the audio channel is again fed to the Audio-stream
   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/Parsons/Rafferty/Spitzer            Standards track   26

                 H.248 Annex F (Decided and amended)        Jan. 2001

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/Parsons/Rafferty/Spitzer            Standards track   27

                 H.248 Annex F (Decided and amended)        Jan. 2001


   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)

Hellstrom/Parsons/Rafferty/Spitzer            Standards track   28

                 H.248 Annex F (Decided and amended)        Jan. 2001

                DTMF    (0x0002)
                Baudot  (0x0003)
                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

Hellstrom/Parsons/Rafferty/Spitzer            Standards track   29

                 H.248 Annex F (Decided and amended)        Jan. 2001

   telephones in V.18 [9]. DTMF detection may be indicated also from
   the "dd" package if that is active.

   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     (0x000C)        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      (0x000D)        a V.25 calling tone
        V21hi   (0x000E)        a V.21 carrier on the higher
                                frequency channel
        V21lo   (0x000F)        a V.21 carrier on the low
                                frequency channel
        V23hi   (0x0010)        a V.23 high carrier
        V23lo   (0x0011)        a V.23 low carrier
        CI      (0x0012)        a V.8  CI  with contents in
                                "dtvalue"


   Common to FAX, TEXT and DATA:
        ANS     (0x0013)        V.25 ANS, equivalent to T.30
                                CED from answering terminal


     Hellstrom/Parsons/Rafferty/Spitzer            Standards track   30

                 H.248 Annex F (Decided and amended)        Jan. 2001


        ANSbar  (0x0014)        V.25 ANS with phase reversals
        ANSAM   (0x0015)        V.8 ANSam
        ANSAMbar(0x0016)        V.8 ANSam with phase reversals
        CM      (0x0017)        V.8 CM with contents in
                                "dtvalue"
        CJ      (0x0018         V.8 CJ
        JM      (0x0019)        V.8 JM with contents in
                                "dtvalue"
        ENDOFSIG(0x001A)        End of reported signal detected
                                reported for continous or repeated
                                signals
        V8BIS   (0x001B)        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:


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   31

                 H.248 Annex F (Decided and amended)        Jan. 2001

        ESi        (0x0001)      V.8bis signal ESi

        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        (0x000D)      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/Parsons/Rafferty/Spitzer            Standards track   32

                 H.248 Annex F (Decided and amended)        Jan. 2001

   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

   Possible values:


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   33

                 H.248 Annex F (Decided and amended)        Jan. 2001



       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/Parsons/Rafferty/Spitzer            Standards track   34

                 H.248 Annex F (Decided and amended)        Jan. 2001


        MRdi    (0x0004)        V.8bis signal MRd from initiator
        MRdrl   (0x0005)        V.8bis signal MRd from responder on
                                low 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
        MRdrh   (0x000E)        V.8bis signal MRd from responder on
                                high power
        CReh    (0x000F)        V.8bis signal CRe on high power
   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.


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   35

                 H.248 Annex F (Decided and amended)        Jan. 2001

   The contents of valid V.8 bis message(s), if detected, are reported
   using hexadecimal octet coded string(s) (see section 5). 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.

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


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   36

                 H.248 Annex F (Decided and amended)        Jan. 2001

   contrast this package is also used to monitor the line to detect
   signals which are to be relayed to the Media Gateway Controller as
   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/Parsons/Rafferty/Spitzer            Standards track   37

                 H.248 Annex F (Decided and amended)        Jan. 2001


   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/Parsons/Rafferty/Spitzer            Standards track   38

                 H.248 Annex F (Decided and amended)        Jan. 2001


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/Parsons/Rafferty/Spitzer            Standards track   39

                 H.248 Annex F (Decided and amended)        Jan. 2001


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/Parsons/Rafferty/Spitzer            Standards track   40

                 H.248 Annex F (Decided and amended)        Jan. 2001


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/Parsons/Rafferty/Spitzer            Standards track   41

                 H.248 Annex F (Decided and amended)        Jan. 2001


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/Parsons/Rafferty/Spitzer            Standards track   42

                 H.248 Annex F (Decided and amended)        Jan. 2001



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


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   43

                 H.248 Annex F (Decided and amended)        Jan. 2001

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




Hellstrom/Parsons/Rafferty/Spitzer            Standards track   44

                 H.248 Annex F (Decided and amended)        Jan. 2001

   Characteristics: Read/Write
   Defined in:  Termination State

   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
Hellstrom/Parsons/Rafferty/Spitzer            Standards track   45

                 H.248 Annex F (Decided and amended)        Jan. 2001

        UDPFEC              (0x0004)    UDP Forward Error Correction
        UDPRedundancy       (0x0005)    UDP Redundancy Error Correction

   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


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   46

                 H.248 Annex F (Decided and amended)        Jan. 2001


   Event ID:    faxconnchange  (0x0001)

   EventDescriptor Parameters: none

   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.



Hellstrom/Parsons/Rafferty/Spitzer            Standards track   47

                 H.248 Annex F (Decided and amended)        Jan. 2001
11.4.2 Train Downs

   StatisticsID: traindowns (0x0002)
   Units:        count

   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.



Hellstrom/Parsons/Rafferty/Spitzer            Standards track   48

                 H.248 Annex F (Decided and amended)        Jan. 2001

   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
   the environments above, where T.37 [22] 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. For information it can
   be noted that RFC 2301-2305 and RFCs 2530-2532 specify these
   transport mechanisms.

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/Parsons/Rafferty/Spitzer            Standards track   49

                 H.248 Annex F (Decided and amended)        Jan. 2001

              }
            }
          }
        }
      }
    }

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


Hellstrom/Parsons/Rafferty/Spitzer            Standards track   50

                 H.248 Annex F (Decided and amended)        Jan. 2001

   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)

   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/Parsons/Rafferty/Spitzer            Standards track   51

                 H.248 Annex F (Decided and amended)        Jan. 2001

13.1    Non-normative references


-       RFC 2532, Extended Facsimile Using Internet Mail., IETF
-       RFC 2530, Indicating Supported Media Features Using Extensions to
           DSN and MDN., IETF
-          RFC 2531, Content Feature Schema for Internet Fax., IETF
-          RFC 2301, File Format for Internet Fax., IETF
-          RFC 2302, Tag Image File Format (TIFF) - image/tiff  MIME Sub-type
           Registration, IETF
-       RFC 2303, Minimal PSTN address format in Internet Mail., IETF
-       RFC 2304, Minimal FAX address format in Internet Mail., IETF
-       RFC 2305, A Simple Mode of Facsimile Using Internet Mail., IETF

14. Acknowledgements

   The authors wishes to recognize important support in the creation of this
   document given by Nancy Greene, Nortel Networks.


15. Authors' Addresses

   Gunnar Hellstrom
   L M Ericsson
   Tel +46 708 204 288
   E-mail: gunnar.hellstrom@era.ericsson.se

   Glenn Parsons
   Nortel Networks
   Tel:    +1 613-763-7582
   Fax:    +1-613-763-4461
   E-mail: gparsons@nortelnetworks.com

      James Rafferty
   Brooktrout Technology
   410 First Avenue
   Needham, MA 02494 USA
   Phone:  +1-781-433-9462
   Fax: 781-433-9268
   E-mail:  jraff@brooktrout.com

      Roy Spitzer
   Telogy Networks, Inc.
   20250 Century Blvd.
   Germantown, MD 20874  USA
   Phone:  +1 301 515-6531
   Fax:    +1 301 515-7954
   Email:  rspitzer@telogy.com




Hellstrom/Parsons/Rafferty/Spitzer            Standards track   52


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/