• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/24

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

24 Cards in this Set

  • Front
  • Back
What are the basic differences between H323 gateways and MGCP gateways?
MGCP is cisco proprietary and it's very Call Manager centric. When you add the gateway to Call Manager, you actually need to specify each module and interface type and the config is pushed to the gateway. There is a configuration that needs to go into the gateway, to tell the gateway where the primary and backup subscribers that it is going to connect to from a MGCP standpoint. But once that is in, you will not use dial-peers for example, unless you want SRST. For all of its primary functions, MGCP is controlled through Call Manager.

H323 you literally add it as a H323 gateway in Call Manager, but you don't specify the model of gateway or line card model. You just point at the IP address and at the Gateway you need to add POTS dial peers for outbound calling, and VOIP dial peers for inbound calling.
How does PRI deployment differ between the H323 and MGCP?
For a PRI with MGCP you use "PRI Group Timeslots 1-24 Service MGCP", which means that Call Manager has signaling controller knowledge about the PRI at that point.
On the D channel, you need to backhaul the signaling. You need to do an "isdn bind L3 ccm".

For H323, Call Manager does not know about specific PRI's that are at the gateway. You only have a pointer at the IP address of the gateway.
Dial Plans...What are some of the considerations you need to take when you are developing a dial plan?
It's much like a network routing plan... you need to keep things as contiguous as possible. That's the typical best practice. Try to have whatever phone exchanges you are using, you typically want to divvy it up per location so that there is a contiguous range whenever possible. This is because if you are using a Centralized dialing plan through Gatekeeper or SIP proxy, you can have a summarized method of configuring so it does not become an administrative nightmare. You try to avoid overlapping dial plans whenever possible. Sometimes it is unavoidable when you are doing some kind of migration where you don't do the full migration at once. An example of this would be when you take a subset of DN's and move them over to Call Manager, but you still have tie lines to another system like an Avaya. You would need to have more specific Route Patterns at that point that would allow you to route back and forth. In the end-state, you would want it to be very contiguous because whatever you’re central routing mechanism is, Gatekeeper or CUPS, you’re Zone Prefixes or SIP routes would be summarized with a simple set.
4a. Call Admission control.... within a cluster which CAC are you using in CM?
Within a cluster you would use the Locations field in Call Manager where you put in a bandwidth statement, which is applied to the Device Pool, and then applied to the Phone.
4b. Call Admission control.... what about between the clusters?
With gatekeeper you can do Call admission control within the syntax and you can also apply the location settings to the Trunks in Call Manager
5. Migrations.... what are Key issues you had to look into when you did your migrations?
A lot of the issues were book keeping with our BAT profiles where when we did the exports from the old cluster, when we built the Bat .csv Files, where phones only exported phone lines with one line when they really had two, or only exported 2 lines when they really had 4 lines. Or they had certain custom forwarding settings on the lines that we didn't catch. The first few that we did, we realized that our process was a little too generalized, and we didn't have enough checkboxes in our standard form so that all the engineers that were following this standard process could make sure that they could cover all the little details like that. We had situations where let’s say 98% of the DN's worked, but then there were little odd-ball things like that were left over, so when you multiply that by several sites, it really creates a lot of extra tickets for the helpdesk that could be caught ahead of time if the process was better.
6. Unity connection used in your migrations? How was it used?
We used Unity Enterprise in Voicemail Only not Unity Connections
7. Are you familiar with Media resources? What is your goal when you set them up? How do you set them up?
Typically how I set them up is with Conference Resources which are typically "enhanced IOS conference resources" based off hardware resources on your voice gateway at that particular site. Those resources are available through PVDM chips on the ISR, and then you have DSPFarm statements and profiles that will state how many max conference sessions and what codecs you will support. SCCP commands on the Gateway use SCCP which is the protocol that is communicated between the gateways and call manager to register those resources. Then on call Manager, you add the hardware resource as an IOS enhanced device matching the name that is on the gateway. Once you do that it is available and registered. Then you can also add Media Termination Points or Transcoders in a similar way. Then you take those media resources, and apply them to a media resource group, and then apply that media resource group to a media resource group list, and then you apply that media resource group list to your device pool or phones. What happens is when your phone does an ad-hoc conference, you hit the more button and then conference, the RTP stream then goes through the gateway and then to that end destination, so it's actually using that hardware resource.
8. Are there any benefits of using Hardware vs. Software based media resources?
The benefit of hardware resources is that it is more predictable because you are using dedicated hardware at each location which is more scalable. If you were to use software resources off the call manager which is default, and it would work, but it is taxing the subscribers to perform media resource duties instead of registering phones and processing.
9. What is the mechanism in CM to separate devices?
Device pools
10. IP voice streaming resources with regards to CM services. What is it used for?
The Annunciator
11. What is the benefit of load balancing phones across the servers in a cluster?
You would use Call Manager groups in a 1 to 1. Typically since you can support 7500 phones on a G5 for example... you would take 3750 phones and assign them to a certain device pool which in turn has a certain call manager group, so in that call manager group you would have sub1 and sub2, so at that point whatever the first sub in that call manager group is what those phones would register to, but then you take another call manager group and make SUB2 primary and SUB1 as a backup. So now if both subscribers support 3750 phones, then if there is a subscriber failure, let’s say subscriber1 fails, then sub 2 would be able to support the full load of phones on that second subscriber.

