UCM6102 not detecting hangup - UK


#1

Hi

I’m having a problem where the UCM6102 cannot detect the receiving caller hanging up. You can hear the disconnect tone (400Hz continuous), but it’s not recognised by the PBX.

I’ve tried all the things mentioned in the various other posts on this, including:

• enabling/disabling polarity reversal
• running the PSTN detection
• enabling/disabling the current disconnect threshold
• changing that threshold (making it lower, e.g. 70ms)
• customising the busy tone definition to lower the trigger, e.g. f1=400@-130,c=375/375
• customising the busy tone definition to say continuous rather than pulsed (e.g. f1=400@-50,c=0/0)
• running the ACIM impedance detection etc
• changing the busy tone count to 1

… all to no avail.

Does anyone have any suggestions as to what might be wrong please?

Andrew


#2

Hi what firmware you on


#3

Thanks for your reply. I was on 1.0.18.17 but have just upgraded to 1.0.18.18. The issue is the same on both.


#4

Is this a voice line or do you have broadband on the line too?


#5

keep in mind that after making the detection (I recommend the semi-automatic) you must always restart UCM


#6

Thanks. Yes, it’s also a broadband line, but there’s a microfilter in the master socket so there shouldn’t be any crosstalk from the broadband frequencies.

I didn’t realise you needed to restart after the PSTN detection. I’ll try that, though I have a feeling it might not work (as, whether I realised it or not) I have just rebooted it as I upgraded the firmware and it’s still not detecting the continuous tone on hangup.

Is there anything wrong with my busy tone definition? It’s the standard UK onc, but I’m conscious that the busy (engaged tone) is an intermittent beep whereas the hangup tone is continuous (akin to the "number unobtainable tone in the UK). The standard busy tone definition for the UK has a 375ms cadence.


#7

As @damiano says reboot after applying the changes from the ACIM impedance detection.
I have noticed that if you have broadband on the line (in the UK that is) the results from the ACIM impedance can be different to the same line without broadband. They can also vary if the distance to the exchange is long or, more importantly, there are a number of joints on the pair. If you use an analogue handset directly on the line does this pick up the disconnect?
Run the detection again, making sure to apply the results, reboot then check


#8

Thanks. I did the impedance detection (using ERL method), rebooted, then did PSTN detection.

It still doesn’t detect hangup.

On an analogue phone (with answering machine), it does detect the hangup properly - if I hang up after leaving a message (or during the initial outgoing message) that’s detected and the answer phone stops.

On the Grandstream, the answer machine will record 2 minutes of busy signal.

By the way, if I dial a number on the Grandstream that is actually engaged (so I get the busy signal intermittent tone), the Grandstream does properly detect that and ends the call. For some reason though, it won’t detect the continuous 400Hz tone that signals a remote caller hanging up.


#9

did you do semi-automatic detection as I recommended you above?
post the screen of the various settings,
other thing, did you put the country correctly?


#10

Yes, semi-automatic.

Yes, set to UK.

I’ve put the screenshots below. Thanks for your help.


#11

I with semi automatic and the various settings have never had problems, obviously everything must be done correctly and UCM restarted afterwards.


#12

There’s a couple of points here…

  1. I’d expect the current disconnect threshold to be much closer to 200ms
  2. The settings on Port 1 from the ACIM detection look odd. Given a standard UK analogue line with broadband I’d expect to see a lower level of capacitance. From what I can see on line 1 it seems there’s some corrosion on the line joints somewhere…or…your cable from the linebox to the UCM may be at fault

#13

Thanks. That’s interesting.

The default is 200ms I think - during the PTSN test it changed it to 80ms. On other PSTN tests I’ve run it’s disabled it completely (it’s a bit random).

The odd thing here is that the Grandstream will detect the busy tone when you call someone that’s engaged. But it won’t detect the continuous tone on hangup. It’s fundamentally the same tone (though one is pulsed and the other is continuous), but it does indicate that the Grandsteam is capable of detecting the tone, which in turn suggests it’s not an impedance etc problem.

Also, my other analogue phone detects the hangup ok.

Il’l try swapping cables but the broadband is stable (suggesting not a problem up to the master socket) and no noise/crackling on the line.


#14

did you do correctly what was required in these three screens? (are examples of course)


#15

Thanks for your post. I’ve re-checked all of those three screens and tried enabling TISS and nudging the current disconnect threshold up to 200ms. Obviously my settings are otherwise different to yours (I’m in the UK rather than Italy), but I’ve definitely looked at and set up those screens. Still not working though.

I tried switching it over to FXO2 though and it works with exactly the same settings! Maybe my FXO1 port is dodgy or something.


#16

as I wrote to you you must NOT copy my settings, they were just an example.
If FXO2 works properly and FXO1 with the same settings doesn’t work, I guess you have the defective / faulty FXO1.
You can try to make a format factory.


#17

Hi. I’ve looked into this further.

The issue seems to be the amplitude setting within the busy tone definition. If you adjust the RX gain on your line, you need to nudge the amplitude up. Counterintuitively, it doesn’t appear that the amplitude value works as a floor (in other words, if the busy tone exceeds it, then it will be detected). Rather, there appears to be a need actually to match it to the amplitude of the busy signal quite precisely.

Also, PSTN detection does not automatically adjust the value for you. You have to do it manually.

The thing to do is to run the PSTN detection but save the raw sound file as part of that process. Then in Audacity you can check the actual amplitude of the busy signal and use that as the value in the busy tone definition (you need to select “custom” to allow the definition to be edited).

It’s now all working reliably.

Hope this helps anyone else having the problem.