Name display of DNIS on IP Phone or 5550 IP Console

[vlevalois]

Have a situation with an executive suite application where we need to associate a name with a DNIS and deliver that name to sets or a console when re-routed.

So for example 555-1212 where 51212 is the DNIS. We program a phantom DN 51212 on a buried PKM and then always re-route it to "0" for day calls. We add an entry to the Telephone Directory as "Company A".

is there any way to make this work? So far we've been unsuccessful. We've also tried name tag groups but the system sends "FROM GROUP #" + the name which leaves little room for the name really and is unusable.

Any other solutions?

Thanks.

 

[bobcheese]

Ring group? But I'm not sure if you can add consoles to a ring group

 

[LoopyLou]

or name tag hunt group

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[vlevalois]

Sorry, didn't mention this is a 3300 with MCD 5.0.

I need over a hundred entries. We tried the ACD Path route and it did not work. Turns out that there's a bug in 5.0. This is supposed to work, where you name a path in Telephone Directory, then set the console as the unavailable path destination. The console or any other phone for that matter should receive the name of the path. Hoping to get a patch today or tomorrow from product development...

 

[dryaquaman]

Try this with the ACD group:
Instead of using "path unavailable" try queuing to the path for 1 second and then over flowing.

Dry Aquaman

http://www.university-music-on-hold.com

 

[christiankarl]

Class of Service

"Calling Party Name Substitution" should be enable on receiving end.

 

[vlevalois]

For now we ended up using the DSS/BLF entries in the 5550 IP Console's software to pop up the called party name/number.

However, Mitel had suggested this as well:

-----------------------------------

DNIS is preserved when directing the call to a path.
Once it has been handled by an ACD path, it continues to preserve the DNIS when transferring to any non ACD prime or DN.

We really just need two things to happen for this to satisfy the customer’s requirements;

1. It needs to apply to non-ACD stations on any programmed DN. (see work-around below…might actually be good enough for now if we can overcome item 2)

2. The ability to associate an alpha string with the original DNIS. After my last discussion with the prospect, this is a deal breaker. (I attempted to utilize the Telephone Directory Alpha Tagging for the destination DNIS, but received and error; “Alpha tag delimiter only valid for external numbers”)

Bonus (work around):
I set up a path, programmed (0) no agents, and directed the DID to the path pilot and used the “path unavailable answer point directory number” as the initial destination. With no agents available or logged in, DNIS was preserved for all ensuing transfers to any programmed DN.

Update;

I had a few minutes to play with this further, and was able to alpha tag and preserve the DNIS using Name Tag Hunt Groups.

Unless I’ve lost my mind, this was not possible prior to running the script.

No ACD path or Agents were required as long as the COS options were set as described.

The Alpha/DNIS was preserved when transferred to any DN type and regardless of transfer hops.

The work around might suffice in this case, but adds a layer of minor complexity programming wise, is somewhat limited in terms of scalability, and DNIS/NameTag is lost when networked to other nodes (per the doc’s…not actually tested).

--------------------------

 

[christiankarl]

I have no prob with this issue since i already tested this feature on 5550. We have a client who caters several small offices and asssigned DID's respectively. All calls from these offices will fall on a single operator(5550) and present exact calling name id. Its only a matter of COS.