Hello, I looked a bit over the code and actually it is not any MI code there, there is a different control socket (unix file) specific for the module, not having to deal with Kamailio's RPC interface. Likely it is the control socket for an external application, so it should not be a problem from Kamailio point of view, that has not been changed from 4.x to 5.x. Not using that module myself, but it should work unless the external app using that control socket has changed, but the code in Kamailio in v4.x should be the same as in v5.x.

Cheers, Daniel

On Wed, Jun 26, 2019 at 2:20 PM Daniel-Constantin Mierla miconda@gmail.com wrote:

Hello,

are you saying that the call_control module in kamailio is still using MI in version 5.2.x? The code related to MI was removed, should not be any use of it, can you point in the code where that happens? It can be migrated to RPC if is some raw MI operation ...

Cheers, Daniel

On Wed, Jun 26, 2019 at 1:45 PM Efelin Novak efelin.novak@gmail.com wrote:

...

Hi Folks,

I'm migrating to Kamailio 5.2.x from 4.4.x. Everything seems to be fine, however I have came to an issue with call_control module as this one is still using old MI interface.

Standard situations work nice (maximum debit, prepaid, "CDRs") however when call_control needs to kill a call (credit is gone), it tries to send dlg_end_dlg over MI and it fails.

Question are: Is call_control still supported? I haven't found any note about it. Is there any workaround from Kamailio point of view?

I'm running last versions of both applications. I'm also rising a ticket at ag-projects side.

Thanks

Efelin _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Hi Daniel,

