mirror of https://github.com/sipwise/kamailio.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
180 lines
5.8 KiB
180 lines
5.8 KiB
1. Presence B2B UA
|
|
|
|
Vaclav Kubart
|
|
|
|
Iptel/Tekelec
|
|
<vaclav.kubart@iptel.org>
|
|
__________________________________________________________________
|
|
|
|
1.1. Dependencies
|
|
1.2. Usage
|
|
1.3. Parameters
|
|
1.4. Functions
|
|
|
|
This module acts as back to back user agent for presence events. In the
|
|
future it will do subscriptions to reg events and presence with
|
|
resource lists too.
|
|
|
|
It is accessible only using the internal Query Status API (QSA).
|
|
Everywhere (in the C code) where you need subscriptions to presentity
|
|
status, you only create an internal subscription to it and the rest is
|
|
done by this module. It processes the internal subscription and creates
|
|
a SIP subscription (SUBSCRIBE-NOTIFY dialog) to requested presentity.
|
|
Every NOTIFY request produces new QSA message with status information
|
|
into destination message queue.
|
|
|
|
Instead of this module can be used PA module with parameter
|
|
accept_internal_subscriptions set to 1. In that case the subscription
|
|
will be only to internal status hold by PA.
|
|
|
|
For every requested (record, subscriber) a new SIP subscription is
|
|
created. This is due to authorization of such subscriptions - B2B UA
|
|
can't decide about authorization rules, thus it has to leave it on the
|
|
presence server to which it creates the subscription and this means,
|
|
that it has to create the subscription as a subscriber. There is a
|
|
possibility to do subscriptions with the same To + From only once, but
|
|
this is left for future optimalizations (it will probably not help a
|
|
lot).
|
|
|
|
1.1. Dependencies
|
|
|
|
Modules
|
|
* tm
|
|
* dialog
|
|
|
|
Libraries
|
|
* libcds (internal)
|
|
* libpresence (internal)
|
|
|
|
1.2. Usage
|
|
|
|
This module can be used by RLS module (e.g. RLS module does internal
|
|
subscriptions to "presence" which can be handled by this module or PA
|
|
module).
|
|
|
|
In near future it will be used by PA module for subscribing to users;
|
|
this could be useful with UACs capable to process SUBSCRIBE/NOTIFY but
|
|
not using PUBLISH for presence state publication (like Windows
|
|
Messenger).
|
|
|
|
1.3. Parameters
|
|
|
|
default_expiration (integer)
|
|
Default subscription expiration timeout in seconds.
|
|
|
|
Default value is 3600.
|
|
|
|
on_error_retry_time (integer)
|
|
Time in seconds to next attempt at subscription creation after
|
|
receiving an error from peer (for example 404 response on
|
|
SUBSCRIBE request).
|
|
|
|
Default value is 120.
|
|
|
|
presence_route (string)
|
|
Route header put into first generated SUBSCRIBE request.
|
|
|
|
Default value: empty.
|
|
|
|
additional_presence_headers (string)
|
|
Additional headers put into sent SUBSCRIBE requests.
|
|
|
|
Default value: empty.
|
|
|
|
wait_for_term_notify (integer)
|
|
Default timeout for receiving terminating NOTIFY after
|
|
unsubscribe (SUBSCRIBE with Expires: 0). If no NOTIFY is
|
|
received during this time, the subscription is destroyed without
|
|
processing last notify.
|
|
|
|
Default value is 30.
|
|
|
|
resubscribe_delta (integer)
|
|
Number of seconds before subscription expiration when should be
|
|
sent resubscription request. For example if this value is 60 and
|
|
the subscription is for 3600 seconds (Expires in 2xx response),
|
|
next SUBSCRIBE request will be sent after 3540 seconds.
|
|
|
|
Default value is 30.
|
|
|
|
min_resubscribe_time (integer)
|
|
Minimum number of seconds between consequent SUBSCRIBE requests.
|
|
(Renewal SUBSCRIBE is sent at least after this number of
|
|
seconds.)
|
|
|
|
Default value is 30.
|
|
|
|
handle_presence_subscriptions (integer)
|
|
If set to nonzero value the module will handle internal (QSA)
|
|
subscriptions to presence events. If not set, these internal
|
|
subscriptions are ignored.
|
|
|
|
Default value is 1.
|
|
|
|
presence_outbound_proxy
|
|
URI where to send all presence SUBSCRIBEs. It is better to use
|
|
this than presence_route.
|
|
|
|
Empty by default.
|
|
|
|
max_subscribe_delay
|
|
If set to value greater than zero SUBSCRIBE requests are sent
|
|
randomly at most after max_subscribe_delay seconds. SUBSCRIBE
|
|
requests are sent immediately when processing internal (QSA)
|
|
subscription when set to 0.
|
|
|
|
Default value is 0.
|
|
|
|
1.4. Functions
|
|
|
|
handle_notify()
|
|
Handles NOTIFY request.
|
|
|
|
The module tries to find the subscription to which the NOTIFY
|
|
belongs to (it tries both - confirmed and unconfirmed
|
|
subscriptions because NOTIFY may arrive before 2xx response on
|
|
SUBSCRIBE request). If no such subscription exists, the function
|
|
returns -1, otherwise it processes the request (generates
|
|
internal notification, ...) and returns 1.
|
|
|
|
Example 1. Configuration example
|
|
...
|
|
loadmodule "/home/kubartv/SER/lib/ser/modules/tm.so"
|
|
loadmodule "/home/kubartv/SER/lib/ser/modules/dialog.so"
|
|
loadmodule "/home/kubartv/SER/lib/ser/modules/presence_b2b.so"
|
|
|
|
...
|
|
modparam("presence_b2b", "presence_route", "<sip:my-sip-server.domain.com;lr>")
|
|
modparam("presence_b2b", "on_error_retry_time", 600)
|
|
modparam("presence_b2b", "wait_for_term_notify", 33)
|
|
modparam("presence_b2b", "resubscribe_delta", 15)
|
|
modparam("presence_b2b", "min_resubscribe_time", 55)
|
|
modparam("presence_b2b", "default_expiration", 667)
|
|
...
|
|
|
|
route {
|
|
|
|
...
|
|
|
|
if (uri==myself) {
|
|
|
|
...
|
|
|
|
if (method=="NOTIFY") {
|
|
if (!t_newtran()) {
|
|
log(1, "newtran error\n");
|
|
sl_reply_error();
|
|
};
|
|
if (!handle_notify()) {
|
|
t_reply("481", "Unable to handle notification");
|
|
}
|
|
break;
|
|
};
|
|
|
|
...
|
|
}
|
|
|
|
...
|
|
|
|
}
|