Kamailio module dialog: Difference between revisions

From 탱이의 잡동사니
Jump to navigation Jump to search
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 ==

Revision as of 07:53, 28 July 2019

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.

See also