Wednesday, December 29, 2010

Important new section of Unity Connection 8.5 readme

Synchronizing Connection and Exchange Mailboxes (Single Inbox)

You can configure Connection to synchronize voice messages between Connection mailboxes and the corresponding Exchange mailboxes. When single inbox is enabled for a user, all voice messages, including those sent from Cisco ViewMail for Microsoft Outlook, are first stored in Connection and are immediately replicated to the Exchange mailbox for the recipient. Voice messages appear in the Outlook inbox for the user, alongside email and faxes, and also appear in the Connection mailbox for the user.

For Connection 8.5(1), single inbox will support only Exchange 2010. Support will be added for Exchange 2003 in the first quarter of calendar year 2011, and support for Exchange 2007 will be added in the second quarter of calendar year 2011. When support for a version of Exchange is added, the "Unified Messaging Requirements: Synchronizing Connection and Exchange Mailboxes (Single Inbox) (Connection 8.5 and Later Only)" section in the System Requirements for Cisco Unity Connection Release 8.x will be updated with that information.


Tuesday, December 28, 2010

Disallow subscription is the new white

Disallow subscription is now the default interpresence subscription for CUCM 8.0. This could be quite a pain in the butt for those of you who can't work out why you can't see other users presence status.

It is also a pain when your working with the new presence server 8.0 and CUCM 8.0 and presence is not showing correctly.

Here is the relevant parameter, notice the default parameter on the side.




Clusterwide Parameters(System - Presence)






Disallow Subscription


Friday, December 17, 2010

Bulk Admin Tool and Extension Mobility

Hi Guy's,

I am currently doing a CUCM 8.0 deployment for a customer. A few cool new little things in 8.0 that I really like that I thought I would mention

1. Just like in CCME, you can now update your personal directory/fast dials etc. etc. from the phone itself.

2. You can reset your PIN from the extension mobility login page.

Just a quick thing around Extension Mobility though: You can't actually perform bulk updates to user device profiles.. This is a bit frustrating and I hope Cisco resolve this ASAP.

Other than that 8.0 is great. There are lot's of good enhancements you can use in your life, the major one being of course the SSL VPN on your phone. How cool is that!

Tuesday, December 14, 2010

Cisco WAAS Express

Hi Guys, super quick update, nothign to do with voice :p

Cisco WAAS express,

Cisco WAAS is Cisco's WAN acceleration technology, I personally believe in it quite strongly. I have done a few deployments of it and it's always worked very well especially when the software is up to date.

With cisco WAAS you need a device that actually performs the acceleration of the traffic, normally this is in the form of an appliance (a dedicated peice of hardware) or an SRE that slots into the router, however with WAAS express you can now perform the WAAS functionality in software. It's very simple to enable and works quite well. You even have the ability to trial it.


here are the caveats around it.

Only supported on ISR G2

Only supported if you have a central manager (cisco WAAS appliance that manages all the devices)

Thursday, October 28, 2010

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)

Wednesday, October 27, 2010

Journey may be over...

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

Tuesday, October 19, 2010

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

Thursday, October 14, 2010

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

Saturday, October 9, 2010

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!




Tuesday, October 5, 2010

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

Monday, October 4, 2010

"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



Saturday, October 2, 2010

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

What a great bug!!!

Thursday, September 30, 2010

sip-ua statistics

hey guys, useful troubleshooting command for sip

show sip-ua statistics

shows all sorts of things including how many times you have sent/received a certain message

