Single Number Reach Problem

[artieman209]

I am having a problem with single number reach not pulling the call back to voicemail.

Basicly I call the extension and it does go to the desk phone and calls out to the cell phone. The problem is after 15 seconds its not sending it to the extension for voicemail.

ephone-dn  47  octo-line

number 210 no-reg primary

label Tom - 210

description Tom

name Tom

mobility

snr 96200001 delay 5 timeout 15 cfwd-noan 777

call-forward busy 777

call-forward noan 777 timeout 15

Any ideas? The system is a uc520 with the lastest software pack.

[mcasimirc63]

SNR does not work with FXO lines.

"Call forwarding of unanswered calls, configured with the cfwd-noan keyword in the snrcommand, is not supported for PSTN calls from FXO trunks because the calls connect immediately."

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmesnr.html

[paolo bevilacqua]

With as much I try to avoid FXO, I fail to understand what is the logic of "because the calls connect immediately". There are many cases in which an already connected calls is then forwarded.

[Albert Wilhelm]

Hello Arthur,

Marcus make a good point re FXOs. We use PRI circuits and SIP trunks with our clients and have deployed SNR successfully. On your snr line, try to increase the timeout for cfwd-noan to beyond the call-forward noan timeout. See the config below with the areas bolded.

ephone-dn  35  octo-line

number 226 no-reg primary

pickup-group 1

label Bert 226

description Bert Wilhelm

name Bert Wilhelm

mobility

snr 95551212 delay 5 timeout 25 cfwd-noan 399

call-forward busy 399

call-forward noan 399 timeout 20

translation-profile incoming CallBlocking

Hope this helps.

Bert Wilhelm

[David Trad]

Hi Guys,

SNR does work with FXO, but there are inherent problems that need to be considered when deploying SNR on an FXO based system.

1. With FXO lines generally the calls is received by the system imediatly, but not answered until about the second ring... This needs to be factored into the SNR timers as well
2. When an inbound call comes in on an Analogue Trunk (FXO) and then a second "B" leg is done over another Analogue trunk (Same System) you will get locked ports as often more than not there is no proper clear down procedure with FXO lines as there are with say PRI/BRI or SIP... This issue alone makes SNR on an Analogue system a dangerous proposition, consider maybe obtaining a SIP trunk and forwarding all SNR calls over a SIP trunk, you will find that this will make much more easier for you

The other thing to remember that if you want SNR to go to the local VM then its NOAN has to be less than the DN's NOAN otherwise your SNR destination may beat the system to the punch.

Just thought to throw my opinion into the mixed bag already

Cheers,

David.