so ag-projects (Call-control developer) said the Call-control python app is designed for MI and there is no plan to support anything else ( http://lists.opensips.org/pipermail/users/2019-June/041235.html). So this makes this project unusable in Kamailio 5.x.

I have hacked call-control module to return something, so the Kamailio does not error, but this is just a hack, nothing production.

I humbly suggest to remove call-control from modules or at least write in documentation, that it does not support ag-projects applications anymore.

Anyway thanks for willingness to help

Kind regards

Efelin

st 26. 6. 2019 o 14:45 Efelin Novak efelin.novak@gmail.com napísal(a):

Hi Daniel,

thanks for a reply. No, the module is not using an MI. The Python application call-control is using the MI to end the calls using dlg_end_dlg. I see it like this: the communication from Kamailio to Call-control works, however the communication from Call-Control to Kamailio (I think this is only used to kill a call - http://callcontrol.ag-projects.com/images/prepaid-engine.png) does not. It is using an MI (CallControl -> Kamailio).

I understand this is not your problem (that is why I also post a message to the developer list), but call_control module without call-control application is useless (as far as I understand).

Is there any workaround how to turn the MI on or to have some interface separately, to do MI <-> JSON-RPC?

I want to switch to Evapi and CGRateS, however in a meanwhile I wanted to have both systems running simultaneously.

Again thanks

Efelin

st 26. 6. 2019 o 14:21 Daniel-Constantin Mierla miconda@gmail.com napísal(a):

...

Hello,

are you saying that the call_control module in kamailio is still using MI in version 5.2.x? The code related to MI was removed, should not be any use of it, can you point in the code where that happens? It can be migrated to RPC if is some raw MI operation ...

Cheers, Daniel

On Wed, Jun 26, 2019 at 1:45 PM Efelin Novak efelin.novak@gmail.com wrote:

...

Hi Folks,

I'm migrating to Kamailio 5.2.x from 4.4.x. Everything seems to be fine, however I have came to an issue with call_control module as this one is still using old MI interface.

Standard situations work nice (maximum debit, prepaid, "CDRs") however when call_control needs to kill a call (credit is gone), it tries to send dlg_end_dlg over MI and it fails.

Question are: Is call_control still supported? I haven't found any note about it. Is there any workaround from Kamailio point of view?

I'm running last versions of both applications. I'm also rising a ticket at ag-projects side.

Thanks

Efelin _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Checking quickly on google for call control app for sip, it resulted in a github repository and at my first guess after searching for dlg_end_dlg is that you need to change the line:

* https://github.com/AGProjects/callcontrol/blob/master/callcontrol/opensips.p...

To be from:

cmd = ':dlg_end_dlg:\n%s\n%s\n\n' % (dialog_id.h_entry, dialog_id.h_id)

something like:

cmd = '{ "jsonrpc": "2.0", "method": "dlg.end_dlg", "params": [%s, %s], "id": 1}' % (dialog_id.h_entry, dialog_id.h_id)

You don't need reply_name, because it is using socket file not fifo file for interacting with the sip server. In kamailio use jsonrpcs module configured with a unix socket control file. Not a python developer, so take the above as guidelines, maybe you need some small changes to make the cmd assignment done properly.

Cheers, Daniel

On Thu, Jun 27, 2019 at 2:33 PM Daniel-Constantin Mierla miconda@gmail.com wrote:

Hello, if the external call control is open source, then you can patch it -- the changes should be quite minimal, the format of MI command was line oriented, for jsonrpc is in json format, but the values put there should be the same.

So, for MI, to the Kamailio's fifo file was written something like:

:dlg_end_dlg:_reply_fifo_file_ 342 56 _empty_line_

For JSONRPC, it should be:

{ "jsonrpc": "2.0", "method": "dlg.end_dlg", "params": [342, 56], "reply_name": "_reply_fifo_file_", "id": 1 }

The values 342 and 56 are taken from dialog module example for v4.4, representing dialog id values (hash id and label), so they are specific for each call.

Likely you have to also handle the response that will be in json format, but expecting again to be something simple to deal with.

The alternative will be to make a FIFO proxy to translate from MI to JSONRPC and back for this specific command -- it should be several lines of python, node or other scripting language.

Cheers,

Daniel

On Thu, Jun 27, 2019 at 11:29 AM Efelin Novak efelin.novak@gmail.com wrote:

...

Hi Daniel,

so ag-projects (Call-control developer) said the Call-control python app is designed for MI and there is no plan to support anything else ( http://lists.opensips.org/pipermail/users/2019-June/041235.html). So this makes this project unusable in Kamailio 5.x.

I have hacked call-control module to return something, so the Kamailio does not error, but this is just a hack, nothing production.

I humbly suggest to remove call-control from modules or at least write in documentation, that it does not support ag-projects applications anymore.

Anyway thanks for willingness to help

Kind regards

Efelin

st 26. 6. 2019 o 14:45 Efelin Novak efelin.novak@gmail.com napísal(a):

...

Hi Daniel,

thanks for a reply. No, the module is not using an MI. The Python application call-control is using the MI to end the calls using dlg_end_dlg. I see it like this: the communication from Kamailio to Call-control works, however the communication from Call-Control to Kamailio (I think this is only used to kill a call - http://callcontrol.ag-projects.com/images/prepaid-engine.png) does not. It is using an MI (CallControl -> Kamailio).

I understand this is not your problem (that is why I also post a message to the developer list), but call_control module without call-control application is useless (as far as I understand).

Is there any workaround how to turn the MI on or to have some interface separately, to do MI <-> JSON-RPC?

I want to switch to Evapi and CGRateS, however in a meanwhile I wanted to have both systems running simultaneously.

Again thanks

Efelin

st 26. 6. 2019 o 14:21 Daniel-Constantin Mierla miconda@gmail.com napísal(a):

...

Hello,

are you saying that the call_control module in kamailio is still using MI in version 5.2.x? The code related to MI was removed, should not be any use of it, can you point in the code where that happens? It can be migrated to RPC if is some raw MI operation ...

Cheers, Daniel

On Wed, Jun 26, 2019 at 1:45 PM Efelin Novak efelin.novak@gmail.com wrote:

...

Hi Folks,

I'm migrating to Kamailio 5.2.x from 4.4.x. Everything seems to be fine, however I have came to an issue with call_control module as this one is still using old MI interface.

Standard situations work nice (maximum debit, prepaid, "CDRs") however when call_control needs to kill a call (credit is gone), it tries to send dlg_end_dlg over MI and it fails.

Question are: Is call_control still supported? I haven't found any note about it. Is there any workaround from Kamailio point of view?

I'm running last versions of both applications. I'm also rising a ticket at ag-projects side.

Thanks

Efelin _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

---

Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda