Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

PLAR destination re-rings immediately after hang up (before analog originator has time to hang up)

CallManager 7.1(3b)SU2

VG202 12.4(24)T3

Using SCCP

Have VG202 port set up as PLAR to ring a destination. Everything works fine, have much experience with PALR config. However when the destination hangs up before the VG202 originating end has time to go on hook it immediately re-rings the destination.

If I set up PLAR between 2 IP phones we do not have this issue. When either end hangs up the connection is dropped for both sides.

It's only when the originating end is an analog port that we have this problem. It makes sense, it's analog, and when the destination hangs up, the logic returns the analog side to idle, detects the offhook and of course rings the destination.

What I am looking for is a way to either force the VG202 port to go onhook and back offhook before initiating another PLAR call, or use a time, etc, to give the user at the VG202 port time to hang up before triggering another PLAR call.

This is a gate phone (analog side) ringing to security (IP phone), if security hangs up first then it basically false rings before the user at the gate has time to hang up.

I've tried several timers and settings on both the voice-port as well as the dynamic SCCP dial-peer with no success.

thanks, rick.

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
New Member

What command exacly did you

What command exacly did you use on the VG?

I had the same issue with a VG224 and I was able to do the same but I used 

sccp plar

    voiceport 2/0 dial 50200

    voiceport 2/1 dial 50201

So they call eachother if they go off hook.

9 REPLIES
Cisco Employee

PLAR destination re-rings immediately after hang up (before anal

If your VG202 is setup with FXS ports and you're using the plar command then any time that port is off hook it will try to ring the plar extension. 

For FXS ports use station IDs and dial-peers.  Save the plar command for FXOs.

Unless I'm missing something here....

New Member

PLAR destination re-rings immediately after hang up (before anal

Thanks. Not using IOS commands, note that query states we are using SCCP, so PLAR config is set up in CUCM. Only manual config in VG202 is for SCCP and CallManager for registration. The notes about destination are not commmands but call reference points to explain how issue is manifesting itself.

Hall of Fame Super Red

PLAR destination re-rings immediately after hang up (before anal

Hi Rick,

Maybe you could  setup some sort of Number plan overlap that delays the dialing back  to these lines due to the T302 Timer. Kind of reverse engineering I  guess

Cheers!

Rob

"Show a little faith, there's magic in the night" - Springsteen

New Member

PLAR destination re-rings immediately after hang up (before anal

Hmm, interestring thought may have to go there but I've got ~40 of these and that would get hairy. thanks though.

New Member

Rick - did you every figure

Rick - did you every figure this out?

Thanks,

Dan

New Member

I replied to my own post just

I replied to my own post just now, see that please.

For some reason I haven't been getting notifications on this, even thour they are turned on but your's woke it up. LOL

New Member

Replying to my own post to

Replying to my own post to cover all the comments.

What we ended up doing was to use SCCP PLAR command in the gateways.

We've found this fixes all the "ghost ringback" on VGxxx gateways as well as other IOS gateways (FXS & Line-Side T1 configurations.)

Then in CallManager we don't set up PLAR at all, just give the port/gateway the CSS it needs to reach the PLAR destination set up in the gateway using IOS.

No more ringback. With this configuration if the far end of a PLAR connection (the PLAR destination) hangs up first, the near end (the IOS gateway port initiating the PLAR by coming offhook) does not return to dial tone, but remains silent until you place it back on hook again.

Frankly it's easier as well since we don't need the PLAR Partition and CSS in CallManager any longer. We now only use those if we are setting up PLAR for non-IOS based devices such as IP Phones and ATA's.

New Member

What command exacly did you

What command exacly did you use on the VG?

I had the same issue with a VG224 and I was able to do the same but I used 

sccp plar

    voiceport 2/0 dial 50200

    voiceport 2/1 dial 50201

So they call eachother if they go off hook.

New Member

zandokan1978 has the correct

zandokan1978 has the correct command.

sccp plar

    voiceport 2/0 dial 50200

Then in CallManager just give it any CSS that can get to the destination DN.

No need to set up PLAR in CallManager

1101
Views
10
Helpful
9
Replies