[asterisk-dev] Routing data modem calls

[Brian Candler]

Does anyone know if there's a standard mechanism for carrying data modem
calls over a VoIP-type network? I know there's T.38 for fax, but I have not
been able to find something equivalent for generic data modem calls.

* Why do I want this?

There are still many devices out there which make data calls (e.g. EPOS
terminals, credit card authorisation, ATMs, telemetry...) which it would be
extremely useful to integrate into a SIP-type network in a transparent,
plug-and-play manner.

The calls should be able to transit an IP network reliably and break back
out to the PSTN at the other side, to be terminated by another modem at the
final destination.

* What options have I considered?

1. Sending the modulated audio signal using G.711. This is unlikely to work
for the reasons described at http://www.soft-switch.org/foip.html
In particular you'd need an extremely low jitter, low loss IP network.

Furthermore, a G.711 call uses a large bandwidth (up to ~120kbps), even for
a low data rate modem, or when no data is being transmitted. A typical ADSL
line has an uplink capacity of 288kbps, so 2 calls would eat all that up.

2. Encapsulating the call as L2TP. Unfortunately, this only works for PPP
calls, so it excludes other applications. [note *1]

3. I understand that GSM mobile terminals can make a 'data call' which is
implemented as V.110 over RLP - an InterNetworking Function at the far side
has a modem to connect to the PSTN. Perhaps this could be adapted for use
over IP? But 'async to sync' rate adaption seems to be a pointless thing to
do for IP use. e.g. a 38.4kbps data stream takes 64kbps, and you'd waste
part of that stream with start and stop bits. [note *2]

4. V.42 error correction is implemented using HDLC frames. If there was an
RTP payload type for carrying HDLC frames, these could be exchanged
end-to-end. It would have the advantage of performing end-to-end error
correction, data compression and flow control between the endpoint modems,
without the intervening network having to get involved.

I think this should work over IP, since I've seen V.42 working over
satellite phone calls with very long latency.

Note that this allows the modems at the two ends to run at different speeds.
Where the incoming data arrives too slowly for the outgoing link, you just
fill in between frames with HDLC flag characters.

As well as V.42, this would transparently support all HDLC applications
(including synchronous PPP and X25). It wouldn't support async users on
ancient non-error-correcting modems though.

5. If the endpoint modems perform the full demodulation *and* decoding of
V.42/V.42bis/MNP, then you get back the raw stream of characters which was
stuffed into the modem in the first place. This could then be carried over a
vanilla TCP session, or RTP over TCP. There is something along these lines
in RFC 4103, "RTP for Text Conversation" (T.140), although modem data is not
text and so it needs to be 8-bit clean and fully error free.

This, in some ways, is the "obvious" approach, since modems are really just
intended to carry a stream of bytes in the first place [note *3]. If we
decode to this level, then there is also the potential of mapping an
analogue modem call at one side to an ISDN data call at the other, or of
routing a data call directly to an RS232 serial port or to a pseudo-tty,
eliminating the need for a modem bank at the central site.

There is an issue of flow control: if the far end is receiving data and
drops RTS, then perhaps it would make sense to have a mechanism to drop CTS
at the far side. (Just letting the TCP window fill up, together with the
socket buffers at both ends, would store a huge backlog)

In any case, this seems eminently feasible to me, so it surprises me that I
was unable to find any reference to this having been done before. So if
someone knows of this being done, and can provide me with references to it,
I'd be happy to go away and read up.

Otherwise, is anyone interested in starting our own standard, and
integrating it into Asterisk? :-)

Regards,

Brian Candler.

[*1] This is also a non-SIP protocol, as L2TP has its own mechanisms for
signalling call setup and teardown, and multiplexing multiple calls into a
single L2TP tunnel. There are existing devices which can perform switching
of individual calls between L2TP bundles. Having said that, if Asterisk were
able to turn PPP modem calls into L2TP, use L2TP as bearer type and switch
L2TP calls, that would be a cool feature anyway.

[*2] I found a standard, RFC 4040, for carrying an ISDN clear-channel
64kbps data call over IP. So by mapping an async modem call into V.110 or
V.120 over RFC 4040, arguably you get a 'standards compliant' way of
working.

However it will still burn as much bandwidth as G.711. RFC 4040 does not
allow for the the 8kbps, 16kbps or 32kbps intermediate rates of V.110, other
than by stuffing them up to 64kbps as is done with ISDN B-channel.

[*3] OK, I know modems just carry streams of bits. In principle it's
possible for someone to use a synchronous dial-up data modem to carry a
stream of bits using neither async (start/stop) nor HDLC framing, but
something else instead. This is common for leased lines (e.g. E1 framing),
but I don't know of any examples where other framing is used in dial-up over
the PSTN. So I'd be happy to limit support to async and HDLC applications.
Indeed, 99% of usage would be covered by just async (incl V.110) and V.42.

Maybe the odd person still does X25 over PSTN dialup (by which I mean proper
synchronous X25, not talking to an async PAD); we could carry the HDLC
frames as suggested in paragraph (4), or just not worry about such a small
minority of users.