PeterCCIE18371#show sip-ua statistics
SIP Response Statistics (Inbound/Outbound)
Informational:
Trying 121/283, Ringing 116/109,
Forwarded 0/0, Queued 0/0,
SessionProgress 3/3
Success:
OkInvite 100/255, OkBye 88/61,
OkCancel 31/42, OkOptions 0/0,
OkPrack 2/2, OkRegister 0/408
OkSubscribe 82/157, OkNotify 2059/180, OkPublish 0/0
OkInfo 0/0, OkUpdate 6/14,
202Accepted 0/0, OkOptions 0/0
Redirection (Inbound only except for MovedTemp(Inbound/Outbound)) :
MultipleChoice 2, MovedPermanently 0,
MovedTemporarily 20/11, UseProxy 0,
AlternateService 0
Client Error:
BadRequest 0/0, Unauthorized 0/39366,
PaymentRequired 0/0, Forbidden 0/0,
NotFound 4/1331, MethodNotAllowed 0/0,
NotAcceptable 0/0, ProxyAuthReqd 0/0,
ReqTimeout 0/0, Conflict 0/0, Gone 0/0,
ConditionalRequestFailed 0/0,
ReqEntityTooLarge 0/0, ReqURITooLarge 0/0,
UnsupportedMediaType 0/0, UnsupportedURIScheme 0/0,
BadExtension 0/0, IntervalTooBrief 0/0,
TempNotAvailable 0/0, CallLegNonExistent 3389/77,
LoopDetected 0/0, TooManyHops 0/0,
AddrIncomplete 0/0, Ambiguous 0/0,
BusyHere 0/2, RequestCancel 32/42,
NotAcceptableMedia 0/0, BadEvent 0/5,
SETooSmall 0/0, , RequestPending 0/0
UnsupportedResourcePriority 0/0
Server Error:
InternalError 0/3, NotImplemented 0/0,
BadGateway 0/0, ServiceUnavail 5/2,
GatewayTimeout 0/0, BadSipVer 0/0,
PreCondFailure 0/0
Global Failure:
BusyEverywhere 0/0, Decline 0/0,
NotExistAnywhere 0/0, NotAcceptable 0/0
Miscellaneous counters:
RedirectRspMappedToClientErr 0

SIP Total Traffic Statistics (Inbound/Outbound)
Invite 283/160, Ack 290/159, Bye 62/89,
Cancel 45/32, Options 0/0,
Prack 2/2, Update 14/6,
Subscribe 1738/3684, Notify 257/27750, Publish 0/0
Refer 0/0, Info 0/0,
Register 41203/0

Retry Statistics
Invite 8, Bye 1, Cancel 1, Response 45,
Prack 0, Reliable1xx 0, Notify 24177, Info 0
Register 0 Subscribe 202 Update 0 Options 0
Publish 0



Monday, September 20, 2010

Bootcamp

Hey Guys

Having a really educated time down here at IPExpert's bootcamp. Vik know's his shit backwards and the other guy's are really cool too.

I am actually kinda tempted to give the exam a go while i am down here, things are going very well. I will think about it.

Cheers
Pete

Tuesday, September 7, 2010

More H.323 Gatekeeper stuff

Hi Guys,

Blog update, this time I am going to talk about H.323 Gatekeepers, man, I thought I had them 100 percent sorted but over this weekend I took two IPExpert practice labs and boy did gatekeeper give me grief.

The workbooks from IPExpert had tough but fair questions, really impressed! Your voice labs are so much better than Internetworkexpert's it almost borders on the ridiculous.

Let's talk really quickly about something that tripped me up that's not actually gatekeeper but is related to everyone's FAVORITE protocol that is TOTALLY _NOT_ past its prime and is definitely NOT completely outmoded and not really used much more in the real world. (your sarcasm detector should have gone off at this point.)


H.323 fast start, Slow start, and terminal capability set

Lets say you have a SIP gateway, a CUBE and then CUCM pointing to that CUBE as h.323

you have an issue where the phone rings out when a SIP handset calls the CUCM through the CUBE, when you pick up the handset at CUCM, it answers on the CUCM side but the SIP phone keeps ringing.

This is caused by SIP early-offer and H323 fast start and slow start.

you see with H.323 codec parameters are not negotiated until the handset actually answers if you do NOT have fast-start, (so your using slow-start), the problem is the way the poor CUBE (or ip to ip gateway) has to convert the SIP messages into h.323

