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
- echo: no need to use uag_current() -- ref #815 — committed to baresip/baresip by alfredh 5 years ago
- menu: clean up usage of uag_current() -- ref #815 — committed to baresip/baresip by alfredh 5 years ago
- call: add call_find_id() -- ref #815 — committed to baresip/baresip by alfredh 5 years ago
- menu: new command /callfind -- ref #815 — committed to baresip/baresip by alfredh 5 years ago
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:
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>:
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.