combadge / spindoctor Goto Github PK

Currently, the server can hear the badge, badges can hear each other but badges cannot hear the server. We need to feed back to the badge to let it know when the server is listening.

Following Star Trek and Farscape, we should use non-verbal cues.

Also, the pre-recorded sound files on the OEM Server are a no - any audio should be generated programmatically, whether through some sort of libClickySounds or through TTS.

#13 is a WIP to fix this.

As above, but side note - a "special case" of group for direct two-user badge-badge calls is probably a good way of making sure that all steps are properly completed.

Currently, setting up a badge requires one of three processes:

1. Having a copy of the badge config software (not publicly available).
2. Using on-badge config to set up with a default open ssid and preconfigured server address (10.98.2.30 being the most widely supported across badge models and software).
3. Doing the above to set open ssid, additionally enabling ssh on the badge and then using that to manually edit badge.properties with vim to populate the correct values.

Spindoctor needs a minimal implementation of an ability to push config to an unconfigured badge to set the SSID, encryption, server IP and InstallDone (to true).

This is a fun ticket that I'm not assigning myself to. I have one working B1000A and a handful of working B1000's, and for funsies I decided to start one of each up and see if they connected to Spindoctor. And hey - they did - both show "Logged Out". But, they don't seem to log in properly, and calling doesn't seem to work. Actually, other than "ping", they don't seem to work with the server at all.

Unless someone has pcaps of an (at least) 13 year old Voice Server talking to the B1000, you're stuck doing guesswork with the badges which - I do not have the patience for. So, the ticket is up - if you want to try and get B1kx combadges working, good luck! We look forward to your PR.

Currently, there's no handling of a badge being "reset" - i.e. being turned off, or being away from the network long enough for the badges' internal serial counter to reset.

A good implementation would be for an autodelete of the Combadge() class instance, for badges that have not been seen for a certain amount of time.

Baseline feature set: Implement remote SIP/RTP screen, speaker, camera, mic (using USB webcam for cam/mic) which automatically accepts calls if the Spindoctor server tells it to (so, have a simple API for call management).

Stretch goal 1: Implement general purpose media casting target. Should disconnect sources when a call is received. Perfect implementation would be pausing and hiding cast while retaining connection. Should not automatically unpause when call concludes.

Stretch goal 2: Implement an API to locally render information sent. Should probably be in the form of a HTML engine, but I'm concerned about performance on targer hardware.

Stretch goal 3: implement the ability to send HDMI-CEC commands to wake up the display when one of the functions is requested.

Speaking of: target hardware is a Pi 4, 4GB. stretch hardware is a Pi 3 1GB. The reasoning is: these can be readily found as pluggable modules for commercial signage displays; and can also be readily connected to a simple TV and webcam for a more common install.

Goal 0 is to allow the "On-screen" / "Transfer to my quarters" function when receiving external calls with video - as badges do not support this.

Stretch Goal 1 is to allow the display enough functionality that it can just be left on all the time while still being useful as something other than a phone.

Stretch Goal 2 is to allow the "corridor wall display" functionality from TNG - e.g. when Riker is navigated to locate Data in Encounter at Farpoint. Realistically could be a function of 1. (have the computer agent render and display), but if the compute module has the power for local rendering, this would allow distribution of workload in a way that would lower cost of entry for any one component - e.g. Spindoctor Server runs on a Pi, Terminal runs on a Pi, building management server runs on a pi - no single power-hungry central node is required.

Stretch Goal 3 is for power efficiency.

This is a device I really want to support, since the Minibadge is the closest thing yet to an on-screen combadge. Unfortunately there are some issues in supporting it. Because it doesn't have a display, it doesn't have vcb.out, the local configuration editor. Also, because they're so new I haven't even seen one yet, much less gotten hold of one.

I'm probably not going to be able to support this until a commercial organisation with an active contract for the commercial server:

• Decides to donate me one of these badges (not, that's the organisation itself, no borrowed technology please!).
• Pre-configures it to my test network for me.
• Sends me some sample packet caps of calls between the badge and server (startup and ping, login, logout, calls to agent) so I can check the protocol matches the B-series badges and/or modify as needed.

This device mostly seems to use a similar protocol to the B-Series badges, but with some oddities. I have some packet captures but it needs further investigation.

As above, current fixed-period inferencing is not useful.

I think this says a lot about one or more of the following:

• The quality of testing.
• My late-in-the-day urgency to have this "over with".

Either way, my bad - but still a big jump forward. I'm currently focused on getting bidi audio running, but after than I'll take a look if no-one else does.

Currently, both badges have to individually press the hang-up button, as currently if the second badge doesn't have the button pressed it just continues to spam UDP/RTP traffic at the first badge. A good fix for #23 should fix this.