<!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">
A packet capture of all traffic in/out of the phone would help
significantly with conditions for any lab test or recreate.<br>
<br>
/Wes<br>
<br>
On Thursday, July 01, 2010 3:47:46 PM, Pawlowski, Adam
<a class="moz-txt-link-rfc2396E" href="mailto:ajp26@buffalo.edu"><ajp26@buffalo.edu></a> wrote:<br>
<blockquote
cite="mid:06F4A0AECDEB8248951A4CFAF9044EDBEACA9BEC10@MBCCR3.itorg.ad.buffalo.edu"
type="cite">
<pre wrap="">Absolutely. Like several other quirks and bugs, it may turn out that there is a very specific set of circumstances which contributes to this problem, which may likely disappear after a change like a new load, one piece or another rebooting, something else on the network leaving, etc.
Thanks though for the help and I will post if I find anything new.
Adam Pawlowski
CIT/OSS Repair Services
University at Buffalo
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Wes Sisk [<a class="moz-txt-link-freetext" href="mailto:wsisk@cisco.com">mailto:wsisk@cisco.com</a>]
Sent: Thursday, July 01, 2010 3:07 PM
To: Ryan Ratliff
Cc: Pawlowski, Adam; <a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
Subject: Re: [cisco-voip] 7900 series and ARP
And after that it will likely be best to proceed through a formal TAC
case. There isn't a plethora of information available in this area so
it will take some dedicated time and communication.
/Wes
On Thursday, July 01, 2010 2:58:27 PM, Ryan Ratliff
<a class="moz-txt-link-rfc2396E" href="mailto:rratliff@cisco.com"><rratliff@cisco.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Before you do anything you need to upgrade the phone firmware to the
</pre>
</blockquote>
<pre wrap="">latest load.
</pre>
<blockquote type="cite">
<pre wrap="">-Ryan
On Jul 1, 2010, at 2:06 PM, Pawlowski, Adam wrote:
The phones are 7961G-GE's and 7941G-GE's. Load is 8.5.3S . I have a
</pre>
</blockquote>
<pre wrap="">partial capture, not being mindful of my buffering when I was able to
reproduce it, I missed call setup. Basically there is a bunch of
broadcast ARP request from the destination phone to the originating
phone but it does not reply. I toggled GARP from off to on, which
shouldn't have really made a difference, and following is the start of
the next call which then it answers the first request and the call
begins.
</pre>
<blockquote type="cite">
<pre wrap="">Except for that one instance I haven't been able to reliably
</pre>
</blockquote>
<pre wrap="">reproduce it, only receive reports of the issue, and then I can see on
the console log, from the phone, the ERR about not receiving any RTP
packets. Of course within the last couple of loads the log just fills
up with "CDP-D: holdThrd SendingCmd:proto:1 port:0" leaving us with
only a short time window to observe, if the user happens to call in as
soon as it happens.
</pre>
<blockquote type="cite">
<pre wrap="">If there is a theoretical scenario it may be easier to try and
</pre>
</blockquote>
<pre wrap="">reproduce it here in a test environment, barraging the phone with some
variety of traffic, if need be.
</pre>
<blockquote type="cite">
<pre wrap="">-----------
Adam
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>