IAX2 call entering at default context with AMI originate

Hi.

First of all, I want to apologize if my english is not perfect. We created a click to call application using AMI originate action, at the beggining we were only used endpoints using SIP protocol and it worked perfectly, but now we’re working at home and now the extensions are using IAX2 protocol, as the click to call aplication needed still to be used, we only modified our originate action, the only difference is that we changed the channel parameter from SIP/xxxx to IAX2/xxxx, the context and extension remains the same. I tested the application and it worked perfectly too.

But two days ago I found at the CDR that the originated calls with IAX2, are not registering the src field, and there aren’t generating call recordings !!!.

I tested the application with SIP extensions and they registered both fileds correctly and thus recordings are generated.

Finally I entered at the CEL recordings and I found that at the moment the channel is created by the click to call using IAX2 is entering at the default context, and I read that this context at FreePBX is indicating either a bug or bad configuration.

I checked a SIP CEL register and it seems good, creating the channel, entering into a defined context and generating the call recording.

What is causing this behaviour?, I really need to know how to fix it, I believe that is something related with the IAX2 configuration, but I could’t find any solution. I hope you can help us.

Thank you very much.

Originate to:

Local/xxx@from-internal

Where X’s are the extension number.

Hi, thank you for your answer :), I recently made the change you said, at the moment the call is not entering at default context :), but unfortunately the problem, of having filled the src field and the recording, remains. The most recently rows are SIP call, and the next ones are IAX2, as you can see even the clid field doesn’t change at IAX call but SIP does.

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