[cisco-voip] VG224/VG248 with PLAR/CUCM behaviour after far end hangs up.

[Wes Sisk]

What comes to mind:

On Friday, April 09, 2010 1:05:58 PM, Lelio Fulgenzi <lelio at uoguelph.ca> 
wrote:
> 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.
>
> First off, VG224.
>
> 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.
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.
>
> 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.
>
> OK, now for the VG248.
>
> 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,
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.

vg248 defect introducing the configuration:
CSCuk37897    Call Manager can treat VG248 ports as idle when physically 
off hook

vg248 defect documenting the conflict that occurs with these configurations:
CSCse77040    PLAR behavior inconsistent with VG248 ph when called party 
ends the call

CM has been known to change interpretations of SCCP messages that break 
this design:
CSCse28510    High CPU and Code Yellow on CM because of new call loop 
with vg248

with vg248 EoL it now receives nominal integration testing with CM
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps2250/end_of_life_notice_c51-569310.html

> 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.
>
> 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).
>
> Thoughts?
>
>
>
>
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Cooking with unix is easy. You just sed it and forget it.
>                               - LFJ (with apologies to Mr. Popeil)
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100409/b00959ea/attachment.html>