I had a similar issue where phones behind an SRST integrated with Call Manager had the same behaviour.

In my case (and perhaps yours) CFwdAll was dependant on what the CSS was set to on the Directory Number >

Call Forward and Call Pickup Settings > Forward All line.  In my case it had defaulted to "None", and I had to  map it to the CSS that in turn mapped to the same partition my other phones were in.

HTH

Jason

Thank you Chris for your reply. Below are the configurations you ask.

call-manager-fallback

secondary-dialtone 9

max-conferences 8 gain -6

transfer-system full-consult

timeouts interdigit 4

ip source-address 10.16.0.10 port 2000

max-ephones 100

max-dn 100 octo-line

transfer-pattern .T

keepalive 10

alias 1 184 to 221          // 221 is the extension on reception phone, 184 is the AA number during normal operation

call-forward pattern .T

call-forward busy 221

call-forward noan 221 timeout 20

------------------------------------------------------------

dial-peer voice 1000 voip

preference 1

destination-pattern [23]..

modem passthrough nse codec g711ulaw

session target ipv4:10.16.0.7

voice-class codec 1

dtmf-relay h245-alphanumeric

fax rate disable

no vad

!

dial-peer voice 2000 pots

destination-pattern 9.T

incoming called-number .

direct-inward-dial

port 0/0/0:23

!

dial-peer voice 911 pots

destination-pattern 911

incoming called-number .

port 0/0/0:23

forward-digits all

!

dial-peer voice 9911 pots

destination-pattern 9911

direct-inward-dial

port 0/0/0:23

forward-digits 3

What is 10.16.0.7, is this local CUE module or something?

Can you do "debug voice dialpeer" for a test call?

Chris

10.16.0.7 is CallManager IP. I will debug dialpeer when testing the SRST today.

if that is CUCM then how do you expect to reach it under SRST condition as that is where you'r 221 call forwarding is pointing to?

Chris

If I understand correctly, a dial-peer will be created for each extension when phones register with gateway under SRST mode.

For example, the reception extension 221, forward to 244.

Call-forward is not working when using CFwALL softkey. It works fine when transfering a call manually.

Can you enter the callFwdAll destination, or do you get fast busy, etc when you enter it  on the phone?

Dear

i think you have the problem  when you use forwad  you still stay forwarded and will that keep working.The call forwad for SRST can be workinf for cisco IP phones unregistered (The phone is "unregistered":  Which means the phone had a healthy registration in the recent past. Please find the below scinario

When CUCM is down :

The phone with DN 2000 goes offhook and dials 3000 to reach the site RS1

step 1

Since RS1 is in SRST mode, all phones at that site have the status of "unregistered" from the CUCM cluster point of view.  Given this state of affairs, the CUCM call processing node handling DN-2000's call setup request will pass the call decision process to the ForwardManager sub-process for a call routing decision.  The ForwardManager will determine that DN-3000 has a Call Forward Unregistered (CFUR) setting of "92025553000".

Thank you

please rate , if this usefull

This is not what I'm referring to, maybe this will detail it a bit better:

User owning DN2000 located at a remote site sets the phone using the CFwdALL softkey to forward all calls to 555-555-1234.

PSTN calls to DN2000 correspondingly forward to 555-555-1234.

The remote site that DN2000 is located at loses connectivity to CUCM, when the phone with DN2000 registers to the SRST gateway the CFwdALL configuration is not retained.  The result is that calls from the PSTN to DN2000 do not forward to 555-555-1234 they end up following call forward no answer and end up in voicemail.