if the CUBE gateway receives a SIP message with an "Early offer" which is kind of like the equivalent to H.323 fast-start (and is the default on Cisco SIP handsets with CME by the way) it will try and send a "Fast start" to CUCM because that's what it will convert the early offer to.

You need to make sure your trunk is enabled to support this in CUCM!


Also, while we are on the topic, on that same page, make sure you turn off "terminal capability set" as this is NOT supported by CUBE gateways and features like hold, transfer ETC through a cube gateway will not work with this enabled.

So much to remember!

Ok, onto the gatekeeper stuff, really briefly, a Via-zone is a very useful feature where you can FORCE calls to be routed through an intermediary device (a CUBE router in other words)

Let's say for example, your a huge multinational company, you've bought so many companies and have many departments.

Let's say you have two "companies" under your parent company that for legislation reasons or some other good reason can't actually directly talk to each other via IP, but you have a central site with a gatekeeper and a CUBE router that they can both talk to (Just not straight to each other)

in that case, a configuration on your gatekeeper like this might help you:

gatekeeper
zone local VIAZONE cisco.com
zone local LOCAL cisco.com outvia VIAZONE enable-intrazone
zone prefix LOCAL 3...
gw-type-prefix 1#* default-technology
no shutdown
!


lets try and analyze this, first of all you can see we have two zones, VIAZONE and LOCAL, two seemingly normal named zones and they are for all intents and purposes, the important commands in this config come from here:

outvia VIAZONE enable-intrazone

what these commands say is

"any ARQ message that matches zone local, must actually be routed out any gateway in the zone VIAZONE"

the enable-intrazone simply means that even calls from endpoints in the same ZONE are routed through the "intermediary" zone VIAZONE

Check out some sample commands to give you an idea:

R2#show gatekeeper gw-type-prefix
buffer used: 205, size: 20480
GATEWAY TYPE PREFIX TABLE
=========================
Prefix: 1#* (Default gateway-technology)
Zone LOCAL master gateway list:
192.168.1.251:1720 R1
192.168.3.2:1720 R3

Prefix: 2#*
Zone VIAZONE master gateway list:
192.168.2.2:1720 R2

