Looking for reliable indicator that a connection is established

pabint

Hello, I was hoping to get some help regarding this issue.

Short story:

I need a way of knowing the status of a TeamViewer session in real time. I used the "online" property of the session (from the API) but it's showing some inconsistencies.

Long story:

I am developing a C# app from where a new TeamViewer support session is created and launched.

To do this I POST to the webapi.teamviewer.com/api/v1/sessions collection and then I open the supporter link (that is found in the response) with the browser.

That is working fine.

The issue is that I need to be able to show the status of the connection inside my app. For monitoring this I was using the "online" property of the session (obtained from api/v1/sessions/{sessionId}).

I tested this property and it seemed to represent the real status of the session. Today though it's not working as I understand it should. Are there new changes being made? Is this a bug?

For example, it shows online=false even when the session is established and the screen sharing or remote control is being used.

Is there any other method of checking the connection status that is more reliable than this one?

Thanks in advance,

Pablo.

Edit: Another possible bug I found is that the "online" value is different for the same collection depending where you obtain the information from. You can do a GET api/v1/sessions/{aSession} and see that it's "online" value is different than the one shown for the session in GET api/v1/sessions. (I attach this two responses, made one after the other)

Finally, I've found that the following filters (mostly #2) seem to work fine, and show only the sessions that are indeed online. Still, I'm not sure how to access this information programatically and I need help.

(found in: login.teamviewer.com/nav/servicequeue)

pabint

I have found the reason of the issue. Since no support was provided.

If you call GET api/v1/sessions/{aSession} and {aSession} is formated: "snn-nnn-nnn" (n stands for number) then you will have no problems.

But once you call this same enpoint with {aSession} looking like: "nnnnnnnn" inconsistencies start happening, even if you call the endpoint again with the format of above this session remains "broken" (in the way I expressed in the post).

This also explains why GET api/v1/sessions/ showed sessions values in an accurate but showed different results than the other.

To sum up, after all, a GET request is modifing something in the session permanently and by modifing I mean breaking it. According to REST this is not to be expected for a GET request although it is clear that this is wasn't designed on purpose and it's a bug (a one hard to spot indeed).