Hi,
What is the idiomatic way to call an RPC from a remote HTTP client in the 5.1.x series?
I'd like to invoke mtree.reload from a remote HTTP client.
My goal is to avoid a dependency on kamcmd on the remote client system - it would be nice to be able to issue a HTTP RPC which could be implemented in any environment.
Or should I be looking to implement a BINRPC client on the remote system?
TIA,
Ben
Hello,
you can do jsonrpc over http/s by using jsonrpcs+xhttp modules -- example at:
- https://www.kamailio.org/docs/modules/stable/modules/jsonrpcs.html#jsonrpcs....
There is also an xmlrpc module that works over http/s.
Cheers, Daniel
On 02.03.18 09:57, Ben Hood wrote:
Hi,
What is the idiomatic way to call an RPC from a remote HTTP client in the 5.1.x series?
I'd like to invoke mtree.reload from a remote HTTP client.
My goal is to avoid a dependency on kamcmd on the remote client system
- it would be nice to be able to issue a HTTP RPC which could be
implemented in any environment.
Or should I be looking to implement a BINRPC client on the remote system?
TIA,
Ben
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Cool, many thanks for the heads up.
So jsonrpc_dispatch() in the request handler binds to the method parameter in the JSON blob sent by the client to the corresponding internal management function?
On Fri, Mar 2, 2018 at 9:12 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
you can do jsonrpc over http/s by using jsonrpcs+xhttp modules -- example at:
https://www.kamailio.org/docs/modules/stable/modules/jsonrpcs.html#jsonrpcs....
There is also an xmlrpc module that works over http/s.
Hi Ben,
we're using something like this to do dispatcher.reload:
``` event_route[xhttp:request] { if ($hu =~ "^/rpc") { $var(command) = $(hu{s.select,2,/}); $var(parameter) = $(hu{s.select,3,/});
if($var(command) == "reload.dispatchers") { route(DISPATCHER_LIST); xhttp_reply("200", "OK", "text/html", "Dispatchers Set for RELOAD"); exit; } ... } ```
And then in the DISPATCHER_LIST route we do an API call for fetching the updated dispatcher list for that node. After the dispatcher list is updated we just run: jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": "1"}');
So you can just put a `jsonrpc_exec` inside the event_route[xhttp:request].
Kind regards, -- Aleksandar Sosic mail: alex.sosic@timenet.it skype: alex.sosic cell: +385 91 2505 146
On Fri, Mar 2, 2018 at 10:16 AM, Ben Hood 0x6e6562@gmail.com wrote:
Cool, many thanks for the heads up.
So jsonrpc_dispatch() in the request handler binds to the method parameter in the JSON blob sent by the client to the corresponding internal management function?
On Fri, Mar 2, 2018 at 9:12 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
you can do jsonrpc over http/s by using jsonrpcs+xhttp modules -- example at:
https://www.kamailio.org/docs/modules/stable/modules/jsonrpcs.html#jsonrpcs....
There is also an xmlrpc module that works over http/s.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
use jsonrcp_dispatch() when you want the rpc command response to be sent back via incoming transport (http in this case).
jsonrpc_exec() should be used when you want to do it from normal SIP routing blocks and get the jsonrpc response in a local variable.
Cheers, Daniel
On 02.03.18 10:29, Aleksandar Sosic wrote:
Hi Ben,
we're using something like this to do dispatcher.reload:
event_route[xhttp:request] { if ($hu =~ "^/rpc") { $var(command) = $(hu{s.select,2,/}); $var(parameter) = $(hu{s.select,3,/}); if($var(command) == "reload.dispatchers") { route(DISPATCHER_LIST); xhttp_reply("200", "OK", "text/html", "Dispatchers Set for RELOAD"); exit; } ... }
And then in the DISPATCHER_LIST route we do an API call for fetching the updated dispatcher list for that node. After the dispatcher list is updated we just run: jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": "1"}');
So you can just put a `jsonrpc_exec` inside the event_route[xhttp:request].
Kind regards,
Aleksandar Sosic mail: alex.sosic@timenet.it skype: alex.sosic cell: +385 91 2505 146
On Fri, Mar 2, 2018 at 10:16 AM, Ben Hood 0x6e6562@gmail.com wrote:
Cool, many thanks for the heads up.
So jsonrpc_dispatch() in the request handler binds to the method parameter in the JSON blob sent by the client to the corresponding internal management function?
On Fri, Mar 2, 2018 at 9:12 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
you can do jsonrpc over http/s by using jsonrpcs+xhttp modules -- example at:
https://www.kamailio.org/docs/modules/stable/modules/jsonrpcs.html#jsonrpcs....
There is also an xmlrpc module that works over http/s.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Fri, Mar 2, 2018 at 11:06 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
use jsonrcp_dispatch() when you want the rpc command response to be sent back via incoming transport (http in this case).
jsonrpc_exec() should be used when you want to do it from normal SIP routing blocks and get the jsonrpc response in a local variable.
OK, so jsonrcp_dispatch() invokes the underlying RPC method defined in the request and writes the result back into the HTTP response?
And jsonrpc_exec() invokes the underlying RPC method and instead of writing the result back to the socket, it stores the result in a variable?
Hey Aleksandar,
Many thanks for the heads up - very interesting to see how other people are doing this.
So if I understand you correctly, you have a dynamic list of dispatchers.
And then you invoke "dispatcher.reload" to reload all of the dispatchers you have defined dynamically?
What does the DISPATCHER_LIST route look like?
Cheers, Ben
On Fri, Mar 2, 2018 at 9:29 AM, Aleksandar Sosic alex.sosic@timenet.it wrote:
Hi Ben,
we're using something like this to do dispatcher.reload:
event_route[xhttp:request] { if ($hu =~ "^/rpc") { $var(command) = $(hu{s.select,2,/}); $var(parameter) = $(hu{s.select,3,/}); if($var(command) == "reload.dispatchers") { route(DISPATCHER_LIST); xhttp_reply("200", "OK", "text/html", "Dispatchers Set for RELOAD"); exit; } ... }
And then in the DISPATCHER_LIST route we do an API call for fetching the updated dispatcher list for that node. After the dispatcher list is updated we just run: jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": "1"}');
So you can just put a `jsonrpc_exec` inside the event_route[xhttp:request].
Hi Ben,
we are working on a dockerized infrastructure orchestrated with Kubernetes with two kamailio layers, a `proxy` and a `router` level. In a stateless infrastructure like that we need to have also a SIP orchestrator that will handle all the active and ready nodes and notify or provide the correct information to all the other nodes upon changes in the infrastructure.
So upon the creation of a `router` node we will give it a list of `proxy` nodes (Kamailio), `TPS` (transcoding and playback handled by asterisk), `RTPs` (rtpengine). When that container (aka Pod in kubernetes) starts and it's ready we also notify the `proxy` nodes to reload the dispatcher list and add the new node. We do that via API.
The API is a Node.js application using GraphQL query language. So our DISPATCHER_LIST route does an async http request to the API: ``` route[DISPATCHER_LIST] { if($sht(api=>token) == $null) { route(GET_API_TOKEN); } $http_req(method) = "POST"; $http_req(hdr) = "Content-Type: application/json"; $http_req(hdr) = "Authorization: Bearer " + $sht(api=>token); $var(graphql_query) = "{"query": "{ kamailio { dispatcher { list { kamailioConf } } } }"}"; $http_req(body) = $var(graphql_query); http_async_query(API_QUERY_URL, "DISPATCHER_SET"); } ```
We're using the JWT as authentication/security between nodes and API.
the DISPATCHER_SET route then handles the async response: ``` route[DISPATCHER_SET] { jansson_get("data.kamailio.dispatcher.list.kamailioConf", $http_rb, "$var(api_conf)"); if($var(api_conf) != "0") { exec_msg("printf "$var(api_conf)" > /tmp/dispatcher.list"); jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": "1"}'); ... } ```
Those are simplified routes without logs and checks and failovers. As you can immagine the dispatcher module has a param like this: ``` modparam("dispatcher", "list_file", "/tmp/dispatcher.list") ```
I'll be giving a speech on CD/CI and Kamailio route testing in a dockerized environment like this at this year Kamailio World Conference in Berlin: https://www.kamailioworld.com/k06/speakers/
If you're attending the event we can discuss this further ad visum.
Kind regards, -- Aleksandar Sosic mail: alex.sosic@timenet.it skype: alex.sosic cell: +385 91 2505 146
On Fri, Mar 2, 2018 at 6:46 PM, Ben Hood 0x6e6562@gmail.com wrote:
Hey Aleksandar,
Many thanks for the heads up - very interesting to see how other people are doing this.
So if I understand you correctly, you have a dynamic list of dispatchers.
And then you invoke "dispatcher.reload" to reload all of the dispatchers you have defined dynamically?
What does the DISPATCHER_LIST route look like?
Cheers, Ben
On Fri, Mar 2, 2018 at 9:29 AM, Aleksandar Sosic alex.sosic@timenet.it wrote:
Hi Ben,
we're using something like this to do dispatcher.reload:
event_route[xhttp:request] { if ($hu =~ "^/rpc") { $var(command) = $(hu{s.select,2,/}); $var(parameter) = $(hu{s.select,3,/}); if($var(command) == "reload.dispatchers") { route(DISPATCHER_LIST); xhttp_reply("200", "OK", "text/html", "Dispatchers Set for RELOAD"); exit; } ... }
And then in the DISPATCHER_LIST route we do an API call for fetching the updated dispatcher list for that node. After the dispatcher list is updated we just run: jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": "1"}');
So you can just put a `jsonrpc_exec` inside the event_route[xhttp:request].
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Aleksandar,
That's quite a cool set of technologies that you've integrated together :-)
Many thanks for taking the time to explain this so clearly, very much appreciated.
I like the fact that you've connected a GraphQL query (which I've only really seen being used in React) to populate a tmp file.
Previously I had never thought of doing redirecting printf to a well known file (shared memory in one sense), but it seems like a simple and effective thing to do, especially as the data in that file is inherently reconstructable via a remote request.
It also demonstrates the use of jsonrpc_exec - this command is invoking a local RPC API without a network call.
Many thanks,
Ben
On Fri, Mar 2, 2018 at 10:03 PM, Aleksandar Sosic alex.sosic@timenet.it wrote:
Hi Ben,
we are working on a dockerized infrastructure orchestrated with Kubernetes with two kamailio layers, a `proxy` and a `router` level. In a stateless infrastructure like that we need to have also a SIP orchestrator that will handle all the active and ready nodes and notify or provide the correct information to all the other nodes upon changes in the infrastructure.
So upon the creation of a `router` node we will give it a list of `proxy` nodes (Kamailio), `TPS` (transcoding and playback handled by asterisk), `RTPs` (rtpengine). When that container (aka Pod in kubernetes) starts and it's ready we also notify the `proxy` nodes to reload the dispatcher list and add the new node. We do that via API.
The API is a Node.js application using GraphQL query language. So our DISPATCHER_LIST route does an async http request to the API:
route[DISPATCHER_LIST] { if($sht(api=>token) == $null) { route(GET_API_TOKEN); } $http_req(method) = "POST"; $http_req(hdr) = "Content-Type: application/json"; $http_req(hdr) = "Authorization: Bearer " + $sht(api=>token); $var(graphql_query) = "{\"query\": \"{ kamailio { dispatcher { list { kamailioConf } } } }\"}"; $http_req(body) = $var(graphql_query); http_async_query(API_QUERY_URL, "DISPATCHER_SET"); }
We're using the JWT as authentication/security between nodes and API.
the DISPATCHER_SET route then handles the async response:
route[DISPATCHER_SET] { jansson_get("data.kamailio.dispatcher.list.kamailioConf", $http_rb, "$var(api_conf)"); if($var(api_conf) != "0") { exec_msg("printf \"$var(api_conf)\" > /tmp/dispatcher.list"); jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": "1"}'); ... }
Those are simplified routes without logs and checks and failovers. As you can immagine the dispatcher module has a param like this:
modparam("dispatcher", "list_file", "/tmp/dispatcher.list")
I'll be giving a speech on CD/CI and Kamailio route testing in a dockerized environment like this at this year Kamailio World Conference in Berlin: https://www.kamailioworld.com/k06/speakers/
If you're attending the event we can discuss this further ad visum.
Kind regards,
Aleksandar Sosic mail: alex.sosic@timenet.it skype: alex.sosic cell: +385 91 2505 146
On Fri, Mar 2, 2018 at 6:46 PM, Ben Hood 0x6e6562@gmail.com wrote:
Hey Aleksandar,
Many thanks for the heads up - very interesting to see how other people are doing this.
So if I understand you correctly, you have a dynamic list of dispatchers.
And then you invoke "dispatcher.reload" to reload all of the dispatchers you have defined dynamically?
What does the DISPATCHER_LIST route look like?
Cheers, Ben
On Fri, Mar 2, 2018 at 9:29 AM, Aleksandar Sosic alex.sosic@timenet.it wrote:
Hi Ben,
we're using something like this to do dispatcher.reload:
event_route[xhttp:request] { if ($hu =~ "^/rpc") { $var(command) = $(hu{s.select,2,/}); $var(parameter) = $(hu{s.select,3,/}); if($var(command) == "reload.dispatchers") { route(DISPATCHER_LIST); xhttp_reply("200", "OK", "text/html", "Dispatchers Set for RELOAD"); exit; } ... }
And then in the DISPATCHER_LIST route we do an API call for fetching the updated dispatcher list for that node. After the dispatcher list is updated we just run: jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": "1"}');
So you can just put a `jsonrpc_exec` inside the event_route[xhttp:request].
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