Here in Minnesota we like to say that there are only two seasons – winter and road construction.
As winter finally comes to an end in the frozen north, we are already starting to see the inevitable lane, bridge, and ramp closures. However, worse than that are all the potholes. This was an especially cold winter with lots of snow and the roads are experiencing an epidemic of those suspension-destroying, jaw-rattling road hazards. My son hit an especially nasty one a week ago that took out one of his tires.
There is one interesting aspect to potholes, though. You get a peek at what lies below all that concrete and asphalt. Those of you who don’t live in a city as old as Saint Paul, Minnesota might not understand what I am talking about. To you, roads sit on dirt. Not here. Many of our roads sit on much older roads. Specifically, they sit on brick or cobblestone. Instead of removing all that previous material, Saint Paul just paved over it.
In addition to older roads, you might get a glimpse at our former modes of transportation. This happened to me on Monday when I passed by a pothole so deep that it exposed ancient trolley tracks. Even after the introduction of cars, trolleys crisscrossed the Twin Cities and for decades were the main form of transportation for many people. Like those bricks and cobblestones, those tracks were simply covered up when the new roads were laid.
A lot of IP telephony systems are like our present-day roads. Remember, until the early to middle 2000’s, most telephone systems were analog or digital and used proprietary backbones, or TDM busses, to provide dial tone and talk paths. I don’t have any real number to refer to, but experience tells me that instead of forklifting their PBXs, the vast majority of companies simply upgraded them with new software and some new hardware. However, there are still lots of old chassis (what I affectionately call refrigerator cabinets) and line cards out there. And why not? They still work and do what they were designed to do.
For much of its life, a VoIP call operates independently of the underlying TDM infrastructure. That TDM bus is still there, but SIP signaling goes to and from a SIP proxy (e.g. Session Manager) and media (please see my article, Getting Real With Real-Time Protocol) flows end-to-end between IP devices.
That’s not true all the time, though. Those VoIP calls may need to take advantage of system messages, announcements, conference, music on hold, etc. The resources that supply those features have been around for a long time and were built around TDM.
However, you don’t want to marry SIP to the TDM infrastructure. In other words, you don’t want to prohibit end-to-end multimedia sent directly from one SIP device to another.
This is where shuffling comes in. Shuffling allows a SIP call to take advantage of legacy TDM resources when it needs them and ignore them when it doesn’t.
Shuffling works like this. When a SIP endpoint calls another SIP endpoint, the media stream will initially pass through a TDM resource. This resource could be an announcement board or it could be a ringtone generator. However, once the call has been established and the TDM resource is no longer required, the call is “shuffled” away from the TDM bus and IP flows directly between two SIP endpoints. This frees up the TDM resource, releases timeslots on the voice bus, and allows IP media to flow more efficiently.
There are a few rules that apply to shuffling that need to be recognized.
- Both SIP endpoints must be administered to allow shuffling. For Avaya telephones, enable Intra-region IP-IP Direct Audio, Inter-region IP-IP Direct Audio, and IP Audio Hairpinning for the IP Network Region, and Direct-IP in System Features and the Signaling Group.
- A point-to-point voice connection must exist between two endpoints and no active call (in-use or held) exists on either endpoint which requires TDM connectivity (such as applying tones, announcement, or conferencing).
- The endpoints must be in the same LAN region or in interconnected LAN regions.
- The inter-region connection management rules must be met.
- There is at least one codec in common between the codec lists of the endpoints involved and the Internetwork region Connection Management codec list.
- The endpoints must have at least one codec in common as shown in their current codec negotiations (i.e. SDP) between the endpoint and the switch.
Thankfully, the endpoints don’t have to do anything special to initiate shuffling. It’s all handled by the gateway. The endpoints will know when shuffling is occurring when they receive re-INVITE messages with new media descriptions. However, re-INVITE is standard SIP and endpoints already know what to do when they receive one.
In time, those older TDM resources will be replaced by their IP equivalents. Until then, it makes sense to take advantage of the investments already made in perfectly good communications hardware and software. If it ain’t broke, don’t fix it.