update: change "Ring" to "Jami" strings
Change-Id: Id3a413b3fbc38a19231b5bced9428d416c3c7003
This commit is contained in:
parent
253113bad8
commit
cc63937765
|
@ -1,7 +1,7 @@
|
|||
Account management
|
||||
==================
|
||||
|
||||
In this part, we will learn how to manage a Ring account. This means, how to create a Ring account, modify the basic settings and delete the account. This part will *NOT* explain what all the settings mean or how we can use the account to do any action like adding a contact.
|
||||
In this part, we will learn how to manage a Jami account. This means, how to create a Jami account, modify the basic settings and delete the account. This part will *NOT* explain what all the settings mean or how we can use the account to do any action like adding a contact.
|
||||
|
||||
## Create a new account
|
||||
|
||||
|
@ -67,7 +67,7 @@ The main logic to create a new account is located in `src/ringdht/ringaccount.cp
|
|||
|
||||
### How it works, from scratch
|
||||
|
||||
A Ring account is in fact represented by some files stored in a gzip archive. If a password is provided during the account creation, the archive will be encrypted as following: `dht::crypto::aesEncrypt(archive, password)` (`dht::crypto::aesEncrypt` is defined in OpenDHT and use `nettle/{aes,gcm}`). This is what the archive will contain a big JSON file with:
|
||||
A Jami account is in fact represented by some files stored in a gzip archive. If a password is provided during the account creation, the archive will be encrypted as following: `dht::crypto::aesEncrypt(archive, password)` (`dht::crypto::aesEncrypt` is defined in OpenDHT and use `nettle/{aes,gcm}`). This is what the archive will contain a big JSON file with:
|
||||
|
||||
1. The private key `ringAccountKey` and certificate chain `ringAccountCert` (base64 encoded)
|
||||
2. Generated CA key (for self-signed certificates) `ringCAKey`
|
||||
|
@ -83,7 +83,7 @@ So let's generate it!
|
|||
|
||||
## Delete the account
|
||||
|
||||
Deleting a Ring account is pretty simple. Because the keys are only on the device, if the keys are deleted... the account is deleted! The only thing outside the device is the username, on the nameserver. To remove this info, it depends how the nameserver work. For example, it's not possible with https://ns.jami.net
|
||||
Deleting a Jami account is pretty simple. Because the keys are only on the device, if the keys are deleted... the account is deleted! The only thing outside the device is the username, on the nameserver. To remove this info, it depends how the nameserver work. For example, it's not possible with https://ns.jami.net
|
||||
|
||||
|
||||
### Daemon side
|
||||
|
@ -194,7 +194,7 @@ Then `exportOnRingEnded` is emitted.
|
|||
```xml
|
||||
<method name="revokeDevice" tp:name-for-bindings="revokeDevice">
|
||||
<tp:docstring>
|
||||
Revoke device attached to the given Ring account, and publish the new revocation list.
|
||||
Revoke device attached to the given Jami account, and publish the new revocation list.
|
||||
</tp:docstring>
|
||||
<arg type="s" name="accountID" direction="in">
|
||||
</arg>
|
||||
|
|
|
@ -2,7 +2,7 @@ Banned contacts
|
|||
===============
|
||||
|
||||
Following information are here for development purposes and may not
|
||||
reflect the current state of any Ring client.
|
||||
reflect the current state of any Jami client.
|
||||
|
||||
Introducing scenario
|
||||
--------------------
|
||||
|
@ -10,7 +10,7 @@ Introducing scenario
|
|||
Let's explain banned contacts with a simple scenario:
|
||||
|
||||
Alice and Jessica are friends, and like all good friends do, they use
|
||||
Ring to communicate. They are both Ring contact of each other, so Alice
|
||||
Jami to communicate. They are both Jami contact of each other, so Alice
|
||||
is a contact of Jessica and Jessica is a contact of Alice. Some day
|
||||
however, Jessica does something really bad to Alice and Alice doesn't
|
||||
want to hear from her anymore. Instead of removing Jessica from her Ring
|
||||
|
|
|
@ -200,7 +200,7 @@ For now, if a file transfer fails when ongoing, the sender can not resume
|
|||
the transfer and must relaunch the whole transfer. In the future, there
|
||||
will be a retry button for resuming the transfer.
|
||||
|
||||
Finally, because Ring do not support text conferences (just video
|
||||
Finally, because Jami do not support text conferences (just video
|
||||
conferences, where there is one master merging slaves SIP calls), there
|
||||
is no real file transfer in conferences. For now, when you are in a
|
||||
conference on the gnome client for example: A master, B and C slave. B
|
||||
|
|
|
@ -1,10 +1,10 @@
|
|||
Protocol
|
||||
========
|
||||
|
||||
Ring account creation
|
||||
Jami account creation
|
||||
---------------------
|
||||
|
||||
A **Ring account** is defined by an **RSA key pair** with a key length
|
||||
A **Jami account** is defined by an **RSA key pair** with a key length
|
||||
of at least 4096 bits.
|
||||
|
||||
The standard x509 160-bits fingerprint of the account public key is
|
||||
|
@ -12,7 +12,7 @@ called the **RingID**.
|
|||
|
||||
The account public key is used as the subject of an x509 certificate
|
||||
that must be valid, have the Certificate Authority flag set, and can be
|
||||
self-signed. This certificate is called the **Ring account
|
||||
self-signed. This certificate is called the **Jami account
|
||||
certificate**.
|
||||
|
||||
The subject UID field of the account certificate must be the hexadecimal
|
||||
|
@ -21,14 +21,14 @@ hexadecimal form of the issuer public key fingerprint.
|
|||
|
||||
### Persisting the account
|
||||
|
||||
Persisting a Ring account private key and certificate is implementation
|
||||
Persisting a Jami account private key and certificate is implementation
|
||||
defined.
|
||||
|
||||
Access to a saved Ring account private key must be authenticated and
|
||||
Access to a saved Jami account private key must be authenticated and
|
||||
authorized. Authentication and authorization method to access the
|
||||
account private key is implementation defined.
|
||||
|
||||
### Adding a device to a Ring account
|
||||
### Adding a device to a Jami account
|
||||
|
||||
*See [RFC 5280](https://tools.ietf.org/html/rfc5280)*
|
||||
|
||||
|
@ -45,13 +45,13 @@ defined. Access to a saved device private key should be authenticated.
|
|||
Authentication method to access the device private key is implementation
|
||||
defined.
|
||||
|
||||
### Removing a device from a Ring account
|
||||
### Removing a device from a Jami account
|
||||
|
||||
A device can be "removed" from a Ring account through revocation of the
|
||||
A device can be "removed" from a Jami account through revocation of the
|
||||
device certificate. Revoked device certificates are added to one or more
|
||||
standard x509 Certificate Revocation List (CRL). CRLs for revoked device
|
||||
must be valid and signed with the corresponding CA key, which is the
|
||||
Ring account private key.
|
||||
Jami account private key.
|
||||
|
||||
### Account transmission format
|
||||
|
||||
|
@ -114,7 +114,7 @@ OpenDHT specifications.
|
|||
RFC 5245 defines ICE (Interactive Connectivity Establishment), a
|
||||
protocol for NAT traversal.
|
||||
|
||||
ICE is used in Ring to establish a peer-to-peer communication between
|
||||
ICE is used in Jami to establish a peer-to-peer communication between
|
||||
two devices.
|
||||
|
||||
The calling device gathers candidates and build an Initial Offer
|
||||
|
@ -187,7 +187,7 @@ SIP INVITE as soon as the DTLS channel is established.
|
|||
|
||||
The SIP implementation must support ICE and SRTP.
|
||||
|
||||
Supported codecs are implementation defined, but Ring clients should
|
||||
Supported codecs are implementation defined, but Jami clients should
|
||||
support the Opus audio coded and the H264 video codec.
|
||||
|
||||
SRTP must be used when negotiating media with SIP, using a new random
|
||||
|
@ -230,7 +230,7 @@ peers.
|
|||
|
||||
The protocol is a classic SRTP, with following supported crypto suites:
|
||||
|
||||
- Ring account force AES\_CM\_128\_HMAC\_SHA1\_80
|
||||
- Jami account force AES\_CM\_128\_HMAC\_SHA1\_80
|
||||
- SIP can use AES\_CM\_128\_HMAC\_SHA1\_80 or
|
||||
AES\_CM\_128\_HMAC\_SHA1\_32
|
||||
|
||||
|
@ -240,6 +240,6 @@ call's master key is constant during the full live of a call.
|
|||
The keys are exchanged using SDES method: keys are written into the SIP
|
||||
SDP messages during the SIP INVITE negotiation. When SDES is used, Ring
|
||||
forces the underlaying transport to be secure (encrypted) to not
|
||||
disclose these keys. Ring supports DTLS natively for SIP and Ring
|
||||
disclose these keys. Jami supports DTLS natively for SIP and Ring
|
||||
accounts for such. The call cannot be done if this condition is not
|
||||
fulfilled.
|
||||
|
|
|
@ -1,15 +1,15 @@
|
|||
Release process
|
||||
===============
|
||||
|
||||
Each Ring sub-project has its own repository, build process, integration
|
||||
cycle and so on. More over the **Ring architecture is split into two
|
||||
Each Jami sub-project has its own repository, build process, integration
|
||||
cycle and so on. More over the **Jami architecture is split into two
|
||||
independent modules**: LibRing *(daemon)* and clients.
|
||||
|
||||
Having a unique revision is not a solution in this situation. The
|
||||
retained idea is having a global "state" and **various updates per
|
||||
module**.
|
||||
|
||||
For consistency, **each Ring module has to follow the same process** as
|
||||
For consistency, **each Jami module has to follow the same process** as
|
||||
described in following points. But not all modules have to be modified
|
||||
in same time.
|
||||
|
||||
|
@ -38,7 +38,7 @@ Repository Preparation
|
|||
Testing
|
||||
-------
|
||||
|
||||
* Remove any existing Ring installations from your machine.
|
||||
* Remove any existing Jami installations from your machine.
|
||||
* Start with clean git tree by running `git clean -d -f -x` from the top
|
||||
level directory of the project.
|
||||
* Build and install the daemon and client, see How\\\_to\\\_build
|
||||
|
@ -46,7 +46,7 @@ level directory of the project.
|
|||
machines.
|
||||
* Run manual tests
|
||||
* Try registering and using different accounts.
|
||||
* Try making calls between Ring and other free softphones (Ekiga,
|
||||
* Try making calls between Jami and other free softphones (Ekiga,
|
||||
Linphone), as well as hardware VoIP phones.
|
||||
* To catch uninitialized values being used, memory leaks, invalid frees,
|
||||
etc. run `valgrind --track-origins=yes --db-attach=yes ./bin/dring`
|
||||
|
|
|
@ -646,7 +646,7 @@ There is two major use case for group chats:
|
|||
1. Something like a Mattermost in a company, with private channels, and some roles (admin/spectator/bot/etc) or for educations (where only a few are active).
|
||||
2. Horizontal conversations like a conversation between friends.
|
||||
|
||||
Ring will be for which one?
|
||||
Jami will be for which one?
|
||||
|
||||
#### Implementation idea
|
||||
|
||||
|
|
Loading…
Reference in New Issue