SPA525G with UC540 - caller id and called-name - phone display help needed

Unanswered Question
Apr 7th, 2011

Hi, I have a UC540 with 18 SPA525G2 phones (4 deployed using VPN).

The phone call quality is great, even between Australia and Thailand.

Our first issue is that the display on the phones doesn't show the  callers name (when the caller is saved in the company directory or in  the phones directory). It only shows the callers phone number twice. I  can't find any way to get it to display the callers name if the callers  number is in our directory. Please help me with this if you can.

Our second issue is that we have multiple departments with multiple  incoming phone numbers coming into the system. Some of our phones  receive calls from multiple departments (multiple incoming numbers). In  order to answer the phone appropriately we need to see which of our  phone numbers (or corresponding department name) is being called. Cisco  advertised this feature with the UC500 series and it is called  "called-name". I have looked but cant find anyway to turn this on for  our phones. Can someone please help me with this?

As you could imagine, without these two advertised features working  on our system, we are having difficulty answering the phones the way we  would like.

I would appreciate any help you can offer.

Michael

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 3.7 (29 ratings)
David Trad Thu, 04/07/2011 - 23:43

Hi Michael,

Lets tack the first one:

Our first issue is that the display on the phones doesn't show the  callers name (when the caller is saved in the company directory or in  the phones directory). It only shows the callers phone number twice. I  can't find any way to get it to display the callers name if the callers number is in our directory. Please help me with this if you can.

It would be good to see what is in the Directory listings, normally you can do this via Command Line and using the command "sh telephony-service" and you can remove all the stuff out of it and just show us the directory listing with the numbers removed or "x"ed out. I have a bad feeling that for the name it was issued with the number as well, which is not a good thing

OK second one:

Our second issue is that we have multiple departments with multiple  incoming phone numbers coming into the system. Some of our phones  receive calls from multiple departments (multiple incoming numbers). In order to answer the phone appropriately we need to see which of our  phone numbers (or corresponding department name) is being called. Cisco advertised this feature with the UC500 series and it is called  "called-name". I have looked but cant find anyway to turn this on for  our phones. Can someone please help me with this?

I have no idea what "Called-Named" is never heard of it and never seen it

However if I understood what you said correctly, you can do this via shared DN method, which is effectively a floating extension which you tag it with the name you want, and you direct the incoming call from a particular DID or Line or Port to point to that DN and you then assign it to all the phones you want it to be on (Hope this makes sense to you). Doing it this way you can see where the call is coming from and then know how to answer the call properly, however though it takes up valuable real estate such as buttons, and you need to assign overflows to them even if you make them octo-lines.

The above is one method, there are other ways you can do it, but this seems to be the most common one and also the easiest one to do, it is also supported by CCA which is the preferred method to configure such a call routing path with.

Anymore questions or if you need clarifications on something please ask

Cheers,

David.

alltraders001 Fri, 04/08/2011 - 00:32

Hi David and thank you for your help.

I ran "sh telephony-service" and have attached the output. I couldn't see any phone numbers and names in the list. I also cannot see how to add them. I have added names and numbers using CUCME (configure - system parameters - directory services) and have added about 10 numbers but they dont show up anywhere else. I have also added names to the spa525G phones using the handsets themselves but this doesnt work either.

"called-name" is a documented UC500 series feature. I have attached some documents that I found that refer to it. I have put some links and other details about it below. Sorry about the formatting.

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif";}

·        http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmedirs.html#wp1014562

·        https://cisco-support2.uat3.hosted.jivesoftware.com/search.jspa?peopleEnabled=true&userID=&containerType=&container=&q=Called-Name

·        http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmecover.html#wp1093567

·        http://uc500.com/en/altering-incoming-caller-id-based-trunk-group

Called-Name Display

When phone agents answer calls for several different departments or people, it is often helpful for them to see a display of the name, rather than the number, of the called party. For example, if order-entry agents are servicing three catalogs with individual 800 numbers configured in one overlay ephone-dn set, they need to know which catalog is being called to give the correct greeting, such as "Thank you for calling catalog N. May I take your order?" The called-name display feature can display either of the following types of name:

http://www.cisco.com/en/US/i/templates/blank.gifName for a directory number in a local directory

