Problems recognizing distinctive ring using Sangoma B600E

General Help
1

I am not having much success using the Sangoma B600E to recognize distinctive ring patterns.

I have four ring patterns (the maximum permitted in the USA) on my POTS line:

  • very long (standard ring pattern)
  • long long
  • short long short
  • short short long

I have added the following to the chan_dahdi_channels_custom_conf file:

usedistinctiveringdetection=yes
distinctiveringaftercid=no

I have configured the Asterisk Logfile Settings so that everything is turned on in my full log.

The Detected ring pattern messages in my full log show that two of my ring patterns (very long and short short long) are always detected as 0,0,0. One of my ring patterns (long long) is fairly consistently detected as 332,0,0 to 335,0,0. The fourth ring pattern is often detected as 0,0,0, but has also been detected as 369,0,0 and 307,0,0. All four ring patterns sound correct on an analog phone connected to the same POTS line. I have tried two different FXO ports on the B600E with similar results.

My questions are:

  • Are there any DAHDI settings that I need to adjust to achieve consistent distinctive ring detection?
  • The second and third value of the detected ring pattern is always 0. Is this normal? What are the meanings each of the three numbers?
  • It appears as if RING_PATTERNS is hardcoded to 3 in sig_analog.h. Although I believe I can make this work (once the rings are correctly detected), it is not optimal, since I would need to make one of the ring patterns use my default context, and would thus not have any way to direct errors to a different extension. Is there any chance that RING_PATTERNS could be increased to 4 in a subsequent update? I suppose I could build this module myself, but then I would need to deal with code signing.
  • What is the proper way to define the dring1context, dring2context, dring3context, and default context? I have tried making this the phone number (e.g. 5035551212 ā€“ not my real phone number) and then using the matching value as the DID number on my inbound routes, but the calls (even for the long long ring) donā€™t get routed to the desired extension. Once the rings are properly detected, what is the correct way to route them? (See the error messages below.)

chan_dahdi.c: Matched Distinctive Ring context 5035551212
pbx.c: Channel ā€˜DAHDI/1-1ā€™ sent to invalid extension but no invalid handler: context,exten,priority= 5035551212,s,1
sig_analog.c: Hanging up on ā€˜DAHDI/1-1ā€™

2

Assuming that you have
dring1context=5035551212

Then in /etc/asterisk/extensions_custom.conf put something like

[5035551212]
exten => s,1,Goto(from-pstn,5035551212,1)

Finally, set up an Inbound Route with DID 5035551212 and Destination as desired.

Sorry, I know nothing about the detection reliability issue. Does this line have caller ID? If so, does the number get received correctly?

Iā€™m curious why you donā€™t just port some or all of these numbers to VoIP. What city are they in? Unless itā€™s very rural, there is probably a CLEC with a presence in the rate center.

3

Iā€™m using a B600 with analog lines and distinctive ring detection, and I donā€™t have any issues with inconsistency. Maybe you need to visit your dringxrange values. I have the following in the file chan_dahdi_channels_custom.conf

usedistinctiveringdetection=yes
dring1=0,0,0
dring1context=from-trunk-dring1
dring1range=10
dring2=337,0,0                                 ; edit to suit
dring2context=from-trunk-dring2
dring2range=30
; uncomment for third ring pattern
;dring3=0,0,0
;dring3context=from-trunk-dring3
;dring3range=10

and the following in the file extensions_custom.conf

[from-trunk-dring1]
exten => s,1,Noop(Entering from-trunk-dring1 setting DID to: 1902abcdefg)
exten => s,n,Goto(from-pstn,1902abcdefg,1)
; end of [from-trunk-dring1]

[from-trunk-dring2]
exten => s,1,Noop(Entering from-trunk-dring2 setting DID to: 1902qrstuvw)
exten => s,n,Goto(from-pstn,11902qrstuvw,1)
; end of [from-trunk-dring2]

; [from-trunk-dring3]    ; uncomment for 3rd ring pattern
; exten => s,1,Noop(Entering from-trunk-dring3 setting DID to: zzzzzzzzzzz)
; exten => s,n,Goto(from-pstn,zzzzzzzzzzz,1)
; end of [from-trunk-dring3]

