How do you send an Octothorp?

[leejor]

I'm using 3 digit numbers starting with "1" as speed call numbers. With "normal" phone numbers this works just fine. Dial 123 , sends on a PSTN trunk using a SPA-3102. Strips 3 digits and prepends with the 10 digit local number. However I need to be able to activate and deactivate call forwarding fixed using 72# and 73# respectively.

I've created a speedcall number for each, stripping 3 digits and prepending with the codes. What is being send, however is, 7223 and 7323. Is there some special way to send an octothorp? Could this something that the 3102 is misinterpreting?
Thanks, Lee

 

[William400]

HI

From the 3CX support perspective we do not go into using these codes on the devices. We woudl recommend that you use forwarding rules in the 3CX extension / line settings to achieve what your require.

 

[leejor]

I'm going to have to "play with this" to try and get it to work. The Call Forward Fixed is a feature i pay for from the PSTN telephone company and use all the time when i want calls to go directly to my mobile. I can currently activate and deactivate remotely via a DISA Port , or via a speed call code, on the analog PBX I want to eventually replace.

 

[William400]

Hi

You could get 3CX to pickup the call and divert to your mobile.

 

[leejor]

That assumes that there is a second line to send the call out on. Even if there is it won't pass the callers number to the mobile as does PSTN call forwarding, you'd only get the number of your outgoing line showing up on your phone, then you can't screen your calls, which is very important to me.

 

[leejor]

Well, I'm still working on this as the call forward feature has to be activated and deactivated on one of the incoming lines to forward afterhour calls to another number and caller ID of the callers number MUST be sent, so using the call forward feature of the pbx just won't work

The log on 3CX shows the info going out to the SPA-3102 is correct...

17:32:38.697 [CM503004]: Call(61): Calling: PSTNline:72#@(Ln.10002@689)@[Dev:sip:[email protected]:5065]

However, the 3102 shows the received info is different...

<sip:72%[email protected]:5065>;tag=e45e126ce9582048i1<013><010>From: <sip:[email protected]:5060>;tag=3a644405<013><010>Call-ID:

So somehow the # is being converted to %23. The 3102 is dialing 7232

I've tried using Wireshark to see which end is being truthfull but I don't actually see the number being sent.

Does anyone else send the # to a PSTN line as part of a dialstring to activate phone company features?

Thanks

 

[Cjay]

I've tried using Wireshark to see which end is being truthfull but I don't actually see the number being sent.

I don't have the answer to this problem but I can tell you what is happening:
It is the 3cx end which converts the # in your 72# dial string and actually sends it out to your SPA3102 as 72%23 (23 is the hex ASCII code for #). The % sign gets ignored by the 3102 when dialing out on the PSTN line.

I have had a small degree of success by setting a VoIP to PSTN dial plan in the SPA3102 that intercepts the incoming dial stream and replaces the %23 with a # (<%23:#>) where the # does get dialed out on the PSTN line. However this is only a part of the problem since you need to create a plan that passes all other digits/strings unchanged. I think it can be done in the 3102, but I am not particularly expert in this area!

Good luck.

Chris

 

[leejor]

I was thinking I will have to do something like that as there are no other digits being sent to the 3102 that begin with 72 or 73. I'm very surprised that the 3CX won't actually send the "dialable" digit (#), even though it seem to give every indication that it is.

 

[smtharrison]

Having the same problem. Has anyone gotten an answer from 3cx on why the # is converted to the ASCII code? trying to integrate a school PA system that uses #0000 for all call, but having the same issue.

 

[leejor]

Since I first posted that I do not recall seeing any solution in the forums, at least when using the Linksys SPA series gateways as I was. Other gateways may behave differently. I was trying to activate a call forward feature on the PSTN line, a simple wait (time out) was used instead.