master/coturn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs fixed

Browse Source
This commit is contained in:
mom040267 2014-04-21 06:14:29 +00:00
parent ed527c53b9
commit 6bad096e4b
2 changed files with 19 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
README.turnserver
View File

@ -613,11 +613,14 @@ Once the temporary username and password are obtained by the client (browser)
application, then the rest is just 'classic" long-term credentials mechanism.
For developers, we are going to describe it step-by-step below:
- a new TURN client sends a request command to the TURN server.
- a new TURN client sends a request command to the TURN server. Optionally,
it adds the ORIGIN field to it.
- TURN server sees that this is a new client and the message is not
authenticated.
- the TURN server generates a random nonce string, and return the
error 401 to the client, with nonce and realm included.
error 401 to the client, with nonce and realm included. If the ORIGIN
field was present in the client request, it may affect the realm value
that the server chooses for the client.
- the client sees the 401 error and it extracts two values from
the error response: the nonce and the realm.
- the client uses username, realm and password to produce a key:
@ -703,7 +706,11 @@ the "open password" option is less secure but more convenient for low-security e
For short-term credentials, you will use open passwords only. See the file
turndb/testredisdbsetup.sh as an example.
6) Of course, the turnserver can be used in non-secure mode, when users are allowed to establish
6) If a database is used, then users can be divided into multiple independent realms. Each realm
can be administered separately, and each realm can have its own set of users and its own
performance options (max-bps, user-quota, total-quota).
7) Of course, the turnserver can be used in non-secure mode, when users are allowed to establish
sessions anonymously. But in most cases (like WebRTC) that will not work.
For the status and statistics database, there are two choices:

11
man/man1/turnserver.1
View File

@ -843,13 +843,16 @@ application, then the rest is just 'classic" long\-term credentials mechanism.
For developers, we are going to describe it step\-by\-step below:
.RS
.IP \(bu 3
a new TURN client sends a request command to the TURN server.
a new TURN client sends a request command to the TURN server. Optionally,
it adds the ORIGIN field to it.
.IP \(bu 3
TURN server sees that this is a new client and the message is not
authenticated.
.IP \(bu 3
the TURN server generates a random nonce string, and return the
error 401 to the client, with nonce and realm included.
error 401 to the client, with nonce and realm included. If the ORIGIN
field was present in the client request, it may affect the realm value
that the server chooses for the client.
.IP \(bu 3
the client sees the 401 error and it extracts two values from
the error response: the nonce and the realm.
@ -947,6 +950,10 @@ the "open password" option is less secure but more convenient for low\-security
For short\-term credentials, you will use open passwords only. See the file
turndb/testredisdbsetup.sh as an example.
.IP 6) 4
If a database is used, then users can be divided into multiple independent realms. Each realm
can be administered separately, and each realm can have its own set of users and its own
performance \fIoptions\fP (max\-bps, user\-quota, total\-quota).
.IP 7) 4
Of course, the \fIturnserver\fP can be used in non\-secure mode, when users are allowed to establish
sessions anonymously. But in most cases (like WebRTC) that will not work.
.PP