Browse code

modules_k/*: moved k modules in directory modules/

Daniel-Constantin Mierla authored on 20/01/2013 11:57:52
Showing 1 changed files
1 1
deleted file mode 100644
... ...
@@ -1,217 +0,0 @@
1
-presence_dialoginfo Module
2
-
3
-Juha Heinanen
4
-
5
-   <jh@tutpro.com>
6
-   Klaus
7
-   Darilion
8
-   <klaus.darilion@mailinglists@pernau.at>
9
-
10
-Edited by
11
-
12
-Juha Heinanen
13
-
14
-   <jh@tutpro.com>
15
-
16
-Edited by
17
-
18
-Klaus Darilion
19
-
20
-   <klaus.darilion@mailinglists@pernau.at>
21
-
22
-   Copyright © 2007 Juha Heinanen
23
-
24
-   Copyright © 2008 Klaus Darilion, IPCom (Module implementation was
25
-   partly sponsored by Silver Server (www.sil.at))
26
-     __________________________________________________________________
27
-
28
-   Table of Contents
29
-
30
-   1. Admin Guide
31
-
32
-        1. Overview
33
-        2. Dependencies
34
-
35
-              2.1. Kamailio Modules
36
-              2.2. External Libraries or Applications
37
-
38
-        3. Parameters
39
-
40
-              3.1. force_single_dialog (int)
41
-
42
-        4. Functions
43
-
44
-   List of Examples
45
-
46
-   1.1. Set parameter
47
-
48
-Chapter 1. Admin Guide
49
-
50
-   Table of Contents
51
-
52
-   1. Overview
53
-   2. Dependencies
54
-
55
-        2.1. Kamailio Modules
56
-        2.2. External Libraries or Applications
57
-
58
-   3. Parameters
59
-
60
-        3.1. force_single_dialog (int)
61
-
62
-   4. Functions
63
-
64
-1. Overview
65
-
66
-   The module enables the handling of "Event: dialog" (as defined in RFC
67
-   4235) inside of the presence module. This can be used distribute the
68
-   dialog-info status to the subscribed watchers.
69
-
70
-   The module does not currently implement any authorization rules. It
71
-   assumes that publish requests are only issued by an authorized
72
-   application and subscribe requests only by authorized users.
73
-   Authorization can thus be easily done in Kamailio configuration file
74
-   before calling handle_publish() and handle_subscribe() functions.
75
-
76
-   Note: This module only activates the processing of the "dialog" in the
77
-   presence module. To send dialog-info to watchers you also need a source
78
-   which PUBLISH the dialog info to the presence module. For example you
79
-   can use the pua_dialoginfo module or any external component. This
80
-   approach allows to have the presence server and the dialog-info aware
81
-   publisher (e.g. the main proxy) on different Kamailio instances.
82
-
83
-   This module by default does body aggregation. That means, if the
84
-   presence module received PUBLISH from multiple presentities (e.g. if
85
-   the entity has multiple dialogs the pua_dialoginfo will send multiple
86
-   PUBLISH), the module will parse all the received (and still valid,
87
-   depending on the Expires header in the PUBLISH request) XML documents
88
-   and generate a single XML document with multiple "dialog" elements.
89
-   This is perfectly valid, but unfortunately not supported by all SIP
90
-   phones, e.g. Linksys SPA962 crashes when it receives dialog-info with
91
-   multiple dialog elements. In this case use the ..... module parameter.
92
-
93
-   To get better understanding how all the module works together please
94
-   take a look at the follwing figure:
95
-    Main Proxy and Presence Server on the same Instance
96
-
97
-   caller        proxy &      callee         watcher
98
-alice@example   presence   bob@example   watcher@example
99
-                 server
100
-     |             |            |               |
101
-     |             |<-------SUBSCRIBE bob-------|
102
-     |             |--------200 OK------------->|
103
-     |             |--------NOTIFY------------->|
104
-     |             |<-------200 OK--------------|
105
-     |             |            |               |
106
-     |--INV bob--->|            |               |
107
-     |             |--INV bob-->|               |
108
-     |             |<-100-------|               |
109
-     |             |            |               |
110
-     |             |<-180 ring--|               |
111
-     |<--180 ring--|            |               |
112
-     |             |--          |               |
113
-     |             |   \        |               |
114
-     |             | PUBLISH bob|               |
115
-     |             |   /        |               |
116
-     |             |<-          |               |
117
-     |             |            |               |
118
-     |             |--          |               |
119
-     |             |   \        |               |
120
-     |             | 200 ok     |               |
121
-     |             |   /        |               |
122
-     |             |<-          |               |
123
-     |             |--------NOTIFY------------->|
124
-     |             |<-------200 OK--------------|
125
-     |             |            |               |
126
-
127
-     * The watcher subscribes the "Event: dialog" of Bob.
128
-     * Alice calls Bob.
129
-     * Bob replies with ringing, the dialog in the dialog module transits
130
-       to "early". The callback in pua_dialoginfo is executed. The
131
-       pua_dialoginfo module creates the XML document and uses the pua
132
-       module to send the PUBLISH. (pua module itself uses tm module to
133
-       send the PUBLISH stateful)
134
-     * PUBLISH is received and handled by presence module. Presence module
135
-       updates the "presentity". Presence module checks for active
136
-       watchers of the presentity. It gives all the XML dcouments to
137
-       presence_dialoginfo module to aggregate them into a single XML
138
-       document. Then it sends the NOTIFY with the aggregated XML document
139
-       to all active watchers.
140
-
141
-   The presence server can also be separated from the main proxy by using
142
-   a separate Kamailio instance as shown in the following figure. (Either
143
-   set the outbound_proxy parameter of pua module or make sure to route
144
-   the "looped" PUBLISH requests from the main proxy to the presence
145
-   server).
146
-    Main Proxy and Presence Server use a separate Instance
147
-
148
-   caller        proxy &   presence      callee         watcher
149
-alice@example    server     server     bob@example   watcher@example
150
-     |             |            |               |            |
151
-     |             |<--------------------SUBSCRIBE bob-------|
152
-     |             |-SUBSC bob->|               |            |
153
-     |             |<-200 ok----|               |            |
154
-     |             |---------------------200 OK------------->|
155
-     |             |          .... NOTIFY ... 200 OK ...     |
156
-     |             |            |               |            |
157
-     |             |            |               |            |
158
-     |--INV bob--->|            |               |            |
159
-     |             |--INV bob------------------>|            |
160
-     |             |<-100-----------------------|            |
161
-     |             |            |               |            |
162
-     |             |<-180 ring------------------|            |
163
-     |<--180 ring--|            |               |            |
164
-     |             |--PUBL bob->|               |            |
165
-     |             |<-200 ok----|               |            |
166
-     |             |            |--------NOTIFY------------->|
167
-     |             |            |<-------200 OK--------------|
168
-     |             |            |               |            |
169
-
170
-   Known issues:
171
-     * The "version" attribute is increased for every NOTIFY, even if the
172
-       XML document has not changed. This is of course valid, but not very
173
-       smart.
174
-
175
-2. Dependencies
176
-
177
-   2.1. Kamailio Modules
178
-   2.2. External Libraries or Applications
179
-
180
-2.1. Kamailio Modules
181
-
182
-   The following modules must be loaded before this module:
183
-     * presence.
184
-
185
-2.2. External Libraries or Applications
186
-
187
-   None.
188
-
189
-3. Parameters
190
-
191
-   3.1. force_single_dialog (int)
192
-
193
-3.1. force_single_dialog (int)
194
-
195
-   By default the module aggregates all available dialog info into a
196
-   single dialog-info document containing multiple "dialog" elements. If
197
-   the phone does not support this, you can activate this parameter.
198
-
199
-   If this parameter is set, only the dialog element with the currently
200
-   most interesting dialog state will be put into the dialog-info
201
-   document. Thus, the dialog-info element will contain only a single
202
-   "dialog" element. The algorithm chooses the state based onf the
203
-   following order of priority (least important first): terminated,
204
-   trying, proceeding, confirmed, early. Note: I consider the "early"
205
-   state more intersting than confirmed as often you might want to pickup
206
-   a call if the originall callee is already busy in a call.
207
-
208
-   Default value is “0”.
209
-
210
-   Example 1.1. Set parameter
211
-...
212
-modparam("presence_dialoginfo", "force_single_dialog", 1)
213
-...
214
-
215
-4. Functions
216
-
217
-   None to be used in configuration file.
Browse code

modules*: regenerated readmes

Daniel-Constantin Mierla authored on 02/10/2011 08:53:35
Showing 1 changed files
... ...
@@ -35,11 +35,11 @@ Klaus Darilion
35 35
               2.1. Kamailio Modules
36 36
               2.2. External Libraries or Applications
37 37
 
38
-        3. Exported Parameters
38
+        3. Parameters
39 39
 
40 40
               3.1. force_single_dialog (int)
41 41
 
42
-        4. Exported Functions
42
+        4. Functions
43 43
 
44 44
    List of Examples
45 45
 
... ...
@@ -55,11 +55,11 @@ Chapter 1. Admin Guide
55 55
         2.1. Kamailio Modules
56 56
         2.2. External Libraries or Applications
57 57
 
58
-   3. Exported Parameters
58
+   3. Parameters
59 59
 
60 60
         3.1. force_single_dialog (int)
61 61
 
62
-   4. Exported Functions
62
+   4. Functions
63 63
 
64 64
 1. Overview
65 65
 
... ...
@@ -186,7 +186,7 @@ alice@example    server     server     bob@example   watcher@example
186 186
 
187 187
    None.
188 188
 
189
-3. Exported Parameters
189
+3. Parameters
190 190
 
191 191
    3.1. force_single_dialog (int)
192 192
 
... ...
@@ -212,6 +212,6 @@ alice@example    server     server     bob@example   watcher@example
212 212
 modparam("presence_dialoginfo", "force_single_dialog", 1)
213 213
 ...
214 214
 
215
-4. Exported Functions
215
+4. Functions
216 216
 
217 217
    None to be used in configuration file.
Browse code

docs: cleanup in xml files

- useless revision history removed
- docs depend on entities.xml
- updated global entities
- fixed the links to users and devel mailing lists
- fixed the link to tracker

Daniel-Constantin Mierla authored on 18/06/2011 21:21:41
Showing 1 changed files
... ...
@@ -19,30 +19,27 @@ Klaus Darilion
19 19
 
20 20
    <klaus.darilion@mailinglists@pernau.at>
21 21
 
22
-   Copyright � 2007 Juha Heinanen
22
+   Copyright © 2007 Juha Heinanen
23 23
 
24
-   Copyright � 2008 Klaus Darilion, IPCom (Module implementation
25
-   was partly sponsored by Silver Server (www.sil.at))
26
-   Revision History
27
-   Revision $Revision: 1 $ $Date: 2007-04-30 14:05:57 +0200 (Mon,
28
-                           30 Jan 2007) $
29
-     __________________________________________________________
24
+   Copyright © 2008 Klaus Darilion, IPCom (Module implementation was
25
+   partly sponsored by Silver Server (www.sil.at))
26
+     __________________________________________________________________
30 27
 
31 28
    Table of Contents
32 29
 
33 30
    1. Admin Guide
34 31
 
35
-        1.1. Overview
36
-        1.2. Dependencies
32
+        1. Overview
33
+        2. Dependencies
37 34
 
38
-              1.2.1. Kamailio Modules
39
-              1.2.2. External Libraries or Applications
35
+              2.1. Kamailio Modules
36
+              2.2. External Libraries or Applications
40 37
 
41
-        1.3. Exported Parameters
38
+        3. Exported Parameters
42 39
 
43
-              1.3.1. force_single_dialog (int)
40
+              3.1. force_single_dialog (int)
44 41
 
45
-        1.4. Exported Functions
42
+        4. Exported Functions
46 43
 
47 44
    List of Examples
48 45
 
... ...
@@ -50,43 +47,51 @@ Klaus Darilion
50 47
 
51 48
 Chapter 1. Admin Guide
52 49
 
53
-1.1. Overview
54
-
55
-   The module enables the handling of "Event: dialog" (as defined
56
-   in RFC 4235) inside of the presence module. This can be used
57
-   distribute the dialog-info status to the subscribed watchers.
58
-
59
-   The module does not currently implement any authorization
60
-   rules. It assumes that publish requests are only issued by an
61
-   authorized application and subscribe requests only by
62
-   authorized users. Authorization can thus be easily done in
63
-   Kamailio configuration file before calling handle_publish() and
64
-   handle_subscribe() functions.
65
-
66
-   Note: This module only activates the processing of the "dialog"
67
-   in the presence module. To send dialog-info to watchers you
68
-   also need a source which PUBLISH the dialog info to the
69
-   presence module. For example you can use the pua_dialoginfo
70
-   module or any external component. This approach allows to have
71
-   the presence server and the dialog-info aware publisher (e.g.
72
-   the main proxy) on different Kamailio instances.
73
-
74
-   This module by default does body aggregation. That means, if
75
-   the presence module received PUBLISH from multiple presentities
76
-   (e.g. if the entity has multiple dialogs the pua_dialoginfo
77
-   will send multiple PUBLISH), the module will parse all the
78
-   received (and still valid, depending on the Expires header in
79
-   the PUBLISH request) XML documents and generate a single XML
80
-   document with multiple "dialog" elements. This is perfectly
81
-   valid, but unfortunately not supported by all SIP phones, e.g.
82
-   Linksys SPA962 crashes when it receives dialog-info with
83
-   multiple dialog elements. In this case use the ..... module
84
-   parameter.
85
-
86
-   To get better understanding how all the module works together
87
-   please take a look at the follwing figure:
50
+   Table of Contents
51
+
52
+   1. Overview
53
+   2. Dependencies
54
+
55
+        2.1. Kamailio Modules
56
+        2.2. External Libraries or Applications
57
+
58
+   3. Exported Parameters
59
+
60
+        3.1. force_single_dialog (int)
61
+
62
+   4. Exported Functions
63
+
64
+1. Overview
65
+
66
+   The module enables the handling of "Event: dialog" (as defined in RFC
67
+   4235) inside of the presence module. This can be used distribute the
68
+   dialog-info status to the subscribed watchers.
69
+
70
+   The module does not currently implement any authorization rules. It
71
+   assumes that publish requests are only issued by an authorized
72
+   application and subscribe requests only by authorized users.
73
+   Authorization can thus be easily done in Kamailio configuration file
74
+   before calling handle_publish() and handle_subscribe() functions.
88 75
 
76
+   Note: This module only activates the processing of the "dialog" in the
77
+   presence module. To send dialog-info to watchers you also need a source
78
+   which PUBLISH the dialog info to the presence module. For example you
79
+   can use the pua_dialoginfo module or any external component. This
80
+   approach allows to have the presence server and the dialog-info aware
81
+   publisher (e.g. the main proxy) on different Kamailio instances.
89 82
 
83
+   This module by default does body aggregation. That means, if the
84
+   presence module received PUBLISH from multiple presentities (e.g. if
85
+   the entity has multiple dialogs the pua_dialoginfo will send multiple
86
+   PUBLISH), the module will parse all the received (and still valid,
87
+   depending on the Expires header in the PUBLISH request) XML documents
88
+   and generate a single XML document with multiple "dialog" elements.
89
+   This is perfectly valid, but unfortunately not supported by all SIP
90
+   phones, e.g. Linksys SPA962 crashes when it receives dialog-info with
91
+   multiple dialog elements. In this case use the ..... module parameter.
92
+
93
+   To get better understanding how all the module works together please
94
+   take a look at the follwing figure:
90 95
     Main Proxy and Presence Server on the same Instance
91 96
 
92 97
    caller        proxy &      callee         watcher
... ...
@@ -119,29 +124,25 @@ alice@example   presence   bob@example   watcher@example
119 124
      |             |<-------200 OK--------------|
120 125
      |             |            |               |
121 126
 
122
-
123 127
      * The watcher subscribes the "Event: dialog" of Bob.
124 128
      * Alice calls Bob.
125
-     * Bob replies with ringing, the dialog in the dialog module
126
-       transits to "early". The callback in pua_dialoginfo is
127
-       executed. The pua_dialoginfo module creates the XML
128
-       document and uses the pua module to send the PUBLISH. (pua
129
-       module itself uses tm module to send the PUBLISH stateful)
130
-     * PUBLISH is received and handled by presence module.
131
-       Presence module updates the "presentity". Presence module
132
-       checks for active watchers of the presentity. It gives all
133
-       the XML dcouments to presence_dialoginfo module to
134
-       aggregate them into a single XML document. Then it sends
135
-       the NOTIFY with the aggregated XML document to all active
136
-       watchers.
137
-
138
-   The presence server can also be separated from the main proxy
139
-   by using a separate Kamailio instance as shown in the following
140
-   figure. (Either set the outbound_proxy parameter of pua module
141
-   or make sure to route the "looped" PUBLISH requests from the
142
-   main proxy to the presence server).
143
-
144
-
129
+     * Bob replies with ringing, the dialog in the dialog module transits
130
+       to "early". The callback in pua_dialoginfo is executed. The
131
+       pua_dialoginfo module creates the XML document and uses the pua
132
+       module to send the PUBLISH. (pua module itself uses tm module to
133
+       send the PUBLISH stateful)
134
+     * PUBLISH is received and handled by presence module. Presence module
135
+       updates the "presentity". Presence module checks for active
136
+       watchers of the presentity. It gives all the XML dcouments to
137
+       presence_dialoginfo module to aggregate them into a single XML
138
+       document. Then it sends the NOTIFY with the aggregated XML document
139
+       to all active watchers.
140
+
141
+   The presence server can also be separated from the main proxy by using
142
+   a separate Kamailio instance as shown in the following figure. (Either
143
+   set the outbound_proxy parameter of pua module or make sure to route
144
+   the "looped" PUBLISH requests from the main proxy to the presence
145
+   server).
145 146
     Main Proxy and Presence Server use a separate Instance
146 147
 
147 148
    caller        proxy &   presence      callee         watcher
... ...
@@ -166,51 +167,51 @@ alice@example    server     server     bob@example   watcher@example
166 167
      |             |            |<-------200 OK--------------|
167 168
      |             |            |               |            |
168 169
 
169
-
170
-
171
-
172 170
    Known issues:
173
-     * The "version" attribute is increased for every NOTIFY, even
174
-       if the XML document has not changed. This is of course
175
-       valid, but not very smart.
171
+     * The "version" attribute is increased for every NOTIFY, even if the
172
+       XML document has not changed. This is of course valid, but not very
173
+       smart.
176 174
 
177
-1.2. Dependencies
175
+2. Dependencies
178 176
 
179
-1.2.1. Kamailio Modules
177
+   2.1. Kamailio Modules
178
+   2.2. External Libraries or Applications
179
+
180
+2.1. Kamailio Modules
180 181
 
181 182
    The following modules must be loaded before this module:
182 183
      * presence.
183 184
 
184
-1.2.2. External Libraries or Applications
185
+2.2. External Libraries or Applications
185 186
 
186 187
    None.
187 188
 
188
-1.3. Exported Parameters
189
+3. Exported Parameters
190
+
191
+   3.1. force_single_dialog (int)
189 192
 
190
-1.3.1. force_single_dialog (int)
193
+3.1. force_single_dialog (int)
191 194
 
192
-   By default the module aggregates all available dialog info into
193
-   a single dialog-info document containing multiple "dialog"
194
-   elements. If the phone does not support this, you can activate
195
-   this parameter.
195
+   By default the module aggregates all available dialog info into a
196
+   single dialog-info document containing multiple "dialog" elements. If
197
+   the phone does not support this, you can activate this parameter.
196 198
 
197
-   If this parameter is set, only the dialog element with the
198
-   currently most interesting dialog state will be put into the
199
-   dialog-info document. Thus, the dialog-info element will
200
-   contain only a single "dialog" element. The algorithm chooses
201
-   the state based onf the following order of priority (least
202
-   important first): terminated, trying, proceeding, confirmed,
203
-   early. Note: I consider the "early" state more intersting than
204
-   confirmed as often you might want to pickup a call if the
205
-   originall callee is already busy in a call.
199
+   If this parameter is set, only the dialog element with the currently
200
+   most interesting dialog state will be put into the dialog-info
201
+   document. Thus, the dialog-info element will contain only a single
202
+   "dialog" element. The algorithm chooses the state based onf the
203
+   following order of priority (least important first): terminated,
204
+   trying, proceeding, confirmed, early. Note: I consider the "early"
205
+   state more intersting than confirmed as often you might want to pickup
206
+   a call if the originall callee is already busy in a call.
206 207
 
207
-   Default value is "0".
208
+   Default value is “0”.
208 209
 
209 210
    Example 1.1. Set parameter
210 211
 ...
211 212
 modparam("presence_dialoginfo", "force_single_dialog", 1)
212 213
 ...
213 214
 
214
-1.4. Exported Functions
215
+4. Exported Functions
215 216
 
216 217
    None to be used in configuration file.
Browse code

- typo in name reported by Inaki Baz Castillo

git-svn-id: https://openser.svn.sourceforge.net/svnroot/openser/trunk@5005 689a6050-402a-0410-94f2-e92a70836424

Daniel-Constantin Mierla authored on 26/09/2008 19:31:04
Showing 1 changed files
... ...
@@ -1,5 +1,4 @@
1
-
2
-presenece_dialoginfo Module
1
+presence_dialoginfo Module
3 2
 
4 3
 Juha Heinanen
5 4
 
... ...
@@ -26,8 +25,8 @@ Klaus Darilion
26 25
    was partly sponsored by Silver Server (www.sil.at))
27 26
    Revision History
28 27
    Revision $Revision: 1 $ $Date: 2007-04-30 14:05:57 +0200 (Mon,
29
-   30 Jan 2007) $
30
-     _________________________________________________________
28
+                           30 Jan 2007) $
29
+     __________________________________________________________
31 30
 
32 31
    Table of Contents
33 32
 
... ...
@@ -61,29 +60,28 @@ Chapter 1. Admin Guide
61 60
    rules. It assumes that publish requests are only issued by an
62 61
    authorized application and subscribe requests only by
63 62
    authorized users. Authorization can thus be easily done in
64
-   Kamailio configuration file before calling handle_publish()
65
-   and handle_subscribe() functions.
66
-
67
-   Note: This module only activates the processing of the
68
-   "dialog" in the presence module. To send dialog-info to
69
-   watchers you also need a source which PUBLISH the dialog info
70
-   to the presence module. For example you can use the
71
-   pua_dialoginfo module or any external component. This approach
72
-   allows to have the presence server and the dialog-info aware
73
-   publisher (e.g. the main proxy) on different Kamailio
74
-   instances.
63
+   Kamailio configuration file before calling handle_publish() and
64
+   handle_subscribe() functions.
65
+
66
+   Note: This module only activates the processing of the "dialog"
67
+   in the presence module. To send dialog-info to watchers you
68
+   also need a source which PUBLISH the dialog info to the
69
+   presence module. For example you can use the pua_dialoginfo
70
+   module or any external component. This approach allows to have
71
+   the presence server and the dialog-info aware publisher (e.g.
72
+   the main proxy) on different Kamailio instances.
75 73
 
76 74
    This module by default does body aggregation. That means, if
77
-   the presence module received PUBLISH from multiple
78
-   presentities (e.g. if the entity has multiple dialogs the
79
-   pua_dialoginfo will send multiple PUBLISH), the module will
80
-   parse all the received (and still valid, depending on the
81
-   Expires header in the PUBLISH request) XML documents and
82
-   generate a single XML document with multiple "dialog"
83
-   elements. This is perfectly valid, but unfortunately not
84
-   supported by all SIP phones, e.g. Linksys SPA962 crashes when
85
-   it receives dialog-info with multiple dialog elements. In this
86
-   case use the ..... module parameter.
75
+   the presence module received PUBLISH from multiple presentities
76
+   (e.g. if the entity has multiple dialogs the pua_dialoginfo
77
+   will send multiple PUBLISH), the module will parse all the
78
+   received (and still valid, depending on the Expires header in
79
+   the PUBLISH request) XML documents and generate a single XML
80
+   document with multiple "dialog" elements. This is perfectly
81
+   valid, but unfortunately not supported by all SIP phones, e.g.
82
+   Linksys SPA962 crashes when it receives dialog-info with
83
+   multiple dialog elements. In this case use the ..... module
84
+   parameter.
87 85
 
88 86
    To get better understanding how all the module works together
89 87
    please take a look at the follwing figure:
... ...
@@ -121,6 +119,7 @@ alice@example   presence   bob@example   watcher@example
121 119
      |             |<-------200 OK--------------|
122 120
      |             |            |               |
123 121
 
122
+
124 123
      * The watcher subscribes the "Event: dialog" of Bob.
125 124
      * Alice calls Bob.
126 125
      * Bob replies with ringing, the dialog in the dialog module
... ...
@@ -137,10 +136,10 @@ alice@example   presence   bob@example   watcher@example
137 136
        watchers.
138 137
 
139 138
    The presence server can also be separated from the main proxy
140
-   by using a separate Kamailio instance as shown in the
141
-   following figure. (Either set the outbound_proxy parameter of
142
-   pua module or make sure to route the "looped" PUBLISH requests
143
-   from the main proxy to the presence server).
139
+   by using a separate Kamailio instance as shown in the following
140
+   figure. (Either set the outbound_proxy parameter of pua module
141
+   or make sure to route the "looped" PUBLISH requests from the
142
+   main proxy to the presence server).
144 143
 
145 144
 
146 145
     Main Proxy and Presence Server use a separate Instance
... ...
@@ -169,10 +168,11 @@ alice@example    server     server     bob@example   watcher@example
169 168
 
170 169
 
171 170
 
171
+
172 172
    Known issues:
173
-     * The "version" attribute is increased for every NOTIFY,
174
-       even if the XML document has not changed. This is of
175
-       course valid, but not very smart.
173
+     * The "version" attribute is increased for every NOTIFY, even
174
+       if the XML document has not changed. This is of course
175
+       valid, but not very smart.
176 176
 
177 177
 1.2. Dependencies
178 178
 
... ...
@@ -189,10 +189,10 @@ alice@example    server     server     bob@example   watcher@example
189 189
 
190 190
 1.3.1. force_single_dialog (int)
191 191
 
192
-   By default the module aggregates all available dialog info
193
-   into a single dialog-info document containing multiple
194
-   "dialog" elements. If the phone does not support this, you can
195
-   activate this parameter.
192
+   By default the module aggregates all available dialog info into
193
+   a single dialog-info document containing multiple "dialog"
194
+   elements. If the phone does not support this, you can activate
195
+   this parameter.
196 196
 
197 197
    If this parameter is set, only the dialog element with the
198 198
    currently most interesting dialog state will be put into the
Browse code

- add modules for dialog-info support to pua and presence module This work was sponsored by Silver Server (www.sil.at)

- add modules to debian presence package

- add new modules to exclude_modules



git-svn-id: https://openser.svn.sourceforge.net/svnroot/openser/trunk@4937 689a6050-402a-0410-94f2-e92a70836424

Klaus Darilion authored on 17/09/2008 11:45:48
Showing 1 changed files
1 1
new file mode 100644
... ...
@@ -0,0 +1,216 @@
1
+
2
+presenece_dialoginfo Module
3
+
4
+Juha Heinanen
5
+
6
+   <jh@tutpro.com>
7
+   Klaus
8
+   Darilion
9
+   <klaus.darilion@mailinglists@pernau.at>
10
+
11
+Edited by
12
+
13
+Juha Heinanen
14
+
15
+   <jh@tutpro.com>
16
+
17
+Edited by
18
+
19
+Klaus Darilion
20
+
21
+   <klaus.darilion@mailinglists@pernau.at>
22
+
23
+   Copyright � 2007 Juha Heinanen
24
+
25
+   Copyright � 2008 Klaus Darilion, IPCom (Module implementation
26
+   was partly sponsored by Silver Server (www.sil.at))
27
+   Revision History
28
+   Revision $Revision: 1 $ $Date: 2007-04-30 14:05:57 +0200 (Mon,
29
+   30 Jan 2007) $
30
+     _________________________________________________________
31
+
32
+   Table of Contents
33
+
34
+   1. Admin Guide
35
+
36
+        1.1. Overview
37
+        1.2. Dependencies
38
+
39
+              1.2.1. Kamailio Modules
40
+              1.2.2. External Libraries or Applications
41
+
42
+        1.3. Exported Parameters
43
+
44
+              1.3.1. force_single_dialog (int)
45
+
46
+        1.4. Exported Functions
47
+
48
+   List of Examples
49
+
50
+   1.1. Set parameter
51
+
52
+Chapter 1. Admin Guide
53
+
54
+1.1. Overview
55
+
56
+   The module enables the handling of "Event: dialog" (as defined
57
+   in RFC 4235) inside of the presence module. This can be used
58
+   distribute the dialog-info status to the subscribed watchers.
59
+
60
+   The module does not currently implement any authorization
61
+   rules. It assumes that publish requests are only issued by an
62
+   authorized application and subscribe requests only by
63
+   authorized users. Authorization can thus be easily done in
64
+   Kamailio configuration file before calling handle_publish()
65
+   and handle_subscribe() functions.
66
+
67
+   Note: This module only activates the processing of the
68
+   "dialog" in the presence module. To send dialog-info to
69
+   watchers you also need a source which PUBLISH the dialog info
70
+   to the presence module. For example you can use the
71
+   pua_dialoginfo module or any external component. This approach
72
+   allows to have the presence server and the dialog-info aware
73
+   publisher (e.g. the main proxy) on different Kamailio
74
+   instances.
75
+
76
+   This module by default does body aggregation. That means, if
77
+   the presence module received PUBLISH from multiple
78
+   presentities (e.g. if the entity has multiple dialogs the
79
+   pua_dialoginfo will send multiple PUBLISH), the module will
80
+   parse all the received (and still valid, depending on the
81
+   Expires header in the PUBLISH request) XML documents and
82
+   generate a single XML document with multiple "dialog"
83
+   elements. This is perfectly valid, but unfortunately not
84
+   supported by all SIP phones, e.g. Linksys SPA962 crashes when
85
+   it receives dialog-info with multiple dialog elements. In this
86
+   case use the ..... module parameter.
87
+
88
+   To get better understanding how all the module works together
89
+   please take a look at the follwing figure:
90
+
91
+
92
+    Main Proxy and Presence Server on the same Instance
93
+
94
+   caller        proxy &      callee         watcher
95
+alice@example   presence   bob@example   watcher@example
96
+                 server
97
+     |             |            |               |
98
+     |             |<-------SUBSCRIBE bob-------|
99
+     |             |--------200 OK------------->|
100
+     |             |--------NOTIFY------------->|
101
+     |             |<-------200 OK--------------|
102
+     |             |            |               |
103
+     |--INV bob--->|            |               |
104
+     |             |--INV bob-->|               |
105
+     |             |<-100-------|               |
106
+     |             |            |               |
107
+     |             |<-180 ring--|               |
108
+     |<--180 ring--|            |               |
109
+     |             |--          |               |
110
+     |             |   \        |               |
111
+     |             | PUBLISH bob|               |
112
+     |             |   /        |               |
113
+     |             |<-          |               |
114
+     |             |            |               |
115
+     |             |--          |               |
116
+     |             |   \        |               |
117
+     |             | 200 ok     |               |
118
+     |             |   /        |               |
119
+     |             |<-          |               |
120
+     |             |--------NOTIFY------------->|
121
+     |             |<-------200 OK--------------|
122
+     |             |            |               |
123
+
124
+     * The watcher subscribes the "Event: dialog" of Bob.
125
+     * Alice calls Bob.
126
+     * Bob replies with ringing, the dialog in the dialog module
127
+       transits to "early". The callback in pua_dialoginfo is
128
+       executed. The pua_dialoginfo module creates the XML
129
+       document and uses the pua module to send the PUBLISH. (pua
130
+       module itself uses tm module to send the PUBLISH stateful)
131
+     * PUBLISH is received and handled by presence module.
132
+       Presence module updates the "presentity". Presence module
133
+       checks for active watchers of the presentity. It gives all
134
+       the XML dcouments to presence_dialoginfo module to
135
+       aggregate them into a single XML document. Then it sends
136
+       the NOTIFY with the aggregated XML document to all active
137
+       watchers.
138
+
139
+   The presence server can also be separated from the main proxy
140
+   by using a separate Kamailio instance as shown in the
141
+   following figure. (Either set the outbound_proxy parameter of
142
+   pua module or make sure to route the "looped" PUBLISH requests
143
+   from the main proxy to the presence server).
144
+
145
+
146
+    Main Proxy and Presence Server use a separate Instance
147
+
148
+   caller        proxy &   presence      callee         watcher
149
+alice@example    server     server     bob@example   watcher@example
150
+     |             |            |               |            |
151
+     |             |<--------------------SUBSCRIBE bob-------|
152
+     |             |-SUBSC bob->|               |            |
153
+     |             |<-200 ok----|               |            |
154
+     |             |---------------------200 OK------------->|
155
+     |             |          .... NOTIFY ... 200 OK ...     |
156
+     |             |            |               |            |
157
+     |             |            |               |            |
158
+     |--INV bob--->|            |               |            |
159
+     |             |--INV bob------------------>|            |
160
+     |             |<-100-----------------------|            |
161
+     |             |            |               |            |
162
+     |             |<-180 ring------------------|            |
163
+     |<--180 ring--|            |               |            |
164
+     |             |--PUBL bob->|               |            |
165
+     |             |<-200 ok----|               |            |
166
+     |             |            |--------NOTIFY------------->|
167
+     |             |            |<-------200 OK--------------|
168
+     |             |            |               |            |
169
+
170
+
171
+
172
+   Known issues:
173
+     * The "version" attribute is increased for every NOTIFY,
174
+       even if the XML document has not changed. This is of
175
+       course valid, but not very smart.
176
+
177
+1.2. Dependencies
178
+
179
+1.2.1. Kamailio Modules
180
+
181
+   The following modules must be loaded before this module:
182
+     * presence.
183
+
184
+1.2.2. External Libraries or Applications
185
+
186
+   None.
187
+
188
+1.3. Exported Parameters
189
+
190
+1.3.1. force_single_dialog (int)
191
+
192
+   By default the module aggregates all available dialog info
193
+   into a single dialog-info document containing multiple
194
+   "dialog" elements. If the phone does not support this, you can
195
+   activate this parameter.
196
+
197
+   If this parameter is set, only the dialog element with the
198
+   currently most interesting dialog state will be put into the
199
+   dialog-info document. Thus, the dialog-info element will
200
+   contain only a single "dialog" element. The algorithm chooses
201
+   the state based onf the following order of priority (least
202
+   important first): terminated, trying, proceeding, confirmed,
203
+   early. Note: I consider the "early" state more intersting than
204
+   confirmed as often you might want to pickup a call if the
205
+   originall callee is already busy in a call.
206
+
207
+   Default value is "0".
208
+
209
+   Example 1.1. Set parameter
210
+...
211
+modparam("presence_dialoginfo", "force_single_dialog", 1)
212
+...
213
+
214
+1.4. Exported Functions
215
+
216
+   None to be used in configuration file.