Incoming caller ID for one of our offices says we are 'IP TRUNKS'

[chewie]

Hi all.  We have a Mitel 3300 running  44.0.1.26.

Running into another issue, which we are being told is due to system versions/incompatabilities between them.
One of our sites, which uses site to site VOIP connectivity from here to there and vice versa, shows anyone who calls from here to there as 'IP TRunks' for caller ID.

Everything I've read says that if callerID isn't available, then it will default to the description/name label in our system...it worked on our older system just fine, and only happened when we upgraded this site to the version mentioned above.

The other site in question is running a 3300 at 40.1.1.10 .  However we have two other sites with 3300's as well, and at least one of them runs 40.2.0.16 but their caller ID shows us correctly (AFAIK). So far it's just this one site saying it shows that way.

What would I be looking for in this case?  Is there something I need to turn off or on on this end, and likewise the other end, for callerID to be displaying properly? It displays correctly calling the other sites, and also external lines from here, and internal lines from here (desk to desk) work as well.

Appreciate any help.

[sunspark]

In TRUNKS --> TRUNK ATTRIBUTE you have in one of your trunk service ( Trunk label : IP TRUNKS)

[chewie]

Hi Sunspark.

Yes, in trunk attributes we have two trunks I see:

One labled IP Trunks, the other IP Trunks2.

Are you saying those should be blank or something else?

[sunspark]

if u put nothing you will see nothing.

If you put MITEL you will see MITEL that all.

[chewie]

Hmm.

So you're saying Trunk Label controls what the other site would see for callerID?

I just looked @ the old system, and it was set to IP Trunks as well.  So not sure why it wouldn't have shown that way before hand then.

If there is no label there, what do they see? Nothing? Or would they see an extension or a name?

[ZuluAlpha]

If the number being called is not in the Telephone Directory our system will show this from time to time.

[chewie]

ZuluAlpha... you may be on to something.
All of the entries in the directory here are showing this site's info only.
I saw on the old system, data sharing between this and the other site in question was enabled. 

What does that data sharing actually do?

[chewie]

Well, not sure what the data sharing was supposed to do, but the directory only has local #s.

So how in the world does mitel know that when I dial an extension in another site, that it translates it to that person's #?
I can't figure out the call flow from how it's presented...

[sunspark]

First. Try to replace ip trunks 2 label by something else and make a call. Then tell us what do u see.

[chewie]

Before I do that, quick update.
It shows the extension # and then IP TRUNKS after it, so not just IP TRUNKS.
So part of the callerID is coming in.

[ZuluAlpha]

Well, not sure what the data sharing was supposed to do, but the directory only has local #s.

So how in the world does mitel know that when I dial an extension in another site, that it translates it to that person's #?
I can't figure out the call flow from how it's presented...

If SDS sharing is broken due to the version differences your directory may not be getting updated. Sometimes if we use a speed call or a main ACD number that info isn't in the directory either so we have to put it in. I would do a test and add one of the numbers not working in to your Telephone Directory. If that works you can export that entry as a .csv and use excel to put the rest of the info in, then upload the new info.

The SDS sharing lets Node A know that extension 3456 is on Node B when the extension is dialed from Node A. However, if there is no other information it won't be able to say who it is calling. Typically the Telephone Directory is shared, but if that part is broken - or the nodes need re-synced that could all be in play as a potential issue.

[chewie]

Well, not sure what the data sharing was supposed to do, but the directory only has local #s.

So how in the world does mitel know that when I dial an extension in another site, that it translates it to that person's #?
I can't figure out the call flow from how it's presented...

If SDS sharing is broken due to the version differences your directory may not be getting updated. Sometimes if we use a speed call or a main ACD number that info isn't in the directory either so we have to put it in. I would do a test and add one of the numbers not working in to your Telephone Directory. If that works you can export that entry as a .csv and use excel to put the rest of the info in, then upload the new info.

The SDS sharing lets Node A know that extension 3456 is on Node B when the extension is dialed from Node A. However, if there is no other information it won't be able to say who it is calling. Typically the Telephone Directory is shared, but if that part is broken - or the nodes need re-synced that could all be in play as a potential issue.

Does data sharing have to be enabled for SDS to be working properly?
It was on the old system, not in the new, and I have no idea why it was before and why it wouldn't be now.

[x-man]

It shows the extension # and then IP TRUNKS after it, so not just IP TRUNKS.

Now, just a thought here. This is due to another issue we had with IP trunks not really related but it could be IYSWIM.

I wonder if the IP trunks are being treated as internal groups and the 3300 is therefore doing what it does with internal groups when they are rung by default; they display group number and then the CLI. There is a setting to change this but I can't remember what it is. But it might be worthwhile finding out and changing that setting. Display ANI/ISDN Calling Number Only (see Programming). When the call is answered, the caller's name and/or number are displayed on the member's set  (COS Option - After Answer Display Time)
For Ring Group calls, blank (the default) will cause the group member's display to immediately change to the caller name/number upon answer.

In our case the IP trunks were being controlled by the INTERNAL call timer even though they were trunks (we didn't look at the internal timer closley and didn't notice it had been set for some reason and we cannot remember setting it) Funnily enough the external call timer hadn't been set. Took some finding that did even by Mitel support who had a copy of the dataase.