Incoming POTS calls dropped when going to AA/VM, plar/plar opx

Unanswered Question

I am having problems with incoming PSTN calls. I have the voice-port setup to 'plar opx' to a hunt group. the hunt group rings fine, but the call drops when it is time to transfer to AA (final for the hunt group).

I think it's a dial-peer problem, but I'm not sure what to do about it.

I've noticed that if i change from 'plar opx' to just 'plar', it works fine. what are the differences between plar and plar opx, and how could it cause this behavior? should i just leave it at 'plar' or should it really be 'plar opx'? I haven't noticed any side effects, yet.

Here is some of the voice config:

dial-peer voice 2000 voip

description ** cue voicemail pilot number **

destination-pattern 800

b2bua

session protocol sipv2

session target ipv4:10.1.10.1

dtmf-relay sip-notify

codec g711ulaw

no vad

dial-peer voice 2001 voip

description ** cue auto attendant number **

translation-profile outgoing PSTN_CallForwarding

destination-pattern 801

b2bua

session protocol sipv2

session target ipv4:10.1.10.1

dtmf-relay sip-notify

codec g711ulaw

no vad

dial-peer voice 50 pots

description ** incoming dial peer **

incoming called-number .%

port 0/1/0

dial-peer voice 51 pots

description ** incoming dial peer **

incoming called-number .%

port 0/1/1

dial-peer voice 52 pots

description ** incoming dial peer **

incoming called-number .%

port 0/1/2

dial-peer voice 53 pots

description ** incoming dial peer **

incoming called-number .%

port 0/1/3

dial-peer voice 54 pots

corlist outgoing call-local

description ** FXO pots dial-peer **

translation-profile outgoing CALLER_ID_TRANSLATION_PROFILE

preference 5

destination-pattern 9[2-9]......

port 0/1/0

forward-digits 7

no sip-register

dial-peer voice 55 pots

corlist outgoing call-domestic

description ** FXO pots dial-peer **

translation-profile outgoing CALLER_ID_TRANSLATION_PROFILE

preference 5

destination-pattern 91[2-9]..[2-9]......

port 0/1/0

prefix 1

no sip-register

dial-peer voice 56 pots

corlist outgoing call-international

description ** FXO pots dial-peer **

translation-profile outgoing CALLER_ID_TRANSLATION_PROFILE

preference 5

destination-pattern 9011T

port 0/1/0

prefix 011

no sip-register

dial-peer voice 57 pots

description ** FXO pots dial-peer **-Emergency dial-peer

translation-profile outgoing CALLER_ID_TRANSLATION_PROFILE

preference 5

destination-pattern 9911

port 0/1/0

forward-digits 3

no sip-register

dial-peer voice 58 pots

description ** FXO pots dial-peer **-Emergency dial-peer

translation-profile outgoing CALLER_ID_TRANSLATION_PROFILE

preference 5

destination-pattern 911

port 0/1/0

forward-digits 3

no sip-register

dial-peer voice 59 pots

corlist outgoing call-local

description ** FXO pots dial-peer **

translation-profile outgoing CALLER_ID_TRANSLATION_PROFILE

preference 5

destination-pattern 9[2-9]11

port 0/1/0

forward-digits 3

no sip-register

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
mciarfello Sat, 07/12/2008 - 22:03

From:

http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_c4_ps1839_TSD_Products_Command_Reference_Chapter.html#wp998575

Specifies a PLAR off-premises extension (OPX) connection. Using this option, the local voice port provides a local response before the remote voice port receives an answer. On Foreign Exchange Office (FXO) interfaces, the voice port does not answer until the remote side has answered.

From me:

If you didn't have any of the PLAR commands on the voice-port then the router will answer the incoming call after the first ring and present a dial-tone. (two-stage dialing.) The router is in essence expecting DTMF digits to be played. You can manually dial an extension to ring the final IP Phone.

You are not looking for that. The PLAR command will pickup the voice-port after the first ring then send the digits of the plar command to the router--matching an incoming-called number command.

OPX prevents the Voice-port from going off-hook after the first ring. It will only go off hook after the IP Phone goes off hook

This is useful when other devices share the POTS line, like an answering machine or cordless phone, which might want to answer the phone by themselves.

But may not work for hunt-groups or other entities that don't send an off-hook message.

So regular plar is fine.

Paolo Bevilacqua Sun, 07/13/2008 - 02:55

Michael,

actually hunt-groups and all cisco "entities" do "send an off-hook message" when the calls is answered.

If you are using an hunt-grop without AA, it's correct to use OPX so that caller will not be charged for non-answered calls.

I think the problem is due to some bug in the IOS used, CUE AA should take a forwarded calls even if OPX was specified.

So depending if you want to give caller the chance of hanging up before going to VM without being charged, you would use OPX as well.

In any case VM and FXO will need a supervisory disconnect configuration, but that's another issue.

Actions

This Discussion