NEC SV9100 Caller ID Name Issue

[Fonbiz]

thread937-1801809

I have a client who has moved to the US from AUS and we are programming their SV9100. The only remaining issues are Caller ID name and voice message language and display voice mail status. I believe the issues are incoming call/ringing timing settings.
The caller ID from the client has been verified on a US SV9100 on both SIP and analog trunks. On analog trunks the Caller ID name shows up after two rings and stays in place for a few seconds and disappears leaving only the number showing. This is why I believe there are timing settings involved.
All calls on SIP or Analog trunks are working Any help with this would be appreciated.

One only other issue I am experiencing is with the basic voice mail subscriber mailbox greetings. While I have been able to change the greetings on the desktop display to US English, and in all other areas where the language is an adjustable setting, the basic "at the tone you can leave a message for Extension xxx, press the hash to exit" I would like to be able to change this to US English. The employees except for the owners would be confusing to the employees who are not used to this lingo and accent. Can anyone help with this ?

Last thing is the Vmsg softkey on the display. I have to program a 77 button - InSkin voice mail for the users mailbox. On the US version the VMsg soft key button is always on the display and accessible with a soft key. On the AUS there is no VMsg softkey and an inskin button has to be programmed. Was hoping there was a way to change this so we don't have to waste a button on the phones.

Any help with any of these issues would be very much appreciated.

Thanks

 

[CoralTech]

Look AT 20-02-08

 

[CoralTech]

Look at 47-07 for prompts.

 

[Fonbiz]

Thank you to you both. I will explore both of these recommendations and let you know.

 

[Fonbiz]

The big remaining issue now is Caller ID Name. The number is coming through, but the name is not. I have duplicated the settings between this and another system (SV9100) and regardless of what settings I have changed or verified, the Name will not come through. The SIP trunk has been verified as we used it on another system and name is being sent by the provider.

Any ideas ? Help badly needed.. Only scratching head and ... Thanks

 

[CoralTech]

Explain your call flow and are your trunk type set to DID.

 

[Fonbiz]

Hi Coral Tech. Thanks for responding.

Our call flow is SIP Trunking with six trunks on this system. The trunks are set to start at port 1 for a total of six trunks. There is one DID ending in 6663 that is set to a destination of Sta.105 All six trunks are set to DID. There are another four trunks that are analog and trunks 7-10 are set to normal.
When this system was in AUS I imagine it had some kind of BRI or other trunking format as there were ten trunks and each one had its own DID of two digits and each trunk eg trunk no 1 had a DID of 01, two had 02, etc. Not sure if this is relevant but thought I would try not to leave this info out in case it was important. I have only changed the trunking format from A-law to U-law in 84-14-03 which allowed the SIP trunks to work.
I have gone through all of the Caller ID settings in 20-02, 20-08, 20-19 as well as any pertinent settings in the 14's, 15's and 22's.
All the settings seem to match a US version SV9100 but no name comes through on the SIP Trunks. I have verified the trunking provider is sending name as we used this same trunk on a US SV9100. Any ideas would be very helpful and appreciated.

I am really stuck here as our US NEC Tech has no training or familiarity with anything but US systems, and the AUS folks I spoke to are unfamiliar with anything outside of AUS. The trunking provider tech did review the settings in the SV9100 and noticed the format was A-Law and had me change it to U-Law.
He also insisted that SIP was SIP was SIP and there were worldwide standards. They sell service in several countries in the Western Hemisphere and insisted they do nothing different except for DID treatment in certain countries. Other than that I am stuck.

 

[CoralTech]

Call flow...goes to AA what? Also if you check CID key does the name show there?

 

[Fonbiz]

Hi CoralTech

I've done some poking around and here's what I have come up with - hope this helps.
Call Flow - Unless I misunderstood what you were asking, the DID ending in 6663 only routes to 105 in Day Mode 1
When I checked the CID Key initially, it only showed the incoming phone number but not the name.

