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.
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.
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!
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)
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)
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!
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 CODEFROM OTHER PEERFROM H323 PEER
34 no circuit (34)03
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)
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
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.
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)
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"
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
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!
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 REQUESTSSENTRECEIVEDFAILED
Setup100
Setup confirm010
Alert010
Progress000
Call proceeding010
Notify010
Info000
User Info000
Facility000
Release110
Reject000
Passthrough000
H225 establish timeout 0
RAS failed0
H245 failed0
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 MESSAGEREQUESTS SENTCONFIRMS RCVDREJECTS RCVD
GK Discoverygrq15gcf1grj2
Registrationrrq2rcf2rrj0
Admissionarq0acf0arj0
Bandwidthbrq0bcf0brj0
Disengagedrq0dcf0drj0
Unregisterurq1ucf1urj0
Resource Availrai0rac0
Req In Progress rip0
RAS MESSAGEREQUESTS RCVDCONFIRMS SENTREJECTS SENT
GK Discoverygrq0gcf0grj0
Registrationrrq0rcf0rrj0
Admissionarq0acf0arj0
Bandwidthbrq0bcf0brj0
Disengagedrq0dcf0drj0
Unregisterurq0ucf0urj0
Resource Availrai0rac0
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.0H323 Stack Version: 0.1
H.323 service is up
GatewayPeterCCIEis 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 REQUESTSSENTRECEIVEDFAILED
Setup000
Setup confirm000
Alert000
Progress000
Call proceeding000
Notify000
Info000
User Info000
Facility000
Release000
Reject000
Passthrough000
H225 establish timeout 0
RAS failed1
H245 failed0
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 MESSAGEREQUESTS SENTCONFIRMS RCVDREJECTS RCVD
GK Discoverygrq1gcf1grj0
Registrationrrq2rcf2rrj0
Admissionarq1acf0arj1
Bandwidthbrq0bcf0brj0
Disengagedrq0dcf0drj0
Unregisterurq0ucf0urj0
Resource Availrai0rac0
Req In Progress rip0
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 MESSAGEREQUESTS RCVDCONFIRMS SENTREJECTS SENT
GK Discoverygrq0gcf0grj0
Registrationrrq0rcf0rrj0
Admissionarq0acf0arj0
Bandwidthbrq0bcf0brj0
Disengagedrq0dcf0drj0
Unregisterurq0ucf0urj0
Resource Availrai0rac0
Req In Progress rip0
DISC CAUSE CODEFROM OTHER PEERFROM H323 PEER
3 no route to destinatio01
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 CODEFROM OTHER PEERFROM H323 PEER
3 no route to destinatio01
47 no resource (47)01
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)