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)
Trying 121/283, Ringing 116/109,
Forwarded 0/0, Queued 0/0,
SessionProgress 3/3
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


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.


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:

zone local VIAZONE
zone local LOCAL 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
Prefix: 1#* (Default gateway-technology)
Zone LOCAL master gateway list: R1 R3

Prefix: 2#*
Zone VIAZONE master gateway list: 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
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
--------------- ----- --------------- ----- --------- ---- ----- 1720 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 1720 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 1720 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
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 1720 61090
Endpt(s): Alias E.164Addr
dst EP: R2 3333
CallSignalAddr Port RASSignalAddr Port 1720 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 1720 58414
callstate: DEP,

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