[Solved] hash/pound/# key translated to %23 issue

Hello,

I am starting with Asterisk for a few weeks now.

I found help to implement my solution that consists in :

  • an AsteriskNow 1.7 + FreePBX machine. FreePBX upgraded to 2.8.1.4 + a few standard modules.
  • a Cisco SPA5xx IP Phone
  • Cisco’s SPA8800 gateway (4FXO + 4FXS)

French analog lines support call forwarding using 210606060606# dial sequence. 0606060606 is number to forward calls to. We use #21# to cancel.

I modified SPAs’ dial plan to allow this. It was working fine since today. I’ve made some changes yesterday, including Asterisk Yum udpate to 1.6.2.17.3, in order to have Reports working. And they run fine now.

But… today, we couldn’t use the call forwarding because it seems that Asterisk translates the # key to %23. From SPAs’ and also from softphones.

I certainly made some other config changes yesterday evening (french prompts…) but I can’t remember them all.

CLI says :

-- Executing [s@macro-outbound-callerid:12] ExecIf("SIP/1711-00000050", "1?Set(CALLERID(all)=0321212121)") in new stack -- Executing [s@macro-outbound-callerid:13] ExecIf("SIP/1711-00000050", "0?Set(CALLERID(all)=)") in new stack -- Executing [s@macro-outbound-callerid:14] ExecIf("SIP/1711-00000050", "0?Set(CALLERID(all)=)") in new stack -- Executing [s@macro-outbound-callerid:15] ExecIf("SIP/1711-00000050", "0?Set(CALLERPRES()=prohib_passed_screen)") in new stack -- Executing [s@macro-dialout-trunk:12] GosubIf("SIP/1711-00000050", "0?sub-flp-2,s,1") in new stack -- Executing [s@macro-dialout-trunk:13] Set("SIP/1711-00000050", "OUTNUM=%2321%23") in new stack -- Executing [s@macro-dialout-trunk:14] Set("SIP/1711-00000050", "custom=SIP/fxo1") in new stack -- Executing [s@macro-dialout-trunk:15] ExecIf("SIP/1711-00000050", "0?Set(DIAL_TRUNK_OPTIONS=M(setmusic^default))") in new stack -- Executing [s@macro-dialout-trunk:16] Macro("SIP/1711-00000050", "dialout-trunk-predial-hook,") in new stack -- Executing [s@macro-dialout-trunk-predial-hook:1] MacroExit("SIP/1711-00000050", "") in new stack -- Executing [s@macro-dialout-trunk:17] GotoIf("SIP/1711-00000050", "0?bypass,1") in new stack -- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/1711-00000050", "0?customtrunk") in new stack -- Executing [s@macro-dialout-trunk:19] Dial("SIP/1711-00000050", "SIP/fxo1/%2321%23,300,") in new stack

I found sb with same issue on one other forum but w/o solution. A quick search here did’t help. I hope I did not miss it :wink:

Does somebody knows what I am suffering from ?

If not, I will rollback with backups and I’ll repeat changes step by step and test.

Thks for help. Sorry for bad english :wink:

URL encoding is legitimate. I’m not sure if SIP URLs can have fragments, but it might even be necessary. The real problem is probably with an over-simplified SIP implementation at the other end, that is failing to undo the URL encoding.

I suspect adding an option to control this behaviour (to work round broken third party systems) would constitute a feature request, so you would need to provide a source code patch against the trunk version, to put it into the issue tracker.

RFC 1738:

So it doesn’t actually matter whether fragments are possible.

I had assumed that you were using a SIP based PSTN provider.

It looks like Asterisk is failing to URL decode.

You will need to reproduce this on 1.8.x to submit an acceptable bug report, as 1.6.2 is closed to non-security bugs.

If Asterisk is failing to URL decode, you could do so explicitly, in the dialplan, by calling ${URIDECODE(…)}.

In case it is not clear, the translation will be being done in the phones. The problem is that it is not being reversed before dialling the FXO.

Actually, it looks like the pedantic SIP checking option may control this.

Hello David,

thanks a lot for your answers and help.

I worked on it yesterday and solved this issue by upgrading Asterisk to 1.8.3.3 (+ add-ons)

Indeed, even dialing from softphone to sip trunk showed %23 in reports and CLI… so nothing to do with Cisco’s FXO gateway.

No, just a Cisco SPA8800 Gateway… which provides 4 PSTN through SIP + 4 FXS.

Now I still have another issue that might be a problem between french pstn provider and the SPA… but it is another topic… not Asterisk linked I suppose.

Thanks again !!