Have an odd issue where cfwdall only works if you are calling from an internal extension. If you place a call from an outside phone the forward doesn't happen. If you place the call from an internal extension the call forward happens.
Outside caller --- reception phone (1001) --- cfwdall ---- different phone (1002) (this does not work)
inside caller --- reception phone (1001) --- cfwdall ---- different phone (1002) (this works)
I do have the css set for the forward all on the line. The reverse works, if you want to call forward all to an outside number that works fine.
Sure there is, device pool is a mandatory attribute and controls several gateway parameters including local route group. Perhaps you are using default DP which may not be a good idea for reasons you are encountering.
Sent from Cisco Technical Support iPhone App
Yes, I am using the default DP. I am using various different DP's for all of my phones and have specified a local route group that points to a local srst router, so that those phones have a path to the local pstn for use for 911. But I have not used a device pool for a gateway.
Still don't see why I need a device pool....specifying a local route group would allow me to do what? Sorry I don't quite understand how this has to do with call forward all not working.
Maybe I should be more clear.
Outside caller (555-555-1234) - calls in to our PSTN number (555-555-9999) --- PRI router matches our number and call is forwarded to the UCM server. Translation pattern machines the PSTN number and the "called party transformation mask" directs the call to the reception's phone (1001). If the reception phone is cfwdall to (1002) it still rings on (1001) and not on (1002).
If I call (1001) from my phone (1003) it is cfwdall to (1002) like it should be.
I'm not understanding where the device pool / route group comes in for this type of call.
You need local route group in the GW's DP because when using Route patterns that point to Local Route List --> Local Route group the routing is always based on the originating device (at least in CUCM up until version 9.0), since the call originally comes from PSTN and is never answered but call forwarded, when it hits the route pattern it looks at the local route group assigned to the device pool of the GW. If the DP does not have a local route group the call will simply fail, this works as designed.
As I stated earlier it is a good idea to build "system" site specific DP for items such as Gateways, local media resources, etc to get more routing control both inbound (via CSS on GW) as well as outbound in case local route groups are used.
HTH, please rate all useful posts!