Hello,
based on lib linking in Makefiles, the following modules still use MI, categorized by their state from my point of view. Hopefully some other people will help with those listed in 2) to 6).
1) to be removed
- mi_datagram - mi_fifo - mi_rpc - mi_xmlrpc - pua_mi
2) rpc commands implemented
- dialog - others modules depend on some mi callback from it (qos and sst) - qos - this looks ready to wipe out the mi code, but didn't get the time not analyze properly as I don't use it usually
3) some rpc commands implemented and the rest should not be very complex
- carrierroute - I implemented the dump rpc command, but it was reported that it has issues, so it needs follow up.
4) rpc commands have to be implemented, expecting not to be very complex
- cplc - imc
5) expecting some degree of complexity, but they are important modules
- rtpengine - rtpproxy
6) not familiar with the mi commands in these modules, so not able to assert what to expect
- ims_dialog - some rpc commands are implemented, not sure if the rest of MI are used/usefull - mohqueue - it doesn't seem complex to implement rpc commands at first sight, but the indentation style didn't allowed a fast analyze on a quick look - p_usrloc - several mi commands - sst - uses some callback for MI from dialog module. qos has something similar with rpc alternative already implemented - userblacklist - several mi commands - utils - there are few mi commands related to some forwarding rules: https://www.kamailio.org/docs/modules/devel/modules/utils.html#idp21741924
The 1) to 5) should be done in a way or another, before of after freeze of 5.0.0. But 6) would require the devs of the modules (or the MI parts) to help if they want those commands via RPC.
Cheers, Daniel
I will take a look at mohqueue tomorrow and see what I can do. However, if rtpproxy doesn't work, neither will mohqueue.
Bob
On Mon, Jan 2, 2017 at 5:17 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
based on lib linking in Makefiles, the following modules still use MI, categorized by their state from my point of view. Hopefully some other people will help with those listed in 2) to 6).
to be removed
- mi_datagram
- mi_fifo
- mi_rpc
- mi_xmlrpc
- pua_mi
rpc commands implemented
- dialog - others modules depend on some mi callback from it (qos and
sst)
- qos - this looks ready to wipe out the mi code, but didn't get the
time not analyze properly as I don't use it usually
- some rpc commands implemented and the rest should not be very complex
- carrierroute - I implemented the dump rpc command, but it was
reported that it has issues, so it needs follow up.
- rpc commands have to be implemented, expecting not to be very complex
- cplc
- imc
- expecting some degree of complexity, but they are important modules
- rtpengine
- rtpproxy
- not familiar with the mi commands in these modules, so not able to
assert what to expect
- ims_dialog - some rpc commands are implemented, not sure if the rest
of MI are used/usefull
- mohqueue - it doesn't seem complex to implement rpc commands at
first sight, but the indentation style didn't allowed a fast analyze on a quick look
- p_usrloc - several mi commands
- sst - uses some callback for MI from dialog module. qos has
something similar with rpc alternative already implemented
- userblacklist - several mi commands
- utils - there are few mi commands related to some forwarding rules:
https://www.kamailio.org/docs/modules/devel/modules/utils.html#idp21741924
The 1) to 5) should be done in a way or another, before of after freeze of 5.0.0. But 6) would require the devs of the modules (or the MI parts) to help if they want those commands via RPC.
Cheers, Daniel
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
On 02/01/2017 23:49, Robert Boisvert wrote:
I will take a look at mohqueue tomorrow and see what I can do. However, if rtpproxy doesn't work, neither will mohqueue.
Thanks, getting mohqueue updated to rpc would be appreciated! Rtpproxy module has some rpc commands already and the plan is to implement all of them.
Cheers, Daniel
Bob
On Mon, Jan 2, 2017 at 5:17 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, based on lib linking in Makefiles, the following modules still use MI, categorized by their state from my point of view. Hopefully some other people will help with those listed in 2) to 6). 1) to be removed - mi_datagram - mi_fifo - mi_rpc - mi_xmlrpc - pua_mi 2) rpc commands implemented - dialog - others modules depend on some mi callback from it (qos and sst) - qos - this looks ready to wipe out the mi code, but didn't get the time not analyze properly as I don't use it usually 3) some rpc commands implemented and the rest should not be very complex - carrierroute - I implemented the dump rpc command, but it was reported that it has issues, so it needs follow up. 4) rpc commands have to be implemented, expecting not to be very complex - cplc - imc 5) expecting some degree of complexity, but they are important modules - rtpengine - rtpproxy 6) not familiar with the mi commands in these modules, so not able to assert what to expect - ims_dialog - some rpc commands are implemented, not sure if the rest of MI are used/usefull - mohqueue - it doesn't seem complex to implement rpc commands at first sight, but the indentation style didn't allowed a fast analyze on a quick look - p_usrloc - several mi commands - sst - uses some callback for MI from dialog module. qos has something similar with rpc alternative already implemented - userblacklist - several mi commands - utils - there are few mi commands related to some forwarding rules: https://www.kamailio.org/docs/modules/devel/modules/utils.html#idp21741924 <https://www.kamailio.org/docs/modules/devel/modules/utils.html#idp21741924> The 1) to 5) should be done in a way or another, before of after freeze of 5.0.0. But 6) would require the devs of the modules (or the MI parts) to help if they want those commands via RPC. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com> _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
All,
mohqueue was updated to use RPC instead of MI commands.
Bob
On Tue, Jan 3, 2017 at 3:22 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 02/01/2017 23:49, Robert Boisvert wrote:
I will take a look at mohqueue tomorrow and see what I can do. However, if rtpproxy doesn't work, neither will mohqueue.
Thanks, getting mohqueue updated to rpc would be appreciated! Rtpproxy module has some rpc commands already and the plan is to implement all of them.
Cheers, Daniel
Bob
On Mon, Jan 2, 2017 at 5:17 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
based on lib linking in Makefiles, the following modules still use MI, categorized by their state from my point of view. Hopefully some other people will help with those listed in 2) to 6).
to be removed
- mi_datagram
- mi_fifo
- mi_rpc
- mi_xmlrpc
- pua_mi
rpc commands implemented
- dialog - others modules depend on some mi callback from it (qos and
sst)
- qos - this looks ready to wipe out the mi code, but didn't get the
time not analyze properly as I don't use it usually
- some rpc commands implemented and the rest should not be very complex
- carrierroute - I implemented the dump rpc command, but it was
reported that it has issues, so it needs follow up.
- rpc commands have to be implemented, expecting not to be very complex
- cplc
- imc
- expecting some degree of complexity, but they are important modules
- rtpengine
- rtpproxy
- not familiar with the mi commands in these modules, so not able to
assert what to expect
- ims_dialog - some rpc commands are implemented, not sure if the rest
of MI are used/usefull
- mohqueue - it doesn't seem complex to implement rpc commands at
first sight, but the indentation style didn't allowed a fast analyze on a quick look
- p_usrloc - several mi commands
- sst - uses some callback for MI from dialog module. qos has
something similar with rpc alternative already implemented
- userblacklist - several mi commands
- utils - there are few mi commands related to some forwarding rules:
https://www.kamailio.org/docs/modules/devel/modules/utils.ht ml#idp21741924
The 1) to 5) should be done in a way or another, before of after freeze of 5.0.0. But 6) would require the devs of the modules (or the MI parts) to help if they want those commands via RPC.
Cheers, Daniel
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Thanks, Daniel
On 06/01/2017 21:01, Robert Boisvert wrote:
All,
mohqueue was updated to use RPC instead of MI commands.
Bob
On Tue, Jan 3, 2017 at 3:22 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, On 02/01/2017 23:49, Robert Boisvert wrote:I will take a look at mohqueue tomorrow and see what I can do. However, if rtpproxy doesn't work, neither will mohqueue.Thanks, getting mohqueue updated to rpc would be appreciated! Rtpproxy module has some rpc commands already and the plan is to implement all of them. Cheers, DanielBob On Mon, Jan 2, 2017 at 5:17 PM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote: Hello, based on lib linking in Makefiles, the following modules still use MI, categorized by their state from my point of view. Hopefully some other people will help with those listed in 2) to 6). 1) to be removed - mi_datagram - mi_fifo - mi_rpc - mi_xmlrpc - pua_mi 2) rpc commands implemented - dialog - others modules depend on some mi callback from it (qos and sst) - qos - this looks ready to wipe out the mi code, but didn't get the time not analyze properly as I don't use it usually 3) some rpc commands implemented and the rest should not be very complex - carrierroute - I implemented the dump rpc command, but it was reported that it has issues, so it needs follow up. 4) rpc commands have to be implemented, expecting not to be very complex - cplc - imc 5) expecting some degree of complexity, but they are important modules - rtpengine - rtpproxy 6) not familiar with the mi commands in these modules, so not able to assert what to expect - ims_dialog - some rpc commands are implemented, not sure if the rest of MI are used/usefull - mohqueue - it doesn't seem complex to implement rpc commands at first sight, but the indentation style didn't allowed a fast analyze on a quick look - p_usrloc - several mi commands - sst - uses some callback for MI from dialog module. qos has something similar with rpc alternative already implemented - userblacklist - several mi commands - utils - there are few mi commands related to some forwarding rules: https://www.kamailio.org/docs/modules/devel/modules/utils.html#idp21741924 <https://www.kamailio.org/docs/modules/devel/modules/utils.html#idp21741924> The 1) to 5) should be done in a way or another, before of after freeze of 5.0.0. But 6) would require the devs of the modules (or the MI parts) to help if they want those commands via RPC. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com> _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev> _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>-- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com> _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>
On 03/01/2017 10:00, Victor Seva wrote:
On 01/02/2017 11:17 PM, Daniel-Constantin Mierla wrote:
- expecting some degree of complexity, but they are important modules
- rtpengine
I'm going to coordinate with Richard and work on rtpengine
Thanks! To start this, I just pushed the commit with the implementation of the rpc command rtpengine.reload.
I think the enable and list (show) commands can be inspired from the rtpproxy module -- rtpengine has more options though, but could be a good starting point.
I will try to look at the other modules, hopefully you or Richard get the time for rtpengine.
Cheers, Daniel
Hello,
couple of more modules were updated for rpc only: qos, sst, cplc, imc, rtpproxy. Dialog module is ready to get the mi code removed.
Rtpengine and mohqueue should be worked on in the near future by devs.
Given the very small amount of what is left, later today I will remove the libkmi and comment (within ifdefs) the implementation of mi commands in the modules that still have them. That should help implementing the rpc alternatives, which can be done during the testing period as a fix of a regression.
Cheers, Daniel
On 02/01/2017 23:17, Daniel-Constantin Mierla wrote:
Hello,
based on lib linking in Makefiles, the following modules still use MI, categorized by their state from my point of view. Hopefully some other people will help with those listed in 2) to 6).
to be removed
- mi_datagram
- mi_fifo
- mi_rpc
- mi_xmlrpc
- pua_mi
rpc commands implemented
- dialog - others modules depend on some mi callback from it (qos and sst)
- qos - this looks ready to wipe out the mi code, but didn't get the
time not analyze properly as I don't use it usually
- some rpc commands implemented and the rest should not be very complex
- carrierroute - I implemented the dump rpc command, but it was
reported that it has issues, so it needs follow up.
- rpc commands have to be implemented, expecting not to be very complex
- cplc
- imc
- expecting some degree of complexity, but they are important modules
- rtpengine
- rtpproxy
- not familiar with the mi commands in these modules, so not able to
assert what to expect
- ims_dialog - some rpc commands are implemented, not sure if the rest
of MI are used/usefull
- mohqueue - it doesn't seem complex to implement rpc commands at
first sight, but the indentation style didn't allowed a fast analyze on a quick look
- p_usrloc - several mi commands
- sst - uses some callback for MI from dialog module. qos has
something similar with rpc alternative already implemented
- userblacklist - several mi commands
- utils - there are few mi commands related to some forwarding rules:
https://www.kamailio.org/docs/modules/devel/modules/utils.html#idp21741924
The 1) to 5) should be done in a way or another, before of after freeze of 5.0.0. But 6) would require the devs of the modules (or the MI parts) to help if they want those commands via RPC.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Robert Boisvert -
Victor Seva