I have seen people use the Tertiary subscriber in their CM groups, but it is typically used for a disaster recovery for a large scale failure where the third subscriber would exist in a completely different datacenter in case of a large scale disaster.
12. Network Management Tools? Which ones have you used? Explain.
Used RTMT mostly, but have also implemented ciscoworks where we used the phone manager feature where you can get reporting.
Used RTMT to track down calls when CAR was not available.
13a. CME? Explain your experience with it.
I have done CME mostly for smaller customers. It's like SRST, but with more command line. You need to configure ephones and ephone DN's in command line. It's like you took the graphical interface and turned it into command line. There is a GUI for CME, but i really haven't worked much with it because the command line is somewhat straight forward to me.
13b. what do you use to communicate between CME and CUE? What is the protocol connection is used to communicate between the CME and CUE?
SIP Trunk
15. From a dial plan perspective, some features have come around with the later versions of CM like 7 and 8 what is the local route group used for?
The concept of that is where in your device pool you would specify the local route group, and that way you don't need to create multiple iterations of route patterns per site. It simplifies your route plan.
16. Multi Cluster deployments.... communication between clusters.... what bandwidth requirements are needed to be accounted for? Latency requirements?
Within your cluster, you want to have less than 40ms latency. This would restrain you from being in the same LAN or MAN in the same geographic latency. This is one of the prerequisites of the A2Q process to gain support from cisco.
There is also a device weight calculation where you take the total number of registration devices, and calculate the number of signaling traffic is going to be required between your devices that are split across a MAN. You take that calculation, and classify that type of traffic in your priority queue so that across the WAN the traffic is always prioritized over other data traffic.
17. Gatekeeper...711 calls what bandwidth is required?
128k on Gatekeeper

32 and 80k for call manager
18. Gatekeeper...What methodology is used to scale your gatekeepers from a call routing
Perspective?
For redundancy you would use HSRP where you would use a VIP that your CM trunk would point at, using primary and standby, and then duplicate all the zone information OR Use GUP, which is more of a stateful protocol, where you would have a primary zone and a backup zone that it would register.

From a call routing perspective, you would have a centralized dial-plan, you may have a pair of gatekeepers at a central location. Then all the other clusters will have a summarized route pattern for all the DN's that they need to reach that are in another cluster.
You would typically have a route pattern, and then a route list, and within that route list there would be a route group, which would in turn have your gatekeeper trunks in it. That way from a signaling standpoint, call manager would communicate to the gatekeeper, and on the gatekeeper you would have zone prefixes typically for the other DN ranges that live on other clusters, and they would in turn have route patterns that would point back at the gatekeeper, so it acts as a centralized device.

If you have a lot of gatekeepers, you would use directory gatekeeper.
19. Video background... Desktop video... Microsoft integration with Call manager?
I haven't done video from a call manager perspective, but have done IP based CCTV. That was more from an application and network perspective.
20. Cisco Services Framework? Mock integration Experience?
NO i haven’t done that.
21. CUPSC integration? Any experience?
NO i haven’t done that.
SIP SIGNALLING
Basic SIP session setup involves a SIP UA client sending a request to the SIP URL of the called endpoint (UAS), inviting it to a session. If the UAC knows the IP address of the UAS, it can send the request. Otherwise, the UAC sends the request to a proxy or redirect server to locate the user. That server might forward the request to other servers until the user is located. After the SIP address is resolved to an IP address, the request is sent to the UAS. If the user takes the call, capabilities are negotiated and the call commences. If the user does not take the call, it can be forwarded to voice mail or another number.
PLUS DIALING
The E.164 standard defines an international numbering plan for public phone systems. In the E.164 standard, each number contains a country code, an area code, and a subscriber number. Each phone user has a globally unique number.
If a phone number has a plus character ("+") at the start, the number is in E.164 format. Phone numbers in LDAP directories can have a plus character prefix. Typically, when you dial an international number, you replace the plus character with the correct international access code for the locale from which you make the call.


For example, in the United States, you replace the plus character with 011, in France you replace the plus character with 00, and so on. However, some phone systems allow you to dial the plus character directly.


You can configure Cisco Unified Communications Manager Release 7.0 to support the plus character in dialed numbers. Cisco Unified Personal Communicator Release 7.0 does not remove the plus character from dialed numbers. Releases of Cisco Unified Personal Communicator earlier than Release 7.0 do remove the plus character from dialed numbers.

You might only need to configure application dialing rules for numbers that users enter manually, if all of the following conditions are true:
•Your system uses only Cisco Unified Communications Manager Release 7.0 and Cisco Unified Personal Communicator Release 7.0.

•You have configured translation patterns in Cisco Unified Communications Manager to accommodate numbers that begin with a plus character.

•Your LDAP directory contains phone numbers that are only in full E.164 format and begin with a plus character.

You must configure the application dialing rules in Cisco Unified Communications Manager to remove the plus character from dialed numbers, if both of the following conditions are true:
•Support for the plus character is not enabled or supported in your Cisco Unified Communications Manager installation.

•Your LDAP directory contains phone numbers formatted with the plus character.

You do not need to reconfigure the application dialing rules if you reconfigure Cisco Unified Communications Manager to process the plus character correctly. However, in this case you might need to reconfigure the application dialing rules to support both Cisco Unified Personal Communicator Release 7.0, and releases earlier than Release 7.0.