(note: I deliberately registered my "Cube" Router (R2) in a diffirent tech-prefix to show you that for VIAZONE's the tech-prefix does not actually matter! Wow one of the only times in H.323 where it doesnt bloody matter!)

here's more:

R2#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
--------------- ----- --------------- ----- --------- ---- -----
192.168.2.2 1720 192.168.2.2 51825 VIAZONE H323-GW
ENDPOINT-ID: 66C4236000000003 VERSION: 4 AGE: 21 secs SupportsAnnexE: FALSE
g_supp_prots: 0x00000050
H323-ID: R2
Voice Capacity Max.= Avail.= Current.= 0
192.168.3.2 1720 192.168.3.2 61090 LOCAL VOIP-GW
ENDPOINT-ID: 66C4081C00000003 VERSION: 4 AGE: 9 secs SupportsAnnexE: FALSE
g_supp_prots: 0x00000050
H323-ID: R3
Voice Capacity Max.= Avail.= Current.= 0
192.168.1.251 1720 192.168.1.251 58414 LOCAL H323-GW
ENDPOINT-ID: 66C4212000000002 VERSION: 4 AGE: 6 secs SupportsAnnexE: FALSE
g_supp_prots: 0x00000050
H323-ID: R1
Voice Capacity Max.= Avail.= Current.= 0
Total number of active registrations = 3

Finally, let's see where the RTP goes etc when I actually do make a call between these two endpoints, my router (r3) is trying to ring 3333, there is a dial-peer on R1 for this also on R2 (my cube router)


R2#show gatekeeper calls
Total number of active calls = 2.

largest hash bucket = 2
GATEKEEPER CALL INFO
====================
LocalCallID Age(secs) BW
18-42194 710 11 16(Kbps)
ConferenceID CallID SrcCRV
A452C0D2 B9FD11DF 8029E0F6 1ECAFB8D A452C0D2 B9FD11DF 802AE0F6 1ECAFB8D 16
Endpt(s): Alias E.164Addr
src EP: R3
CallSignalAddr Port RASSignalAddr Port
192.168.3.2 1720 192.168.3.2 61090
Endpt(s): Alias E.164Addr
dst EP: R2 3333
CallSignalAddr Port RASSignalAddr Port
192.168.2.2 1720 192.168.2.2 51825
callstate: SEP, DEP,
LocalCallID Age(secs) BW
19-42194 710 10 16(Kbps)
ConferenceID CallID SrcCRV
A452C0D2 B9FD11DF 8029E0F6 1ECAFB8D A452C0D2 B9FD11DF 802AE0F6 1ECAFB8D 0
Endpt(s): Alias E.164Addr
src EP: R2
Endpt(s): Alias E.164Addr
dst EP: R1 3333
CallSignalAddr Port RASSignalAddr Port
192.168.1.251 1720 192.168.1.251 58414
callstate: DEP,



VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 11 12 21106 19052 192.168.2.2 192.168.3.2
2 12 11 27982 20382 192.168.2.2 192.168.1.251
Found 2 active RTP connections








Monday, August 30, 2010

Cisco Unity Assistant

I plan to update this part of the blog more tomorrow, but i super quickly wanted to note down my main findings about personal assistant:

- Personal assistant is a unity connection feature that allows users to specify quite granular transfer rules for calls that are sent to them, it can screen calls and do many other things before they arrive at the users phone

- unity assistant is slightly different, this allows users to control things like order of messages, playback of menu speed and quite a few other bits and pieces. You can also create things called "Contacts" that can be dialed from a voice menu.

But my issue was, how the hell do I enable a user to have access to voice-based menus?

The answer is you must enable it in the Class of service, then enable it under the user.

Go to Class of service -> "Allow access to advanced features" -> "Allow user to use voice recognition"

also to enable PCA while you are tick the boxes for this:

Then, under the user go to
"
(Tick this)
"



More details to come soon but I hope this helps someone out there!





Wednesday, August 25, 2010

Debugging H.323


Before we get too much into looking straight at the actual h.323 debug messages, lets check out an extremely useful command for troubleshooting H.323 including both gateway stuff and gatekeeper stuff.

This has lots of useful info on the

PeterCCIE18371#show h323 gateway

H.323 STATISTICS AT 3d01h

H.225 REQUESTS SENT RECEIVED FAILED

Setup 1 0 0

Setup confirm 0 1 0

Alert 0 1 0

Progress 0 0 0

Call proceeding 0 1 0

Notify 0 1 0

Info 0 0 0

User Info 0 0 0

Facility 0 0 0

Release 1 1 0

Reject 0 0 0

Passthrough 0 0 0

H225 establish timeout 0

RAS failed 0

H245 failed 0

Here we see lots of useful general messages about the type of h225 requests we have sent and received, rather than wading through h225 debug outputs you could clear the counters before you made a call with

Clear h323 gateway

Then look at these counters as you make calls. You can see from the above that we first sent a setup, received an alert, call-proceeding (ring ring), notify, release (hung up)

Lets take a moment now and say that I setup my CUCME to register to a gatekeeper. I then create a dial-peer to a number I know the gatekeeper won’t be able to resolve so I can see what happens when I try and make a call and look at the stats. I will also try and tell the gateway to register with a zone-name that doesn’t exist. Lets look at what happens

PeterCCIE18371#show h323 gateway ras

RAS STATISTICS AT 3d01h

RAS MESSAGE REQUESTS SENT CONFIRMS RCVD REJECTS RCVD

GK Discovery grq 15 gcf 1 grj 2

Registration rrq 2 rcf 2 rrj 0

Admission arq 0 acf 0 arj 0

Bandwidth brq 0 bcf 0 brj 0

Disengage drq 0 dcf 0 drj 0

Unregister urq 1 ucf 1 urj 0

Resource Avail rai 0 rac 0

Req In Progress rip 0

RAS MESSAGE REQUESTS RCVD CONFIRMS SENT REJECTS SENT

GK Discovery grq 0 gcf 0 grj 0

Registration rrq 0 rcf 0 rrj 0

Admission arq 0 acf 0 arj 0

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

You can see here in the part I have highlighted in red ((grj 2) that our attempts at registration have been rejected. This normally indicates a config problem between the gatekeeper and gateway, say something like a certain someone not actually using the same zone name ;)

When I try and make a call, because the gateway is not even registered my session target ras dialpeer is totally ignored:

PeterCCIE18371#show gateway

H.323 ITU-T Version: 4.0 H323 Stack Version: 0.1

H.323 service is up

Gateway PeterCCIE is not registered to any gatekeeper

Alias list (CLI configured)

E164-ID 3002

E164-ID 911

E164-ID 2123942123

E164-ID 6178632683

E164-ID 32141891

E164-ID 6745738932

E164-ID 9004522138

H323-ID PeterCCIE

Alias list (last RCF) is empty

So lets first clear our stats and then fix up our registration so we actually register then make another test call.

#clear h323 gateway

----- Dialed number here ----

PeterCCIE18371#show h323 gateway

H.323 STATISTICS AT 3d01h

H.225 REQUESTS SENT RECEIVED FAILED

Setup 0 0 0

Setup confirm 0 0 0

Alert 0 0 0

Progress 0 0 0

Call proceeding 0 0 0

Notify 0 0 0

Info 0 0 0

User Info 0 0 0

Facility 0 0 0

Release 0 0 0

Reject 0 0 0

Passthrough 0 0 0

H225 establish timeout 0

RAS failed 1

H245 failed 0

That’s interesting! We get a lovely new field called “RAS failed” so we can tell its tried to route the call via the gatekeeper..

RAS MESSAGE REQUESTS SENT CONFIRMS RCVD REJECTS RCVD

GK Discovery grq 1 gcf 1 grj 0

Registration rrq 2 rcf 2 rrj 0

Admission arq 1 acf 0 arj 1

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

The bit I have highlighted in red shows that there was an admission request (1) and then an admission reject (1) because we had the wrong number. Unfortunately you don’t get much detail as to exactly why the call was admission reject, and this could be because of invalid number OR no bandwidth. Annoying right? Well keep scrolling down…

RAS MESSAGE REQUESTS RCVD CONFIRMS SENT REJECTS SENT

GK Discovery grq 0 gcf 0 grj 0

Registration rrq 0 rcf 0 rrj 0

Admission arq 0 acf 0 arj 0

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

DISC CAUSE CODE FROM OTHER PEER FROM H323 PEER

3 no route to destinatio 0 1

No route to destination! We are given the exact reason why the call was rejected.

I truly believe you could work out 99 percent of issues without requiring any sort of debug messages with this command. It presents them in an easy to read format. This works for H.323 gateway stuff too, observe the output when I make another test call to a number not configured to use a gatekeeper but just a simple H.323 dial-peer where I have set my codec to use g.711 but the other end is configured for G.729 only.

PeterCCIE18371#show h323 gateway

(Output omitted)

DISC CAUSE CODE FROM OTHER PEER FROM H323 PEER

3 no route to destinatio 0 1

47 no resource (47) 0 1

47, No resource, which we can take to mean that the codec is not supported.

This is my attempt at a similar post to my SIP debugging. Here I have tried to find the most useful debug commands I could for H.323 gatekeepers.

Debug commands used in H323

Debug cch323 h225 (debug h225 asn1 or debug h225 events is simply too detailed to get anything useful at all!)

Debug h245 asn1

(this has some much more handy info)

You can do these same debugs on a Call-manager too by enabling the appropriate traces (h245 detailed and h323 detailed)