End of an era..

Hi Internet World that happens to read my blog :)

This might be the last blog post for a little while (about 6 weeks) as I have passed my CCIE Voice and will now be taking a little well earned break.

Thanks everyone for reading, I really hope you got something out of this blog. I loved getting emails from you and comments, lots of people said nice things about some of the articles i wrote, that some hints and tips where useful to them. I am extremely glad that I could be of help to you.

I hope this blog helped someone out there!

Peter Revill
CCIE #18371 (Routing and Switching, Voice)

Journey may be over...

The journey might be over.. I will find out for sure tomorrow.

Conference Options in CME

Hey Guys,

Sorry its been a while since I posted, I have been diligently preparing for my CCIE Voice lab exam again (i'm going to smash it this time!)

So in tune with that, I have been studying lots of features in CME and CCM and I wanted to talk about conferencing in CME

First of all, heres a quick run down:

CME supports ad-hoc and meet-me conferencing.

Ad-hoc is supported in both software mode and hardware mode, while meet-me is only supported in hardware-mode conferences.

Hardware mode means that you must have a conference dspfarm resource registered to the CCME.


The ad-hoc in software mode is also limited to 3 participants as it uses a built in bridge on the phone. The participants must all be using the same codec.

Now here are some options for the software-based conferencing that you might not know:

First off, live-record (the cisco unity express feature) WILL work with software-based conferences as long as the codec used between all parties is G.711

Have you ever gone under an ephone and seen
"keep-conference"

and wondered what it was? well wonder no more, the keep-conference keyword is a way of controlling what happens when a conference initator leaves a software-based conference (it has no effect whatsoever on hardware-based conferences)

[no] keep-conference [end-call] [local-only]

Really quickly, heres how it works:

if no keep-conference is entered (the default) then if a conference initiator leaves the conference in any way the call is dropped, if the keep-conference command is there by itself, if the initator just hangs up the two other parties are connected to each other but if he presses 'end-call' then the call is dropped (strange I know)


if you have keep-conference end-call then no matter how the initiator hangs up the conference stays up. the local-only keyword ensures that all of these rules only apply if at least one local party is left in the conference.

So now you know the options around the software based conferences

hardware based conferencing (ad-hoc) adds the ability to add more than a certain number of participants (obviously) and also adds support for conflist (shows a list of conference participants) , rmlstc (removes the last caller) and join and select (allows joining of existing calls to conference)

the maximum participants for a conference is set under the dspfarm profile

dspfarm profile 1 conference
maximum conference-participants <>
!

now, some options available to you with conferencing on a hardware-based conference are:

conference add-mode creator

this command means that the only person allowed to add more people to a conference is the creator (this is done under the ephone) whenever that particular ephone creates a conference.

This might be useful for a CEO or someone who does not want other conference participants being able to add more people into the conference.

conference drop-mode creator and local

these are kind of the opposite way around to the keep-confernece command, by default a conference will always stay up if on a DSP farm even if the initiator leaves, with this command you can force it so that if the conference creator leaves the conference is dropped.

Now we come onto one more option that i think is very cool

conference admin

this command means that the phone tagged with this can admin any conference, so any conference he joins he can remove participants and add more participants, one very cool feature it has is that he can even join existing conferences by dialing the ad-hoc number of the conference!

I hope this helps someone out there

Advanced H323 Gatekeeper troubleshooting

Advanced Gatekeeper stuff/Troubleshooting

HI Guys,

So, first things first, how do we troubleshoot for example, when a remote gatekeeper has the bandwidth command restricting us from calling? Example config given below:

gatekeeper

zone local REMOTE cisco.com 113.29.243.26

zone local ZONE1 cisco.com

bandwidth remote 10

no shutdown

!

Lets say we try and send this guy a call, obviously it won’t work, since we need enough bandwidth for a call both ways, (128)

Here is what we will see when we do a show h323 gateway on the GW trying to make a call through our own local GK to this remote GK:

PSTN-WAN# show h323 gateway

….

DISC CAUSE CODE FROM OTHER PEER FROM H323 PEER

34 no circuit (34) 0 3

I tried to call three times here hence the 3 J

Now LOCALLY if our own LOCAL GK (or a GK that they tell us to point to but don’t actually let us go onto) has the bandwidth command, we get a much more useful message (arj)

gatekeeper

zone local MYZONE cisco.com

zone remote REMOTE cisco.com 113.29.243.26 1719

zone prefix REMOTE 6*

gw-type-prefix 3* hopoff MYZONE gw ipaddr 10.0.0.3 1720

bandwidth remote 10

no shutdown

endpoint resource-threshold

So lets check out what happens now, clear our stats again:

PSTN-WAN#clear h323 gateway

All H.323 stats cleared at 1w0d

<- make test call.. beep beep beep beep!->

PSTN-WAN#show h323 gateway ras

RAS STATISTICS AT 1w0d

RAS MESSAGE REQUESTS SENT CONFIRMS RCVD REJECTS RCVD

GK Discovery grq 0 gcf 0 grj 0

Registration rrq 0 rcf 0 rrj 0

Admission arq 1 acf 0 arj 1

You can see here we TRIED to make a call (arq) but where rejected (arj) probably due to the bandwidth issue.

This message will also appear if you do a “endpoint” restriction, heres an example config for this:

gatekeeper

zone local MYZONE cisco.com

zone remote REMOTE cisco.com 113.29.243.26 1719

zone prefix REMOTE 6*

gw-type-prefix 3* hopoff MYZONE gw ipaddr 10.0.0.3 1720

no shutdown

endpoint resource-threshold

endpoint max-calls h323id PSTN-WAN 1

!

You MUST have the “Endpoint resource-threshold” configured for this to actually work

Once again, if you have this configured, the message sent back if you try and make more than two calls will be admission reject

RAS MESSAGE REQUESTS SENT CONFIRMS RCVD REJECTS RCVD

GK Discovery grq 0 gcf 0 grj 0

Registration rrq 4 rcf 4 rrj 0

Admission arq 2 acf 0 arj 2

Bandwidth brq 0 bcf 0 brj 0

Disengage drq 0 dcf 0 drj 0

Unregister urq 0 ucf 0 urj 0

Resource Avail rai 0 rac 0

Req In Progress rip 0

QOS and the error message " CBWFQ : Not supported on subinterfaces"

Hi Guys,

Pete here, so I am doing some more labs, really focusing on IP-IP-GW interaction and QOS to try and get across the line with that, so here is the first thing I wanted to chat about

CBWFQ : Not supported on subinterfaces

Ever seen that error message before? it happens when you try and apply a QOS policy with either the priority command or the bandwidth command on an interface.

HOWEVER, what I did NOT know, is that you can use hierarchical policy maps when faced with this message, observe the below:

BR1-R2#show policy-map
Policy Map voip
Class voip
priority 20 (%)
Class class-default
fair-queue

Policy Map 512
Class class-default
Average Rate Traffic Shaping
cir 512000 (bps) bc 5120 (bits)
service-policy voip


if you now apply the policy-map 512:


interface Serial0/0/1:0.1 point-to-point
description == FR To HQ
ip address 177.0.101.2 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 101
service-policy output 512
end


You can see that it is accepting the fair-queue:


BR1-R2#show policy-map int serial 0/0/1:0.1

Serial0/0/1:0.1

Service-policy output: 512

Class-map: class-default (match-any)
102 packets, 9309 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 102/7795
shape (average) cir 512000, bc 5120, be 5120
target shape rate 512000
lower bound cir 0, adapt to fecn 0

Service-policy : voip

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: voip (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Priority: 20% (102 kbps), burst bytes 2550, b/w exceed drops: 0


Class-map: class-default (match-any)
102 packets, 9309 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
(pkts output/bytes output) 102/7795
Fair-queue: per-flow queue limit 16



I hope this helps someone out there!




Continuation

Hi Guys,

My friend Adrian and future double CCIE who attended a bootcamp with me pointed out this particular supplementary-service that kind of blows all my previous article on "To" numbers out the water ;)

supplementary-service h225-notify cid-update


If you disable this service, H.323 does NOT update the CUCM on the actual number that was dialed in the end.

Thanks Adrian

"To" Number display

Hi Gang,

As some of you may already know, I did not make my first attempt at the exam although my score report indicated I was very close, let me be totally clear: It is very difficult, I personally found it MUCH harder than my routing and switching exam which frankly I cruised through, the exam is very long, so make sure you have good speed.

But I do not give up that easily! If Cisco thinks they have seen the last of me they are sorely mistaken, I have booked the lab again and am revisiting some areas of the blueprint that I know need work, the quick breakdown of areas I want to be 100 percent on are listed below:
  • Switch QOS (I suck at this and I also _hate_ it, I find it very complicated)
  • Gatekeeper Troubleshooting and SIP Call Flows/H323 Call Flows/MGCP Call Flow debugging
  • I am going to investigate every possible way of doing IP to IP Gateways, supplementary services and get definitive answers on things like when MTP is needed, when it's not, what does work, what doesn't and more
  • All the features in CUCM and CUCME including all the service parameters and other little bits that might affect them.
So in line with this, I have been investigating something that we don't see very often but is worth knowing.

We all know about how to change our calling number when we make calls out to the PSTN right? It is fairly simple stuff, there is lot's of ways we can do it. For example on route-patterns, translation-patterns and transformation patterns in CUCM and on CME we can use voice translation-rules, dialplan pattern commands etc (although I personally now never ever use dialplan pattern.)

But what about the display on the phone when we DIAL a number, for example, When I dial 9911, how could I for example make this display as "911" or something else, and what order do these rules take affect?

Let's start from the top

H.323 and SIP interactions
----------------------------

To summarize this right from the start: Basically any sort of digit manipulation you perform, be it a route-pattern, a transformation-pattern, a translation pattern or a voice translation-profile IS going to take affect and update the "To" display for callers. The only exceptions to this rule are dial-peer commands such as prefix or forward-digits (note that voice translation-rules DO affect the "to")

Here are the scenarios I performed and proved 100 percent in a lab environment at my home

First some quick lab information of my home setup:

1 Publisher, CUCM 7.0.3
1 Voice Gateway (Main Router) , Version 12.4(24)T2,
1 PSTN Gateway (Phone configured with "911" and "999")

1.
Prefix Command, Digit strip, forward-digits etc appear to have no affect on "To" display

tested by: configuring the following dial-peer
dial-peer voice 999 pots
destination-pattern 4444
forward-digits 0
prefix 911
!

Phone display showed "4444" despite the fact that 911 was being sent to the ISDN

True for both phones running straight off this CCME and phones connected via CUCM


Voice translation-rules:

Translation rules on either voice-ports or the dial-peer itself did affect the "To" and updated it. It also confirmed a suspicion of mine that the "prefix" and "Forward-digits" commands are applied AFTER the voice translation-rules are applied, even if the rule is configured on a voice-port itself. So the prefix and forward-digits are always the last digit manipulations to be done.

Testing methodology:

dial-peer with destination pattern 900

translation-rule converts 900 to 11 and is then applied to dial-peer

dial-peer has "prefix 9" configured

when calling 900, display updates to show "11" but 911 is sent to PSTN

CUCM elements:

Route-plan called party transformation masks and prefix's
- DO affect TO
Translation-pattern called party transformation masks and prefix's:
- DO affect TO
Transformation-patterns (called party)
- DO affect TO

this confirmed 100 percent with H.323 and SIP, I would love someone else to get the chance to test this in there own lab and confirm. If my testing instructions or methodology is not descriptive enough please let me know in the comments section and I will give more information!

Now we move ontop MGCP.


MGCP
---------------------
To summarize, MGCP "to" was affected for route-pattern called-party transform and translation-pattern called party transforms but NOT updated if a transformation-pattern was applied, voice translation-rules on the voice-port did not work as this is MGCP so they would not take effect. Below is the testing methodology.

Route-pattern created for "11" and called-party digit manipulation said to prefix 9
when ringing "11" phone "to" displayed "911"

Translation-pattern created for "4567" and called-party digit manipulation set to "11"
this then matched the route-pattern shown above
Phone displayed "911"

Transformation-pattern created to match "11" and prefix a 9 infront of it, applied to gateway

route-pattern changed to not perform any digit manipulation and simply send "11" to gateway
transformation-pattern then matched this, so call went out to PSTN as 911 but "TO" display showed as "11"

I hope this helps someone out there!

Kind Regards
Peter



http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?caller=pluginredirector&method=fetchBugDetails&bugId=CSCsl74701

What a great bug!!!

Popular old posts.