http://www.cisco.com/en/US/i/templates/blank.gifName associated with an overlay directory number. Calls to the first directory number in a set of overlay numbers will display a caller ID. Calls to the remaining directory numbers in the overlay set will display the name associated with the directory number.

Our Setup:

Seven numbers all reach our phone system (DID numbers) and are for different departments or companies in our network. Departments D1,D2, D3, D4, D5, D6,D7, all with their own DID numbers are mapped to blast groups. Two of the Departments are in other companies that we own and run.  Users U1, U2, U3,... all belong to various blast groups. Some users belong to multiple departments and companies. eg: U1 may belong to D1, D3, D4 and these departments are also for different companies. We need the phones to show which department/blast group/DID number (or preferably, corresponding name) was used to call us so we can answer the call appropriately. Our current call-flow is incoming calls go to a blast group, then if unanswered go to a floating extensions voicemail with email notification.

Thank you very much for your help with this.

alltraders001 Fri, 04/08/2011 - 00:34

Hi David,

I just re-read your post and will try the method you have detailed to get the called-name.

Thanks for your help.

David Trad Sun, 04/10/2011 - 14:54

Hi Michael,

We need to check and see if the following command is in your "telephony-service" configuration... "service dnis dir-lookup"

Can you please check this and let me know?

The config you provided should work as well

Cheers,

David.

David Trad Sun, 04/10/2011 - 17:47

Hi Michael,

It is right about now where I say "I AM MIFFED"

Your configuration looks sound, and everything appears to be in place, this can only lead me to think that it can only be the following:

  • The number being presented looks nothing like what is in the Directory listings, thus the look-up fails, but if this was done by CCA it should work, it could be something related to the translation rule/profile as well... Question to ask now I guess, is this a BRI or PSTN configuration?
  • Or the Firmware for the phones might have a bug and you were the first one to discover it

At this point I would encourage you to log an SBS case and have them debug/diagnose the issue, if it is a bug we need them to arrest it now before they release another maintenance version, if it is not a bug then at least they can find out the configuration miss-match that is causing the issue and it would be good to report that here.

Sorry I could not help with the rectification of this issue, but I reiterate, log a case the longer you dwell on it the more troublesome it gets for you

Cheers,

David.

alltraders001 Sun, 04/10/2011 - 21:01

Hi David,

thank you for your help. I have contacted Cisco and am trying to open a support case with them to address caller-id.

Can you please help further with the called-name/"shared dn" method? I am not certain that I have understood you correctly. I have done the following to test this:

  1. I added a new blast group with ID 519 and added two test phones to it. The blast group works.
  2. I added a new floating extension with number 188, "Call forward all" to 519, "first name"/"last name"/"user id" all set to text values.
  3. I added a new DiD number to my system that is mapped to the internal number 188.


Phoning in on the new DiD number makes the blast group phone numbers ring but the display on the phones shows the two line display "From: 040xxxxxx and 040xxxxxx repeated on the next line. No names are showing.

Michael

David Trad Sun, 04/10/2011 - 21:12

Hi Michael,

Are you in Australia?

If so can you inbox me a number to call you on??

Cheers,

David.

focusonit Mon, 01/02/2012 - 15:17

Hi David/Michael,

I'm also having this same problem and it has me stumped - what was the trick to get it working?

Thanks,

David Trad Mon, 01/02/2012 - 20:57

Hi Tim,

I am unaware of any resolution to this problem, if it is not working for you in Software Pack 8.2 then you might need to do what we both have done and log a bug report on this, at least then it might get escalated up the ladder

Cheers,

David.

alltraders001 Tue, 01/03/2012 - 02:34

Hi Tim and David,

We have the latest Software pack installed and the latest firmware on our SPA525G2 phones. Cisco have a case open about this from us although they haven't resolved it. The latest CCA allows us to create a local directory but calling from a number in that directory does not show the directory listing. To date, no one at Cisco has been able to get caller-id working on our system in Australia. It is really disappointing as this should be part of the core functionality for the system and it is very important within commercial environments.

I hope Cisco do choose to resolve this soon.

Michael

focusonit Tue, 01/03/2012 - 02:41