Iā€™m not entirely sure how you will incorporate the 4th ring pattern in your case, but I suspect that any ring patterns not matching will default to the context set in the GUI for the channel, which defaults to from-analog.

4

Thank you to Stewart1 and Lorne for your answers, and especially for noting the need to update the extensions_custom.conf file. Mapping the context from DAHDI to the DID in Inbound Routes was a key piece that I was missing.

Stewart, the POTS line DOES have Caller ID, and the Caller ID is getting received correctly. It is only the Distinctive Ring (the destination for the call) that is giving me problems.

In the future, porting these numbers to VOIP is something I might consider. However, I donā€™t want to consider this until I have more experience with freepbx and have everything working. I am tinkering with a lot of settings, and every time I screw something up, I can unplug my POTS line from freepbx and use my old phones.

Lorne, using the Noops in extensions_custom.conf is a great idea for debugging.

I did some more research on the meaning of the three dring1, dring2, and dring3 numbers: ā€œEach value represents a duration of ringing, such that each ring pattern could have up to three rings of varying length in a one- or two-second time span.ā€ ā€“ VoIP HACKS, Ted Wallingford, Oā€™Reilly, ISBN 978-0-596-10133-6, Hack #57 (Route Calls Using Distinctive Ring), page 146.

If the above is correct (and it does make a lot of sense), the results should NEVER be 0,0,0. I should be getting two values for my long-long ring pattern, and I should be getting three values for my short-long-short and short-short-long ring pattern. Perhaps there is a bug in DAHDI. The existing module probably works only for POTS lines with two ring patterns.

I suspect that the only way to make this work for me is to rebuild and debug the dahdi.so modules. Iā€™m not yet sure whether this is something I want to tackle.

5

No idea what the dring integers are intended to represent, and it doesnā€™t really matter. The detected ring pattern is the one that matters. Now that youā€™ve made me go and look thru logs, I can see that perhaps dring detection is not as reliable as Iā€™ve indicated above:

[root@vvs asterisk]# grep " Detected ring pattern" /var/log/asterisk/full*
/var/log/asterisk/full:[2019-05-29 10:30:16] VERBOSE[28601][C-0000012d] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full:[2019-05-29 11:21:20] VERBOSE[1556][C-00000131] chan_dahdi.c: Detected ring pattern: 338,0,0
/var/log/asterisk/full:[2019-05-29 11:56:47] VERBOSE[5419][C-00000133] chan_dahdi.c: Detected ring pattern: 335,0,0
/var/log/asterisk/full:[2019-05-29 11:57:35] VERBOSE[5507][C-00000134] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full:[2019-05-29 13:37:25] VERBOSE[16042][C-00000135] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full:[2019-05-29 15:26:36] VERBOSE[27476][C-00000137] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full:[2019-05-29 15:27:07] VERBOSE[27482][C-00000138] chan_dahdi.c: Detected ring pattern: 338,101,41
/var/log/asterisk/full:[2019-05-29 15:27:40] VERBOSE[27574][C-00000139] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190523:[2019-05-22 09:11:59] VERBOSE[22733][C-000000e9] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190523:[2019-05-22 10:31:59] VERBOSE[31250][C-000000eb] chan_dahdi.c: Detected ring pattern: 0,0,0
/var/log/asterisk/full-20190523:[2019-05-22 13:32:15] VERBOSE[17978][C-000000ed] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190523:[2019-05-22 18:17:11] VERBOSE[15846][C-000000f7] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190524:[2019-05-23 07:28:10] VERBOSE[2404][C-000000fa] chan_dahdi.c: Detected ring pattern: 0,0,0
/var/log/asterisk/full-20190524:[2019-05-23 09:19:54] VERBOSE[14182][C-000000fb] chan_dahdi.c: Detected ring pattern: 0,0,0
/var/log/asterisk/full-20190524:[2019-05-23 17:17:14] VERBOSE[32093][C-000000fe] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190524:[2019-05-23 17:26:35] VERBOSE[615][C-000000ff] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190524:[2019-05-23 17:44:33] VERBOSE[2621][C-00000101] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190524:[2019-05-23 21:01:51] VERBOSE[23506][C-00000102] chan_dahdi.c: Detected ring pattern: 0,0,0
/var/log/asterisk/full-20190525:[2019-05-24 10:36:58] VERBOSE[12632][C-00000105] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190525:[2019-05-24 11:12:56] VERBOSE[16451][C-00000107] chan_dahdi.c: Detected ring pattern: 0,0,0
/var/log/asterisk/full-20190525:[2019-05-24 16:38:16] VERBOSE[18399][C-0000010b] chan_dahdi.c: Detected ring pattern: 0,0,0
/var/log/asterisk/full-20190525:[2019-05-24 17:26:31] VERBOSE[23565][C-0000010f] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190525:[2019-05-24 18:16:25] VERBOSE[28822][C-00000110] chan_dahdi.c: Detected ring pattern: 0,0,0
/var/log/asterisk/full-20190525:[2019-05-24 19:20:09] VERBOSE[3234][C-00000112] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190527:[2019-05-26 14:11:08] VERBOSE[15691][C-00000119] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190528:[2019-05-27 08:10:51] VERBOSE[32497][C-0000011c] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190528:[2019-05-27 10:51:59] VERBOSE[17337][C-0000011d] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190528:[2019-05-27 15:31:23] VERBOSE[14739][C-00000122] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190528:[2019-05-27 16:01:23] VERBOSE[17907][C-00000124] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190528:[2019-05-27 18:09:26] VERBOSE[31722][C-00000125] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190529:[2019-05-28 10:31:30] VERBOSE[6115][C-00000126] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190529:[2019-05-28 11:53:15] VERBOSE[14677][C-00000127] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190529:[2019-05-28 15:20:16] VERBOSE[4229][C-00000128] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190529:[2019-05-28 15:37:56] VERBOSE[6016][C-00000129] chan_dahdi.c: Detected ring pattern: 337,0,0
/var/log/asterisk/full-20190529:[2019-05-28 17:59:18] VERBOSE[20859][C-0000012a] chan_dahdi.c: Detected ring pattern: 338,0,0
/var/log/asterisk/full-20190529:[2019-05-28 21:46:33] VERBOSE[12455][C-0000012b] chan_dahdi.c: Detected ring pattern: 0,0,0

