Ground start is only used in North America and it does gie positive disconnect supervision, so I don't think they are using groundstart signaling.

The original problem description sounds like a loop start supervisory disconnect issue, which occurs because the FXO port goes off hook as the call comes in. As far as the phone company is concerned the call was answered and they expect both sides to hang up. Since the IP phone is ringing, even if the PSTN side hangs up , the IP phone will continue to ring until the ring no answer timer expires (normally 3 minutes!)

If this is H323, you can configure 'connection plar opx ' to get around the continuous ringing - this command allows the voice port to sense the ring signal and establish the VOIP call leg, but the port ONLY goes off hook when the IP answers, and the IP call leg stays up for as long as the voice port sense the ring signal. As a result, if the PSTN side hangs up, the ring signal stops and the voice port clears down the IP call leg as well - so the IP phone stops ringing.

The other option you have is to use tone based supervisory disconnect to detect the disconnect tones played by the PSTN after the original caller has hung up. This will work for H323 and MGCP. We need to know what country you are in to configure this correctly.

Thanks a lot for your reply, 'connection plar opx ' Solved the problems.

Great Thanks,

Hi Cameron,

I Have a similar issue at our office in India, we have 2 service providers Airtel and BSNL. Issue is same with both service provider's. the issue here is "no call Manager" we have a cme and then FXO. we already tried 'connection plar opx' it still doesn't solve the issue.

This won't be the same issue. PRI does not have issues with supervisory disconnect in the way FXO ports do. If your IP phone is providing ring back tone, it is either being generated locally (if the telco sends an alterting with no progress indicator) or from the remote network if the alerting message contains a progress indicator.

If you get a log from 'debug isdn q931' when this problem happens we can confirm what is happening here.

Thanks for your answer. The problem with "debug isdn q931" is that there are tens of calls making at the same time, because there are about houndred users of the CCM. To capture debug from the only call appears difficult. Or do you have any suggestion how to do it?

Thanks

If it happening on calls to particular mobile phone numbers, wait until a quiet period and make the test calls then.

If this is not possible, get a debug capture when the issue is reported. The Q931 debugs are relatively easy to follow if we know the particular called and calling numbers.

I captured output of the "debug isdn q931" command. The result is in the attachemnet named "putty-vbl-08-09-2009.log". The call was from number 59987217 to number 0908700116. After rejecting of the call on the mobile phone (number 0908700116), the tone stayed ringing (ring back tone). I pasted this log to the q931 analyzing tool (http://cosi-nms.sourceforge.net/cgi-bin/isdn_dbg/q931cls_.cgi) and the output is in the second attachement (Q.931 signaling summary.pdf). It seems to be uncompleted.