Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

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

Lucent/Avaya Definity Gx Integration and Vectoring

I'm looking for assistance to a problem and hopefully someone out there has already solved it.

We have vectors configured on our Definity that transfer customers to certain voice mail boxes depending on the number they press from a menu. The command used to forward them to the correct voice mail box is:

messaging split 99 for extension 2058

This tells the Definity to send the call to hunt group 99 which is set up for the old voice mail system and passes extension 2058 to it so that it can play that user's greeting.

When I try to do this with our Unity integration, it simply plays the opening greeting. Everything else works fine as far as basic message taking and logging in properly.

I have tried configuring the system using both tranfer and bridging modes, which both work well for the basics, but not for this. When the call is transfered from the vector to the hunt group the forwarding extension is 0000.

Is there some other command I can use to pass the correct information from the vector to the Unity vector (in bridging mode) or maybe something else?

We are using the PBXLink and 12 port dialogic card.

Cisco Employee

Re: Lucent/Avaya Definity Gx Integration and Vectoring

When "This tells the Definity to send the call to hunt group 99 which is set up for the old voice mail system and passes extension 2058", exactly how is 2058 "passed"?

The PBXLink will parse the display (it "sees" the LCD that a digital phone has) when the incoming call arrives to determine called and calling number. I have seen that when calls are placed to a hunt group, the display that shows up doesn't have enough information to make a decision for called and calling parties.

That's why the integration guide for the PBXLink integration instructs to set up "hunting" not through a hunt-group, but through call-coverage or vectoring.

To get a better handle on what's going on, the PBXLink can show what it saw on the display as the incoming calls arrive. This display will show up on the PBXLink's LCD. The same call flow could be repeated, and you could check what shows up on the PBXLink display. If 2058 and a call reason doesn't show up, that's why Unity is playing the opening greeting.

You could even compare the difference between a "regular" forward/cover from an exension to Unity and the messaging split for the same extension to Unity on the PBXLink display; there will be a difference on that display.

Does it have to be "messaging split for extension?

Could it be "messaging split for extension? I don't know that level of detail on the Avaya.

New Member

Re: Lucent/Avaya Definity Gx Integration and Vectoring

I was just saying that hunt group 99 was the old Audix system, that's all.

I figured out a work around, here's what I did...

The vector command for messaging only gives the option to send to a split (huntgroup), so sending to a vdn# wasn't going to work.

What I did was create a hunt group for each person that needed to be transferred out of a vector to their voice mail account. I didn't put any extensions in, just the coverage path which was set to go to Unity.

I made sure that the huntgroup name contained the user's extension.

I then changed the command for for each user in vectoring to:

route-to number {huntgroup#} with cov y if unconditionally

This routes the caller to the recepients huntgroup with their extension in the group name field which would in turn go directly to the coverage path for Unity. The PBXLink picks up the extension in the group name field from the hunt group and sends them to the correct Unity account.

Thanks for your response!

New Member

Re: Lucent/Avaya Definity Gx Integration and Vectoring

I am not sure if you have solved this problem. There are multiple ways of solving this. One is, you could create a station with "x" port, say, 2058, assign a coverage path with the first point of coverage being the voicemail DN and write a vector step "route to number 2058 with cov y unconditionally" instead of the step "messaging split 99 for extension 2058". This should forward the call. The coverage path for the station 2058 should like similar to somebody's working extension, say, your deskphone. If this does not work, then write to me at and we could look at other alternatives.