VG350 with PLAR - keep getting call backs after hang up

[kylebrogers]

This is a VG350 that is MGCP registered to a CUCM 11.0

I understand what is going on, but not how to fix it.  Essentially we have these emergency call boxes.  Someone hits the button and the call box goes off-hook and hits a blank translation pattern we have set up to PLAR the call to an emergency call system.  The system picks up and the call proceeds correctly.  However, if the system end hangs up, leaving the call box still off-hook, the call-box side doesn't seem to transition into the on-hook state.  It's like it quickly goes on-hook and then back off-hook or something because it hits the PLAR translation pattern again and calls back.  This happens in a never-ending loop until we find a way to make the call box hang up first.  

Is there some kind of setting to make the VG350 endpoints go back on-hook and stay on-hook as soon as the other end hangs up?

[Gregory Brunn]

VG350, FXS port correct, not sure if the model supports FXO off the top of my head, but if FXS then the question becomes, is the port MGCP controlled or SCCP? I have seen mixed gateways before.

Loop start or Pots?

If loop start have you tried adjusting the hook flash timers on the port? 

The situation you describe where the other end goes on hook and then back off quickly is in a hook flash call.  You should be able to tell in more detail by a debug mgcp packet. 

http://www.cisco.com/c/en/us/support/docs/voice/media-gateway-control-protocol-mgcp/40300-mgcp-fxs-hookflash-transfer.html

Have you tried adjusting any timers on the port?

Can you paste the gateway configuration as it relates to the ports.

Also look at the debug mgcp packet if all else fails see exactly what is happening. Document above should help.

Hookflash might not be involved at all, and the phone just goes right off hook again after it receives a disconnect.  I guess with FXS if off hook you will be receiving power and dial tone as long as if you are off hook.

I guess a work around would be to manually shut the port if someone thinks the call and is over and walks away, until someone else can get there. (Not ideal I know)

But in my opinion the non technical problem may be why are the people answer the security phone hanging up on the caller. (Accident?) In which case maybe having the plar calling back right away is not a bad thing in the event of a accidental hang up.  

Hope this helps 

[webberr]

I'm not sure if my situation is exactly the same (since we use SCCP) but I think this may help. For the dial-peer for the port in question:

dial-peer voice 223 pots
 no tone dialtone remote-onhook
 port 2/23

[lilljarrell]

Did you ever find a solution to this, i am dealing with this, i am getting ready to open a TAC case as I cannot find anything on the community of why this is happening. There seems like there should be some setting or timer. Thx

[Adam Pawlowski]

I would also like to know , as the disconnect supervision is not great on these and it has a delay after the circuit is closed.

[lilljarrell]

I found where some folks moved the plar from the CUCM to the VG, and it works fine now, also as Bug CSCe01737 suggests. The only thing is, the PLAR gets a dial tone after the called party hangs up even having the no tone dial-tone remote-onhook configured, but I can live with that. But the VG must be using SCCP instead of MGCP.



Router(config)# sccp plar
Router(config-sccp-plar)# voiceport x/x dial 'PLAR number'