Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Users might experience few discrepancies in Search results. We are working on this on our side. We apologize for the inconvenience it may have caused.
New Member

Internal Greeting Integration

Jeff,<br><br>I am setting up a Unity Enterprise with DTMF inband integration. (Bosch Integral 33XE.) Everything works fine, except the internal greeting.<br><br>Regarding to the avanalog.avd, the integration line should be include the I (internal) and the F (Forwarded). I used the following line: Data7 = 8F#I# NOANSWER<br><br>The expected DTMF tones are received, used the integration monitor to check this.<br><br>Of course the internal greeting is enabled and recorded. <br><br>The system still plays the STANDARD greeting.<br><br>What am I doing wrong?<br><br>Jos<br><br><br><br>


Re: Internal Greeting Integration

Hey Jos.

You’re not doing anything wrong, but I think I know what the problem is. The “I” does not stand for “internal”… it means “Incoming”. This is the calling party which could be an internal extension or an external calling number.

Unlike digital integrations which give us loads of details on the incoming call, analog integration generally are pretty lite on the info. As such there isn’t a specific designation for a call that originated on the local PBX or one that’s coming externally. Things get complicated even in digital integration land when you start talking about networked switches and the like… what, really, is an “internal” caller? The idea behind the internal greeting is that I can impart some information such as where I’m REALLY at to my coworkers that I don’t want external folks hearing. If someone is in the lobby, for instance, and calls my extension, do I want them to hear that I’m out visiting their competitor at the moment? Probably not…

So, we got around this by making a simple rule: If the calling party number matches the DTMF_ID of a subscriber in our directory, we consider the call “internal”. If the calling number does not have a match, it’s considered external. This way we’re not reliant on the switch to specifically tell us it’s an internal vs. external call and we avoid embarrassing missteps when external people are using internal lines.

So, in your example, you have “8F#I# NOANSWER” in your AVANALOG.AVD file, which is fine. The integration monitor will show “internal” as the call origin (it defaults to internal on the display unless it’s specifically over ridden which for analog integrations wont happen unless you have an ANI configuration setup for caller ID on external calls). However I’m willing to bet the calling number column shows a number that doesn’t correspond to the extension of a subscriber in your system.

I tried this out on my 2.4.0 120 box by setting up a subscriber for extension 301 and one for extension 302. I used the same packet definition you have and I entered “8301#302#” (if you don’t have fast fingers, crank of the digit delay times if you want to test this by hand) and I got the internal greeting for the user at 301. If, instead, I entered “8301#333#” I get the standard greeting of 301 since there is no subscriber for 333. The integration monitor shows the same thing for both (other than the calling number is different)… a little confusing, I know…

If that’s not the case, you have something squirrely going on somewhere and we’ll need to take a closer look.

Jeff Lindborg
Unity Product Architect
Active Voice

CreatePlease to create content