Cisco IOS Connection Trunks

For the basics of configuring a connection trunk, refer to this section in Cisco IOS configuration notes.

Cisco IOS 'connection trunks' are a method of building transparent virtual tie-lines between Cisco routers using VoIP. These types of trunked VoIP connections are ideally transparent to the equipment involved, down to the dial-pulse level.

This can be interesting to those in the telephone switch equipment hobby to interconnect with other hobbyists or from one site to another. Historically, this sort of thing would have been done with real circuits, either owned or leased from another entity. However, this practice has always been prohibitively expensive for a hobbyist, and these days we can simulate such arrangements over the internet.

These types of tie-lines may generally be used for FXS<->FXO loop start, FXS<->FXO ground start (currently untested), E&M<->E&M, and even ISDN PRI (using clear-channel codec for the D-channel). For most of these types of connection, the signaling data is transmitted in a side channel in the RTP stream in the form of ABCD signaling bits, just the same as they would be on a T1. For ISDN PRI, the D-channel is carried as an independent stream. They are suitable for trunks from one piece of switching equipment to another, or for 'foreign exchange' or 'off premise' lines from another switching system.

This is not perfect for a number of reasons, some of which I'll outline here:

• Connection quality: usage over the internet will have all of the usual problems of VoIP over the open internet, plus several new failure modes. VoIP on the open internet is terrible, it is barely good enough for voice traffic in the best of cases and presents many challenges. There are many reasons for this, which I will not detail here. It suffices to say that if you don't have good results with normal VoIP, one of these virtual tie lines will not do any better. Good results can be had on a local network with QoS the whole way through (or dedicated facilities).
• Bandwidth usage: per channel, each trunk is effectively a nailed up call, about 80kb/s in either direction. That doesn't sound like much, but a connection established 24 hours a day for 30 days will accumulate to around 52GB of data transferred. If you're on a metered connection, that can become significant, especially if multiple trunks are set up. If you're on a slow connection (old ADSL, cellular, or something worse) it can also be an issue. There seem to be ways of altering the trunk behavior to bring down the voice traffic when idle, but I have not yet tested them.
• Transparent media required: due to the way Cisco IOS packs signaling information into the RTP stream, the RTP media must be passed from one end to the other transparently. There is more data encapsulated into the RTP stream than just the call audio. This means, for example, that trying to use an IAX2 hop in the middle is guaranteed to fail, since IAX2 does not use RTP media and cannot support the signaling information embedded in the RTP stream as required. However, under the right conditions, it may be possible for the connections to traverse multiple hops and even use a combination of H323 and SIP signaling in the middle. The key is that the RTP stream must either be direct, or the entire contents of the RTP stream must be relayed at each stage, including the extra signaling information.
• NAT: you'll run into all the normal VoIP problems if you're operating from behind a NAT, and will need to use all the normal ways of solving that. Get rid of the NAT (keep the firewall though, all these IOS devices are quite old), or use 'SIP ALG' type rewrites (or equivalent for H323), or set up a VPN and bypass NAT that way.
• Various software and hardware-dependent issues: The Cisco ISR support for this is loaded with bugs and deficiencies. I've made some attempt to keep notes on this and document them below. These issues range from not supporting dial-pulsing properly to strange lockup behaviors that are only solved with power cycling the router. Don't be discouraged, though, some of the hardware combinations work quite well, and some of the others can be worked around if you don't care about dial-pulse for example.
• Channel bonding: This is not guaranteed to work. Many devices which use channel bonding (such as ISDN video conferencing devices) rely on the multiple channels used to carry their data arriving with nearly-equal latency. Due to the way VoIP jitter buffers work, individual channels can easily end up with unequal latency. This can cause the channel-bonding device to be unable to reassemble the data stream due to insufficient buffering in the device itself.
• Out of Service conditions: The ISR likes to hold the voice-port in the busy state before the trunk has come up. There is not a way to change this, as far as I can tell. The behavior can only be changed for a port that was in service and then lost connection. This means that from a clean power cycle, all the trunks will be held busy or out of service until they establish, and once they have established, you have your choice of what state they go into if the connection fails.

Compatibility Tables

The table and lists in this section cover scenarios that were tested to check the functionality of 'connection trunk' type tie lines using Cisco hardware. Common problems include non-working dial-pulse signaling and various call-state lockups which may require special user intervention to clear the fault.

Each of these scenarios considers two sides: side A and side B. The two sides simply represent the two groupings of hardware which communicate via and are separated by the VoIP link in the middle.

We can begin to see patterns in this data which lead us to conclude that specific pieces of hardware may have individual problems.

For a thorough test, calls in each direction must be tested, applicable signaling types must be tested, and various combinations of call sequences must be performed to establish proper behavior regardless of which party originates and which party disconnects first. A list is provided below to detail the tests and verifications that should be performed, where applicable, to establish proper operation with a particular combination of hardware and software.

1. Call from A-side to B-side, A-side hangs up first
2. Call from A-side to B-side, B-side hangs up first
3. Call from B-side to A-side, A-side hangs up first
4. Call from B-side to A-side, B-side hangs up first
5. Test tone-type signaling (DTMF and/or MF as applicable)
6. Test dial type signaling (dial pulse)
7. Test answer & disconnect supervision (if applicable: FXS/FXO can use battery reversal and battery drop for answer/disconnect supervision, E&M more directly represents far-end hook state)

The following hardware appears to be 100% working as expected at least on one version of IOS.

• Adit 600 FXS (when used with a T1 port on the ISR)
• VIC2-4FXO
• VIC3-2E/M
• VWIC2-2MFT-T1/E1 (E1 mode remains untested)

The following hardware is suspected to have problems which cannot be solved. In some cases, it may be worth trying an older IOS version (e.g. 12.x instead of 15.x) or other router platforms (e.g. 2600/3600 instead of 2800/3800) before ruling them out completely.

• EVM-HD FXS: dial pulses distorted, works otherwise.
• VG224 onboard FXS: strange lockup issues, voice port gets stuck in ringing, only solved by power cycle.
• VIC3-4FXS/DID: dial pulses distorted, works otherwise.

The table below covers each individual test case which has been documented thus far. If you have tested a combination not listed in this table, you may contact me with the results of the tests listed above and I can add it to the table.