Posts Tagged ‘voip’
I just finished up 2 weeks of a really great CCNP Voice bootcamp, covering all 5 of the latest 8.0 version exams from Cisco (CVOICE, CIPT1, CIPT2, CAPPS, & TVOICE). All in all we ended up with 62 completely brand-new hours of informative video that we are sure you will be excited to watch when they are posted to our streaming and download sites here in probably just about a week. We went fairly in-depth on most every topic, one of them being MGCP during our TVOICE section of class.
BTW, with this new 62 hours of CCNP Voice video, this brings INE to 320 hours of total CCNA-to-CCIE Voice video-on-demand training. Far, far more than any other vendor. And it is all up-to-date and taught by me, not by subcontracted instructors.
You may recall that in my last post related to MGCP Troubleshooting, we took a basic look at the MGCP commands that a Call-Agent (server) instructs a Gateway (client) to preform – something the RFC refers to as “verbs”.
In this post, we are going to take a look at the output of the “debug mgcp packets” command for a single call, and then break down each section of the output into “transactions” (i.e. Command and Response).
This isn’t exactly the latest news, and doesn’t effect the CCIE Voice Lab exam (although it very well may effect the new CCNP Voice exams), however I am hearing more and more how people are upgrading their Voice routers with newer 15.x IOS code, and not realizing how existing (working) VoIP calls are being broken due to new, intelligent feature default configurations.
Last July, Cisco decided (wisely, IMHO) to create a new style of Toll-Fraud prevention to keep would-be dishonest people from defrauding a company by placing calls through their misconfigured voice gateway(s), at the company’s expense. This new mechanism works by preventing unintended TDM (FXO/CAS/PRI) and VoIP (H.323 & SIP) calls from being able to be placed through a given company’s voice gateway(s), by simply blocking all unknown traffic. Beginning in IOS 15.1(2)T, Cisco added a new application to the default IOS stack of apps that compares all source IP address with an explicitly configured list in the IOS running config, and if the IP address(es) or subnets do not match, all VoIP traffic is denied. Also, the new default for all POTS voice-ports is to not allow secondary dial-tone, making direct-inward-dial the default for CAS/PRI, and PLAR necessary for FXO.
These two new labs both contain video-based solutions, which walk you — task-by-task — through every step of the necessary configuration, along with plenty of live troubleshooting, just as we should expect when sitting for the actual CCIE Voice Lab exam.
For the first two labs alone, we have recorded over forty hours of video-based solutions.
We are in the process completely of re-writing every lab in the Voice Volume II Workbook, and will be releasing them and posting announcements here about each new lab as they are completed. We will also be releasing new CCIE Voice Deep Dives here shortly. So stay tuned for much, much more from INE’s Voice program.
This publication discusses the spectrum of problems associated with transporting Constant Bit Rate (CBR) circuits over packet networks, specifically focusing VoIP services. It provides guidance on practical calculation for voice bandwidth allocation in IP networks, including the maximum bandwidth proportion allocation and LLQ queue settings. Lastly, the publication discusses the benefits and drawbacks of transporting CBR flows over packet switched networks and demonstrates some effectiveness criteria.
Historically, the main design goal of Packet Switched Networks (PSNs) was optimum bandwidth utilization for low-speed links. Compared to their counterpart, circuit-switched networks (CSNs such as SONET/SDH networks), PSNs use statistical as opposed to deterministic (synchronous) multiplexing. This feature allows PSNs to be very effective for bursty traffic sources, i.e. those that send traffic sporadically. Indeed, with many sources this allows the transmission channel to be optimally utilized by sending traffic only when necessary. Statistical multiplexing is only possible if every node in the network implements packet queueing, because PSNs introduce link contention. One good historical example is ARPANET: the network theoretical foundation has been developed in Kleinrock’s work on distributed queueing systems (see ).
Computing voice bandwidth is usually required for scenarios where you provision LLQ queue based on the number of calls and VoIP codec used. You need to account for codec rate, Layer 3 overhead (IP, RTP and UDP headers) and Layer 2 overhead (Frame-Relay, Ethernet, HDLC etc. headers). Accounting for Layer 2 overhead is important, since the LLQ policer takes this overhead in account when enforcing maximum rate.
A voice lab rack usually utilizes dedicated piece of hardware to simulate PSTN switch. Commonly, you can find a Cisco router in this role, with a number of E1/T1 cards set to emulate ISDN network side. It perfectly suits the function, switching ISDN connections between the endpoints. Additionally, it is often required to have an “independent” PSTN phone connected to the PSTN switch, in order to represent “outside” dialing patterns – such as 911, 999, 411 1-800/900 numbers. The most obvious way to do this is to enable a CallManager Express on the PSTN router, and register either hardware IP Phone or any of IP Soft-phones (such as IP Blue or CIPC) with the CME system.
However, there is another way to accomplish the same goal using IOS functionality solely. It relies on the IP-to-IP gateway feature, called “RTP loopback” session target. It is intended to be used for VoIP call testing, but could be easily utilized to loopback incoming PSTN calls to themselves. Let’s say we want PSTN router to respond to incoming calls to an emergency number 911. Here is how a configuration would look like:
PSTN: voice service voip allow-connections h323 to h323 ! interface Loopback0 ip address 22.214.171.124 255.255.255.255 ! dial-peer voice 911 voip destination-pattern 911 session target ipv4:126.96.36.199 incoming called-number 999 tech-prefix 1# ! dial-peer voice 1911 voip destination-pattern 1#911 session target loopback:rtp incoming called-number 1#911
The trick is that only IP-to-IP calls could be looped back. Because of that, we need to redirect the incoming PSTN call to the router itself first, in order to establish an incoming VoIP call leg.
While this approach permits VoIP call testing, it lacks one important feature, available with the “real” PSTN phone: placing calls from the PSTN phone to the in-rack phones. However, you can always use “csim start” command on the PSTN router to overcome this obstacle. Have fun!
Catalyst QoS configuration for IP Telephony endpoints is one of the CCIE Voice labs topics. Many people have issues with that one, because of need to memorize a lot of SRND recommendations to do it right. The good news is that during the lab exam you have full access to the QoS SRND documents and UniverCD content. The bad news is that you won’t probably have enough time to navigate the UniverCD with comfort plus the reference configurations often have a lot of typos and mistakes in them.