Browse code

Documentation updates

These documentation files contains a lot of promises about future
development. I think that belongs to todo's, maybe not to the documentation.

oej authored on 22/10/2009 19:11:09
Showing 5 changed files
... ...
@@ -15,26 +15,26 @@ Vaclav Kubart
15 15
    future it will do subscriptions to reg events and presence with
16 16
    resource lists too.
17 17
 
18
-   It is accessible only using internal Querry Status API (QSA).
19
-   Everywhere (in C code) you need subscriptions to presentity status, you
20
-   only create an internal subscription to it and the rest is done by this
21
-   module. It processes internal subscription and creates a SIP
22
-   subscription (SUBSCRIBE-NOTIFY dialog) to requested presentity. Every
23
-   NOTIFY request produces new QSA message with status information into
24
-   destination message queue.
18
+   It is accessible only using the internal Query Status API (QSA).
19
+   Everywhere (in the C code) where you need subscriptions to presentity
20
+   status, you only create an internal subscription to it and the rest is
21
+   done by this module. It processes the internal subscription and creates
22
+   a SIP subscription (SUBSCRIBE-NOTIFY dialog) to requested presentity.
23
+   Every NOTIFY request produces new QSA message with status information
24
+   into destination message queue.
25 25
 
26 26
    Instead of this module can be used PA module with parameter
27 27
    accept_internal_subscriptions set to 1. In that case the subscription
28 28
    will be only to internal status hold by PA.
29 29
 
30
-   For every requested (record, subscriber) is created new SIP
31
-   subscription! This is due to authorization of such subscriptions - B2B
32
-   UA can't decide about authorization rules, thus it has to leave it on
33
-   the presence server to which it creates the subscription and this
34
-   means, that it has to create the subscription as the subscriber. There
35
-   is a possibility to do subscriptions with the same To + From only once,
36
-   but this is left for future optimalizations (it will probably not help
37
-   a lot).
30
+   For every requested (record, subscriber) a new SIP subscription is
31
+   created. This is due to authorization of such subscriptions - B2B UA
32
+   can't decide about authorization rules, thus it has to leave it on the
33
+   presence server to which it creates the subscription and this means,
34
+   that it has to create the subscription as a subscriber. There is a
35
+   possibility to do subscriptions with the same To + From only once, but
36
+   this is left for future optimalizations (it will probably not help a
37
+   lot).
38 38
 
39 39
 1.1. Dependencies
40 40
 
... ...
@@ -130,7 +130,7 @@ Vaclav Kubart
130 130
    handle_notify()
131 131
           Handles NOTIFY request.
132 132
 
133
-          The module tries to find subscription to which the NOTIFY
133
+          The module tries to find the subscription to which the NOTIFY
134 134
           belongs to (it tries both - confirmed and unconfirmed
135 135
           subscriptions because NOTIFY may arrive before 2xx response on
136 136
           SUBSCRIBE request). If no such subscription exists, the function
... ...
@@ -8,7 +8,7 @@
8 8
 	<term><varname>handle_notify()</varname></term>
9 9
 	<listitem>
10 10
 		<para>Handles NOTIFY request.</para>
11
-		<para>The module tries to find subscription to which the NOTIFY belongs
11
+		<para>The module tries to find the subscription to which the NOTIFY belongs
12 12
 		to (it tries both - confirmed and unconfirmed subscriptions because
13 13
 		NOTIFY may arrive before 2xx response on SUBSCRIBE request). If no such
14 14
 		subscription exists, the function returns -1, otherwise it processes the
... ...
@@ -1,6 +1,12 @@
1 1
 <?xml version="1.0" encoding="UTF-8"?>
2
-<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
3
-   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
2
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3
+"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
4
+
5
+<!-- Include general documentation entities -->
6
+<!ENTITY % docentities SYSTEM "../../../docbook/entities.xml">
7
+%docentities;
8
+
9
+]>
4 10
 
5 11
 <section id="presence_b2b.parameters"><title>Parameters</title>
6 12
 
... ...
@@ -1,6 +1,12 @@
1 1
 <?xml version='1.0' encoding='UTF-8'?>
2
-<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
3
-   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
2
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3
+"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
4
+
5
+<!-- Include general documentation entities -->
6
+<!ENTITY % docentities SYSTEM "../../../docbook/entities.xml">
7
+%docentities;
8
+
9
+]>
4 10
 
5 11
 <section id="presence_b2b"><title>Presence B2B UA</title>
6 12
 
... ...
@@ -17,12 +23,12 @@
17 17
 future it will do subscriptions to reg events and presence with resource lists
18 18
 too.</para>
19 19
 
20
-<para>It is accessible only using internal Querry Status API (QSA). Everywhere
21
-(in C code) you need subscriptions to presentity status, you only create an internal
22
-subscription to it and the rest is done by this module. It processes internal
23
-subscription and creates a SIP subscription (SUBSCRIBE-NOTIFY dialog) to
24
-requested presentity. Every NOTIFY request produces new QSA message with status
25
-information into destination message queue.
20
+<para>It is accessible only using the internal Query Status API (QSA). Everywhere
21
+(in the C code) where you need subscriptions to presentity status, you only create
22
+an internal subscription to it and the rest is done by this module. 
23
+It processes the internal subscription and creates a SIP subscription 
24
+(SUBSCRIBE-NOTIFY dialog) to requested presentity. Every NOTIFY request produces 
25
+new QSA message with status information into destination message queue.
26 26
 </para>
27 27
 
28 28
 <para>Instead of this module can be used PA module with parameter
... ...
@@ -30,11 +36,11 @@ information into destination message queue.
30 30
 subscription will be only to internal status hold by PA.
31 31
 </para>
32 32
 
33
-<para>For every requested (record, subscriber) is created new SIP subscription!
33
+<para>For every requested (record, subscriber) a new SIP subscription is created.
34 34
 This is due to authorization of such subscriptions - B2B UA can't decide about
35 35
 authorization rules, thus it has to leave it on the presence server to which it
36 36
 creates the subscription and this means, that it has to create the subscription
37
-as the subscriber. There is a possibility to do subscriptions with the same
37
+as a subscriber. There is a possibility to do subscriptions with the same
38 38
 To + From only once, but this is left for future optimalizations (it will
39 39
 probably not help a lot).
40 40
 </para>
... ...
@@ -23,6 +23,14 @@
23 23
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
24 24
  */
25 25
 
26
+/*!
27
+ * \file
28
+ * \brief SIP-router core :: version and compile flag macros
29
+ * \ingroup core
30
+ *
31
+ * Module: \ref core
32
+ */
33
+
26 34
 #ifndef version_h
27 35
 #define version_h
28 36