[PHREAKNET-62] Trunk calls where a #7 is keyed a second tone is inserted
When sending MF over the Operator Trunk I hear two tones when I send a 7.
This means that any number with 7 in it fails.
I have made a call using the same MF keypad over other lines, which has indicated that there is no second tone inserted on a call including a 7, so not the MF Keypad, I have tried another keypad and received the same result on both types of circuit.
I have checked the ATA, rebooted the Tandem node server.
Please could you let me know what else I need to provide to resolve this issue?
Comments
11/26/2025 4:54 PM — paulash134
Core debug was 0 and has been set to 5 for 'app_mf'.
[Nov 26 21:42:53] == Using SIP RTP Audio TOS bits 184
[Nov 26 21:42:53] == Using SIP RTP Audio TOS bits 184 in TCLASS field.
[Nov 26 21:42:53] -- Executing [2@hotline2:1] Wait("PJSIP/Operator3000-00000020", "2") in new stack
[Nov 26 21:42:55] -- Executing [2@hotline2:2] Dial("PJSIP/Operator3000-00000020", "IAX2/phreaknetopkeyset:[email protected]/trunk") in new stack
[Nov 26 21:42:55] -- Called IAX2/phreaknetopkeyset:[email protected]/trunk
[Nov 26 21:42:56] -- Call accepted by 64.227.30.169:4569 (format ulaw)
[Nov 26 21:42:56] -- Format for call is (ulaw)
[Nov 26 21:42:56] -- IAX2/phreaknet-operator-trunk-11248 is making progress passing it to PJSIP/Operator3000-00000020
[Nov 26 21:42:56] -- IAX2/phreaknet-operator-trunk-11248 is making progress passing it to PJSIP/Operator3000-00000020
[Nov 26 21:42:56] > 0x7eff7805d740 -- Strict RTP learning after remote address set to: 192.168.1.108:5012
[Nov 26 21:42:56] > 0x7eff7805d740 -- Strict RTP switching to RTP target address 192.168.1.108:5012 as source
[Nov 26 21:43:01] > 0x7eff7805d740 -- Strict RTP learning complete - Locking on source address 192.168.1.108:5012
[Nov 26 21:43:16] -- Hungup 'IAX2/phreaknet-operator-trunk-11248'
[Nov 26 21:43:16] == Spawn extension (hotline2, 2, 2) exited non-zero on 'PJSIP/Operator3000-00000020'
This is all that I can see from this end.
I plug into the Operator Trunk and hear the tone to start keying
I am sending KP 234 047 121 ST
This then returns reorder tone
11/26/2025 5:27 PM — InterLinked
Okay, it looks like the trunk you are accessing here in on a different system, so the debug wouldn't apply.
This is something I'd like to troubleshoot by phone sometime, on or after December 12th when you have time.
11/26/2025 6:02 PM — paulash134
Look forward to speaking to you after December 12th, I think it will be the following week. December 15th onward.
1/2/2026 8:41 PM — InterLinked
Paul, is this still an issue?
1/4/2026 5:47 AM — paulash134
Yes it is still happening, I just tried it now on the Trunk 9804000 This is the CLI response at that time.
[Jan 4 10:25:45] == Using SIP RTP Audio TOS bits 184
[Jan 4 10:25:45] == Using SIP RTP Audio TOS bits 184 in TCLASS field.
[Jan 4 10:25:45] -- Executing [2@hotline2:1] Wait("PJSIP/Operator4000-00000119", "2") in new stack
[Jan 4 10:25:47] -- Executing [2@hotline2:2] Dial("PJSIP/Operator4000-00000119", "IAX2/phreaknetopkeyset:[email protected]/trunk") in new stack
[Jan 4 10:25:47] -- Called IAX2/phreaknetopkeyset:[email protected]/trunk
[Jan 4 10:25:47] -- Call accepted by 64.227.30.169:4569 (format ulaw)
[Jan 4 10:25:47] -- Format for call is (ulaw)
[Jan 4 10:25:47] -- IAX2/phreaknet-operator-trunk-5526 is making progress passing it to PJSIP/Operator4000-00000119
[Jan 4 10:25:47] -- IAX2/phreaknet-operator-trunk-5526 is making progress passing it to PJSIP/Operator4000-00000119
[Jan 4 10:25:47] > 0x7fbf6c095870 -- Strict RTP learning after remote address set to: 192.168.1.108:5016
[Jan 4 10:25:47] > 0x7fbf6c095870 -- Strict RTP switching to RTP target address 192.168.1.108:5016 as source
[Jan 4 10:25:52] > 0x7fbf6c095870 -- Strict RTP learning complete - Locking on source address 192.168.1.108:5016
[Jan 4 10:26:15] -- Hungup 'IAX2/phreaknet-operator-trunk-5526'
[Jan 4 10:26:15] == Spawn extension (hotline2, 2, 2) exited non-zero on 'PJSIP/Operator4000-00000119'
1/4/2026 10:55 AM — InterLinked
I got your message to repair service, could you give me a call directly so we can take a look at this? I tried calling you back but it didn't go through.
1/4/2026 11:31 AM — InterLinked
Resolved by disabling the MF "echo back" after a DTMF digit is dialed on the trunk... unfortunately the loosey goosey DTMF detection used by Asterisk and the ATA causes this to get treated as DTMF "3" and sent back to us. Best to avoid combining MF and DTMF on the same call.
You must be logged in to leave a comment.
11/26/2025 4:05 PM — InterLinked
Please provide a dialplan CLI trace of when the issue occurs.
Also run
core set debug 5 app_mfprior and make sure debug logs are going to the console.