<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
timely question.<br>
<br>
MGCP gateway can be viewed as:<br>
<br>
MGCP Gateway<br>
mgcp/udp based registration and keepalives<br>
analog endpoints<br>
mgcp/udp based registration and transactions<br>
digital endpoints<br>
backhaul/tcp based<br>
<br>
on CM if you see the alarm:<br>
MGCPGatewayLostComm then the top level mgcp process stopped
communicating with CM. Usually the GW sends keepalives to CM similar
to:<br>
12/27/2005 10:16:40.173 CCM|MGCPHandler received msg from: 10.10.33.250<br>
NTFY 333382 *@HQ-VG224-3rdFlr MGCP 0.1<br>
X: 0<br>
O:<br>
|<CLID::MFCU-CM-1-Cluster><NID::10.10.200.11><CT::2,100,66,1.23017474><IP::10.10.33.250><DEV::>
<br>
<br>
If CM does not receive keepalive from gateway CM will attempt to query
the gw with this message:<br>
12/27/2005 10:17:07.002 CCM|MGCPHandler send msg SUCCESSFULLY to:
10.10.31.250<br>
AUEP 13561613 AALN/S2/0@HQ-VG224-1stFlr MGCP 0.1<br>
F: X<br>
|<CLID::MFCU-CM-1-Cluster><NID::10.10.200.11><CT::2,100,66,1.23017448><IP::10.10.31.250><DEV::>
<br>
<br>
This AUEP is not 'normal'.<br>
F = RequestedInfo<br>
X = RequestIdentifier<br>
Normal AUEP requests much more information. This is a special "hello,
are you there" type exchange.<br>
<br>
the gateway should respond:<br>
12/27/2005 10:17:07.002 CCM|MGCPHandler received msg from: 10.10.31.250<br>
200 13561613<br>
X: 2<br>
|<CLID::MFCU-CM-1-Cluster><NID::10.10.200.11><CT::2,100,66,1.23017648><IP::10.10.31.250><DEV::>
<br>
<br>
<br>
This is getting very close to unregistration. Another way to look at
this is to look for indicates of lost messages to the gateway. Each
MGCP transaction is retransmitted up to 3 times if not ack'd. You can
see retries in the CM SDI traces:<br>
01/13/2005 10:34:33.603 CCM|MGCPHandler TransId: 1097943 Timeout.
Retry#1<br>
<br>
If you see frequent retries then you are intermittently dropping or
excessively delaying the UDP packets carrying the MGCP payload.<br>
<br>
<br>
There is also an issue where endpoints may stop responding to CM. CM
will retry the transaction 3 times and then unregister the gateway.
This looks similar to the retries tracked above. The main difference
is that you will see valid exchanges with other endpoints on the
gateway or you will see successful keepalives with the top level
gateway MGCP process. This was historically caused by CSCsf26617 and
similar. The signature of this failure is repeated retransmits of the
DLCX, RQNT, or CRCX messages from CM to the gateway while other
endpoints are responding. If this is happening then the gateway is
having an internal error such as resource allocation or dsp hang.<br>
<br>
HTH.<br>
<br>
/Wes<br>
<br>
<br>
<br>
On Tuesday, November 03, 2009 3:39:24 AM, Wilson Hew
<a class="moz-txt-link-rfc2396E" href="mailto:wilsonhew@gmail.com"><wilsonhew@gmail.com></a> wrote:<br>
<blockquote
cite="mid:777fe0130911030039u4cbd4302saf6905b2405a3af9@mail.gmail.com"
type="cite">Bob/Ryan, appreciate your feedback. Thanks.<br>
<br>
Guess I need to look at the connection between my MGCP gateway and
CUCM. Any idea what else I may need to check? I am looking at the SDI
traces, but have no idea what to look at.<br>
<br>
Thanks,<br>
Wil<br>
<br>
<div class="gmail_quote">On Tue, Nov 3, 2009 at 2:35 AM, Bob Fronk <span
dir="ltr"><<a moz-do-not-send="true" href="mailto:bob@btrfronk.com">bob@btrfronk.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="color: rgb(31, 73, 125);">I
had this happening and found out it was an MPLS circuit going down.
Due
to location of this particular site, our 12mbps MPLS circuit is
supplied by
multiple T1s bonded with MLPPP.</span></p>
<p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="color: rgb(31, 73, 125);">One
of the T1s was going up/down several times a day (telco problem) and
each time,
the MLPPP would reset for a couple seconds. The MGCP gateway
responded by going into SRST and the PRI would go down for a moment.</span></p>
<p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Just
something to check</span></p>
<p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span></p>
<div
style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">
<p class="MsoNormal"><b><span style="font-size: 10pt;">From:</span></b><span
style="font-size: 10pt;">
<a moz-do-not-send="true"
href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>
[mailto:<a moz-do-not-send="true"
href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>]
<b>On
Behalf Of </b>Wilson Hew<br>
<b>Sent:</b> Monday, November 02, 2009 11:47 AM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> [cisco-voip] MGCP - Fallback to SRST very often
even though
connectivity to CUCM is fine</span></p>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<p class="MsoNormal">Hello there,<br>
<br>
Greetings. I am having problem with my MGCP gateway, and I need little
help and
advice. My MGCP gateway is running as SRST, and it will fallback to
SRST very
often (twice a day). And it will go back to normal operation from
fallback just
after that. The connectivity from my MGCP gateway (remote site) to CUCM
is
fine.<br>
<br>
I noticed my E1 is going down everytime when it falls back to SRST - is
it
considered normal?<br>
<br>
My gateway is running 12.4(24)T1 and CUCM version 7.0.2.<br>
<br>
In 'sh ccm-manager', I have the below:<br>
--------------------------------------------------------------<br>
TFTP retry count to shut Ports: 2<br>
<br>
Statistics:<br>
Packets recvd: 857<br>
Recv failures: 1<br>
Packets xmitted: 852<br>
Xmit failures: 0<br>
--------------------------------------------------------------<br>
In 'sh mgcp stats':<br>
<br>
UDP pkts rx 557379, tx 558783<br>
Unrecognized rx pkts 0, MGCP message parsing errors 0<br>
Duplicate MGCP ack tx 9, Invalid versions count 0<br>
CreateConn rx 36256, successful 36249, failed 7<br>
DeleteConn rx 36274, successful 36101, failed 173<br>
ModifyConn rx 66178, successful 66126, failed 52<br>
DeleteConn tx 154, successful 154, failed 0<br>
NotifyRequest rx 54652, successful 54516, failed 136<br>
AuditConnection rx 3, successful 3, failed 0<br>
AuditEndpoint rx 14887, successful 8080, failed 6807<br>
RestartInProgress tx 6248, successful 6248, failed 0<br>
Notify tx 342779, successful 342779, failed 0<br>
ACK tx 201075, NACK tx 7191<br>
ACK rx 349100, NACK rx 0<br>
Collisions: Passive 0, Active 0<br>
--------------------------------------------------------------<br>
<br>
Can I tell what is wrong with the above? Apart from that, I see numbers
of
slips in controllers e1 increasing, and I have
network-clock-participate
configured.<br>
<br>
Would appreciate if you could give me your feedback about this. Any
feedback is
very much appreciated.<br>
<br>
Thanks,<br>
Wil</p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
<br>
</body>
</html>