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. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Forwarding Inbound calls based on Caller ID

Hi,

I don't find immediately an answer on our customer's question:

"is it possible to reroute some fax calls to a specific number (based on the country codes or by specific numbers) ?

For example all faxes arriving in Brussels on + 32 2 XXX XX XX from +49 YYYYYYYY (being a customer or a provider)

diverted to a number in Poland ?"

The customer has CUCM 7.1 running with a 2911 with some E1s. The fax number for EMEA is a dedicated +32 (Brussels) number.

The 2911 is in MGCP mode.

Is there a possible scenario with MGCP/CUCM 7.1? Or alternatives?

Some say you need CUCM 8.x but an upgrade is not an option for the customer now.

Some say you need a H.323 gateway.

Thanks in advance for the help.

gr

G.

3 ACCEPTED SOLUTIONS

Accepted Solutions
Hall of Fame Super Gold

Forwarding Inbound calls based on Caller ID

With MGCP, nothing is possible.

With H.323 or SIP, you can use number manipulation using answer-address, or a TCL/IVR scripts like my °number to name°, that support call calling number routing-

Forwarding Inbound calls based on Caller ID

With CUCM 7.1, Paolo is correct: you could use a SIP or H.323 gateway with answer-address or TCL. If you are stuck with CUCM 7.1 then I would choose H.323 over SIP.

With CUCM 8.x, you have the option of solving this in CUCM and can support either H.323, SIP, or MGCP. As with CUCM 7.1, you can leverage answer-address and TCL on H.323/SIP gateways. With CUCM 8.x, you can leverage the Hotline feature to configure a translation pattern that routes by calling party number. This feature allows you to make the necessary call routing decision in the CUCM. This feature can be implemented independantly of call signaling protocal to the voice GW.

I did a write-up on using the holine feature for another application (black listing), but the basic concepts are the same:

http://www.netcraftsmen.net/blogs/cisco-cucm-blocking-calls-by-calling-party-number-id.html

Also, Cisco describes the feature in the 8.0.2 Features and Services guide:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_2/ccmfeat/fshotline.html

HTH.

Regards,

Bill (@ucguerrilla)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Forwarding Inbound calls based on Caller ID

Gunther,

There are several possibilities. Assuming that the requirement is that the UCM must remain at version 7.x then I would think that the most economical and efficient method would be to look at converting your gateways to H.323 and leverage the dial-peer logic on those systems.

That being said, here are my opinions on your specific queries.

1) They also have Unity Connection 7. Isn't it possible to have an inbound fax call arriving on an UCN IVR and then have the fax message forwarded to a user inbox?

Fax messaging is not my area of expertise but Unity Connection does support integration with a fax server. The fax servers that are supported depend on your version of CUC. With 7.0, Cisco Fax Server 9.0+ is the only version supported. Cisco Fax Server is basically OEM'd version of RightFax. There have been changes/enhancements to this integration since the intial introduction was added to CUC 7.0. I am not 100% up on all of that.

I can say that with the Right Fax/Cisco Fax integration, the call is actually directed to the fax server and the fax server then delivers it to the Unity Connection mailbox via SMTP. If the fax DID is unique then this is pretty straightforward, the call processing agent (CUCM in your case) routes the call to the fax server, T.38 is engaged, and the fax server caches the message for post processing (i.e. delivery to CUC). If you want to share a DID (user has a phone DN and a fax DN that are unified) then your gateway needs to be converted to H.323 (or SIP, I guess) so that it can detect the fax tones. if it detects a fax, relay to the fax server. If it doesn't then pass to CUCM for further digit analysis.

I can only infer from your original post that the above option is not 100% in tune with expectations. You have to determine if it is or isn't adequate. See link below:

http://www.cisco.com/en/US/docs/voice_ip_comm/connection/7x/design/guide/7xcucdg080.html

2) Can we install and configure a cheap Cisco ISR (1900 or so) as a H.323 gateway and letting arrive all inbound fax calls on this device? The problem of course is that they use DDI ranges on 1 PRI...so it would be, I guess, nearly impossible to separately transmit the fax DDI numbers to this new H.323 gateway.

Plausible. In your case, you would need to feret out the DIDs associated with fax numbers and program route patterns on CUCM to direct the calls to this one-arm H.323 device. The effort on CUCM is directly related to whether the DIDs for fax number assignment is contiguous or not. I will hazard a guess and say that in your case, we are dealing with fax DIDs peppered throughout the overarching range. So, it may be a tad bit cumbersome.

From a call routing perspective, this approach is plausible. However, I have not tested this scenario (for fax, anyway) and would advise you test it out to validate that things like T.38 negotiation, media path, codec negotiation, call setup timers, and failover scnarios are fully vetted.

3) Our sales is also propising IPCC Express, via another collegue, to this customer. Would that solve the problem? (If ok, should be ordered in October or so).

I am not sure this is viable from a logistical perspective. You are running CUCM 7.1 and I believe that the only UCCX versions that are compatible with CUCM 7.1 are UCCX 7.x and 8.0, both of which are on the EoL/EoS track. The last day to order UCCX 8.0 was Nov 2011 and for UCCX 7.0 it was Apr 2011. UCCX 8.5 is not compatible with CUCM 7.x. Now, if the customer is already licensed for the software via CUWL or something then maybe you don't need to order new software and my concern is unwarranted (at least in regards to ordering). Need to do your homework on that one.

From a technical perspective, I can't recommend this approach. UCCX can make routing decisions on called/calling IE but it has to answer the call to do so. I think that answering the call and then transfering would impair the ability for the sending fax machine to do its job. However, I may be mistaken here and would defer to our UCCX forum gurus.

I will say that the UCCX proposal seems silly to me. Especially if your sales team is pushing UCCX just for this application. Given all of the options we have discussed on this thread, this is the least attractive solution. With the CUC and Cisco Fax integration fighting hard for last place.

The most economical option is to consider doing H.323 on the gateways but that may impact other call flows. So, I can't guarantee anything since I do not have full context of all requirements and operational considerations. Testing would be required to ensure that existing flows are not negatively impacted. The one-arm H.323 approach may be viable and is worth further research and (as is par for the course) should be vetted as well.

HTH.

Regards,

Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

4 REPLIES
Hall of Fame Super Gold

Forwarding Inbound calls based on Caller ID

With MGCP, nothing is possible.

With H.323 or SIP, you can use number manipulation using answer-address, or a TCL/IVR scripts like my °number to name°, that support call calling number routing-

Forwarding Inbound calls based on Caller ID

With CUCM 7.1, Paolo is correct: you could use a SIP or H.323 gateway with answer-address or TCL. If you are stuck with CUCM 7.1 then I would choose H.323 over SIP.

With CUCM 8.x, you have the option of solving this in CUCM and can support either H.323, SIP, or MGCP. As with CUCM 7.1, you can leverage answer-address and TCL on H.323/SIP gateways. With CUCM 8.x, you can leverage the Hotline feature to configure a translation pattern that routes by calling party number. This feature allows you to make the necessary call routing decision in the CUCM. This feature can be implemented independantly of call signaling protocal to the voice GW.

I did a write-up on using the holine feature for another application (black listing), but the basic concepts are the same:

http://www.netcraftsmen.net/blogs/cisco-cucm-blocking-calls-by-calling-party-number-id.html

Also, Cisco describes the feature in the 8.0.2 Features and Services guide:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_2/ccmfeat/fshotline.html

HTH.

Regards,

Bill (@ucguerrilla)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

New Member

Forwarding Inbound calls based on Caller ID

Thanks William and Paolo,

I'll certainly use your info in my reply to the customer.

I am still thinking about a solution

1) They also have Unity Connection 7. Isn't it possible to have an inbound fax call arriving on an UCN IVR and then have the fax message forwarded to a user inbox?

2) Can we install and configure a cheap Cisco ISR (1900 or so) as a H.323 gateway and letting arrive all inbound fax calls on this device? The problem of course is that they use DDI ranges on 1 PRI...so it would be, I guess, nearly impossible to separately transmit the fax DDI numbers to this new H.323 gateway.

3) Our sales is also propising IPCC Express, via another collegue, to this customer. Would that solve the problem? (If ok, should be ordered in October or so).

Thanks again for the help.

gr

