Manager atxfer issues

Hello,

Thought I’d post this here and see if anyone else have been experiencing this issue. We’re currently on Asterisk 11, and it seems as if there is an issue with triggering the atxfer command when the dialplan requires a + sign in front of the number (+ being the international prefix).

The callcenter context looks like this:

_+X. => { //Do something }

The command that is being triggered is like this:

In the console I then see:

So, it appears that the + sign is being ignored. It is also worth noting that changing the action from atxfer to redirect will work, so it seems to be a bug in the way the manager is treating the atxfer command.

As this is a URL, + would be translated to space. Try with the uriencoding of + (%xx), for the right xx.

Hi David, and thanks for the suggestion.

As a matter of fact, I already tried this. The encoded version would look something like this:

http://asterisk_server/asterisk/manager?action=atxfer&channel=SIP/100&exten=%2B44[number]&context=callcenter&priority=1

However, that does not change the outcome.

It might be the reverse problem. Asterisk might not be decoding the URI, but the browser is encoding it, so already sending %2B.

Why don’t you use the native AMI interface, rather than the http: one?

Hi David,

Thanks for the suggestion.

If that was the case, I should see the same issues when triggering a redirect or originate command, wouldn’t you agree? The problem only exist on atxfer.

The reason the http api is used is just because it is simpler to communicate than using a socket connection. It also works just fine, with the exception of this issue. I can, of course, code my way around it by forcing a + to be added to any number sent to that particular context which doesn’t already have + preceding the dialed number, but it’s just that to me this looks like inconsistencies in the way the manager behaves, and if that is the case, a more appropriate way of dealing with the matter is to eliminate the inconsistency.