Kamailio module dialog - Revision history

Pchero: /* Functions */

2019-07-29T20:16:37Z

Functions

← Older revision		Revision as of 20:16, 29 July 2019
Line 60:		Line 60:
	set_dlg_profile("caller","$fu");		set_dlg_profile("caller","$fu");
	</pre>		</pre>

			== Exported Variables ==
			=== $dlg_var(key) ===
			This is a read/write variable that can be used to store custom values assigned with a dialog (e.g. the URI of a billing-server, an assigned emergency-server). This pseudo-variable will be available only for subsequential requests after doing loose_route().

	== See also ==		== See also ==

Pchero: /* Parameters */

2019-07-28T08:06:10Z

Parameters

@@ Line 45: / Line 45: @@
 <pre>
 modparam("dialog", "hash_size", 4096)
 </pre>

Pchero: /* Dialog profiling */

2019-07-28T07:59:40Z

Dialog profiling

← Older revision		Revision as of 07:59, 28 July 2019
Line 35:		Line 35:

	Profiles are visible (at the moment) in the request route (for initial and sequential rquests) and in the branch, failure and reply routes of the original request.		Profiles are visible (at the moment) in the request route (for initial and sequential rquests) and in the branch, failure and reply routes of the original request.

			== Parameters ==
			=== hash_size(integer) ===
			The size of the hash table internally used to keep the dialogs. A larger table is much faster but consumes more memory. The hash size must be a power of two.

			If dialog information should be stored in a database, a constant hash_size should be used, otherwise the restoring process will not take place. If you really want to modify the hash_size, you must delete all table's rows before restarting the server.

			Default value is "4096"
			<pre>
			modparam("dialog", "hash_size", 4096)
			</pre>

	== See also ==		== See also ==

Pchero: /* How it works */

2019-07-28T07:53:30Z

How it works

← Older revision		Revision as of 07:53, 28 July 2019
Line 15:		Line 15:

	The dialog is automatically destroyed when a "BYE" is received. In case of no "BYE", the dialog lifetime is controlled via the default timeout and custom timeout. The dialog timeout is reset each time a sequential request is processed.		The dialog is automatically destroyed when a "BYE" is received. In case of no "BYE", the dialog lifetime is controlled via the default timeout and custom timeout. The dialog timeout is reset each time a sequential request is processed.

			== Dialog states ==
			Dialogs have states that are shown in the RPC interface as well as stored in the database.
			* 1: Unconfirmed dialog.
			* 2: Early dialog(ringing)
			* 3: Confirmed dialog(waiting for ACK)
			* 4: Confirmed dialog(active call)
			* 5: Deleted dialog
			The early and deleted dialog states are not updated in database storage.

			== Dialog profiling ==
			Dialog profiling is a mechanism that helps in classifying, sorting and keeping track of cerain types of dialogs. The classification criteria can be any attributes desired by the administrator; it can be SIP message attributes, other pseudo-variables, custom values, etc. Dialogs can be dynamically added into one or more profile tables. Logically, each profile table can have a special meaning (like dialogs outside the domain, dialogs terminated to the PSTN etc.).

			There are two types of profiles:
			* with no value: a dialog simply belongs to a profile(for instance, an outbound calls profile). There is no other additional information to describe the dialog beyond its membership in the profile per se.
			* with value: a dialog belongs to a profile a certain value (like in a caller profile, where the value is the caller ID). The membership of the dialog in the profile is strictly related to the value. For example, if the account ID of the caller is stored in the pseudo-variable $var(account_id), you can use $var(account_id) as a value/key by which to group dialogs so that you can count the number of open dialogs for each account, enforce concurrent call limits as necessary, etc.

			A dialog can be added to multiple profiles at the same time.

			Profiles are visible (at the moment) in the request route (for initial and sequential rquests) and in the branch, failure and reply routes of the original request.

	== See also ==		== See also ==

Pchero: /* Basic */

2019-07-28T07:44:10Z

Basic

← Older revision		Revision as of 07:44, 28 July 2019
Line 11:		Line 11:
	This module also provides a API foundation on which to build more complex dialog-oriented functionality in other Kamailio modules.		This module also provides a API foundation on which to build more complex dialog-oriented functionality in other Kamailio modules.

			== How it works ==
			To create the dialog associated with an initial INVITE request, execute the function "dlg_manage()" or set the flag specified by parameter "dlg_flag" before creating the corresponding transaction.

			The dialog is automatically destroyed when a "BYE" is received. In case of no "BYE", the dialog lifetime is controlled via the default timeout and custom timeout. The dialog timeout is reset each time a sequential request is processed.

	== See also ==		== See also ==

Pchero: Created page with "== Overview == Kamailio dialog 모듈 내용 정리. == Basic == Kamailio can behave as a stateful proxy through the TM module. However, "stateful" in this context refers to..."

2019-07-28T07:41:54Z

Created page with "== Overview == Kamailio dialog 모듈 내용 정리. == Basic == Kamailio can behave as a stateful proxy through the TM module. However, "stateful" in this context refers to..."

New page

== Overview ==
Kamailio dialog 모듈 내용 정리.

== Basic ==
Kamailio can behave as a stateful proxy through the TM module. However, "stateful" in this context refers to transaction state, not dialog state. Certain applications may benefit from an awareness of "calls" in the proxy, not just SIP transactions.

For example, a common need is to limit the number of calls that can be made concurrently by an endpoint, account, user group, etc. In order to count the number of calls in progress, it is necessary for the proxy to be aware of whole dialogs, not just transactions, and to provide some means of programmatically classifying these dialogs. This is just one common application discussed for illustrative purposes; there are many others.

The dialog module provides dialog awareness for the kamailio proxy. It's functionality is to keep track of the current dialogs, to offer information about them (e.g. how many dialogs are active), and to manage various characteristics of dialogs. The module exports several functions that can be used directly from the configuration route script as well as functions for the RPC interface.

This module also provides a API foundation on which to build more complex dialog-oriented functionality in other Kamailio modules.

== See also ==
* https://kamailio.org/docs/modules/5.3.x/modules/dialog.html

[[category:kamailio]]