×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

How to elegantly get 80 Openning Greetinsg to Alternate Greetings

Unanswered Question
Jan 7th, 2004
User Badges:
  • Cisco Employee,

School Commission has setup CM and Unity (3.X.X) where they have some 80 different schools all identified/addressed by their own DIDs (ie. 80 DIDs).


After some programming of the Call amd Directory handlers they were able to setup in the Call Routing Rules Table these 80 DIDs each pointing to the Openning Greeting of that school. Done and works like a charm.


Now during a school snow storm (in Quebec, Canada of course), they want to have special greeting played for each School (ie. Alternate Greeting say).


How can this be done as elegantky as possible avoiding the need to have to redine 80 Alternate Greetings messages...too long.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
lindborg Wed, 01/07/2004 - 10:39
User Badges:
  • Cisco Employee,

Hmmm… that one’s a bit tricky. There _is_ a plan that’s crazy, but it just. Might. Work.


There’s a little known (and undocumented) feature in Unity that lets you insert variables into the transfer strings off of call handlers/subscribers – I talk about this a bit in the ‘audio text applications in Unity’ paper on the Documents page of www.CiscoUnityTools.com. The short story is you can insert the forwarding number, calling number, dialed number, trunk or port into the transfer string using a format that looks like this “%Dialed_Number%” as the transfer string. You can include other digits on either side of the percent sign and strip off the left/right most digits and other fun stuff.


So… what you might be able to do is setup a single call handler that _direct_ calls to all those DID lines all go to – this plays a generic “snow day’ greeting or, in the case of no problems, a blank greeting and then goes to a transfer call handler that sends the call to the DID number the user dialed. Then you’d have routing rules that say if the call comes from the range of extensions that Unity is assigned to AND are directed at the DID number, it goes to the handlers you have now. You should be able to edit the existing routing rules you have to simply include the provision that the call comes from one of the Unity ports and add a new routing rule at the bottom that says all calls to those range of DID lines (regardless of their source) goes to this routing call handler.


I have never tried this type of thing myself – but it _should_ work – this is precisely the type of scenario we added that variable insertion logic for. If it’s a CM integration it should whip through that handler and get to the next handler quickly – if it’s a legacy switch there may be a bit of a delay. You’ll also want to make sure to ditch the “please hold on while I transfer your call” prompt there so the caller experience is a bit more smooth.


amastroi Wed, 01/07/2004 - 11:02
User Badges:
  • Cisco Employee,

Nice, I will suggest it and try it out.

:))

amastroi Tue, 01/13/2004 - 11:30
User Badges:
  • Cisco Employee,

OK so we went ahead and are testing with this suggestion in the lab but are stuck at the point when we have a Call Handler just for Transfer from SNOW_DAY Greeting with Variable dialed number.


Problem is that Unity then tries to Transfer to Variable "Dialed Number"and of course this is sent to CCM but CCM recieves it but never sends it back to Unity (as a Forwarded call of course).


Error in CCM Trace :Sends a Re-order tone to Unity essentially.


...So stuck at this point.

amastroi Tue, 01/13/2004 - 12:27
User Badges:
  • Cisco Employee,

We did more testing and it seems that when why use same logic for Transfer Call Handler just for Transfer from SNOW_DAY Greeting BUT WITHOUT Variable "Dialed_Number" or even "Forwarding_Station" all is well.


Therefore seems that Variable expressions are cleared or not passed at all between Call Handlers



__________________________

Caller1500 call 8400 , CCM just CFA to VM

Routing Rules intercept Fwd(Uncon) 8400 and send to SnowDay

SnowDay play his greeting and after greeting action .. : Attempt Transfert to SnowDayTransfertOnlyCH


Between the time, the call is routed, and finally transfered ... the Variable are somewhere cleared to $null .

lindborg Tue, 01/13/2004 - 13:49
User Badges:
  • Cisco Employee,

Hmmm... - the variable info may get cleared along with the "First transfer" flag that ensures we over ride the transfer for forwarded calls that hit Unity so we don't get in a transfer loop when we bounce to the 2nd handler - I'll have to dig around.


So you tried a transfer off the first handler it hits using the variable insersions and it worked but when you hand off to the 2nd handler it doesnt? I'm not sure I followed your testing scenario here.


I just wanted to make sure the forwarding station/dialed number values were properly filled in when the call initially hits Unity - you can check this by looking at Call Viewer when the call comes in. But if you got it to work on a single hop but it fails on a 2nd hop then that pretty much rules out any problems there.



amastroi Tue, 01/13/2004 - 18:11
User Badges:
  • Cisco Employee,

