presence: update documentation regarding the presence in Jami
Change-Id: Ia47ba8d6ab1bfbd6f26947c09fb0559352396306
This commit is contained in:
Sébastien Blin
parent
76d243edc3
commit
69e912d5c9
|
|
@ -65,6 +65,85 @@ dht_.get<DeviceAnnouncement>(to, [shared,to,treatedDevices,op](DeviceAnnouncemen
|
|||
|
||||
And that's all.
|
||||
|
||||
### Client perspective
|
||||
|
||||
```xml
|
||||
<method name="subscribeBuddy" tp:name-for-bindings="subscribeBuddy">
|
||||
<tp:docstring>
|
||||
Ask be be notified when 'uri' presence change
|
||||
</tp:docstring>
|
||||
<tp:added version="1.3.0"/>
|
||||
<arg type="s" name="accountID" direction="in">
|
||||
<tp:docstring>
|
||||
An account from which get request presence informations
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
<arg type="s" name="uri" direction="in">
|
||||
<tp:docstring>
|
||||
A SIP uri to watch
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
<arg type="b" name="flag" direction="in">
|
||||
<tp:docstring>
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
</method>
|
||||
|
||||
<signal name="newBuddyNotification" tp:name-for-bindings="newBuddyNotification">
|
||||
<tp:added version="1.3.0"/>
|
||||
<tp:docstring>
|
||||
Notify when a registered presence uri presence informations changes
|
||||
</tp:docstring>
|
||||
<arg type="s" name="accountID">
|
||||
<tp:docstring>
|
||||
The associated account
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
<arg type="s" name="buddyUri">
|
||||
<tp:docstring>
|
||||
The registered URI
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
<arg type="i" name="status">
|
||||
<tp:docstring>
|
||||
Is the URI present or not
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
<arg type="s" name="lineStatus">
|
||||
<tp:docstring>
|
||||
A string containing informations from the user (human readable)
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
</signal>
|
||||
|
||||
<method name="publish" tp:name-for-bindings="publish">
|
||||
<tp:added version="1.3.0"/>
|
||||
<arg type="s" name="accountID" direction="in">
|
||||
<tp:docstring>
|
||||
The account from which the presence will be emitted
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
<arg type="b" name="status" direction="in">
|
||||
<tp:docstring>
|
||||
Is this account present or not
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
<arg type="s" name="note" direction="in">
|
||||
<tp:docstring>
|
||||
A message transmitted by the server to other users
|
||||
</tp:docstring>
|
||||
</arg>
|
||||
</method>
|
||||
```
|
||||
|
||||
Are the main APIs for clients. `subscribeBuddy` will listen on the DHT to detect presence changes and `newBuddyNotification` will be sent whenever a new status is detected:
|
||||
+ The status sent to the client is now 0=offline (no device found on the DHT), 1=dht_presence (at least a device is found on the DHT), 2=connected (with a TCP + SIP channel, so ready to exchange data).
|
||||
+ `lineStatus` will contain any custom status sent by the peer (e.g. *Lunch Time!*)
|
||||
|
||||
`publish` is used for publishing a custom note (`status` is ignored for Jami accounts, note will contain the custom status).
|
||||
|
||||
RFC3863 is used to send status over the SIP connection.
|
||||
|
||||
## Pending request
|
||||
|
||||
### Send a request
|
||||
|
|
|
|||
26
user/faq.rst
26
user/faq.rst
|
|
@ -48,21 +48,23 @@ the most significant practical differences are that you have more
|
|||
..
|
||||
TODO: expand on this
|
||||
|
||||
What do the red/green status circles next to avatars mean?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
What do the green/orange/red status circles next to avatars mean?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
On your own account, a red circle means that you aren't connected to
|
||||
the DHT. You may need to check your connection or restart the app.
|
||||
the DHT or offline. You should have a detailled error banner explaining the issue.
|
||||
You may need to check your connection or restart the app.
|
||||
|
||||
On other contacts, a red circle means that they are not online, and a
|
||||
green circle means they are online and you should be able to message
|
||||
them.
|
||||
For contacts, no circle means that no device is detected on the DHT. This contact
|
||||
is unreachable. If an orange circle is present, this means that at least a device
|
||||
is announced on the DHT, so this contact SEEMS to be reachable. You do not have
|
||||
a direct connection towards this peer yet. But they should be able to receive
|
||||
connection requests. Because the device is not directly connected to anything, we
|
||||
can't determine for sure the status of this device. So this can be translated to
|
||||
"Seems to be reachable", but connection may fail (firewall, deadlock, NAT, etc).
|
||||
|
||||
Note that a green circle only means that the contact has announced
|
||||
their presence on the DHT. It does not indicate a direct connection
|
||||
to their device. In some cases, a contact may be able to send and
|
||||
receive messages but cannot make calls or file transfers because of
|
||||
their firewall.
|
||||
The presence generally have a TTL of 10 min over the DHT and several hours if push notifications are enabled.
|
||||
|
||||
If a green circle is present, this means that you're connected to a device of this peer.
|
||||
|
||||
Why is a feature missing on my client?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
Loading…
Reference in New Issue