V5000 "Smartbadge" not supported

[mo-g]

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.

[mo-g]

Here's a Hex Stream from my V5000 badge for the new protocol.

564352410000000100000002000000010000019f0000000100497b2274696d657374616d70223a2022323833222c202273657373696f6e4964223a202263313237613931392d633037372d346637302d393836342d646539623537363230333935227d01367b22636c69656e744d616341646472657373223a2022303030396566353030356465222c2022636c69656e7454797065223a202247656e35222c2022636c69656e745265706c79546f495041646472657373223a2022222c2022636c69656e745265706c79546f506f7274223a20353030322c2022636c69656e7456657273696f6e223a2022352e302e34205b4275696c642033305d222c2022636c69656e7454696d655a6f6e65223a2022222c2022636c69656e744465766963654964656e74696669657254797065223a20224d414341444452222c2022636c69656e744465766963654964656e746966696572223a2022303030396566353030356465222c202272657472616e736d6974456e61626c65223a202274727565222c202261706d6163223a2022383232616138376639333936227d00000000

So VCRA is the new 0xaeaeaeae, which makes a lot more sense. Most of that is actually JSON:

{
    "timestamp":"1643660995227",
    "sessionId":"c127a919-c077-4f70-9864-de9b57620395"
}
{
    "serverType":"Vocera Voice Server",
    "serverVersion":"5.4 [Build 166]",
    "serverTimeZone":"0",
    "failureCode":1,
    "failureMessage":"VMP is not enabled"
}

And the server response:

56435241000000020000000000000000000000720000000100507b2274696d657374616d70223a2231363433363630393935323233222c2273657373696f6e4964223a2263313237613931392d633037372d346637302d393836342d646539623537363230333935227d0002222200000000

{
    "timestamp":"1643660995223",
    "sessionId":"c127a919-c077-4f70-9864-de9b57620395"
}
""

So, it seems to have something to do with the Messaging Platform, an Exchange Integration service that provides a fancier way to handle text messages to the badge. Which, makes sense - since the SmartBadge presumably has greater messaging capabilities than the Badge. As long as the badge can be told to ignore the problem, I don't think implementing this is urgent, or really that practical since I have no protocol examples to work from.

They're continuing to prepend each value (this time, each JSON chunk) with a two-byte counter: 0049, 0136, 0050, 0002 as with the badge protocol. 0000000100000002000000010000019f00000001 and 0000000200000000000000000000007200000001 will take some figuring out, but we can assume there's a serial number in there somewhere.

[mo-g]

I've tweaked combadge_packet on my giant RTP branch to not-immediately-die when a V5000 connects to a server, but no more at this point. I'll take a brief look at this again when I've got 2-way server calls working. Honestly this comes down to whether we can quickly implement a "acknowledged" to the badge which lets it naturally revert to the B-Protocol. If it is more complicated than it looks right now, this will get hard pushed to the bottom of the to-do-list and we'll officially only support the B-Series for now. (B2000, B3000, B3000N).

[mo-g]

Chief Engineers log, stardate whatever. I've been able to confirm that without a confirmatory response to the JSON query, the badge does not revert to B-series protocol. Sadface.