<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
What comes to mind:<br>
<br>
On Friday, April 09, 2010 1:05:58 PM, Lelio Fulgenzi
<a class="moz-txt-link-rfc2396E" href="mailto:lelio@uoguelph.ca"><lelio@uoguelph.ca></a> wrote:<br>
<blockquote
cite="mid:1759341224.1606871270832758477.JavaMail.root@simcoe.cs.uoguelph.ca"
type="cite">
<style type="text/css">p { margin: 0; }</style>
<div
style="font-family: Verdana; font-size: 10pt; color: rgb(0, 0, 0);">OK,
this started off as a simple why doesn't this work on a VG224, but when
I tested it on a VG248 things got weird.<br>
<br>
First off, VG224.<br>
<br>
When I configure a VG224 port via SCCP with CallManger (v4.1 and v7.1
confirmed) and have PLAR working (blank translation in partition
style), if the far end hangs up first after the initial PLAR, the VG224
port gets dialtone for a bit, then immediately starts the dial process
again.<br>
</div>
</blockquote>
ws: Yes, the behavior is client dependent. CM uses SCCP to tell the
phone to go onhook but there is no way to force the analog side
onhook. So the device doing the internetworking from SCCP to analog
ground or loop start has to make some decisions. I believe the 224 may
change behavior based on guard timers configured on the analog voice
port.<br>
<blockquote
cite="mid:1759341224.1606871270832758477.JavaMail.root@simcoe.cs.uoguelph.ca"
type="cite">
<div
style="font-family: Verdana; font-size: 10pt; color: rgb(0, 0, 0);"><br>
When I configure the VG224 with PLAR for SRST, this does not happen.
When the far end hangs up, they simply get dial tone. This is the
behaviour I'd like to see (and expect?) during CCM operation.<br>
<br>
OK, now for the VG248.<br>
<br>
When I configure a VG248 port with CallManager (v4.1 confirmed) and
have PLAR working as above, if the far end hangs up after the initial
PLAR, the VG248 gets dead air, then eventually gets error tone. The far
end IP phone starts acting all screwed up, </div>
</blockquote>
ws: this sounds like the vg248 configuration 'busy out offhook ports'
is enabled. This is specifically triggered when the digital side
(SCCP) transitions from offhook to onhook but analog side remains
offhook. Many vg248's were connected to voicemail systems or fax
banks. In those cases it is highly undesirable to have CM attempt to
send another call to the device because analog is not ready for another
call. At that time there was no Reject Softkey (CSCsc75099, internal
only for now, will be visible on Monday) so the only option for the
vg248 was to send SCCP offhook to indicate to CM that the analog side
was still busy. This prevents CM from sending additional calls. Now,
if you combine that with a PLAR configuration you get very bad
results. The vg248 initiates a new offhook message every time CM
attempts to clear the call for as long as the analog side remains
offhook.<br>
<br>
vg248 defect introducing the configuration:<br>
CSCuk37897 Call Manager can treat VG248 ports as idle when
physically off hook <br>
<br>
vg248 defect documenting the conflict that occurs with these
configurations:<br>
CSCse77040 PLAR behavior inconsistent with VG248 ph when called
party ends the call <br>
<br>
CM has been known to change interpretations of SCCP messages that break
this design:<br>
CSCse28510 High CPU and Code Yellow on CM because of new call loop
with vg248 <br>
<br>
with vg248 EoL it now receives nominal integration testing with CM<br>
<a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps2250/end_of_life_notice_c51-569310.html">http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps2250/end_of_life_notice_c51-569310.html</a><br>
<br>
<blockquote
cite="mid:1759341224.1606871270832758477.JavaMail.root@simcoe.cs.uoguelph.ca"
type="cite">
<div
style="font-family: Verdana; font-size: 10pt; color: rgb(0, 0, 0);">like
it's trying to ring from the VG248 port, but it's all static-y and
stop/start. One phone had 290 missed calls by the time it stopped.
Others I've had to unplug and plug back in.<br>
<br>
I'm using older phone loads on the 7940/60s which could be the problem,
a 7912 seems to behave a little bit better (but not much).<br>
<br>
Thoughts?<br>
<br>
<br>
<br>
<br>
<br>
---<br>
Lelio Fulgenzi, B.A.<br>
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
Cooking with unix is easy. You just sed it and forget it. <br>
- LFJ (with apologies to Mr. Popeil)<br>
<br>
</div>
<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>