Actually Jeff we even tried just with the one single Transfer Call Handler...using the variable expression and even then NO LUCK.


In the Transfer Page used:


"%Dialed_Number%" -no luck

"1500" -works, call transferred to 1500

"%Dialed_Number%1500 -transfers call to 1500


Therefore even with and only with the "First Transfer" , variables are not being passed...or are being cleared.

lindborg Tue, 01/13/2004 - 18:50
User Badges:
  • Cisco Employee,

can you verify with the call viewer (you'll find this in the tools depot on your desktop) that the dialed number is being filled in on the call object on incoming calls? From your description it sounds like maybe it's not and that's the problem...

amastroi Tue, 01/13/2004 - 19:30
User Badges:
  • Cisco Employee,

Indeed Jeff we can verify this for you using the Call Viewer and get back to you...no problem


However, keep in mind that we have been using instead your other tool "Port Status Monitor" and we have kept seeing that the dialed number (for us 8400) was in fact being filled in on the incoming calls....


Would the results then of using the "Port Status Monitor" be as conclusive as using Call Viewer?

5mgagnon Wed, 01/14/2004 - 06:36
User Badges:

Hi Jeff,


I was with Tony yesterday, testing this in my lab.


To resume our very last test :

We got the "SnowDay" CH configured to transfert instead of playing the greeting. In the routing rules, we got the rules set to "send to greeting" of "SnowDay" CH.


With the %Dialed_Number% var, CCM wait for digit, then send re-order to Unity.


With "1500" DN, CCM forward the call back to Unity (as set in the CFA Option of the "dummy phone"), We can see in the CallViewer, the call coming back on the Second UNITY Port, with the Calling number tag to Unity Port DN.


So, It's like the Var are cleared after the "Call Routing" function.


I hope this will help.


Another question was about the "Wait before I transfert your call message". In the port Monitor, we can see a message that look like main() look is a flag is set before playing the message. If there a way to configure this flag to "False" by default for CallHandler only, Subscriber only, or Both. Or, a way to control to flag as a "per CallHandler" basis from the web page ?


Anyway .,.. for the moment, the main concern is the "cleared" %var%


Thanks !

Martin Gagnon


lindborg Tue, 01/27/2004 - 10:04
User Badges:
  • Cisco Employee,

OK... follow up to this (no, I didn't forget about you). The conversations guys found the bug - it was introduced during the over haul for SIP support a couple versions ago. The conversations will only recognize those insertion variables in all CAPS (i.e. "%DIALED_NUMBER%"). However the SA only recognizes them as you have them in this thread. Problem.


The conversations guys will have a fix for this that will be published with 4.0(4) and will also be available as an ES on 4.0(3). In the meantime you can get around this by using DOHPropTest to enter the transfer number with all caps for the insertion variable - we tried this in house and it seems to work fine that way.


If you want to go that route, let me know and I'll follow up with detailed instructions on using DPT for this purpose.

amastroi Tue, 01/27/2004 - 15:21
User Badges:
  • Cisco Employee,

OK...Jeff will try it out this way and let you know.


"In Jeff we Trust"!

5mgagnon Tue, 01/27/2004 - 20:24
User Badges:

Hi Jeff,


Thanks for the reply.


Please, follow up to Tony for the DPT instruction .


Will get a try in labs by the end of the week !


Martin


amastroi Tue, 02/03/2004 - 13:31
User Badges:
  • Cisco Employee,

Jeff,


Still standing by DEFINITELY I want to go that route, so let me know about the detailed instructions on using DPT for this purpose.


lindborg Tue, 02/03/2004 - 15:13
User Badges:
  • Cisco Employee,

The conversations guys have a fix for it and it's in the 4.0(4) line - there's an ES for 4.0(3) being put together but it hasn't been tested by QA yet.

Doing this in DOHPropTest isn't too hard - open up DOHPropTest with today's password (100-2)(2+3)="985".

Select call handlers in the left column (after DPT loads completely - it takes a minute or two sometimes). Then select the call handler you want to test with in the middle column. Then select "AVP_CONTACT_RULES" in the properties column on the right. This will bring up the contact rules dialog. Select which contact rule you want (presumably Alternate) and assuming you've setup that contact rule in the SA for transfer you can just go to the AVP_EXTENSION property, force the variable name to be all caps in the value at the bottom and then press "SET" - it'll store it in all caps for you.

This is good for testing but not real practical for deployment since the SA will crab about that string format if you change something there later in the SA and the like.


BTW, the DDTS opened for this that the conversations guys worked off of is:


http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCed49945&Submit=Search


the release notes will be updated with information about a 4.0(3) ES for this once it's tested and available.

Actions

This Discussion