<!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">
blah! I forgot to mention the service parameter.&nbsp; CM Service parameter
"MGCP Retry Timeout Handling" configures the behavior when a timeout is
observed.&nbsp; This allows marking the endpoint oos, resetting just the
port, unregistering the entire gateway.&nbsp; Unregistering then entire
gateway is the default value.<br>
<br>
/wes<br>
<br>
On Tuesday, November 03, 2009 9:29:24 AM, Wes Sisk
<a class="moz-txt-link-rfc2396E" href="mailto:wsisk@cisco.com">&lt;wsisk@cisco.com&gt;</a> wrote:<br>
<blockquote cite="mid:4AF03E44.7060804@cisco.com" type="cite">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
timely question.<br>
  <br>
MGCP gateway can be viewed as:<br>
  <br>
MGCP Gateway<br>
&nbsp;&nbsp;&nbsp; mgcp/udp based registration and keepalives<br>
&nbsp;&nbsp;&nbsp; analog endpoints<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; mgcp/udp based registration and transactions<br>
&nbsp;&nbsp;&nbsp; digital endpoints<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; backhaul/tcp based<br>
  <br>
on CM if you see the alarm:<br>
MGCPGatewayLostComm then the top level mgcp process stopped
communicating with CM.&nbsp; 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>
|&lt;CLID::MFCU-CM-1-Cluster&gt;&lt;NID::10.10.200.11&gt;&lt;CT::2,100,66,1.23017474&gt;&lt;IP::10.10.33.250&gt;&lt;DEV::&gt;
  <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>
|&lt;CLID::MFCU-CM-1-Cluster&gt;&lt;NID::10.10.200.11&gt;&lt;CT::2,100,66,1.23017448&gt;&lt;IP::10.10.31.250&gt;&lt;DEV::&gt;
  <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>
|&lt;CLID::MFCU-CM-1-Cluster&gt;&lt;NID::10.10.200.11&gt;&lt;CT::2,100,66,1.23017648&gt;&lt;IP::10.10.31.250&gt;&lt;DEV::&gt;
  <br>
  <br>
  <br>
This is getting very close to unregistration.&nbsp; Another way to look at
this is to look for indicates of lost messages to the gateway.&nbsp; Each
MGCP transaction is retransmitted up to 3 times if not ack'd.&nbsp; 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.&nbsp; CM
will retry the transaction 3 times and then unregister the gateway.&nbsp;
This looks similar to the retries tracked above.&nbsp; 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.&nbsp; This was historically caused by CSCsf26617 and
similar.&nbsp; 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.&nbsp; 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 moz-do-not-send="true" class="moz-txt-link-rfc2396E"
 href="mailto:wilsonhew@gmail.com">&lt;wilsonhew@gmail.com&gt;</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">&lt;<a moz-do-not-send="true" href="mailto:bob@btrfronk.com">bob@btrfronk.com</a>&gt;</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.&nbsp;
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);">&nbsp;</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. &nbsp;&nbsp;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);">&nbsp;</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);">&nbsp;</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">&nbsp;</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>
&nbsp;&nbsp;&nbsp; Packets recvd:&nbsp;&nbsp; 857<br>
&nbsp;&nbsp;&nbsp; Recv failures:&nbsp;&nbsp; 1<br>
&nbsp;&nbsp;&nbsp; Packets xmitted: 852<br>
&nbsp;&nbsp;&nbsp; Xmit failures:&nbsp;&nbsp; 0<br>
--------------------------------------------------------------<br>
In 'sh mgcp stats':<br>
      <br>
&nbsp;UDP pkts rx 557379, tx 558783<br>
&nbsp;Unrecognized rx pkts 0, MGCP message parsing errors 0<br>
&nbsp;Duplicate MGCP ack tx 9, Invalid versions count 0<br>
&nbsp;CreateConn rx 36256, successful 36249, failed 7<br>
&nbsp;DeleteConn rx 36274, successful 36101, failed 173<br>
&nbsp;ModifyConn rx 66178, successful 66126, failed 52<br>
&nbsp;DeleteConn tx 154, successful 154, failed 0<br>
&nbsp;NotifyRequest rx 54652, successful 54516, failed 136<br>
&nbsp;AuditConnection rx 3, successful 3, failed 0<br>
&nbsp;AuditEndpoint rx 14887, successful 8080, failed 6807<br>
&nbsp;RestartInProgress tx 6248, successful 6248, failed 0<br>
&nbsp;Notify tx 342779, successful 342779, failed 0<br>
&nbsp;ACK tx 201075, NACK tx 7191<br>
&nbsp;ACK rx 349100, NACK rx 0<br>
&nbsp;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 moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a moz-do-not-send="true" 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>
  <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>