Module: sip-router Branch: master Commit: 2723ba88d9d061c9c33534983024bc0e6e3d2099 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=2723ba8… Author: oej &lt;oej(a)edvina.net&gt; Committer: oej &lt;oej(a)edvina.net&gt; Date: Thu Oct 22 21:11:09 2009 +0200 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. --- modules_s/presence_b2b/README | 32 +++++++++++++------------- modules_s/presence_b2b/doc/functions.xml | 2 +- modules_s/presence_b2b/doc/params.xml | 10 ++++++- modules_s/presence_b2b/doc/presence_b2b.xml | 26 +++++++++++++-------- version.h | 8 ++++++ 5 files changed, 49 insertions(+), 29 deletions(-) diff --git a/modules_s/presence_b2b/README b/modules_s/presence_b2b/README index 09781f1..3c8ba81 100644 --- a/modules_s/presence_b2b/README +++ b/modules_s/presence_b2b/README @@ -15,26 +15,26 @@ Vaclav Kubart future it will do subscriptions to reg events and presence with resource lists too. - It is accessible only using internal Querry Status API (QSA). - Everywhere (in C code) you need subscriptions to presentity status, you - only create an internal subscription to it and the rest is done by this - module. It processes 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. + 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) is created new SIP - subscription! 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 the 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). + 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 @@ -130,7 +130,7 @@ Vaclav Kubart handle_notify() Handles NOTIFY request. - The module tries to find subscription to which the NOTIFY + 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 diff --git a/modules_s/presence_b2b/doc/functions.xml b/modules_s/presence_b2b/doc/functions.xml index 7d91db8..a44b591 100644 --- a/modules_s/presence_b2b/doc/functions.xml +++ b/modules_s/presence_b2b/doc/functions.xml @@ -8,7 +8,7 @@ <term><varname>handle_notify()</varname></term> <listitem> <para>Handles NOTIFY request.</para> - <para>The module tries to find subscription to which the NOTIFY belongs + <para>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 diff --git a/modules_s/presence_b2b/doc/params.xml b/modules_s/presence_b2b/doc/params.xml index adfcc8e..7dacb70 100644 --- a/modules_s/presence_b2b/doc/params.xml +++ b/modules_s/presence_b2b/doc/params.xml @@ -1,6 +1,12 @@ <?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" - "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" +"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [ + +<!-- Include general documentation entities --> +<!ENTITY % docentities SYSTEM "../../../docbook/entities.xml"> +%docentities; + +]> <section id="presence_b2b.parameters"><title>Parameters</title> diff --git a/modules_s/presence_b2b/doc/presence_b2b.xml b/modules_s/presence_b2b/doc/presence_b2b.xml index 0399248..2ee4e0f 100644 --- a/modules_s/presence_b2b/doc/presence_b2b.xml +++ b/modules_s/presence_b2b/doc/presence_b2b.xml @@ -1,6 +1,12 @@ <?xml version='1.0' encoding='UTF-8'?> -<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" - "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" +"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [ + +<!-- Include general documentation entities --> +<!ENTITY % docentities SYSTEM "../../../docbook/entities.xml"> +%docentities; + +]> <section id="presence_b2b"><title>Presence B2B UA</title> @@ -17,12 +23,12 @@ future it will do subscriptions to reg events and presence with resource lists too.</para> -<para>It is accessible only using internal Querry Status API (QSA). Everywhere -(in C code) you need subscriptions to presentity status, you only create an internal -subscription to it and the rest is done by this module. It processes 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. +<para>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. </para> <para>Instead of this module can be used PA module with parameter @@ -30,11 +36,11 @@ information into destination message queue. subscription will be only to internal status hold by PA. </para> -<para>For every requested (record, subscriber) is created new SIP subscription! +<para>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 the subscriber. There is a possibility to do subscriptions with the same +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). </para> diff --git a/version.h b/version.h index 056e885..1c60539 100644 --- a/version.h +++ b/version.h @@ -23,6 +23,14 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +/*! + * \file + * \brief SIP-router core :: version and compile flag macros + * \ingroup core + * + * Module: \ref core + */ + #ifndef version_h #define version_h