I then went to 10-29 and experimented with the Carrier settings.
all of the carrier choices except for D & G made any difference. All of the others still only showed the number but no name.
Carrier D showed only the name but never the number and when I went to List CID no number or any other info showed up.
Carrier G only showed the number with a 9 in front of the number and I switched back to D.

What I do notice is that the name occupies the right side of the screen where the number typically shows up and the left side of the screen where the name usually shows up is blank.
I seem to remember there was a setting that involved the header. Don't know if that applies, but at this point I'll try just about anything.

I am at my office where the system is on the bench and can be accessed for testing. If you're available or if anyone has any ideas I would very much welcome them. This is the only issue at this point that is preventing us from taking the system to the Customer. Help please.

 

[Fonbiz]

Sorry, NONE of the carrier choices in 10.29 made any difference except for Carrier D and Carrier G

 

[Shaun E]

This is something that I suspect might be in the Australian firmware (CID name is not really a thing here on the public network).

I have *never* been able to get caller ID name working on an Australian SV8100/SV9100 CPU regardless of the trunk type - SIP/PRI/POTS even though traces reveal it being sent to the system.

If you manage to get it working then I'd definitely be keen to hear about it, but I've tried just about every single option in the system with no luck and simply can't get it to show.

 

[Fonbiz]

I will let you know where we end up with this I am going to try to have our service provider modify the header to contain both name and number, but since only one field is populated there may not be enough room for both pieces of information. I do wish there was a way to reflash this processor to be used in the North American market. But wishing doesn't make it happen. I'll let you know what we come up with.

Thanks

 

[CoralTech]

What is 105? Is that an extension? You need to open up SMDR and see if name is getting to the system at all.

20-02-15
20-09-02
20-19-10 2 AND 3

 

[Fonbiz]

CoralTech: Yes, 105 is an extension. We did test with the same trunk on a US SV9100 and name and number did come through as well as on another system we have on our workbench, so the trunk and the delivery of name and number to the AUS SV9100 are not debatable, they are proven. In 10-29 we tested every Carrier Type, including default and Carrier A all the way to Carrier Z.
In all Carrier Types, except D and G, only the number came through. In D, only the name came through. In G the number came through with a 9 in front of the number.

Shaun E who posted to this thread mentioned that he has never gotten the name to show up on an AUS SV9100 so I contacted our company's phone network tech and he did come up with a fix and it is working, but the "fix" was from outside the system. He wrote a script in our service platform that provides SIP trunks and hosted stations that "Overrides the Caller ID name with a special string that puts all Caller ID info (name and number) in the name field. In 10-29 I have to leave the setting at Carrier D.

That said, while we can get these AUS SV9100's well equipped with licenses for a fraction of what the same item would cost in the US if available, and yes we have determined what settings need to be changed to work in the US, and yes there are supply chain issues in the US and yes, companies source materials and parts from all over the world, while I normally don't worry about stuff like this, something is telling me this is just a problem waiting to surface, whether its a problem with NEC or some disgruntled customer down the road who changes service providers and loses their name capability, or who knows what. I am looking at this as a temporary fix just to get this customer up and running.

I probably need to get customers to sign an letter of understanding that there is no provision or expectation of manufacturer support for any equipment sourced in the used or refurbished market just to cover our a-ses and maybe I would feel better about using these CPU's in the field.

Anyhow, thanks to all of you who helped with your input. Several other issues were resolved because of the help I received, and where we were not able to resolve an issue with programming, the experience of another tech, Shaun E, told me I had to look beyond the system for our resolution, else these would be emergency situation systems only or temporary systems whilst awaiting the permanent CPU.

Thanks to all involved, for your help, this is truly a wonderful community. I am so glad I found it.

 

[OzzieGeorge]

I have supplied Belvedere with a podcast on SIP setup by an Australian expert, that may have pertinent info in it. I can't post it on an open forum as I can be identified by it (and it could be/probably is copyright). Belvedere may be able to hook you up with it or you can ask here....

NEC PABX Forum - Australian Communications Forum