Hi Michael I agree!

We're a recently appointed Telstra/Cisco partner and we have sold the system with this feature specifically included - every other phone system I can think of has it as standard!

100+ handsets 3x uc500 and I can assure you that if it doesn't work the system will be pulled out and given back to us.

Do you have an existing case number perhaps I can work from yours if techs have already done some research.

Sent from my iPhone

Paolo Bevilacqua Tue, 01/03/2012 - 04:18

service dnis dir-lookup

That may not work with non-cisco, non-sccp phones. SPA phones are Linksys not Cisco.

There are however other advanced techniques that can be used.

alltraders001 Wed, 01/04/2012 - 01:08

Hi Paolo,

From my understanding, Australian exchanges, unlike the rest of the world, don't send a users name as well as the phone number with the call. The only way we will get a name to match the phone number is via a local directory and only if it is made to work (at some future time).

On our phones we get the phone number displayed and it is repeated on two lines. Querying the directory using CLI shows the directory entries correctly. When we phone from one of the local directory entries' phones, all the system shows is the phone number repeated on two lines. The displayed phone number matches both the incoming callers number and matches the phone number in the directory. All of my tests have been using only Cisco equipment as outlined above.

My system is completely CCA compliant. As such I am not willing to use "other advanced techniques" to get this to work. This is an advertised feature and not only should it work, but it also should have been addressed as Cisco have known about this for many months.

Even with that issue it is a great phone system. However, because of that issue, it is not easy for us as a reseller to recommend it to others.

Michael

Paolo Bevilacqua Wed, 01/04/2012 - 05:04

Michael,

As explained in documentation, "service dnis dir-lookup" does not rely on the exchange sending any name.

Beside, what you want is the called name, not the calling one.

I have already explained to you above why the "advertised feature" may not work on the entry point phones, that are really not fully CME compliant. Good luck arguing with Cisco about that.

Finally, the decision to stay with CCA and suffer all the limitations that it introduces, or use the CME system to its full potential, lies totally with you.

alltraders001 Wed, 01/04/2012 - 00:59

Hi Tim,

I think the case number is 619520399. I have just written to Cisco and have asked for an update and for them to confirm that I have the right number.

Michael

David Trad Thu, 01/05/2012 - 19:43

Guys,

The issue has nothing to do with SPA phones, from Software Pack 8.1 and above the Directory look-up broke and it might be related to it being moved to an XML format I am not entirely sure, I have got it to work manually on some systems but then others even doing it manually via CLI it still wouldn't work (I cannot possibly explain this).

The reason the number is being displayed on the phone twice is because it is not able to translate a name to the number when it looks it up in the directory, so it just defaults to the number associated to the name, which I guess is fair enough.

Persistence guys, keep knocking on Cisco's door to get them to resolve it, If I was still working with a Cisco partner or even on Cisco products (well I do in my spare time anyway) I would be helping you both with it, but just keep badgering them until they get it resolved, and PLEASE do not hesitate to get this escalated to engineering level, and even then ask for it to go to Management within engineering.

Lastly... You could beg someone like Dave Harper to help you guys look into this, he is a Champion with getting stuff like this resolved one way or another, but he is probably rejoicing that he wont get bugged by me for a long time... Well I do owe him a drink or two and I will deliver on that promise Dave .

It is an important feature and I agree that it should have been fixed a long time ago, please just be persistent with following it up, I know you shouldn't have to but if you don't, potentially no one else will.

Cheers,

David.

focusonit Thu, 01/05/2012 - 19:50

Gone to level 2 with a 'promise' it will work as expected!

They wrote their own lines of cli to 'prove' it will work!! Haha completely missing the point...

Believe me this will be resolved as the customer is demanding it - and who wouldn't!

The case number I've created for this issue is 620225363 if that helps anyone else.

Unfortunately I'm about 2 hours away from the broken install and won't get there until next week. I really needed to get away from the situation for my own sanity..

Will keep this post updated

Sent from my iPhone

David Trad Thu, 01/05/2012 - 20:00

Hi Tim,

Yeah I know it works via CLI in "MOST" cases, but there have been instances where it would work even though I know it should

