UC560 with intermittent long ring delay

[marquisderay]

Good morning all,

I've got a seemingly intermittent problem that is driving me nuts trying to track down.

UC560 on a PRI.  Configured using CCA.  Every so often, we get an incoming call who says our main line takes about 10-20 seconds to ring.   I've personally tested it a few times.  Cellphone and land line.  No rhyme or reason that I can find.  Sometimes it connects in 0-2 seconds, other times, I get the delay.  Now while I can admin the UC560, my experience for engineering an environment is no where near sufficient.  Our install engineer is saying it's the PRI, the PRI vendor says their line is fine its the system.  Anyone ever run into this?  Any help is greatly appreciated.

[Alexander Maroukian]

Hello Raymond,

What type is the phone which is configured to ring your main line?

Best regards,

Alex

[marquisderay]

Our main line is a CISCO SPA525G2 with 2 Expansion Modules.

[Alexander Maroukian]

Hello Raymond,

Could you please check if by any chance the the ephone-dn of the main line is octoline. If it is you should delete it and make it dual line.

HTH,

Alex

*please rate helpful posts

[marquisderay]

Alex,

Quick Q.  I know how to do the ephone-dn on the CLI, but we've been cautioned to always use the CCA as using the CLI and CCA may cause the CCA to stop working, so where is ephone-dn in the CCA?  I've looked every which way but sideways can can't seem to find it.

Also, clarification, the main line is a 7965 with 2 expansion modules.  Poor memory on my part.

- Ray

[Alexander Maroukian]

Hello Ray,

The ephone-dn is the button assignment you do in the CCA under the user and phone configuration or the floating extension. There only under user phone you can see when you click on the extension what type is it - dual or octo line. Well if the phone is 7965 the octoline will not be an issue. Just to be shure check if this line is not shared with another SPA500 phone.

Also please check if you run the current 8.6 software pack.

If it will be easier for you may call the SBSC (Small Businees Support Center) and log a case to help you troubleshoot and resolve the issue.

Best regards,

Alex

[marquisderay]

Good morning Alex,

Thanks for the info.  We are running 8.6.  So after trending call volumes, traffic and when the problem occurs, it seems like the problem is the calling going to the extension of the main DID.  We only recently were able to notice it does it internally also, but with no rhyme or reason, some times it just takes 7-10 seconds to ring the main extension, even if no one is on that line at the time.  So.. we're still running it through.  I think next step now is the SBSC now that I have some tangible info for them.

Cheers!

- Ray

[Alexander Maroukian]

Hello Ray,

It is good idea to log a case with SBSC. This could be also due to dialpeer configuration but not necessarily.

Best regards,

Alex

[paolo bevilacqua · Accepted solution]

This is unlikely to be UC500 problem.

You can take "debug isdn q931" with "term mon", try to catch a problem call and post the relevant output here.

[David Trad]

Hi Raymond,

I am with Paolo on this, you need to debug the ISDN line and see if the call is hitting the UC at all, if it is then you should be able to see if it is sending the call to the appropriate Ephone-DN, or if an error pops up you can then tell us what that is.

Regardless if this is a problem and causing interruptions to your business, you should log a case immediatly assuming you have an active SBSC contract in place.

Further to that, I have seen odd issues like this (Bot not quite the same) when the cable being used from the NTU to the UC is faulty, you may also consider replacing this and seeing if this assists with the problem.

Cheers,


David Trad.

[Alexander Maroukian]

Hello Ray,

Just to clarify the call is hitting the UC because even with the delay it is ringing as far as I understand. IMHO the ISDN debug will help to find out when the call arrives at the UC and if it is delayed there, if it is the carrier who delays the call or how the call arrives (number, IEs, type, etc).

Absolutely agree with David this could also be due to cabling issues.

But .T in a dialpeer is adding some 10 seconds and this could also be the reason although not necessarily.

Could be something else also.

If you are not sure about the skills to troubleshoot the issue SBSC should be the easiest way.

Best regards,

Alex