Home

presence_b2b

Keywords: 2.0.x | Module | presence_b2b

Standard

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 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 dialogi) to requested presentity. Every NOTIFY request produces new QSA message with status information into destination message queue.


1. Presence B2B UA

Vaclav Kubart

Iptel/Tekelec

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 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 dialogi) 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).

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

URIi 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 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/SERi/lib/seri/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;
 		};
		
		...
	}

	...
	
}
» login or register to post comments | printer friendly version
Home |  Recent changes |  Search |  Glossary |  Sitemap |  Login