Attendant Forwarding and CLID

[brandonmckee]

I apologize ahead of time if I don't provide enough information as I'm still fairly new to this system. We have a 3300 ICP (v8, UR5), with a T1 PRI line.

When an outside caller dials our main number, our auto-attendant picks up this call. The user can then dial someone's extension. Normally, the internal user receiving the call will see the proper Caller ID appear - but occasionally, the user will see "701 Answer" where 701 could be a number anywhere between 701 and 716.

This wasn't a problem until we recently set up mobile SIP users - and when SIP users receive these calls, they always appear as "701 Answer". I believe the 701 to 716 extensions are some sort of internal trunks, but what could be causing them not to pass the CLID information to SIP users?

I will try to provide more information as required. Thanks in advance!

 

[paterson]

Not every inbound call will have CLID, the source caller may have blocked it. The "701 - 716" are probably the voicemail ports where the call has been transfered from.

For the SIP users most likely a COS/SIP capabilities programming change. I haven't done much SIP, so hopefully someone else can further direct you.

_______________________________________________________________

If you did not take enough time to get it right the first time...

What makes you think that you have time to fix it?

 

[brandonmckee]

A little more information on the situation;

- Excluding the SIP users (line side only), all internal users are using either 5330's or 5340's.
- All internal users using the 5330/5340's also use Mitel's Integrated Office Companion. When a call comes in from the auto-attendant, the user quickly sees the "7xx Answer" as the CLID before it quickly changes to the appropriate source CLID.
- These 7xx extensions seem like trunks to me, but they do not appear in Digital Trunk Assignment or Analog Trunk Assignment. They do appear in Telephone Directory Assignment, but do not appear in User Configuration.

paterson: This could be what is passed to the user if the source CLID is blocked - but we did a test of calling from the same number 10 times to an internal user from a cell phone with known working CLID, and once out of those 10 times the CLID came up as "7xx Answer".

Also, in Telephone Directory Assignment, for all 701-716 extensions the Name is Answer, so it is clear why "Answer" appears on the CLID. The question is, why do these extensions never pass the inbound CLID to SIP users? I am leaning to paterson's reasoning of it being a COS option, I just don't know which one. Anybody have some additional insight?

 

[Mitel100]

CLID setup for a COS are as follows:

For Trunks

DASS II OLI/TLI - YES
Display ANI/ISDN Calling number only - NO
Display ANI/DNIS/ISDN Calling/Called number - NO
Public Network Access via DPNSS - YES
Plublic Network to Public Network connections allowed - YES

For Devices

DASS II OLI/TLI - YES
Display ANI/ISDN Calling number only - YES
Display ANI/DNIS/ISDN Calling/Called number - YES
Public Network Access via DPNSS - YES
Plublic Network to Public Network connections allowed - YES

Hope this helps

__________________________

There is no 'I' in 'Team'
__________________________

 

[brandonmckee]

Mitel100:

Thank you for the settings. I have applied them to both trunks and devices, and the SIP user still sees "7xx Answer" calling.

Maybe the lines forwarding the calls from the auto-attendant have a setting that is overriding the CLID with it's own?

 

[kwbMitel]

Based on your earlier posts I can Make the following statements with confidence.

1) 701 - 716 are voicemail ports named "Answer" in the telephone Directory.

2) The SIP mobile users are local (Internal) extensions off the 3300 system.

3) The trunks are programmed to correctly pass on the CLID due to the fact that it works on the 5330 / 5340

4) the SIP mobile phones are displaying the transfering device (Voicemail) and not the connected device after the voicemail releases the call.

From the above I make 2 possible conclusions:

A) SIP phones are incapable of updating caller info after initial call setup.

or

B) The SIP phone is not progragrammed correctly

My 2 bits... I'd put my Money on Conclusion "A"

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[brandonmckee]

Thank you kwbMitel. Now I know they are voicemail ports - this gives me at least a better description of what is going on. I am going to look into the SIP devices and see if there is a way to update the call info after the initial call is setup.

I know the answer most likely lies in your previous post, but if you or anyone else know of a way to *stop* voicemail ports from updating call info after the call setup - and just have the original CLID appear as the call is initiated - this would be the ideal solution.