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
Datatracker
Report a datatracker bug
draft-ietf-megaco-h248f-01
None
| Document | Document type |
Expired Internet-Draft
(megaco WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author |
Gunnar Hellstrom
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |