Easy, huh?
Well, there was one big challgene which turned up pretty late:
While the provider was able to forward the old number, he could only forward all DIDs to the same new number. While this was acceptable for enduser DIDs this meant some trouble for the old fax number.
Since the old fax number was quite important (orders...) we had to find a way to deal with both human callers as well as the fax messages, all coming to the same number.
We decided on using a callflow which goes like this:
- Play a prompt which informs the caller that the number has changes
- During this prompt the router should run CNG detection. This means, if it detects a T.30 fax tone we should jump to special fax handling section
- After the prompt, transfer the caller somewhere else
Luckily this was quite easy to implement with cisco voicexml. Let's assume the following things:
1.)The old number was 9988776600 , so forwarded calls will have a redirecting number of "9988776600"
2.)The new main number is : 1122334400
3.)The new fax number is: 1122334499
The header section just tells that this is a voicexml document
<?xml version="1.0" encoding="iso-8859-1"?>
<vxml version="2.0">
The following section is a variable assignment. We do save the value of the redirecting number of the call into the variable theRDNIS. We do this so we can later check if this call was redirected from the old number or wether it was a call to the new number.
<var name="theRDNIS" expr="session.telephone.rdnis"/>
What follows now is the event handler for the CNG tone. If the script detects a CNG tone we do ouput a log messages (which we can output on the dateway via debug voip application vxml puts and then run a goto to the form with the name "FaxTrans".
<catch event="com.cisco.fax.cng">
<log>!!!!!!! Got com.cisco.fax.cng !!!!!! </log>
<goto next="#FaxTrans"/>
</catch>
Now we move into the form for the call Transfer
<form id="CallTransfer" scope="dialog">
<block>
<log> RDNIS is <value expr="theRDNIS"/></log>
</block>
Now follows a block that only runs if the Redirecting number is equal to the value 9988776600
Inside of the block we play a prompt "oldoffice.au" If at any point during the prompt a CNG tone is detected, the script will jump to the CNG tone event handler above.
<block cond="theRDNIS=='9988776600'" >
<prompt bargein="true"> <audio src="flash:oldoffice.au"/></prompt>
<goto next="#IVR_call"/>
</block>
Now a form for a transfer to the real reception number, we could also use event handlers to handle cases like busy now answer etc. (which we did in the real deployment) <transfer name="IVR_call" type="blind" dest="phone://1122334400" bridge="true">
<filled>
</filled>
</transfer>
</form>
Finally the fax form which initiates the final transfer of the fax to be handled via T.37. This also needs a MMOIP dialpeer on the router
<form id="FaxTrans" scope="dialog">
<transfer name="FAX_CALL" type="blind" dest="fax://1122334499" bridge="false" />
</form>
</vxml>
So that is it, pretty easy.
To make it work, we need some config on the router as well:
First we need the config to load the vxml. If we put the script above into a file on the router flash called oldoffice.vxml we would define it like this:
application
service oldoffice flash:oldoffice.vxml
!
service oldoffice flash:oldoffice.vxml
!
Then we need an incoming dial-peer that runs the script:
dial-peer voice 1000 pots
service oldoffice
incoming called-number 1122334400
!
and finally we need a outbound mmoip dial-peer so the e-mail can be delivered somewhere:
dial-peer voice 2000 mmoip
service fax_on_vfc_onramp_app out-bound
destination-pattern 1122334499
information-type fax
session target mailto:fax@company.com
!
You will also need the normal T.37 fax config as described in the cisco docs
If the IP phones have already downloaded their configuration files after you have configured the proxy server, you must restart the IP phones so that they get the configuration file with the proxy server address in the file.