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)
Ok, we all want our CCIE Voice numbers, I imagine that’s why a heck of a lot of you are reading this blog ;). I want mine too believe me… Double CCIE is the goal this year, 4 by 2012. Will I make it? I guess I’ll see.
Moving on, in the CCIE Voice lab we have all already been warned: Expect tons of troubleshooting. Internetworkexpert’s coursework would have you believe that this is limited to simple stuff like phones in the wrong VLAN and stuff like that, IP Expert seem to take a much better approach that chances are it’s going to be more complicated.
Cisco themselves mentioned at Networkers in Las Vegas that the CCIE Voice lab will now have lots of focus on troubleshooting, up to 15 percent! They also specifically mentioned that the days of assuming your PSTN is going to be an E1 connection in the lab are long gone too (i.e. it may entirely be a SIP trunk or H.323 gatekeeper.)
With this in mind, I set out on a journey of discovering voice troubleshooting, what followed was learning some incredibly useful commands that I wanted to share with you all.
We are going to examine some SIP call flows, some H.323 call flows and some DTMF-relay in an effort to understand them all a bit better. I have never seen an absolutely comprehensive collection of all this info in one place. I truly hope this helps someone out there.
This tutorial assumes you have some basic SIP knowledge already, you should know about the different types of SIP messages (invite, OK, ACK) , the fact that its text-based, that it sends back error codes as 400’s or 500’s like a HTTP server (404 not found, 403 unauthorized, that sort of thing.) Its also important to note (and I think Mark snow who used to be at IP expert for clearing this up in his VOD) that the UAC and UAS terminology you always see in SIP makes it sound way more complicated than it is: A UAC is just the “Calling” party and the UAS the called party. Simple as that.
All testing assumes a SIP trunk between a CUCM and a CUCME. Our CUCME has IP address 1.1.1.1 and binds all its SIP media to this address. Our CUCM has the IP address 10.0.0.252. Finally we have a phone with the IP Address 192.168.10.21 registered to our CUCM.
The CUCM handset has the number 5008, the CUCME has the number 911
First call debug:
In this example I am going to make a simple call from my CUCM handset
G.711, our device “911” will call “5008”
Source address of CCME: 1.1.1.1
SIP Trunk Details: Standard SIP trunk in CUCM. Nothing special configured,
SIP CALL FLOW
current dial-peer:
dial-peer voice 9999 voip
destination-pattern 5...
session protocol sipv2
session target ipv4:10.0.0.252
codec g711ulaw
---- Digits Dialed on handset here ----
PeterCCIE18371#debug ccsip messages
SIP Call messages tracing is enabled
PeterCCIE18371#
Aug 24 14:10:45.879: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:5008@10.0.0.252:5060 SIP/2.0
This part might look fairly obvious. We are SENDING an invite to sip:5008@10.0.0.252, one of the key things I wanted to point out in this was the “Sent” command you see at the top, it can get extremely tricky when debugging SIP working out who sent what message, this should help clarify things a little.
The “Via” message helps us work out what IP Address we are sending out FROM, here you can see we have bound our SIP messages to send out as 1.1.1.1 (we used the bind command in our config previously)so this is a great way to work out where exactly your SIP messages are being sourced from.
Here we run into one of those things that makes it tricky to read SIP, you see here that even though we generated this message (the invite message) we have our phone (911) listed as a REMOTE PARTY? Well, to the server (the UAS, the CUCM that we are calling) we ARE the remote party. So again, important to pay attention to that bit right at the top that tells you if your sending or receiving this message. You will also note since we have only just sent this message we don’t have the display name for the number we are calling (5008) shown yet. We also have a “tag” which helps us identify messages related to this call.
The “Supported” keyword indicates the SIP features we support, in here we have timer refreshes and a few other bits and bobs. We also have a Min-SE which specifies our session interval and when it needs to be refreshed.
Here we are saying “This is the type of device I am” (user-agent) (essentially, although its not always the case) and the allow shows all the SIP methods that we understand and support. Subscribe for example indicates we support presence.
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1282659045
Contact:
Expires: 180
Here we can see that we are specifying a max forward, this says how many times we will allow this call to be forwarded (how many proxies or gateways in the path) we also have a Contact field, this tells the UAS where to send the message back to when its ready to send return messages.
Allow-Events: telephone-event
Supported: precondition
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 206
This is one of the more important parts of the messages and one of the least understood. In SIP some messages will contain SDP information (session description protocol) this is the information SIP that is actually used to control things like codec negotiation, dtmf-relay and also what IP addresses media should actually be sent to (this will become important later.)
v=0
o=CiscoSystemsSIP-GW-UserAgent 391 9124 IN IP4 1.1.1.1
s=SIP Call
c=IN IP4 1.1.1.1
t=0 0
a=rtr
m=audio 17922 RTP/AVP 0 19
c=IN IP4 1.1.1.1
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
We have a lot of confusing looking attributes here so lets try and go through as many as we can, the “C” attribute you can see listed here tells the system who initiated the call, this will come to be important later. The M indicates what codec we want to use, and the attributes specify our dtmf-relays.
Aug 24 14:10:45.899: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Here you see we “RECEIVED” a message back from the other end, the content length is 0, indicating there is no SDP in this message. We also see that it is sending 200 trying, which essentially means its received our request. This is an important message: If the gateway does not receive this message after sending a 101 invite within the “Trying” timeout, it will retry X number of times and if no response is received will inform the gateway. These timers can be changed under SIP-ua with:
Sip-ua
Timers trying
Retry
!
You might need to do this if you have two CUCM’s as I posted in a previous blogpost.
Aug 24 14:10:45.903: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Now we are getting a little further, The other end has successfully found the number we have rung and is proceeding to ring on the handset. This message will be the last message you see until someone picks up the handset, this message times out OR they ignore you, redirect you or heck they just answer the call, whatever the case may be. We can see here at this point that the remote end has also let us know what capabilities (sip methods) this device supports. The content length is again 0 indicating that no SDP is sent with this message.
----- Call Answered Here --------
Aug 24 14:11:32.523: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
This is what we have been waiting for! The handset has picked up so we have been sent a 200 OK message with important details for us to connect the media streams up with.
To: ;tag=bb6a91cf-cec8-42ad-9aa3-7bda337c86c4-30307968
Contact:
Content-Type: application/sdp
Here we can see we have a content length of 155 indicating there is an SDP message waiting and a content-type of application/sdp, we also see above a keyword Supported: replaces, this is one of the many RFC extensions to SIP and is to do with conferencing, these all become more important as we perform call-forwards and other activities.
Here we see values for the session expire, 1800, indicating that a session refresh must occur during this time period. The responsibility of the refresher is also shown (the UAS)
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.0.0.252
s=SIP Call
c=IN IP4 192.168.10.21
t=0 0
m=audio 22782 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
Here we see the SDP sent from the CUCM, as you can see we have less options in the RTP map, and we also have M for the media shown, you will also notice the c= IN IP4 showing the actual IP address of the handset itself. This is very important as this is where we will actually attempt to connect via RTP to. This address would change if you where using an MTP for example. Notice also the bit I have highlighted in red, this is the port number that the RTP will attempt to connect on. If you check the SDP we originally sent in the invite message this is our RTP port too
Aug 24 14:11:32.535: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Hidden away in all of this, is where we have actually been transfered to, the P-preffered-Identity: shown above shows where the forward is sent, Can you see where we have been transferred to?
If you said 5111, good on you!
Aug 24 14:55:12.063: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Again we have the extremely confusing thing where the “From: “ listed is actually a separate number to us, it’s very difficult to read if you look at this to try and determine which side has sent the message, use the Sent: or received at the very top to work out who sent what message. Here we are sending a 107 Invite which is a special type of message.
Aug 24 14:55:12.063: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
o=CiscoSystemsSIP-GW-UserAgent 2272 8359 IN IP4 1.1.1.1
s=SIP Call
c=IN IP4 1.1.1.1
t=0 0
m=audio 16950 RTP/AVP 0 19
c=IN IP4 1.1.1.1
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
Here we are sending the CUCM our IP address and RTP stream that we will be listening on, the CUCM is responsible for relaying this information to the transferred-to party.
Aug 24 14:55:12.271: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Here we received a message back telling us no problem and where we need to connect to with our RTP stream, can you work out where we will be connecting to?
Here is another hint if you can’t get it from the above:
We can finally do our show sip-ua calls for more info, note that annoyingly, even though our display on our phone has updated to indicate we are calling 5111, the number shown in the sip-ua calls is still 5008
There you have it, if you made it this far, well done! I am glad to see your dedication. Why don’t you try debugging with G.729, try with an MTP clicked on your CUCM trunk and you will see things like the IP address for the rtp stream changed, the RTP-map will change depending on what dtmf-relay you want to do and much more.