baresip: Remote Control: Missing explicit UA and call selection for commands

While trying to build a simple multi-UA WebGUI with a single baresip instance I ran into the problem that the MQTT API is missing an explicit UA selection for each command sent from my UI to baresip.

All commands are directed to the “current” UA but it nearly impossible to preselect a specific UA via MQTT.

baresips current command implementation is like that: /baresip/command {"command":"dial","params":"music","token":"123"} You can only toggle between UAs by calling uanext or uafind but you are even unable to get a valid JSON-formated response from reginfo command to get a feedback which of them are available and which is currently selected. Even if you manage to get that in case of multiple MQTT clients anybody else could change the “active” UA in the meantime by running uanext or uafind again (kind of race condition).

In the other direction all events published by baresip already include the accountaor value which can be used to distinguish between the UAs. Example: /baresip/event {"type":"CALL_ESTABLISHED","class":"call","accountaor":"sip:123456789@192.168.0.10","direction":"incoming","peeruri":"sip:+4912345678901@192.168.0.10","id":"04ce3b08af9e91254b5d16cae000","param":"sip:+4912345678901@192.168.0.10"}

So I would suggest to add an optional “accountaor” attribute to all the commands like this /baresip/command {"command":"dial","params":"sip:+4912345678901","accountaor":"sip:123456789@192.168.0.10","token":"123"} and to add a new subtopic (e.g. /baresip/accounts) or event which publishes and updates the list of UAs with a JSON-formated content whenever there is a modification of the internal state (idea and data from /reginfo)

{
 "selected_index":1,
 "accountaors": [
   {"index":1,"accountaor":"sip:12345678901@192.168.0.10","state":"OK"},
   {"index":2,"accountaor":"sip:12345678902@192.168.0.10","state":"OK"},
   {"index":3,"accountaor":"sip:12345678903@192.168.0.10","state":"OK"},
 ]
}

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 21 (4 by maintainers)

Commits related to this issue

Most upvoted comments

yes I think it is a good idea to explicitly specify the UA account.

we currently have the concept of a “current” UA, but perhaps it is time to get rid of it ?

pushed to master.

thanks for good input and testing.

can you please test this patch:

diff --git a/modules/mqtt/subscribe.c b/modules/mqtt/subscribe.c
index 340eb63..9de703a 100644
--- a/modules/mqtt/subscribe.c
+++ b/modules/mqtt/subscribe.c
@@ -25,6 +25,7 @@ static void handle_command(struct mqtt *mqtt, const struct pl *msg)
 	struct odict *od = NULL;
 	const struct odict_entry *oe_cmd, *oe_prm, *oe_tok;
 	char buf[256], resp_topic[256];
+	const char *aor, *callid;
 	int err;
 
 	err = json_decode_odict(&od, 32, msg->p, msg->l, 16);
@@ -42,6 +43,31 @@ static void handle_command(struct mqtt *mqtt, const struct pl *msg)
 		goto out;
 	}
 
+	aor    = odict_string(od, "accountaor");
+	callid = odict_string(od, "callid");
+
+	if (aor) {
+		struct ua *ua = uag_find_aor(aor);
+		if (!ua) {
+			warning("mqtt: ua not found (%s)\n", aor);
+			goto out;
+		}
+
+		uag_current_set(ua);
+
+		if (callid) {
+			struct call *call;
+
+			call = call_find_id(ua_calls(ua), callid);
+			if (!call) {
+				warning("mqtt: call not found (%s)\n", callid);
+				goto out;
+			}
+
+			call_set_current(ua_calls(ua), call);
+		}
+	}
+
 	debug("mqtt: handle_command:  cmd='%s', token='%s'\n",
 	      oe_cmd ? oe_cmd->u.str : "",
 	      oe_tok ? oe_tok->u.str : "");

it looks like there is now consensus for solution 1.) – i.e. add ua/call lookup in the ui/ctrl module.

that means, no changes to the command syntax.

I added a new command to lookup call from <callid>:

/callfind 123456

is there a consensus for implementing option 1.) ?

NOTE: both ua and call will be added. we are now trying to establish how in the baresip framework it will be solved, possibly affecting a lot of code. the chosen solution will also be used for the long term future, we will not revisit this problem again in 6 months.