Implement presence REST API as an informational pull service (not pub/sub push)

[ivelin]

Implement a REST API that informs about the last time a Restcomm user has been known to be active. Similar to the way presence is implemented in popular messaging apps. Unlike the pub/sub presence suggested by standards like RCS, which cause unnecessary N^2 waves of traffic that jam the network and are a terrible design for deployments at scale.

Restcomm would have to keep a state map for each active Restcomm user. An active user can be considered one that has sent any kind of SIP message to the Restcomm server from any of the user's registered client end-points. SIP messages that count against activity could be: REGISTER, INVITE, MESSAGE, INFO, BYE and others.

Restcomm does not need to keep a map of inactive users.

When a certain app is interested to know the presence status of a user, it could use this API to obtain in.

[ghjansen]

Additional info:

[ghjansen]

Considering the diagram from my previous comment, I think REST API layer is ready in ae05b47. Testing my modifications, I discovered some issues with the XML version of the API, when accessing it from a fresh built from source standalone. As SIP clients 'bob' and 'alice' have some default null attributes (like VoiceApplicationSid, VoiceFallbackUrl and VoiceUrl), the XML writer throws some exceptions while creating the structure. I've already tested it with success by leaving the XML tag empty, but maybe the best choice is to remove the entire XML tag if it has no value, just like happens to JSON version of the API. What do you think @ivelin @otsakir ?

[ivelin]

Not including void tags sounds sensible. No need to bloat the response with useless information. It is important however to document how developers should interpret the lack of certain tags.

Related to this API, it may be appropriate to have a more specific resource query that is only targeted at presence.
/Accounts/{AccountSid}/Clients/{ClientSid}/presence

The idea would be to allow presence checks on demand with the least possible overhead. Conceptually similar to an XPath expression into the XML response document.