This is a TCL/IVR script that uses a file with a list of numbers and names to make so your caller's name is displayed on the phone when receiving a call from a number in the list.
The file must reside in flash. This is because the "file" command that I use in the script fails for tftp. There is also a version what works via HTTP queries.
The file is accessed for reading on the first call only, so it should be possible to handle very large lists.
To reload a the file, do:
show call application sessions
call application session stop id <ID-from-show>
Update. The script can now be acquired at ciscoscripts.com
I was just looking for something similar! Can you give us information about model of the router and the IOS version you have tested it with.
this is supposed to work on any platform where TCL/IVR 2.0 and up is supported.
I do use ISRs for testing.
Let me know how it works for you.
I have still problems with consultative call transfer if I use your script. A (external) calls B B transfers to C (consultative). After pressing the transfer-button on phone B. Both calls are still on hold.
Could you already test that? Have you a solution?
I was in the believing that the service was not to interfere with call transfer. I'm away from my systems, it can be sometime before I can go back to that, but I will.
Thanks for letting me know!
I greatly appriciate the effort you putted into this. Is there any change you will further develop the script to do http queries on the fly?
Also I mentioned that you created another version of the script, which handles the DNIS/ANI another way, but I can not find the threath in which you explain why you made this changes.
Again, thanks a lot for all the effort.
No I never developed the http queries for lack of real need now.
Not sure about another way of handling ani/dnis, ani drives the name search and dnis the outgoing dp where the call goes.
I do mean that I saw another version of this .tcl on your website. What are the differences?
http requests would be real cool
Ah, that was not supposed to be seen, it's a modification for a T1 CAS that presents ani/dnis in a peculiar format. So far, that's the only case I've seen.
If someone can write the http server side, I won't take much time for me to adapt the client.
Thanks for the appreciation!
As you might have noticed I am a big fan of your CME additions :-) so sorry for taking a look in your back garden.
HTTP server side off course could be very flexible. We only would have to make some agreements about the format. I would suggest an parameter in the script where you put can put the ani as a variable, like:
param http_ani_get http://server/anirequest.asp?getnamefor=$ani
Any suggestions for return format? Going VXML-style with addiotional info, or simple HTTP answer containing Unknown vs 'Name of Caller'.
Yes that would be exactly the method. Query can also be basic64 authenticated.
I would think that for simplicity, just have a simple string in reply.
Are you considering tying the names database to MS AD ? That is probably what most people would like,
In any case if you can place the server on a reachable IP, I'll patch the client, quickly test, and release for the community.
I set up a quick test:
Valid entries are;
If other numbers are entered, you get a reply with the same number returned. If you need modications, just let me know.
Ok, done and quickly tested:
I would need the server to have authentication, the code is in the client but I'm too lazy to debug it now.
The script seems to work fine. However, tranfering doesn't work anymore if the script is configured under an incoming dialpeer.
I noticed that you replied in another topic about tcl and transfering a call. What is the story about it? Why doesn't it work?
Hmmm normally TCL/IVR scripts work exclusively under incoming DP... if you managed to have working for outgoing, let us know how you did ..
Transfer in TCL/IVR is a whole story in itself. The programming manual dedicates some 30 pages about that topic only.
The bottom line, either the script does a "leg setup" and then handles the transfer request with code similar to the one I wrote (that is the absolute minimum), or it can "handoff" to the default session application, this way the script is not involved anymore when there is a transfer request. That is the method used by B-ACD/AA when transferring to extension.
I do not understand what you mean with 'if you managed to have working for outgoing, let us know how you did'
I only have it working on incoming DP, the name shows up in the display so lookup works.
While I was tranfering an incoming ('looked-up') call to check if the DisplayInfo(name) was kept, I noticed that while completing the tranfers, the originating call is disconnected.
However, because I can not see the script running (sh call appl sess), I was assuming that you, after running the script, handled over to the default sess application.
Can you tranfer an incoming 'looked up' call?
Ok, evidently I broke the transferring support, not surprising considering I didn't test that.
Will fix and let you know. Can you add basic authentication to the test server ?
The following url should do the job:
Just let me know
nice work! Name however doesn't seem to survive a transfer? (doesn't show up in the screen of phone to which call is transfered?)
Transfer is a strange thing. You can see that scripts copies back the name in the display field when transferring. Then if doesn't show I'm not sure what I should do.
On the other not even when doing transfer with phones the name/number of the original caller shows.
Is the reason why it is difficult to make an outgoing TCL/IVR because you can't handle over to some default session app?
I was just coming to the idea of an outgoing version of the script as it is. That way a caller would see the same of the called person in his screen while establishing an outgoing call.
Also I am thinking of something like an 'external bulk speeddial list' by which TCL would send http query with the speeddial (eg *9123) and then return both the name and E164 number of the destination and establishing the call.
Your note about difficult outgoing TCL/IVR however makes me consider..
When you do handoff to the default application, the only parameter that I'm sure you can set, is the destination number as a kind of environment variable. See, B-ACD/AA does like that. I don't know if one would be able to pass a calling name.
Also I'm not sure if you would be able to update the display on the caller phone. I think that a good xml directory service is better for that.
You can have "outgoing" tcl scrips, that is they make calls, in fact number2name belongs to this category.
The complication came when you want to hook the script to an outgoing DP with the command "service xxx outgoing". This require some script linking that honestly I did not quite understood. So I'm happy with scripts triggered by incoming DP only for now.
Considering the handling by default session application; I am quite sure there is a different in this since 12.4(11)XW /cme4.2 and BACD 18.104.22.168. With CME4.0 you couldn't see the name of the phone that was ringing if you called BACD. In cme4.2 it does, the same like when calling a normal hunt-group. The display is updated every time a call switches over to the next hop.
Ok, but b-acd/aa does not contain "leg callerid" commands, so the display update working is probably due to some IOS internals improvement.