Cisco Systems VC-825 User Manual
Cisco Hoot and Holler over IP
The voice multicasting feature on Cisco 2600 and 3600 series routers uses Cisco Voice over IP (VoIP)
technology to create a permanently connected point-to-multipoint hoot and holler network over an IP
connection.
This appendix describes the Cisco hoot and holler over IP feature and contains the following sections:
• Hoot and Holler over IP Overview, page 825
• Cisco Hoot and Holler over IP Overview, page 827
• Configuration Tasks, page 835
• Configuration Examples, page 843
To identify the hardware platform or software image information associated with a feature in this
appendix, use the Feature Navigator on Cisco.com to search for information about the feature or refer to
the softsware release notes for a specific release. For more information, see the “Identifrying Supported
Platforms” section in the “Using Cisco IOS Software” chapter.
Hoot and Holler over IP Overview
Four-wire ear and mouth (E&M), E1/T1, Foreign Exchange Office (FXO), and Foreign Exchange Station
(FXS) configurations provide continuous VoIP connections across a packet network using the
connection-trunk mechanism. By using the inherent point-to-multipoint connectivity of IP multicast
(IPmc), the routers can take several inbound voice streams from the traditional hoot devices and forward
the packetized voice over the IP network to all parties within a defined hoot and holler group.
Hoot and holler networks provide “always on” multiuser conferences without requiring that users dial
into a conference. These networks came into being more than 40 years ago when local concentrations of
small specialized businesses with common, time-critical informational interests began to install their
own phone wires, speakers (called “squawk boxes”), and microphones between their businesses to ask
each other about parts that customers needed. These networks functioned as crude, do-it-yourself,
business-to-business intercom systems.
Hoot and holler broadcast audio network systems have since evolved into the specialized leased-line
networks used by financial and brokerage firms to trade stocks and currency futures and the
accompanying time-critical information such as market updates and morning reports.
Users of various forms of hoot and holler networks now include brokerages, news agencies, publishers,
weather bureaus, transportation providers, power plant operators, manufacturers, collectibles dealers,
talent agencies, and nationwide salvage yard organizations.
Cisco IOS Voice, Video, and Fax Configuration Guide
VC-825
Hoot and Holler over IP Overview
Hoot and holler is used in these various industries as a way to provide a one-to-many or many-to-many
conferencing service for voice communications. In the past, hoot and holler was deployed using
point-to-point telephone company circuits and a hoot and holler bridging and mixing functionality that
was provided either by the customer or as a service of the Public Switched Telephone Network (PSTN)
carrier.
A common use of hoot and holler is a broadcast audio network that is used throughout the brokerage
industry to communicate morning reports as well as to advise the trading community within a brokerage
firm on market movements, trade executions, and so on. All users can talk simultaneously with each
other, if desired.
But more commonly, a broker in a field office will “shout” an order to the trading floor. The shout
ensures that the trading floor can hear the order and a floor trader can confirm the transaction. A typical
brokerage firm has several of these networks for equity, retail, and bonds with network size and degree
of interactivity varying depending on the application.
Within the financial community there are two general uses for hoot and holler networks:
• Market updates—Market update (morning report) hoot networks tend to be active for an hour in the
morning and inactive for the rest of the day.
• Trading—Trading hoot networks tend to be more widely used throughout the trading day.
Both of these applications can reap significant advantages by running over an IP network because any
idle bandwidth can be reclaimed by data applications.
Today most hoot and holler customers pay for separate leased-line charges from a common carrier to
transport their hoot and holler to remote branch offices. This recurring charge is usually
significant—some larger firms spend more than $2 million to $3 million per year just to distribute hoot
and holler feeds.
Cisco Hoot and Holler over IP
Cisco’s hoot and holler over IP feature:
• Eliminates yearly reoccurring switched-circuit telephone company charges (toll-bypass)
• Eliminates the need for leased lines and the accompanying charges
• Reduces the need for hoot and holler bridges
• Improves hoot and holler network manageability
• Reduces the time to troubleshoot a problem from hours to minutes
• Reduces the time to provision bandwidth from days to a few hours
• Increases productivity through future applications (such as IP/TV and turret support)
• Provides the ability to integrate voice, video, and data signaling capabilities
Cisco hoot and holler over IP is supported on Cisco 2600 and 3600 series routers and on NM-HDV,
NMZV, and NM-2V network modules
For information about installing voice network modules and voice interface cards in Cisco 2600 and
Cisco 3600 series routers, refer to the Cisco Network Module Hardware Installation Guide and the WAN
Interface Card Hardware Installation Guide.
For information about configuring Voice over IP features, refer to the Software Configuration Guide for
Cisco 3600 Series and Cisco 2600 Series Routers, to the Voice over IP Quick Start Guide, and to the
“Voice over IP Overview” chapter in this configuration guide.
For further information about IP multicasting, refer to the IP Multicast Site at
http://www.cisco.com/ipmulticast.
For further information about IP/TV, refer to the IP/TV Content Manager User Guide.
VC-826
Cisco IOS Voice, Video, and Fax Configuration Guide
Cisco Hoot and Holler over IP
For further information about interactive voice response (IVR), refer to Configuring Interactive Voice
Response for Cisco Access Platforms.
Current Hoot and Holler Implementations
Traditional hoot and holler networks (see Figure 131) are analog, multipoint, four-wire,
audio-conference networks that are always up. When a user wants to communicate, the user pushes a
button and speaks either through a microphone, a hoot phone, a turret, or a squawk box.
Figure 131 Traditional Hoot and Holler Network
Remote
location
Remote
location
Remote
location
Leased lines
Hoot and Holler over IP Overview
Central site
N-1
voice
bridge
Remote
location
4-wire phone or speaker with microphone
Figure 131 illustrates a traditional hoot and holler network. Each remote location is connected to a
central bridge using leased lines. Four-wire connections and N-1 bridges are used to avoid echo
problems.
Hoot and holler networks are typically spread over four to eight sites although financial retail networks
may have hundreds of sites interconnected. Within a site, bridging (mixing voice signals) is done locally
with a standard analog or digital bridge that may be part of a trading turret system. Between sites, there
are two prevalent methods for providing transport:
• Point-to-point leased lines with customer-provided audio bridging at a central site
• Carrier-provided audio bridging
When customers provide their own bridging services with point-to-point leased lines, branch offices in
a metropolitan area commonly have 25 to 50 lines or more.
The second method, carrier-provided audio bridging, is prevalent within the United States but rare for
overseas transport. In this scenario, the audio bridges are located at the carrier's central office and the
four-wire lines are terminated at the client’s site on a local audio-bridge equipped with four-wire
plug-ins, which then feed to local public address (PA) system speakers. Customer-provided hoot
bridging services can now be replaced with a Cisco hoot and holler over IP solution.
Cisco Hoot and Holler over IP Overview
35836
Cisco's VoIP technology, which was initially focused on traditional PBX toll-bypass applications, can be
used to combine hoot and holler networks with data networks. While some customers may have done
some level of hoot and data integration in the late 1980s with time-division multiplexing (TDM), this
form of integration does not allow for the dynamic sharing of bandwidth that is characteristic of VoIP.
Cisco IOS Voice, Video, and Fax Configuration Guide
VC-827
Hoot and Holler over IP Overview
This dynamic sharing of bandwidth is even more compelling with hoot and holler than with a toll-bypass
application because some hoot circuits may be active for an hour or two for morning reports but dead for
the rest of the day—the idle bandwidth can be used by the data applications during these long periods of
inactivity.
Beginning with Cisco IOS Release 12.1(2)XH, Cisco hoot and holler over IP can be implemented using
Cisco's VoIP technology. This solution leverages Cisco’s IOS expertise in VoIP, quality of service (QoS),
and IP multicasting (IPmc) and is initially available on Cisco 2600 and 3600 series multiservice routers.
Figure 132 shows a diagram of the Cisco hoot and holler over IP solution connecting legacy hoot
equipment over an IP network.
Note The “V” on the Cisco router icons signifies that some of the hoot and holler bridging function is
being done by the router's digital signal processors (DSPs).
Figure 132 Hoot and Holler over IP Using Cisco 2600 and Cisco 3600 Series Routers
Cisco Hoot and Holler over IP
PBX
E&M phones
E&M = ear and mouth
V
FXS
V
Multicast group 1
Multicast group 3
Multicast group 2
T1/E1
V
T1/E1
Turret Turret
FXO
V
FXO
V
V
FXO
Turret
PBX
PBX
35839
Four-wire E&M, E1/T1, FXO, and FXS configurations provide continuous VoIP connections across a
packet network. By using the inherent point-to-multipoint characteristic of IPmc, the routers can take
several inbound voice streams from the traditional hoot devices and forward the packetized voice over
the IP network to all parties within a defined hoot and holler group.
Voice Multicasting
The voice multicasting feature on Cisco 2600 and Cisco 3600 series routers uses Cisco VoIP technology
to create a point-to-multipoint hoot and holler network over an IP connection.
Cisco IOS Voice, Video, and Fax Configuration Guide
VC-828
Cisco Hoot and Holler over IP
Note The voice multicasting feature supports only one E1/T1 line per high-density voice network module.
IP/TV Access
Hoot and Holler over IP Overview
You can connect voice multicasting telephones to routers in the following ways:
• Connect a four-wire E&M telephone, which has no dial and is always off-hook, directly to an E&M
voice interface card that is installed in a voice network module. Configure the E&M interface for
four-wire trunk operation. For information about configuring E&M interfaces, see the chapter
“Configuring Voice Ports” in this configuration guide.
• Connect a conventional telephone to a PBX that is connected to an E&M voice interface card.
• Connect a conventional telephone to an FXS voice interface card that is installed in a voice network
module.
• Connect a conventional telephone to a PBX that is connected through a E1/T1 line to a multiflex
trunk interface card that is installed in a high-density voice network module.
The Cisco hoot and holler over IP feature enables you to access ongoing IP/TV multicasts for listening
to voice content of the IP/TV session. For complete information on IP/TV, see the IP/TV Content
Manager Installation and User Guide.
The following figure illustrates Cisco hoot and holler being used to access IP/TV multicasts:
Figure 133 Cisco Hoot and Holler over IP Access to IP/TV Multicast
IP/TV
Content Manager
IP/TV
server
35970
IP/TV
viewer
For the Cisco hoot and holler over IP and IP/TX interaction to work correctly, do the following:
• Ensure that you have properly connected and configured your network for VoIP. Enable the
Cisco hoot and holler over IP feature using the session protocol multicast command.
• Ensure that the server configured with the IP/TV Content Manager is in the same Ethernet network
as the Cisco hoot and holler over IP functionality.
• Ensure that the Cisco hoot and holler over IP multicast details are registered with the IP/TV Content
Manager.
Cisco IOS Voice, Video, and Fax Configuration Guide
VC-829
Hoot and Holler over IP Overview
Note IP/TV support for Cisco hoot and holler over IP uses only G.711 u-law (mu-law) encoding.
Content Manager
Cisco Hoot and Holler over IP
IP/TV supports one audio stream for Cisco hoot and holler over IP.
IP/TV does not support arbitration and mixing.
On the configuration screen (Administration Tool>Scheduled Programs>New Program>Configuration),
provide the following details:
• Multicast address
• RTP port—defined by the dial peer in the router
• IP/TV server—IP address or name
• From the Settings>Content Manager option, do the following:
–
Click Add New.
–
Enter the IP/TV server name.
–
Enter the port number. It must be 80 because it is HTTP.
–
Click OK and exit.
Note In Content Manager, be sure to specify the multicast IP address and RTP port for the Cisco hoot and
holler over IP session.
Interactive Voice Response
The Cisco hoot and holler over IP feature can support interactive voice response (IVR) as a means of
authentication, authorization, and accounting (AAA) control. See the “Configuring TCL IVR
Applications” chapter in this configuration guide or refer to the Cisco IOS Voice, Video, and Fax
Command Reference for more information.
Migration Strategy
To aid troubleshooting and allow for regionalized hoot and holler conferences, most hoot and holler
networks today are structured by interconnecting multiple regional hoot networks with a centralized
bridge. The regional hoot networks are built using either carrier-based multidrop circuits or point-topoint circuits bridged by the customer. All of these circuits are connected through patch panels that allow
for these regional bridges to be connected for a larger corporate-wide conference call. This is typically
done for the “morning call” that is broadcast to all locations, advising of market movements,
recommendations, and commentary. Later in the day, the patch panel may be reconfigured to allow for
local or regional conference bridges. This allows for multiple conference calls for various purposes,
without provisioning multiple circuits. By segmenting the network into regions, troubleshooting is also
easier because any audio disturbance, feedback, or level problems can be isolated to a smaller subset of
remote offices for more specific troubleshooting.
VC-830
Cisco IOS Voice, Video, and Fax Configuration Guide
Cisco Hoot and Holler over IP
Hoot and Holler over IP Overview
The highly segmented nature of existing hoot and holler networks can be leveraged in the migration from
legacy hoot technology to Cisco hoot and holler over IP. A small segment of the hoot network can be
converted to Cisco hoot and holler over IP while preserving the operational procedures at the main office.
Note that the migration to Cisco hoot and holler over IP does not require replacing end-user equipment
or central bridging equipment. The main impetus for this first phase of migration is to eliminate the
recurring expense of carrier multidrop circuits or dedicated leased lines. Migration success is maximized
by minimizing changes to the end user while realizing an attractive payback period on the capital costs.
As the entire hoot network converges with the data network, additional functionality can be introduced.
Since the hoot and holler connections are now carried in standard multicast RTP packets, hoot channels
can now be received by a soft client such as IP/TV, which can receive an IP multicast RTP stream. An
alternate migration strategy is to use Cisco hoot and holler over IP technology initially as a backup for
the existing hoot circuits within a region with a phased plan of cutting over to Cisco hoot and holler over
IP as the primary transport while keeping the existing circuits as a backup for a predefined burn-in
period.
Technical Details of the Cisco Hoot and Holler over IP Solution
This section describes how Cisco hoot and holler over IP works from a technical perspective. It covers
design considerations in terms of IOS configurations and DSP mixing functionality. It also covers
bandwidth planning and QoS, with the following assumptions:
• That you have some level of Cisco IOS experience.
• That you have some experience configuring QoS features using Cisco IOS software. For assistance,
refer to the Cisco IOS IP and IP Routing Configuration Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/index.htm
• That you have some experience configuring VoIP using Cisco IOS software. For assistance, refer to
the Cisco IOS Voice over IP Overview at the following URL:
• http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/vvfvoip.htm
• That you have some experience configuring IP multicasting using Cisco IOS software. For
assistance, refer to Cisco IOS Configuring IP Multicast Routing at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/
• That you have a working IP network, with IP multicasting configured using the Cisco 2600 and
Cisco 3600 series routers. For assistance, refer to the following documents at the Cisco Connection
Online (CCO) Web site:
–
Cisco IOS Configuration Guides and Command References
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/index.htm)
–
Cisco 2600 Series Routers
(http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis2600/index.htm)
–
Cisco 3600 Series Routers
(http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/index.htm)
• That you are familiar with Cisco IP/TV. For assistance, refer to Cisco IOS Software Configuration
at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/webscale/iptv/
• That you understand basic hoot and holler concepts and equipment.
Cisco IOS Voice, Video, and Fax Configuration Guide
VC-831
Hoot and Holler over IP Overview
IP Multicast and DSP Arbitration and Mixing
When deploying Cisco hoot and holler over IP, first consider how the voice streams are going to be mixed
and how they will be distributed to other locations. This is done using a combination of two technologies:
• IPmc
• DSP arbitration and mixing
Since hoot and holler is generally used to allow many people to simultaneously talk and listen to other
people within a hoot group, by definition it requires that the same speech be delivered to multiple parties
at the same time. In an IP network, this functionality uses IPmc. IPmc allows a source to send a single
packet into the IP network and have it duplicated and sent to many listeners by the other routers within
the network. This technique is beneficial in that it does not require the source to know how many
listeners there are, and the source does not have the additional processing burden of having to send a
copy of each packet to all listeners. IPmc also allows listeners to dynamically join IPmc groups, which
eliminates the administrative burden of new users needing to be added every time a new IPmc session is
initiated.
The individual router/gateway can handle mixing and arbitrating the various voice streams that can be
initiated or terminated on its voice ports. This functionality is handled by the onboard DSPs on each
voice card (NM-1V, NM-2V, or NM-HDV). Arbitration involves identifying the various sources of the
voice stream, and mixing involves taking some of those voice streams and combining them into a
single-sourced voice stream. Cisco hoot and holler over IP can handle many inbound voice streams, but
it only arbitrates and mixes three streams to be heard within the hoot group. This value works fine in
most applications because, with more than three streams, two things happen in normal conversation:
• People are not able to distinguish the content of more than three voice streams.
• People normally stop speaking if they hear others talking ahead of them.
Cisco Hoot and Holler over IP
Note The mixing functionality does not do a summation of the voice streams.
The DSPs in the Cisco hoot and holler over IP feature can mix up to three streams. The mixing of the
three streams is important to network administrators in considering how much bandwidth they should
plan for in their Cisco hoot and holler over IP networks. This is especially crucial when planning for
WAN bandwidth, which is often much more expensive and much less available than LAN bandwidth.
The advantage to this functionality is that a network administrator never has to be concerned about
provisioning voice bandwidth for more than three times each call’s bandwidth for each WAN site, which
helps to simplify overall network planning.
Bandwidth Planning
Four main factors must be considered with regard to bandwidth planning for
Cisco hoot and holler over IP:
• Codecs used for VoIP (G.711, G.726, G.729, and G.729a are currently supported).
• Bandwidth management techniques.
• The number of voice streams to be mixed.
• The amount of guaranteed bandwidth available on the IP network. This includes both LAN and
WAN bandwidth and should take into consideration other factors, such as Frame Relay committed
information rate.
VC-832
Cisco IOS Voice, Video, and Fax Configuration Guide
Cisco Hoot and Holler over IP
Codecs
Hoot and Holler over IP Overview
By default, Cisco IOS sends all VoIP traffic (media, using RTP) at a rate of 50 packets per second. The
packets include not only the voice sample, but also an IP, User Datagram Protocol (UDP), and RTP
header. The IP/UDP/RTP header adds an additional 40 bytes to each packet. The amount of bandwidth
each VoIP call consumes depends on the codec selected. The resulting bandwidths can be as follows:
• G.729 or G.729a = 3,000 bytes * 8 bits = 24 Kb/call
• G.726 = 6,000 bytes * 8 bits = 48 Kb/call
• G.711 = 10,000 bytes * 8 bits = 80 Kb/call
In addition to these calculations, network administrators must consider the Layer 2 headers
(Frame Relay, PPP, Ethernet, and so on) and add the appropriate number of bytes to each packet.
In Tab l e 58, the assumption is that the payload size (in bytes) is 20-millisecond samples per packet with
50 packets per second.
The value of n is equal to the number of voice streams in a session.
The uncompressed bandwidth includes IP/UDP/RTP headers (40 bytes) in the bandwidth calculation.
Compressed RTP (cRTP) reduces the IP/UDP/RTP headers to between 2 to 4 bytes per packet. The
calculation of compressed bandwidth below uses 4 bytes for a compressed IP/UDP/RTP header per
packet.
Maximum RTP Control Protocol (RTCP) bandwidth is 5 percent of the total RTP traffic in a hoot and
holler session. Since the Cisco hoot and holler over IP application supports mixing of a maximum of
three voice streams, the RTCP bandwidth is limited to 5 percent of three-voice-stream traffic.
In addition to the above, Layer 2 headers (Frame Relay, Point-to-Point Protocol, Ethernet, and so on)
should be considered and added to the bandwidth calculation.
Table 58 Bandwidth Consideration Table
Codec
g.729
g.726
g.711
Payload Size
(byte)
20 24 9.6 3.6 27.6 13.2
80 48 33.6 7.2 55.2 40.8
160 80 65.6 12.0 92.0 77.6
Bandwidth/ Voice Stream
(Kbps)
Uncompressed Compressed =(1)*n+(3) =(2)*n+(3)
cRTP, Variable-Payload Sizes and VAD
Some network administrators may consider this amount of bandwidth per call unacceptable or outside
the limits of the bandwidth they can provide, especially in the WAN. There are several options that
network administrators have for modifying the bandwidth consumed per call:
• RTP header compression (cRTP)
• Adjustable byte size of the voice payload
• Voice activity detection (VAD)
IP/UDP/RTP headers add an additional 40 bytes to each packet, but each packet header is basically
unchanged throughout the call. Compressed RTP can be enabled for the VoIP calls, which reduces the
IP/UDP/RTP headers from 2 bytes to 4 bytes per packet.
RTCP Bandwidth per
Cisco Hoot and Holler over IP
Session (Kbps)
Example—One Voice Stream in a
Session (Bandwidth in Kbps)
Cisco IOS Voice, Video, and Fax Configuration Guide
VC-833
Hoot and Holler over IP Overview
More information on cRTP may be found in the “Quality of Service Overview” chapter of the Cisco IOS
Quality of Service Solutions Configuration Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/qcfintro.htm
In addition to reducing the IP/UDP/RTP headers per packet, the network administrator also has the
option of controlling how much voice payload is included in each packet. This is done using the bytes
keyword and argument in a VoIP dial peer. The following example shows a dial-peer configuration:
dial-peer voice 1 voip
destination-pattern 4085551234
codec g729r8 bytes 40
session protocol multicast
session target ipv4:239.10.108.252:20102
As the number of bytes per packet is modified, so too is the number of packets per second that are sent.
VAD enables the DSPs to dynamically sense when there are pauses in a conversation. When these pauses
occur, no VoIP packets are sent into the network. This significantly reduces the amount of bandwidth
used per VoIP call, sometimes as much as 40 percent to 50 percent. When voice is present, VoIP packets
are again sent. When using Cisco hoot and holler over IP, VAD must be enabled to reduce the amount of
processing of idle packets by the DSPs. In basic VoIP, VAD can be enabled or disabled, but since the
DSPs also have to do arbitration and mixing, VAD must be disabled to reduce the DSPs’ processing load.
In addition to enabling VAD (which is only by default), network administrators should modify the VAD
parameters that sense background noise so that idle noise does not consume bandwidth.
Cisco Hoot and Holler over IP
Virtual Interface
Connection Trunk
This can be configured as in the following E&M port example:
voice class permanent 1
signal timing oos timeout disabled
signal keepalive 65535
!
voice-port 1/0/0
voice-class permanent 1
connection trunk 111
music-threshold -30
operation 4-wire
The configuration above is used for a voice port that is in send/receive mode, and only noise above -30Db
is considered voice.
In all Cisco hoot and holler over IP implementations, the routers are configured with an “interface vif1.”
This is a virtual interface that is similar to a loopback interface—a logical IP interface that is always up
when the router is active. In addition, it must be configured so the Cisco hoot and holler over IP packets
that are locally mixed on the DSPs can be fast-switched along with the other data packets. This interface
must reside on its own unique subnet, and that subnet should be included in the routing protocol updates
(Routing Information Protocol [RIP], Open Shortest Path First [OSPF], and so on).
VC-834
Cisco hoot and holler over IP provides an “always-on” communications bridge—end users do not need
to dial any phone numbers to reach the other members of a hoot group. To simulate this functionality,
Cisco IOS provides a feature called “connection trunk.” Connection trunk provides a permanent voice
call, without requiring any input from the end user, because all the digits are internally dialed by the
router/gateway.
Cisco IOS Voice, Video, and Fax Configuration Guide
Loading...