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
No comments:
Post a Comment