When you use CCA it creates an XML file for this as well (Didn't notice this until I analyzed the Debugging screen and followed the bread crumbs), not sure if this is the path they are going down or if it is used for something else, via CLI I just use the Directory setup in telephony-service.

Anyway interesting times ahead

Cheers,

David.

Paolo Bevilacqua Fri, 01/06/2012 - 05:18

I really happen to think that everybody should finally realize that the CCA/GUI du jour is just a bolt-on with major chances of adding bugs on bugs, limitations on limitations.

Someone will jump on me to say how the system is sold to be GUI-only, the support issues, or whatever other excuse that doesn't change the sorry state of the product with current marketing strategy.

Fact is, CME is a CLI system. I can't change that, you can't, even Cisco can't.

But, one can acknowledge that, or keep banging head on it.

mcasimirc63 Fri, 01/06/2012 - 07:51

CCA is actually the only reason why the UC500 sells.  UC500 is mainly sold by select partners who have no CLI background.  Cisco invested 100 million into the small business arena to compete with vendors that have an easy to use interface with low complexity.  You cant get a guy selling Shoretel to sell Cisco CME if he knows nothing about CLI.  If Cisco wants to compete in SMB they have to shorten the deployment cycle and make it cost effective and that's what CCA does.  Remember, Cisco is partner driven.

Paolo Bevilacqua Fri, 01/06/2012 - 16:16

Thanks Marcus for providing exactly the kind of answer I had anticipated.

Cisco got where is now making CLI routers. There was plenty of competition having GUIs, where are they now?

The winning parters achieving the Cisco sales above just learned the CLI, that in case of CME only takes few minutes anyway.

Anyway, I never that said a GUI hasn't to be there. Of course there can be, but not to the point of penalizing the overall system making it mandatory (but then again, only for the less informed).

focusonit Fri, 01/06/2012 - 18:25

I think the issue is that people need to realise this BEFORE they try to deploy them!

The GUI is really just an easy way to set your very first one up. after that i'm sure copy/pasting CLI would be far more efficient and accurate!

David Trad Fri, 01/06/2012 - 23:49

Hi Tim,

Not something I would advise you to  do, no two systems are the same, not even always in hardware thus  working of a text file is fraught with danger... A properly built system  with CCA should work with far less problems then a CLI based systems, and i know this for certain.

The issue at hand to try and keep the thread on topic without me Hijacking it, is quite simple.

  1. Cisco stuffed up with the introduction of the SBCS and the policies surrounding it, they failed big time in adequately training Select Partners on CCA, its concepts, and how the support mechanisms work... The biggest issue of all is that CCa is seriously miss-understood and is constantly given grief by the old school CLI masters, this is Cisco's fault and falls squarely at their feet. Those who understand CCA  and its purpose (And I spent a truck load of hours in beta testing  since version 1.9) know that it has a greater purpose, and not just a  tool for those who are CLI illiterate or do not have the certification, it is a tool to future proof Cisco's SMB model by reducing unnecessary support demands and stripping away the inconsistencies that comes with CLI setups, every single CLI  based configuration is based on the individual who wrote it up not on a  standard set by Cisco because there is not one, imagine having to  support this moving into the future with SMB products that have reached the masses??? Yes think about it for a second with some logic :-)
  2. The worst problem of them all was bringing in the policy that if you design and build the system in CCA and you are not EX-UC certified, they will not assist with configuration via CLI for things that CCA  does not support yet, or had troubles doing, or is bugged out on  etc..etc.. I will openly say it, who ever come up with this policy needs  their heads read because not only is it stupid, but it is moronic and  counter productive and should have even been considered when the  policies were being drawn up Actually when you think about it, it is really an oxy-moron and places  un-due stress and pressure on a Select Partner who Cisco are supposed to  be fully supporting... Seriously guys just for even a split second,  think about this policy and reverse it, and create a new one that is  compatible and works with the direction you are trying to head, do not  enforce a CCA policy on Select partners, and then when something cannot be achieved with CCA leave partners out in the cold, it is a dumb and callas act PERIOD!!!

Now  I know Michael and Tim's issue can be resolved to a degree with CLI,  but since I have endevoured on all accounts to avoid reverting back to  CLI I never persued it, thinking that Cisco would have resolved this  months ago (Yes it has been happening for a long time now guys???).

