Kamailio module dialog
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.
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.
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.
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"
modparam("dialog", "hash_size", 4096)
Functions
set_dlg_profile(profile,[value])
Inserts the current dialog into a profile. Note that if the profile does not support values, they will be silently discarded. Also there is no check for inserting the same profile multiple times.
This function can be used from RQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
Parameters
- profile: name of the profile to be added to.
- value (optional): string value to define the membership of the dialog in the profile. Note that the profile must support values. Pseudo-variable are supported.
set_dlg_profile("inbound_call");
set_dlg_profile("caller","$fu");
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().