[SR-Users] Kamailio 5.x and Call_control module

Fri Jun 28 08:30:51 CEST 2019

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.py#L177

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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at 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
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190628/7827e392/attachment.html>