If  the issues progresses to a point where it puts you in jeopardy with  your client, or it creates a hardship for your business, PM me and I  will set the time aside to assist you with getting this to work, I can  make sure it is CCA compliant so it at least will not break CCA,  but I reiterate my comments above, please keep bashing on Cisco's door  and force them (If you will) to resolve the issue and not sit idle on  it.

Cheers,

David.

Paolo Bevilacqua Sat, 01/07/2012 - 06:03

David Trad wrote:

Hi Tim,

Not something I would advise you to  do, no two systems are the same, not even always in hardware thus  working of a text file is fraught with danger... A properly built system  with CCA should work with far less problems then a CLI based systems, and i know this for certain

For sure, you meant to say, a "CLI based system configured by an incompetent, or careless technician".

The issue at hand to try and keep the thread on topic without me Hijacking it, is quite simple.

  1. Cisco stuffed up with the introduction of the SBCS and the policies surrounding it, they failed big time in adequately training Select Partners on CCA, its concepts, and how the support mechanisms work... The biggest issue of all is that CCa is seriously miss-understood and is constantly given grief by the old school CLI masters, this is Cisco's fault and falls squarely at their feet. Those who understand CCA  and its purpose (And I spent a truck load of hours in beta testing  since version 1.9) know that it has a greater purpose, and not just a  tool for those who are CLI illiterate or do not have the certification, it is a tool to future proof Cisco's SMB model by reducing unnecessary support demands and stripping away the inconsistencies that comes with CLI setups, every single CLI  based configuration is based on the individual who wrote it up not on a  standard set by Cisco because there is not one,

Actually, there are quality CLI configuration standards. And thinking that minor differences prevent people from understanding or achieving their goals, is an insult to their intelligence. Anyway, I want to say how Cisco is not alone in this painful situation.

Few months ago I was at the install site of small business, some sort of public school. They were struggling (among other things) with having a router/firewall made by a very prominent Cisco competitor, to work with a SIP trunk. The GUI of this box was a pitiful job, with configuration elements disjointed over different pages of little logicalness, it did not looked and performed any better that Cisco GUIs. Finally they called their TAC, that kind of laughed and said, "Oh, but you don't do that with the GUI!".

At the same location, they used some "cisco" 2000 gigabit PoE switches, due to their cheapness. I quickly learn i had to HIT ctrl-z to break into an IOS-resembling CLI just to do the very basic configuration needed. However to this day, the business unit  that makes that products, thinks that the world is not smart enough for them to document the CLI - desplicable decision.

A final anedocts, I was in an holiday location trying to get the PPPoE credentials out of an Asian-made ADSL router, to replace it with my UC520 that incidentally I had with me. I failed in extracting the password, but learnt that -Oh, surprise- the device can be fully and completely configured with telnet.

I really don't seen the point in negating this simple fact, network devices are better managed by CLI, but the consumer or small business grade ones requires they come with a GUI. Cisco understood this some lustres ago and they are doing their things, fine with me as long that doesn't interfere with how the product really works.

imagine having to  support this moving into the future with SMB products that have reached the masses??? Yes think about it for a second with some logic :-)
  • The worst problem of them all was bringing in the policy that if you design and build the system in CCA and you are not EX-UC certified, they will not assist with configuration via CLI for things that CCA  does not support yet, or had troubles doing, or is bugged out on  etc..etc.. I will openly say it, who ever come up with this policy needs  their heads read because not only is it stupid, but it is moronic and  counter productive and should have even been considered when the  policies were being drawn up Actually when you think about it, it is really an oxy-moron and places  un-due stress and pressure on a Select Partner who Cisco are supposed to  be fully supporting... Seriously guys just for even a split second,  think about this policy and reverse it, and create a new one that is  compatible and works with the direction you are trying to head, do not  enforce a CCA policy on Select partners, and then when something cannot be achieved with CCA leave partners out in the cold, it is a dumb and callas act PERIOD!!!
  • I understand where do you come from but actually I totally agree with this Cisco policy. To me, it means the following:

    - We (Cisco) know that we cannot sell SMB asking small dealers to "learn first and sell after". They, like their customer, want to be sweet-talked with "ease of use", and two 400-something pages manuals would scare them. It doesn't matter if any good PBX and CO switch has been adminsitered by decades with obscure CLIs compared to which IOS is plain English. JUST DON'T MENTION CLI BEFORE SALE IS MADE:

    - We then introduce the best GUI we could, of course "everybody" with a little experience knows that it cannot do anything, and in some case, not even something. But, it's good enough to make the system work to an acceptable point. Of course, the definition of "acceptable" varies from an individual to another, and here where's the problems begin.

    - Then, out of desperation or whatever reason, the dealer and end-users above, try the CLI, without any previous training or studying effort

    The results are often catastrophic. We all have seen them before - configuration snippets sent as BMP screenshots, useless commands inserted anywhere just because they were in the examples, no understanding of the" basics of nature things" that dictate and why things works - or not. In a word, inability to properly and professional communicate with the TAC to get the issue solved.

    - The Cisco decision is then logical - show me first that you put some effort in learning how to do things, and then I will start talking you in the real language - CLI.

    And by the way, we all know how in this world of cheatsheets aweb-learning, how ridicusly easy the Cisco certifications have become. At a small partner I have been working with, the UC specialization has just been "tick'd on" by someone at Cisco - they figure that with a CCIE in house, another guy with decades of experience, and 2 or 3 TAC cases over 15 years, the partner deserved some trust.

    Now  I know Michael and Tim's issue can be resolved to a degree with CLI,  but since I have endevoured on all accounts to avoid reverting back to  CLI I never persued it, thinking that Cisco would have resolved this  months ago (Yes it has been happening for a long time now guys???).

    If  the issues progresses to a point where it puts you in jeopardy with  your client, or it creates a hardship for your business, PM me and I  will set the time aside to assist you with getting this to work, I can  make sure it is CCA compliant so it at least will not break CCA,  but I reiterate my comments above, please keep bashing on Cisco's door  and force them (If you will) to resolve the issue and not sit idle on  it.

    That is, of course where I agree 100%. When I joined Cisco in 1996, I did not just because they were the leader in what they were doing, but also because they showed they cared fixing their bugs and publicly showin them - beside documenting the product to the best of their abilities (most of the time). To this day, I yet have to see another I.T. company that does the same.

    But, the entire process of Software Quality must also be customer driven, and cannot be put in motions if people sits on their bugs because they don't want to spend $150 for smartner contract, or simple laziness.

    Paolo Bevilacqua Sat, 01/07/2012 - 08:55

    Why low rating a post that reflects the effort of the author to find why something doesn't work? My rating, a "5"".

    focusonit Wed, 01/11/2012 - 15:35

    Hi,

    I've been speaking with Level 2 Cisco support about this and it appears that the BLAST-Group uses SIP and not SSCP. The SIP protocol is not passing on the called number (Note it's the internal number/extension not the external number that was called)

    It does work with hunt-group. I've explained that this is useless for front line call answering (i.e. the purpose of the display!)

    It's been escalated further.

    David Trad Wed, 01/11/2012 - 16:20

    Hi Tim,

    I've been speaking with Level 2 Cisco support about this and it appears  that the BLAST-Group uses SIP and not SSCP. The SIP protocol is not  passing on the called number (Note it's the internal number/extension  not the external number that was called)

    This here does not make sense, SIP as a standard passes all information through and the two end points (A & B) filter out what they do not want, unless Cisco have striped the SIP protocol down to accommodate the IOS?????

    This almost sounds like there is a bigger translation issue taking place, but that could just be me jumping to conclusions.

    Keep us updated, as this is more and more sounding like a bug, but why it isnt hitting everyone needs to discovered.

    Cheers,

    David.

    focusonit Wed, 01/11/2012 - 18:07

    If you use hunt groups it does work...

    We very rarely use hunt groups as most of the time you want the call answered immediately.

    Sent from my iPhone

    Paolo Bevilacqua Thu, 01/12/2012 - 02:52

    Using hunt-groups doesn't mean that the call isn't answered immediately,

    It simply means that the people logged in in the hunt is committed to answer the call as fast as possible.

    And diligent about loggin off when they cannot do the above.

    Also with blast, one can always think, that others will take the calls, then leading to delays.

    Efficient answering is better reached with less confusion in hunts, not blasts.

    focusonit Thu, 01/12/2012 - 02:57

    Sorry that makes no sense?

    When a call comes into the company it should come into the receptionists on duty -all at once. (cca blast group)

    And identified

    There is no logging in or out of the group. There are 6 people who answer the phone if the receptionist is busy - but the caller intent must be identified.

    Sent from my iPhone

    Paolo Bevilacqua Thu, 01/12/2012 - 03:22

    I was not referring to identify the called number, that is discussed in other posts of this thread..

    I was referring to speed and efficiency of answering calls with a proper hunt group, for the reasons explained above.

    focusonit Thu, 01/12/2012 - 03:28

    Sorry again I'm not sure what you mean ?

    I have a team of 8 staff Waiting to take calls. They cannot wait for a hunt group to get to the next available to identify and answer the call.

    A blast group rings all available staff but doesn't identify as it does in a hunt group. This is a problem/bug (from someone using cca only!)

    Sent from my iPhone

    Paolo Bevilacqua Thu, 01/12/2012 - 04:28

    Please read my post above. It explains why a proper hunt with login/logout is more efficient than blast.

    At least, that is my opinion derived from experience.

    Paolo Bevilacqua Thu, 01/12/2012 - 03:19

    I think what the TAC meant, is that parallel hunt groups are configured under SIP, not SCCP.

    My supposition is that In doing so, the effect of "service dnis dir-lookup", is lost. You can notice that in fact that is proprietary SCCP feature, as it displays the string on the status line. Instead, when using a configuration all contained to ephones and telephony-service, it works.

    Makes sense to me.

    focusonit Wed, 01/04/2012 - 10:57

    I have escalated my case about this with Cisco and they say the issue is not with the spa series phones.

    If it is and you are correct I'm sure there will not be a problem arguing that the spa phones were sold as Cisco and therefore should work.

    Sent from my iPhone

    mcasimirc63 Fri, 01/06/2012 - 17:20

    From an engineering and technical perspective, what you say makes sense.  Unfortunately SMB partners usually have few very people on staff (2-5) that need to fill many roles.  SMB, Mid Market and Enterprise are different.  SMB partners would love to have the time and resources to master CLI and dive into more complex solutions, but they need to start somewhere.   So to hit the ground running, GUI is the preferred method.

    Cisco didn't always force select partners to only use CLI, at first they allowed CLI and CCA.  After working with 30+ partners in the SMB space, I can see why they changed.  Select partners with no CLI experience were flooding STAC with calls ranging from install help to CLI changes they made, that caused unexpected results.  The support costs were more than the revenue from the sale.  So, Cisco made it simple, if you are select with no Ex-UC specialization, than you are only supported via CCA.  If you have CLI experience and you have the Ex-UC specialization, you will be supported via CLI, but you can't do both because it will cause CCA to be unstable. 

    I hope that clarifies things and posting to genuinely help people is more important than ratings or points, so don't worry about it, you have a million already

    Darren DeCroock Thu, 01/12/2012 - 07:41

    Hello all,

    Just an update on the original issue:

    This is currently being looked at, and will be forwarded to the developement team to find out if we are planning to add support for this, or if it can be accomplished another way.

    Issue:

    Called-number-display feature does not work with parrallel hunt groups.(Blast groups.)  Parrallel hunt groups use SIP application level forking, which does not support directory lookup.

    Thank you,

    Darren

    David Trad Thu, 01/12/2012 - 16:00

    Hi Darren,

    I wish to thank you for everything you are doing, it is good to see that this is getting the attention it really does deserve, it is an ongoing problem and for those who do need it, knowing that someone is actually actively working on it will bring some peace of mind... So again, THANK YOU!!!

    Cheers,

    David.

    Actions

    Login or Register to take actions

    This Discussion

    Posted April 7, 2011 at 6:41 PM
    Stats:
    Replies:40 Avg. Rating:3.73333
    Views:4141 Votes:0
    Shares:0
    Tags: No tags.

    Discussions Leaderboard