Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations sizbut on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

BRI Trunk calls DROP

Status
Not open for further replies.

danramirez

Programmer
Oct 25, 2009
1,136
ES
Hi all,

We recently installed a new system, two days ago. 3300 CX 4.1. Two Quad BRI MMC and One DSP II. 16 Voicemail ports (8 for voicemail and Auto. Attndt. and 8 for RADs)

People complaint that outside calls drop every so often. Call duration is disabled in COS (Trunks and stations).

I have check the logs and found this. The number on the logs (i.e. 915488242) is the number of the calling party that called in. What could this be?.... Never seen this before...

I have copy the logs description:

call ann. buffer recovered buffer 227 owned by non-existent pid ($5,$4C9)
equip swid: $08000014, equip swid DN: , display digits: 915488242 display name: , call type: 12800

call ann. buffer recovered buffer 301 owned by non-existent pid ($1,$455)
equip swid: $08000014, equip swid DN: , display digits: 915488241 display name: , call type: 12800

call ann. buffer recovered buffer 309 owned by non-existent pid ($2,$44E)
equip swid: $08000010, equip swid DN: , display digits: 914784949 display name: , call type: 12800

call ann. buffer recovered buffer 312 owned by non-existent pid ($2,$44E)
equip swid: $08000010, equip swid DN: , display digits: 914784949 display name: , call type: 0

call ann. buffer recovered buffer 320 owned by non-existent pid ($2,$44E)
equip swid: $08000010, equip swid DN: , display digits: 914784949 display name: , call type: 0

Please need help, regards,

Daniel
 
Hi again,

I opened a ticket with Mitel and they said there is a DPAR for this, the gave me reference "DPAR assigned 334039".

Do you guys know if one can check that DPAR on Mitel On-Line?

Regards,

Daniel
 
I doubt DPARS are visible from MOL as they are internal records. I'm not sure though that these logs are the issue, or a result of the issue.

My 'guess' is that that is complaining about a call announcement on a device that has hung up (for whatever reason). Any chance that the people that complain about the disconnected calls were at one point parked calls?
 
Irwin,
Well... These people have an ACD queue, maybe that's the reason of the problem.

Here is how it happends: ACD agents and/or regular users suddenly hear dial tone while on an outside call... it seems to me that the PBX is running out of resources somehow and hags up the call.

Do you recall how many E2T sessions can be handled by the CX II RTC?

I will try CCS traces to see if I can figure out which end hangs up the call. This also may be the telco... I have asked 100 times if that happened before with the Panasonic and they have said "NO Never...".

Thans very much for your comments, regards,

Daniel
 
Not off hand. I don't think it's an E2T issue though, for two reasons: 1. You would see something in the logs indicating that there were no more resources, and 2. From what you are saying, the call is already established, then it hangs up, so the E2T resource would have already been obtained.

How long after the call is established is it before it gets disconnected? seconds? minutes?
 
Irwin,

Calls hang up randomly, not after a specific amount of time.

I agree with what you say about the E2T and resources.

Regards,

Daniel
 
Sounds like a cleanup problem with the call handling. If those logs are related. Caller calls into ACD queue, then gets answered but the connection gets lost in the move. The call announce can't find the call in it's records, so it clears the connection, which is now in the two-way call. Or some nonsense like that. Bottom line, something Mitel needs to solve.

You could probably try to track the problem down to when the call gets transferred. Not sure that would help you though.
 
Irwin,

Do you think it will be a good idea to take some CCS traces to see what end is actually clearing the call?
 
Irwin,

I foud where the problem was!!!

These BRI truks are configured as Point to Point by the service provider, I had those as Point to Multipoint on my ISDN Protocol.

I changed it to Point to Point and no calls's been drop so far, it's been 5 hours since I changed it, customer started to speak to me again and stop yelling at me.

Thanks very much for your advice, Regards,

Daniel
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top