2 Transcompression Configuration for Scenarios 3c, 4, and 5

-1-
Telecommunications Industry Association (TIA)
TR-30.1/ 02-04-039
Albuquerque, NM, April 15-19, 2002
COMMITTEE CONTRIBUTION
Technical Committee TR30 Meeting
SOURCE:
Cisco Systems
Texas Instruments, Inc.
TITLE:
Configuration of Transcompression Function.
DISTRIBUTION:
Meeting attendees
CONTACT:
Mario Garakani
Cisco Systems
 [email protected]
 +1 (805) 961 3640
Adrian Zakrzewski
Texas Instruments, Inc
 [email protected]
 +1 (301) 515 6636
________________________________
Abstract
This contribution proposes procedures for Configuration of Transcompression Function for V.MoIP.
________________________________
Copyright Statement
-2-
The contributors grant a free, irrevocable license to the Telecommunications Industry Association (TIA) to
incorporate text contained in this contribution and any modifications thereof in the creation of a TIA standards
publication, to copyright in TIA's name any standards publication even though it may include portions of this
contribution, and at TIA's sole discretion to permit others to reproduce in whole or in part the resulting TIA
standards publication.
Intellectual Property Statement
The individuals preparing this contribution do not know of patents, the use of which may be essential to a
standard resulting in whole or in part from this contribution.
-3-
Abbreviations used in this contribution
G1
On-ramp Gateway on calling leg
G2
Off-ramp Gateway on called leg
M1
Originating Modem on calling leg
M2
Answering Modem on called leg
MoIP
Modem over IP
PSTN
Public Switched Telephone Network
MR
Modem Relay
TLP
Transport Layer Protocol
XIDdef
XID corresponding to the default compression parameters
CPoff-ramp Denotes compression parameters negotiated locally on the off-ramp leg
CPon-ramp Denotes compression parameters negotiated locally on the on-ramp leg
1
Introduction
Generic framework for compression negotiation was laid out in Ref. [1]. This contribution presents the
procedures for selecting the trans-compression parameters for V.MoIP.
2
Transcompression Configuration for Scenarios 3c, 4, and 5
G1P: Represents negotiation posture of G1 when it performs XID negotiation with M1. This is the
“maximum” compression options that can be specified by the gateway in XID frames for negotiation with M1.
G2P: Represents negotiation posture of G2 when it performs XID negotiation with M2. This is the
“maximum” compression options that can be specified by the gateway in XID frames for negotiation with M2.
Negotiation posture can be represented as a vector as follows:
GxP=(GxV44Dictionary, GxV44StringLength, GxV44History, GxV42bisDictionary, GxV42bisStringLength,
GxMNP5Support)
Consider vectors G1 and G2 representing the trans-compression capability of a gateway as follows:
G1 = (G1V44Dictionary, G1V44StringLength, G1V44History,
G1V42bisDictionary, G1V42bisStringLength, G1MNP5Support)
G2 = (G2V44Dictionary, G2V44StringLength, G2V44History,
G2V42bisDictionary, G2V42bisStringLength, G2MNP5Support)
If a compression functionality is not supported,its corresponding parameters would be set to zero in above
vector. When the values are non-zero, transcoding may occur from any supported compression type (up to
-4-
supported values) to any other supported compression type. Furthermore, transcoding capabilities are
symmetric, meaning that when a transcoding capability is indicated, the gateway may transcode from a
supported compression type to another supported compression type regardless of whether the conversion is
for data flow from telephony to IP side or in the reverse direction.
Consider vector operation MIN defined as follows:
V = (v1, v2, v3, ….)
U = (u1, u2, u3, ….)
MIN(V, U) = (min(v1, u1), min(v2, u2), min(v3, u3), ….)
For the various scenarios, the compression function shall be setup as follows:
Scenario 3c:
G1P = G1
G2P = G2
GIP = MIN (G1, G2)
Compression coding on IP leg would be symmetric (same by either gateway) and based on GIP element
values and would use the set of GIP elements corresponding to V44 if available, else V42bis, else MNP, else
NONE in this specified order.
Scenario 4:
For V44 elements:
G1P-OnrampToOfframp = G2
G1P-OfframpToOnramp = G1
G2P-OnrampToOfframp = G2
G2P-OfframpToOnramp = G1
For V42bis and MNP5 elements:
G1P = MIN (G1, G2)
G2P = MIN (G1, G2)
Scenario 5:
G1P = Gd
G2P = Gd
Where Gd is the capability vector of the double transcompression gateway.
The above procedures for configuring transcoding function applies only when both on-ramp and off-ramp
telephony links are using V42 link layer.
2.1
Symmetric Non-Error Correcting Operation
For symmetric non-V.42 (e.g. symmetric V.14 operation), all transcoding functions have to be disabled.
Configuration of the transcoding function for assymmetric V.14 operation is outside the scope of this
document.
2.2
Trasparent Mode of Operation
A transcoding function would be unnecessary and may also be disabled locally by a gateway, if the input and
output of the transcoding function are determined to be the same. However, the gateway remains responsible
to re-enable trans-compression, if either the network side or the telephony side compression parameters
change. This is possible in V.44 using the inband negotiation.
2.3
V.44 Inband Negotiation
If this feature is supported, then the gateways shall intercept corresponding in-band V.44 exchanges and
adjust their transcompression parameters accordingly.
-5-
2.4
Assymmetric versus Symmetric Transcoding Functions
The above framework assumes symmetric transcoding functions. This assumption is for the convenience in
gateway implementation only. The framework itself can be easily extended by using tensor or matrix notation
(instead of vector notation) to cover assymmetric transcoding capabilities. Such generalizations were not
made here, since it is difficult to see how any reasonable gateway implementation would benefit from doing
that.
Therefore, the consideration has been made in favor of notational simplicity, since such extensions should
very doubtful practical value and may easily result in confusion for implementors and hence poor
implementations and interoperability problems.
3
[1]
4
References
A. Zakrzewski et. al., “Compression Negotiation for V.MoIP”, Albuquerque TIA TR30.1 contribution
Summary
It is therefore proposed that the committee agrees to the following;
to add the text of this contribution to V.MoIP.
x.y
Agreed