G.

Forwarding Inbound calls based on Caller ID

Gunther,

There are several possibilities. Assuming that the requirement is that the UCM must remain at version 7.x then I would think that the most economical and efficient method would be to look at converting your gateways to H.323 and leverage the dial-peer logic on those systems.

That being said, here are my opinions on your specific queries.

1) They also have Unity Connection 7. Isn't it possible to have an inbound fax call arriving on an UCN IVR and then have the fax message forwarded to a user inbox?

Fax messaging is not my area of expertise but Unity Connection does support integration with a fax server. The fax servers that are supported depend on your version of CUC. With 7.0, Cisco Fax Server 9.0+ is the only version supported. Cisco Fax Server is basically OEM'd version of RightFax. There have been changes/enhancements to this integration since the intial introduction was added to CUC 7.0. I am not 100% up on all of that.

I can say that with the Right Fax/Cisco Fax integration, the call is actually directed to the fax server and the fax server then delivers it to the Unity Connection mailbox via SMTP. If the fax DID is unique then this is pretty straightforward, the call processing agent (CUCM in your case) routes the call to the fax server, T.38 is engaged, and the fax server caches the message for post processing (i.e. delivery to CUC). If you want to share a DID (user has a phone DN and a fax DN that are unified) then your gateway needs to be converted to H.323 (or SIP, I guess) so that it can detect the fax tones. if it detects a fax, relay to the fax server. If it doesn't then pass to CUCM for further digit analysis.

I can only infer from your original post that the above option is not 100% in tune with expectations. You have to determine if it is or isn't adequate. See link below:

http://www.cisco.com/en/US/docs/voice_ip_comm/connection/7x/design/guide/7xcucdg080.html

2) Can we install and configure a cheap Cisco ISR (1900 or so) as a H.323 gateway and letting arrive all inbound fax calls on this device? The problem of course is that they use DDI ranges on 1 PRI...so it would be, I guess, nearly impossible to separately transmit the fax DDI numbers to this new H.323 gateway.

Plausible. In your case, you would need to feret out the DIDs associated with fax numbers and program route patterns on CUCM to direct the calls to this one-arm H.323 device. The effort on CUCM is directly related to whether the DIDs for fax number assignment is contiguous or not. I will hazard a guess and say that in your case, we are dealing with fax DIDs peppered throughout the overarching range. So, it may be a tad bit cumbersome.

From a call routing perspective, this approach is plausible. However, I have not tested this scenario (for fax, anyway) and would advise you test it out to validate that things like T.38 negotiation, media path, codec negotiation, call setup timers, and failover scnarios are fully vetted.

3) Our sales is also propising IPCC Express, via another collegue, to this customer. Would that solve the problem? (If ok, should be ordered in October or so).

I am not sure this is viable from a logistical perspective. You are running CUCM 7.1 and I believe that the only UCCX versions that are compatible with CUCM 7.1 are UCCX 7.x and 8.0, both of which are on the EoL/EoS track. The last day to order UCCX 8.0 was Nov 2011 and for UCCX 7.0 it was Apr 2011. UCCX 8.5 is not compatible with CUCM 7.x. Now, if the customer is already licensed for the software via CUWL or something then maybe you don't need to order new software and my concern is unwarranted (at least in regards to ordering). Need to do your homework on that one.

From a technical perspective, I can't recommend this approach. UCCX can make routing decisions on called/calling IE but it has to answer the call to do so. I think that answering the call and then transfering would impair the ability for the sending fax machine to do its job. However, I may be mistaken here and would defer to our UCCX forum gurus.

I will say that the UCCX proposal seems silly to me. Especially if your sales team is pushing UCCX just for this application. Given all of the options we have discussed on this thread, this is the least attractive solution. With the CUC and Cisco Fax integration fighting hard for last place.

The most economical option is to consider doing H.323 on the gateways but that may impact other call flows. So, I can't guarantee anything since I do not have full context of all requirements and operational considerations. Testing would be required to ensure that existing flows are not negatively impacted. The one-arm H.323 approach may be viable and is worth further research and (as is par for the course) should be vetted as well.

HTH.

Regards,

Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

1875
Views
10
Helpful
4
Replies