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
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
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
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
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
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
"
"
More details to come soon but I hope this helps someone out there!
- 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!
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)
Subscribe to:
Posts (Atom)