So I can see there is an anomalous pattern detected as 338,101,41, in detail:

[root@vvs asterisk]# grep C-00000138 /var/log/asterisk/full
[2019-05-29 15:26:59] VERBOSE[27482][C-00000138] sig_analog.c: Starting simple switch on 'DAHDI/1-1'
[2019-05-29 15:27:07] WARNING[27482][C-00000138] sig_analog.c: CallerID returned with error on channel 'DAHDI/1-1'
[2019-05-29 15:27:07] VERBOSE[27482][C-00000138] chan_dahdi.c: Detected ring pattern: 338,101,41
[2019-05-29 15:27:07] VERBOSE[27482][C-00000138] chan_dahdi.c: Checking 0,0,0 with +/- 10 range
[2019-05-29 15:27:07] VERBOSE[27482][C-00000138] chan_dahdi.c: Checking 337,0,0 with +/- 30 range
[2019-05-29 15:27:07] VERBOSE[27482][C-00000138] chan_dahdi.c: Ring pattern 338 is in range: 307 to 367
[2019-05-29 15:27:07] VERBOSE[27482][C-00000138] chan_dahdi.c: Checking 0,0,0 with +/- 10 range
[2019-05-29 15:27:07] VERBOSE[27482][C-00000138] pbx.c: Executing [s@from-analog:1] NoOp("DAHDI/1-1", "Entering from-dahdi with DID == ") in new stack

but the call still worked tho it just carried the DID I have set in the GUI for the channel. Looks like there may have been a fault with CID which messed up the dring detection.

6

Thanks for your response, Lorne. I did not notice your response earlier, or I would have thanked you sooner. I really appreciate your patience with my questions and your willingness to investigate.

At this point, my curiosity has been piqued to the point where I am determined to investigate this problem. I plan to configure a spare server, build Asterisk 13.22.0 and DAHDI Config 14.0.1.14 from source, add a bit of debugging, and figure out what is going on. This isnā€™t something I need to solve right away, but itā€™s bugging me enough that I want to investigate.

1 Like
7

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.