Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How detect that friend is busy #944

Closed
hkarel opened this issue Jun 25, 2018 · 13 comments
Closed

How detect that friend is busy #944

hkarel opened this issue Jun 25, 2018 · 13 comments
Labels
P3 Low priority suggestion Suggestions
Milestone

Comments

@hkarel
Copy link

hkarel commented Jun 25, 2018

When developing my client, I ran into a problem for which I can not find a solution. So I ask the developers for help.
I develop a tox-client for a landline phone. When I make a call to a friend (call function toxav_call()), I need to know that my friend's lines are free. If at the time of my call - a friend is already talking to someone or he just lifted the handset, I somehow should know about it, in order that played a busy-signal and finish the call.
How can I understand that my friend's line is busy?

@sudden6
Copy link

sudden6 commented Jun 25, 2018

I think there's no API for that, since Tox can handle multiple calls at once. You would have to implement this mechanism in your client at the moment.

Maybe it makes sense to integrate such an API in the core?

@iphydf
Copy link
Member

iphydf commented Jun 25, 2018

This is a privacy concern. Right now, you can't tell whether your friend is having a call at the moment. That is a good thing. The client can auto-reject calls. It might make sense to send a reject reason (e.g. "busy") somehow. You can implement that as custom packet for now.

@sudden6
Copy link

sudden6 commented Jun 25, 2018

I think it could be interesting to have at least an API for a reject "reason" e.g. "busy". The rest can be handled by the client.

@sudden6 sudden6 added the suggestion Suggestions label Jun 25, 2018
@hkarel
Copy link
Author

hkarel commented Jun 26, 2018

This is a privacy concern.

I agree, it can be a vulnerability. However, I develop my client for ordinary people, so I do not give privacy the absolute priority. Therefore would be great to have an opportunity to receive reject-code. API-function is a great variant. For tox-clients who are very take care of security can always return zero.

You can implement that as custom packet for now.

@iphydf, do I understand correctly: You suggest that I implement an alternative call termination function using the function tox_friend_send_lossless_packet ()

@hkarel
Copy link
Author

hkarel commented Jun 26, 2018

As a solution variant: may be to add the new status to enum TOX_USER_STATUS?

@sudden6
Copy link

sudden6 commented Jun 27, 2018

/**
     * User is busy. Signals to other clients that this client does not
     * currently wish to communicate.
     */
TOX_USER_STATUS_BUSY

Hmm, I think this could be already interpreted as the thing you want to implement? Just let your client play a "busy" tone when trying to call a friend who is busy? And auto-drop calls when your own status is busy?

@hkarel
Copy link
Author

hkarel commented Jun 27, 2018

Yes, I saw this flag (TOX_USER_STATUS_BUSY), but I have some doubts: at the moment this flag carries an information function (as far as I understand it). A friend as if says that he is very busy and asks him not to disturb. But nevertheless, if there is an urgent need, I can still write to friend or call him. If I interpret the TOX_USER_STATUS_BUSY flag as a busy-state, it can happen that I can not reach my friend for a very long time. For example, the qtox friend set the TOX_USER_STATUS_BUSES flag, and then forgot to remove it.
So I thought that do not need to assign a second meaning to TOX_USER_STATUS_BUSES flag. And for state "busy because of call", enter a separate line item.

@hkarel
Copy link
Author

hkarel commented Jul 8, 2018

I made a mechanism of notifying about the reason for ending the call through the function tox_friend_send_lossless_packet (). This works quite well. The main thing that the interval between end of a call and the notice wouldn't be very long. But this will be visible only in the process of using.

@hkarel hkarel closed this as completed Jul 8, 2018
@iphydf iphydf modified the milestones: v0.2.x, v0.2.4 Jul 16, 2018
@zoff99
Copy link

zoff99 commented Sep 11, 2021

@hkarel reason for ending the call through the function tox_friend_send_lossless_packet
can you link to the code please?

@hkarel
Copy link
Author

hkarel commented Sep 11, 2021

can you link to the code please?

function sendToxLosslessMessage()

@zoff99
Copy link

zoff99 commented Sep 11, 2021

@hkarel thanks. are you using packet ID 160 ?

can you add your stuff here please (with a PR):

https://github.com/zoff99/toxcore_custom_packets_registry

@hkarel
Copy link
Author

hkarel commented Sep 11, 2021

are you using packet ID 160 ?

Yes. The 160 - it first code for user commands. See macroses PACKET_ID_RANGE_LOSSLESS_CUSTOM_START, PACKET_ID_RANGE_LOSSLESS_CUSTOM_END

@hkarel
Copy link
Author

hkarel commented Sep 11, 2021

can you add your stuff here please (with a PR):

Done: Reserve the code 160 for ToxPhone

@iphydf iphydf added the P3 Low priority label Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 Low priority suggestion Suggestions
Projects
None yet
Development

No branches or pull requests

5 participants