DIALOG module
Admin Guide
Section titled “Admin Guide”Overview
Section titled “Overview”The dialog module provides dialog awareness to the OpenSIPS proxy. Its functionality is to keep trace of the current dialogs, to offer information about them (like how many dialogs are active).
Aside tracking, the dialog module offers functionalities like flags and attributes per dialog (persistent data across dialog), dialog profiling and dialog termination (on timeout base or external triggered).
The module, via an internal API, also provide the foundation to build on top of it more complex dialog-based functionalities via other OpenSIPS modules.
How it works
Section titled “How it works”To create the dialog associated to an initial request, you must call the create_dialog() function, with or without parameter..
The dialog is automatically destroyed when a “BYE” is received. In case of no “BYE”, the dialog lifetime is controlled via the default timeout (see “default_timeout”
- default timeout id) and custom timeout (see “$DLG_timeout” - timeout pvar id).
Dialog profiling
Section titled “Dialog profiling”Dialog profiling is a mechanism that helps in classifying, sorting and keeping trace of certain types of dialogs, using whatever properties of the dialog (like caller, destination, type of calls, etc). Dialogs can be dynamically added in different (and several) profile tables - logically, each profile table can have a special meaning (like dialogs outside the domain, dialogs terminated to PSTN, etc).
There are two types of profiles:
- with no value - a dialog simply belongs to a profile. (like outbound calls profile). There is no other additional information to describe the dialog’s belonging to the profile;
- with value - a dialog belongs to a profile having a certain value (like in caller profile, where the value is the caller ID). The belonging of the dialog to the profile is strictly related to the value.
A dialog can be added to multiple profiles in the same time.
Profiles are visible (at the moment) in the request route (for initial and sequential requests) and in the branch, failure and reply routes of the original request.
Dialog profiles can also be used in distributed systems, using the OpenSIPS CacheDB Interface. This feature allows you to share dialog profile information with multiple OpenSIPS instaces that use the same CacheDB backend. In order to do that, the cachedb_url parameter must be defined. Also, the profile must be marked as shared, by adding the ‘/s’ suffix to the name of the profile in the profiles_with_value or profiles_no_value parameters.
Dialog replication
Section titled “Dialog replication”Dialog replication is a mechanism used to mirror all dialog changes taking place in one OpenSIPS instance to one or more other different instances. The logic is simplified by using the core Binary Internal Interface to build and send the replication-related UDP packets.
The feature is especially useful when dealing with very large systems, where failover through a database backend is no longer feasible, due to the high amount of time required for the backup instance to load the dialog information stored in a typical dialog table by the crashed instance.
Configuring both receival and sending of dialog replication packets is trivial and can be done by using the accept_replicated_dialogs and replicate_dialogs_to parameters of the module. In addition to this, the module also exports several statistics regarding the number of replication packets sent/received.
Dependencies
Section titled “Dependencies”OpenSIPS Modules
Section titled “OpenSIPS Modules”The following modules must be loaded before this module:
- TM - Transaction module
- RR - Record-Route module
External Libraries or Applications
Section titled “External Libraries or Applications”The following libraries or applications must be installed before running OpenSIPS with this module loaded:
- None.
Exported Parameters
Section titled “Exported Parameters”enable_stats (integer)
Section titled “enable_stats (integer)”If the statistics support should be enabled or not. Via statistic variables, the module provide information about the dialog processing. Set it to zero to disable or to non-zero to enable it.
Default value is “1 (enabled)“.
...modparam("dialog", "enable_stats", 0)...hash_size (integer)
Section titled “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 2 number.
Default value is “4096”.
...modparam("dialog", "hash_size", 1024)...log_profile_hash_size (integer)
Section titled “log_profile_hash_size (integer)”The size of the hash table internally used to store profile->dialog associations. A larger table can provide more parallel operations but consumes more memory. The hash size is provided as the base 2 logarithm(e.g. log_profile_hash_size =4 means the table has 2^4 entries).
Default value is “4”.
...modparam("dialog", "log_profile_hash_size", 5) #set a table size of 32...rr_param (string)
Section titled “rr_param (string)”Name of the Record-Route parameter to be added with the dialog cookie. It is used for fast dialog matching of the sequential requests.
Default value is “did”.
...modparam("dialog", "rr_param", "xyz")...default_timeout (integer)
Section titled “default_timeout (integer)”The default dialog timeout (in seconds) if no custom one is set.
Default value is “43200 (12 hours)“.
...modparam("dialog", "default_timeout", 21600)...dlg_extra_hdrs (string)
Section titled “dlg_extra_hdrs (string)”A string containing the extra headers (full format, with EOH) to be added in the requests generated by the module (like BYEs).
Default value is “NULL”.
...modparam("dialog", "dlg_extra_hdrs", "Hint: credit expired\r\n")...dlg_match_mode (integer)
Section titled “dlg_match_mode (integer)”How the seqential requests should be matched against the known dialogs. The modes are a combination between matching based on a cookie (DID) stored as cookie in Record-Route header and the matching based on SIP elements (as in RFC3261).
The supported modes are:
- 0 - DID_ONLY - the match is done exclusively based on DID;
- 1 - DID_FALLBACK - the match is first tried based on DID and if not present, it will fallback to SIP matching;
- 2 - DID_NONE - the match is done exclusively based on SIP elements; no DID information is added in RR.
Default value is “0 (DID_ONLY)“.
...modparam("dialog", "dlg_match_mode", 1)...db_url (string)
Section titled “db_url (string)”If you want to store the information about the dialogs in a database a database url must be specified.
Default value is “mysql://opensips:opensipsrw@localhost/opensips”.
...modparam("dialog", "db_url", "dbdriver://username:password@dbhost/dbname")...db_mode (integer)
Section titled “db_mode (integer)”Describe how to push into the DB the dialogs’ information from memory.
The supported modes are:
- 0 - NO_DB - the memory content is not flushed into DB;
- 1 - REALTIME - any dialog information changes will be reflected into the database immediately.
- 2 - DELAYED - the dialog information changes will be flushed into the DB periodically, based on a timer routine.
- 3 - SHUTDOWN - the dialog information will be flushed into DB only at shutdown - no runtime updates.
Default value is “0”.
...modparam("dialog", "db_mode", 1)...db_update_period (integer)
Section titled “db_update_period (integer)”The interval (seconds) at which to update dialogs’ information if you chose to store the dialogs’ info at a given interval. A too short interval will generate intensive database operations, a too large one will not notice short dialogs.
Default value is “60”.
...modparam("dialog", "db_update_period", 120)...ping_interval (integer)
Section titled “ping_interval (integer)”The interval (seconds) at which OpenSIPS will generate in-dialog pings for dialogs.
Default value is “30”.
...modparam("dialog", "ping_interval", 20)...table_name (string)
Section titled “table_name (string)”If you want to store the information about the dialogs in a database a table name must be specified.
Default value is “dialog”.
...modparam("dialog", "table_name", "my_dialog")...call_id_column (string)
Section titled “call_id_column (string)”The column’s name in the database to store the dialogs’ callid.
Default value is “callid”.
...modparam("dialog", "call_id_column", "callid_c_name")...from_uri_column (string)
Section titled “from_uri_column (string)”The column’s name in the database to store the caller’s sip address.
Default value is “from_uri”.
...modparam("dialog", "from_uri_column", "from_uri_c_name")...from_tag_column (string)
Section titled “from_tag_column (string)”The column’s name in the database to store the From tag from the Invite request.
Default value is “from_tag”.
...modparam("dialog", "from_tag_column", "from_tag_c_name")...to_uri_column (string)
Section titled “to_uri_column (string)”The column’s name in the database to store the calee’s sip address.
Default value is “to_uri”.
...modparam("dialog", "to_uri_column", "to_uri_c_name")...to_tag_column (string)
Section titled “to_tag_column (string)”The column’s name in the database to store the To tag from the 200 OK response to the Invite request, if present.
Default value is “to_tag”.
...modparam("dialog", "to_tag_column", "to_tag_c_name")...from_cseq_column (string)
Section titled “from_cseq_column (string)”The column’s name in the database to store the cseq from caller side.
Default value is “caller_cseq”.
...modparam("dialog", "from_cseq_column", "from_cseq_c_name")...to_cseq_column (string)
Section titled “to_cseq_column (string)”The column’s name in the database to store the cseq from callee side.
Default value is “callee_cseq”.
...modparam("dialog", "to_cseq_column", "to_cseq_c_name")...from_route_column (string)
Section titled “from_route_column (string)”The column’s name in the database to store the route records from caller side (proxy to caller).
Default value is “caller_route_set”.
...modparam("dialog", "from_route_column", "from_route_c_name")...to_route_column (string)
Section titled “to_route_column (string)”The column’s name in the database to store the route records from callee side (proxy to callee).
Default value is “callee_route_set”.
...modparam("dialog", "to_route_column", "to_route_c_name")...from_contact_column (string)
Section titled “from_contact_column (string)”The column’s name in the database to store the caller’s contact uri.
Default value is “caller_contact”.
...modparam("dialog", "from_contact_column", "from_contact_c_name")...to_contact_column (string)
Section titled “to_contact_column (string)”The column’s name in the database to store the callee’s contact uri.
Default value is “callee_contact”.
...modparam("dialog", "to_contact_column", "to_contact_c_name")...from_sock_column (string)
Section titled “from_sock_column (string)”The column’s name in the database to store the information about the local interface receiving the traffic from caller.
Default value is “caller_sock”.
...modparam("dialog", "from_sock_column", "from_sock_c_name")...to_sock_column (string)
Section titled “to_sock_column (string)”The column’s name in the database to store information about the local interface receiving the traffic from callee.
Default value is “callee_sock”.
...modparam("dialog", "to_sock_column", "to_sock_c_name")...dlg_id_column (string)
Section titled “dlg_id_column (string)”The column’s name in the database to store the dialogs’ id information.
Default value is “hash_id”.
...modparam("dialog", "dlg_id_column", "dlg_id_c_name")...state_column (string)
Section titled “state_column (string)”The column’s name in the database to store the dialogs’ state information.
Default value is “state”.
...modparam("dialog", "state_column", "state_c_name")...start_time_column (string)
Section titled “start_time_column (string)”The column’s name in the database to store the dialogs’ start time information.
Default value is “start_time”.
...modparam("dialog", "start_time_column", "start_time_c_name")...timeout_column (string)
Section titled “timeout_column (string)”The column’s name in the database to store the dialogs’ timeout.
Default value is “timeout”.
...modparam("dialog", "timeout_column", "timeout_c_name")...profiles_column (string)
Section titled “profiles_column (string)”The column’s name in the database to store the dialogs’ profiles.
Default value is “profiles”.
...modparam("dialog", "profiles_column", "profiles_c_name")...vars_column (string)
Section titled “vars_column (string)”The column’s name in the database to store the dialogs’ vars.
Default value is “vars”.
...modparam("dialog", "vars_column", "vars_c_name")...sflags_column (string)
Section titled “sflags_column (string)”The column’s name in the database to store the dialogs’ script flags.
Default value is “script_flags”.
...modparam("dialog", "sflags_column", "sflags_c_name")...mflags_column (string)
Section titled “mflags_column (string)”The column’s name in the database to store the dialogs’ module flags.
Default value is “module_flags”.
...modparam("dialog", "mflags_column", "mflags_c_name")...flags_column (string)
Section titled “flags_column (string)”The column’s name in the database to store the dialogs’ flags.
Default value is “flags”.
...modparam("dialog", "flags_column", "flags_c_name")...profiles_with_value (string)
Section titled “profiles_with_value (string)”List of names for profiles with values.
Default value is “empty”.
...modparam("dialog", "profiles_with_value", "caller ; my_profile; share/s")...profiles_no_value (string)
Section titled “profiles_no_value (string)”List of names for profiles without values.
Default value is “empty”.
...modparam("dialog", "profiles_no_value", "inbound ; outbound ; shared/s")...db_flush_vals_profiles (int)
Section titled “db_flush_vals_profiles (int)”Pushes dialog values, profiles and flags into the database along with other dialog state information (see db_mode 1 and 2).
Default value is “empty”.
...modparam("dialog", "db_flush_vals_profiles", 1)...timer_bulk_del_no (int)
Section titled “timer_bulk_del_no (int)”The number of dialogs that should be attempted to be deleted at the same time ( a single query ) from the DB back-end.
Default value is “1”.
...modparam("dialog", "timer_bulk_del_no", 10)...cachedb_url (string)
Section titled “cachedb_url (string)”Enables distributed dialog profiles and specifies the backend that should be used by the CacheDB interface.
Default value is “empty”.
...modparam("dialog", "cachedb_url", "redis://127.0.0.1:6379")...profile_value_prefix (string)
Section titled “profile_value_prefix (string)”Specifies what prefix should be added to the profiles with value when they are inserted into CacheDB backed. This is only used when distributed profiles are enabled.
Default value is “dlg_val_“.
...modparam("dialog", "profile_value_prefix", "dlgv_")...profile_no_value_prefix (string)
Section titled “profile_no_value_prefix (string)”Specifies what prefix should be added to the profiles without value when they are inserted into CacheDB backed. This is only used when distributed profiles are enabled.
Default value is “dlg_noval_“.
...modparam("dialog", "profile_no_value_prefix", "dlgnv_")...profile_size_prefix (string)
Section titled “profile_size_prefix (string)”Specifies what prefix should be added to the entity that holds the profiles with value size in CacheDB backed. This is only used when distributed profiles are enabled.
Default value is “dlg_size_“.
...modparam("dialog", "profile_size_prefix", "dlgs_")...profile_timeout (int)
Section titled “profile_timeout (int)”Specifies how long a dialog profile should be kept in the CacheDB until it expires. This is only used when distributed profiles are enabled.
Default value is “86400”.
...modparam("dialog", "profile_timeout", "43200")...accept_replicated_dialogs (int)
Section titled “accept_replicated_dialogs (int)”Registers the dialog module to the OpenSIPS Binary Internal Interface.
Default value is 0 (not registered).
...modparam("dialog", "accept_replicated_dialogs", 1)...replicate_dialogs_to (string)
Section titled “replicate_dialogs_to (string)”Adds a new dialog replication destination. The destination will receive all dialog-related events (creation, updating and deletion) over UDP, using the Binary Internal Interface.
Default value is “null” (no replication destinations).
...modparam("dialog", "replicate_dialogs_to", "10.0.0.150:5062")...Exported Functions
Section titled “Exported Functions”create_dialog()
Section titled “create_dialog()”The function creats the dialog for the currently processed request. The request must be an initial request.
Optionally,the function also receives a string parameter, which specifies whether the dialog end-points should be pinged via SIP options messages. The parameter can be “P” to specify to only ping the caller, “p” to only ping the callee or “Pp” to ping both dialog sides. If the extra string parameter is provided and one end-point fails to respond to a options ping, OpenSIPS will terminate the dialog from the middle.
The string parameter can also contain “B” to activate the bye on timeout behavior.
The function returns true if the dialog was successfully created or if the dialog was previously created.
This function can be used from REQUEST_ROUTE.
...create_dialog();...#ping callercreate_dialog("P");...#ping caller and calleecreate_dialog("Pp");
#bye on timeoutcreate_dialog("B");...match_dialog()
Section titled “match_dialog()”This function is to be used to match a sequential (in-dialog) request to an existing dialog. In other words, the function will try to match the current request to an known ongoing dialog.
The function tries to use (for dialog matching) the DID (Dialog ID) from Route header and also falls back to SIP-wise matching.
As sequential requests are automatically matched to the dialog when doing “loose_route()” from script, this function is intended to: (A) control the place in your script where the dialog matching is done and (B) to cope with bogus sequential requests that do not have Route headers, so they are not handled by loose_route().
The function returns true if a dialog exists for the request.
This function can be used from REQUEST_ROUTE.
... if (has_totag()) { loose_route(); if ($DLG_status==NULL && !match_dialog() ) { xlog(" cannot match request to a dialog \n"); } }...validate_dialog()
Section titled “validate_dialog()”The function checks the current received requests against the dialog (internal data) it belongs to. Performing several tests, the function will help to detect the bogus injected in-dialog requests (like malicious BYEs).
The performed tests are related to CSEQ sequence checking and routing information checking (contact and route set).
The function returns true if a dialog exists for the request and if the request is valid (according to dialog data). If the request is invalid, the following return codes are returned :
- -1 - invalid cseq
- -2 - invalid remote target
- -3 - invalid route set
- -4 - other errors ( parsing, no dlg, etc )
This function can be used from REQUEST_ROUTE.
... if (has_totag()) { loose_route(); if ($DLG_status!=NULL && !validate_dialog() ) { xlog(" in-dialog bogus request \n"); } else { xlog(" in-dialog valid request - $DLG_dir !\n"); } }...fix_route_dialog()
Section titled “fix_route_dialog()”The function forces an in dialog SIP message to contain the ruri, route headers and dst_uri, as specified by the internal data of the dialog it belongs to. The function will prevent the existence of bogus injected in-dialog requests ( like malicious BYEs )
This function can be used from REQUEST_ROUTE.
... if (has_totag()) { loose_route(); if ($DLG_status!=NULL) if (!validate_dialog()) fix_route_dialog(); }...get_dialog_info(attr,var,key,key_val)
Section titled “get_dialog_info(attr,var,key,key_val)”The function extracts a dialog value from another dialog. It first searches through all existing (ongoing) dialogs for a dialog that has a dialog variable named “key” with the value “key_val” (so a dialog where $dlg_val(key)==“key_val”). If found, it returns the value of the dialog variable “attr” from the found dialog in the “var” pseudo-variable, otherwise nothing is written in “var”, and a negative error code is returned.
Meaning of the parameters is as follows:
- attr - the name of the dialog variable (from the found dialog) to be returned;
- var - a pvar where to store the value of the “attr” dialog variable
- key - name of a dialog variable to be used a search key (when looking after the target dialog)
- key_val - the value of the dialog variable that is used as key in searching the target dialog.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE, FAILURE_ROUTE and LOCAL_ROUTE.
...if ( get_dialog_info("callee","$var(x)","caller","$fu") ) { xlog("caller $fU has another ongoing, talking to callee $var(x)\n")}
# create dialog for current call and place the caller and callee attributescreate_dialog();$dlg_val(caller) = $fu;$dlg_val(callee) = $ru;...set_dlg_profile(profile,[value])
Section titled “set_dlg_profile(profile,[value])”Inserts the current dialog into a profile. Note that if the profile does not support values, this will be silently discarded. A dialog may be inserted in the same profile multiple times.
Meaning of the parameters is as follows:
- profile - name of the profile to be added to;
- value (optional) - string value to define the belonging of the dialog to the profile - note that the profile must support values. Pseudo-variables are supported.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...set_dlg_profile("inbound_call");set_dlg_profile("caller","$fu");...unset_dlg_profile(profile,[value])
Section titled “unset_dlg_profile(profile,[value])”Removes the current dialog from a profile.
Meaning of the parameters is as follows:
- profile - name of the profile to be removed from;
- value (optional) - string value to define the belonging of the dialog to the profile - note that the profile must support values. Pseudo-variables are supported.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...unset_dlg_profile("inbound_call");unset_dlg_profile("caller","$fu");...is_in_profile(profile,[value])
Section titled “is_in_profile(profile,[value])”Checks if the current dialog belongs to a profile. If the profile supports values, the check can be reinforced to take into account a specific value - if the dialog was inserted into the profile for a specific value. If no value is passed, only simply belonging of the dialog to the profile is checked. Note that if the profile does not support values, this will be silently discarded.
Meaning of the parameters is as follows:
- profile - name of the profile to be checked against;
- value (optional) - string value to toughen the check. Pseudo-variables are supported.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...if (is_in_profile("inbound_call")) { log("this request belongs to a inbound call\n");}...if (is_in_profile("caller","XX")) { log("this request belongs to a call of user XX\n");}...get_profile_size(profile,[value],size)
Section titled “get_profile_size(profile,[value],size)”Returns the number of dialogs belonging to a profile. If the profile supports values, the check can be reinforced to take into account a specific value - how many dialogs were inserted into the profile with a specific value. If not value is passed, only simply belonging of the dialog to the profile is checked. Note that the profile does not supports values, this will be silently discarded.
Meaning of the parameters is as follows:
- profile - name of the profile to get the size for;
- value (optional) - string value to toughen the check. Pseudo-variables are supported;
- size - an AVP or script variable to return the profile size in.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
modparam("dialog", "profiles_no_value", "inboundCalls")modparam("dialog", "profiles_with_value", "caller")...get_profile_size("inboundCalls",,"$var(size)");xlog("inboundCalls: $var(size)\n");...get_profile_size("caller", "$fu", "$var(size)");xlog("currently, the user $fu has $var(size) active outgoing calls\n");...set_dlg_flag(idx)
Section titled “set_dlg_flag(idx)”Sets the dialog flag index idx to true. The dialog flags are dialog persistent and they can be accessed (set and test) for all requests belonging to the dialog.
The flag index can be between 0 and 31.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...set_dlg_flag("3");...test_and_set_dlg_flag(idx, value)
Section titled “test_and_set_dlg_flag(idx, value)”Atomically checks if the dialog flag index idx is equal to value. If true, changes the value with the opposite one. This operation is done under the dialog lock.
The flag index can be between 0 and 31.
The value should be 0 (false) or 1 (true).
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...test_and_set_dlg_flag("3", "0");...reset_dlg_flag(idx)
Section titled “reset_dlg_flag(idx)”Resets the dialog flag index idx to false. The dialog flags are dialog persistent and they can be accessed (set and test) for all requests belonging to the dialog.
The flag index can be between 0 and 31.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...reset_dlg_flag("16");...is_dlg_flag_set(idx)
Section titled “is_dlg_flag_set(idx)”Returns true if the dialog flag index idx is set. The dialog flags are dialog persistent and they can be accessed (set and test) for all requests belonging to the dialog.
The flag index can be between 0 and 31.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...if (is_dlg_flag_set("16")) { xlog("dialog flag 16 is set\n");}...store_dlg_value(name,val)
Section titled “store_dlg_value(name,val)”Attaches to the dialog the value val under the name name. The values attached to dialogs are dialog persistent and they can be accessed (read and write) for all requests belonging to the dialog.
Parameter val may contain pseudo-variables.
Same functionality may be obtain by assigning a value to pseudo variable $dlg_val(name).
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...store_dlg_value("inv_src_ip","$si");store_dlg_value("account type","prepaid");# or$dlg_val(account_type) = "prepaid";...fetch_dlg_value(name,pvar)
Section titled “fetch_dlg_value(name,pvar)”Fetches from the dialog the value of attribute named name. The values attached to dialogs are dialog persistent and they can be accessed (read and write) for all requests belonging to the dialog.
Parameter pvar may be a script var ($var) or and avp ($avp).
Same functionality may be obtain by reading the pseudo variable $dlg_val(name).
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
...fetch_dlg_value("inv_src_ip","$avp(2)");fetch_dlg_value("account type","$var(account)");# or$var(account) = $dlg_val(account_type);...Exported Statistics
Section titled “Exported Statistics”active_dialogs
Section titled “active_dialogs”Returns the number of current active dialogs (may be confirmed or not).
early_dialogs
Section titled “early_dialogs”Returns the number of early dialogs.
processed_dialogs
Section titled “processed_dialogs”Returns the total number of processed dialogs (terminated, expired or active) from the startup.
expired_dialogs
Section titled “expired_dialogs”Returns the total number of expired dialogs from the startup.
failed_dialogs
Section titled “failed_dialogs”Returns the number of failed dialogs ( dialogs were never established due to whatever reasons - internal error, negative reply, cancelled, etc )
create_sent
Section titled “create_sent”Returns the number of replicated dialog create requests send to other OpenSIPS instances.
update_sent
Section titled “update_sent”Returns the number of replicated dialog update requests send to other OpenSIPS instances.
delete_sent
Section titled “delete_sent”Returns the number of replicated dialog delete requests send to other OpenSIPS instances.
create_recv
Section titled “create_recv”Returns the number of dialog create events received from other OpenSIPS instances.
update_recv
Section titled “update_recv”Returns the number of dialog update events received from other OpenSIPS instances.
delete_recv
Section titled “delete_recv”Returns the number of dialog delete events received from other OpenSIPS instances.
Exported MI Functions
Section titled “Exported MI Functions”dlg_list
Section titled “dlg_list”Lists the description of the dialogs (calls). If no parameter is given, all dialogs will be listed. If a dialog identifier is passed as parameter (callid and fromtag), only that dialog will be listed. If a index and conter parameter is passed, it will list only a number of “counter” dialogs starting with index (as offset) - this is used to get only section of dialogs.
Name: dlg_list
Parameters (with dialog idetification):
- callid (optional) - callid if a single dialog to be listed.
- from_tag (optional, but cannot be present without the callid parameter) - fromtag (as per initial request) of the dialog to be listed. entry
Parameters (with dialog counting):
- index - offset where the dialog listing should start.
- counter - how many dialogs should be listed (starting from the offset)
MI FIFO Command Format:
:dlg_list:_reply_fifo_file__empty_line_:dlg_list:_reply_fifo_file_abcdrssfrs122444@192.168.1.1AAdfeEFF33:dlg_list:_reply_fifo_file_4010dlg_list_ctx
Section titled “dlg_list_ctx”The same as the “dlg_list” but including in the dialog description the associated context from modules sitting on top of the dialog module. This function also prints the dialog’s values. In case of binary values, the non-printable chars are represented in hex (e.g. \x00)
Name: dlg_list_ctx
Parameters: see “dlg_list”
MI FIFO Command Format:
:dlg_list_ctx:_reply_fifo_file__empty_line_dlg_end_dlg
Section titled “dlg_end_dlg”Terminates an ongoing dialog. If dialog is established, BYEs are sent in both directions. If dialog is in unconfirmed or early state, a CANCEL will be sent to the callee side, that will trigger a 487 from the callee, which, when relayed, will also end the dialog on the caller’s side.
Name: dlg_end_dlg
The accepted formats (as parameters) may be:
- dlg_end_dlg h_entry h_id [extra_hdrs]
- dlg_end_dlg dialog_id [extra_hdrs]
Where:
- h_entry - numerical hash entry of the dialog in the internal dialog table (provided by dlg_list)
- h_id - numerical hash id of the dialog on the hash entry (provided by dlg_list)
- dialog_id - numerical unique ID of the dialog (as provided by dlg_list)
- extra_hdrs - (optional) string containg the extra headers (full format) to be added to the BYE requests.
The values for the h_entry and h_id or dialog_id can be get via the “dlg_list” MI command.
MI FIFO Command Format:
:dlg_end_dlg:_reply_fifo_file_34256_empty_line_profile_get_size
Section titled “profile_get_size”Returns the number of dialogs belonging to a profile. If the profile supports values, the check can be reinforced to take into account a specific value - how many dialogs were inserted into the profile with a specific value. If not value is passed, only simply belonging of the dialog to the profile is checked. Note that the profile does not supports values, this will be silently discarded.
Name: profile_get_size
Parameters:
- profile - name of the profile to get the value for.
- value (optional)- string value to toughen the check;
MI FIFO Command Format:
:profile_get_size:_reply_fifo_file_inbound_calls_empty_line_profile_list_dlgs
Section titled “profile_list_dlgs”Lists all the dialogs belonging to a profile. If the profile supports values, the check can be reinforced to take into account a specific value - list only the dialogs that were inserted into the profile with that specific value. If not value is passed, all dialogs belonging to the profile will be listed. Note that the profile does not supports values, this will be silently discarded. Also, when using shared profiles using the CacheDB interface, this command will only display the local dialogs.
Name: profile_list_dlgs
Parameters:
- profile - name of the profile to list the dialog for.
- value (optional)- string value to toughen the check;
MI FIFO Command Format:
:profile_list_dlgs:_reply_fifo_file_inbound_calls_empty_line_profile_get_values
Section titled “profile_get_values”Lists all the values belonging to a profile along with their count. If the profile does not support values a total count will be returned. Note that this function does not work for shared profiles over the CacheDB interface.
Name: profile_get_values
Parameters:
- profile - name of the profile to list the dialog for.
MI FIFO Command Format:
:profile_get_values:_reply_fifo_file_inbound_calls_empty_line_dlg_db_sync
Section titled “dlg_db_sync”Will synchronize the information about the dialogs from the database with the OpenSIPS internal memory. To be used mainly for transferring OpenSIPS dialog information from one server to another.
Name: dlg_db_sync
It takes no parameters
MI FIFO Command Format:
:dlg_db_sync:_reply_fifo_file__empty_line_dlg_restore_db
Section titled “dlg_restore_db”Restores the dialog table after a potential desynchronization event. The table is truncated, then populated with CONFIRMED dialogs from memory.
Name: dlg_restore_db
It takes no parameters
MI FIFO Command Format:
:dlg_restore_db:_reply_fifo_file__empty_line_list_all_profiles
Section titled “list_all_profiles”Lists all the dialog profiles, along with 1 or 0 if the given profile has/does not have an associated value.
Name: list_all_profiles
Parameters: It takes no parameters
MI FIFO Command Format:
:list_all_profiles:_reply_fifo_file__empty_line_Exported Pseudo-Variables
Section titled “Exported Pseudo-Variables”$DLG_count
Section titled “$DLG_count”Returns the number of current active dialogs (may be confirmed or not).
$DLG_status
Section titled “$DLG_status”Returns the status of the dialog corresponding to the processed sequential request. This PV will be available only for sequential requests, after doing loose_route().
Value may be:
- NULL - Dialog not found.
- 1 - Dialog unconfirmed (created but no reply received at all)
- 2 - Dialog in early state (created provisional reply received, but no final reply received yet)
- 3 - Confirmed by a final reply but no ACK received yet.
- 4 - Confirmed by a final reply and ACK received.
- 5 - Dialog ended.
$DLG_lifetime
Section titled “$DLG_lifetime”Returns the duration (in seconds) of the dialog corresponding to the processed sequential request. The duration is calculated from the dialog confirmation and the current moment. This PV will be available only for sequential requests, after doing loose_route().
NULL will be returned if there is no dialog for the request.
$DLG_flags
Section titled “$DLG_flags”Returns the dialog flags array (as a single integer value) of the dialog corresponding to the processed sequential request. This PV will be available only for sequential requests, after doing loose_route().
NULL will be returned if there is no dialog for the request.
$DLG_dir
Section titled “$DLG_dir”Returns the direction of the request in dialog (as “UPSTREAM” or “DOWNSTREAM” string) - to be used for sequential request. This PV will be available only for sequential requests (on replies), after doing loose_route().
NULL will be returned if there is no dialog for the request.
$DLG_did
Section titled “$DLG_did”Returns the id of the dialog corresponding to the processed sequential request. The output format is entry ’:’ id (as returned by the dlg_list MI function). This PV will be available only for sequential requests, after doing loose_route().
NULL will be returned if there is no dialog for the request.
$DLG_end_reason
Section titled “$DLG_end_reason”Returns the reason for the dialog termination. It can be one of the following :
- Upstream BYE - Callee has sent a BYE
- Downstream BYE - Caller has sent a BYE
- Lifetime Timeout - Dialog lifetime expired
- MI Termination - Dialog ended via the MI interface
- Ping Timeout - Dialog ended because no reply to in-dialog pings
- RTPProxy Timeout - Media timeout signaled by RTPProxy
NULL will be returned if there is no dialog for the request, or if the dialog is not ended in the current context.
$DLG_timeout
Section titled “$DLG_timeout”Used to set the dialog lifetime (in seconds). When read, the variable returns the number of seconds until the dialog expires and is destroyed. Note that reading the variable is only possible after the dialog is created (for initial requests) or after doing loose_route() (for sequential requests). Important notice: using this variable with a REALTIME db_mode is very inefficient, because every time the dialog value is changed, a database update is done.
NULL will be returned if there is no dialog for the request, otherwise the number of seconds until the dialog expiration.
$dlg_val(name)
Section titled “$dlg_val(name)”This is a read/write variable that allows access to the dialog attribute named name. This PV will be available only for sequential requests, after doing loose_route().
NULL will be returned if there is no dialog for the request.
Exported Events
Section titled “Exported Events”E_DLG_STATE_CHANGED
Section titled “E_DLG_STATE_CHANGED”This event is raised when the dialog state is changed.
Parameters:
- ostate - the old state of the dialog.
- nstate - the new state of the dialog.
Developer Guide
Section titled “Developer Guide”Available Functions
Section titled “Available Functions”register_dlgcb (dialog, type, cb, param, free_param_cb)
Section titled “register_dlgcb (dialog, type, cb, param, free_param_cb)”Register a new callback to the dialog.
Meaning of the parameters is as follows:
- struct dlg_cell dlg* - dialog to register callback to. If maybe NULL only for DLG_CREATED callback type, which is not a per dialog type.
- int type - types of callbacks; more
types may be register for the same callback function; only
DLG_CREATED must be register alone. Possible types:
- DLGCB_LOADED
- DLGCB_SAVED
- DLG_CREATED - called when a new dialog is created - it’s a global type (not associated to any dialog)
- DLG_FAILED - called when the dialog was negatively replied (non-2xx) - it’s a per dialog type.
- DLG_CONFIRMED - called when the dialog is confirmed (2xx replied) - it’s a per dialog type.
- DLG_REQ_WITHIN - called when the dialog matches a sequential request - it’s a per dialog type.
- DLG_TERMINATED - called when the dialog is terminated via BYE - it’s a per dialog type.
- DLG_EXPIRED - called when the dialog expires without receiving a BYE - it’s a per dialog type.
- DLGCB_EARLY - called when the dialog is created in an early state (18x replied) - it’s a per dialog type.
- DLGCB_RESPONSE_FWDED - called when the dialog matches a reply to the initial INVITE request - it’s a per dialog type.
- DLGCB_RESPONSE_WITHIN - called when the dialog matches a reply to a subsequent in dialog request - it’s a per dialog type.
- DLGCB_MI_CONTEXT - called when the mi dlg_list_ctx command is invoked - it’s a per dialog type.
- DLGCB_DESTROY
- dialog_cb cb - callback function to be called. Prototype is: “void (dialog_cb) (struct dlg_cell* dlg, int type, struct dlg_cb_params * params); ”
- *void param - parameter to be passed to the callback function.
- param_free callback_param_free - callback function to be called to free the param. Prototype is: “void (param_free_cb) (void *param);“
Frequently Asked Questions
Section titled “Frequently Asked Questions”Q: What happened with “topology_hiding()” function?
The respective functionality was moved into the topology_hiding module. Function prototype has remained the same.
Q: What happened with “use_tight_match” parameter?
The parameter was removed with version 1.3 as the option of tight matching became mandatory and not configurable. Now, the tight matching is done all the time (when using DID matching).
Q: What happened with “bye_on_timeout_flag” parameter?
The parameter was removed in a dialog module parameter restructuring. To keep the bye on timeout behavior, you need to provide a “B” string parameter to the create_dialog() function.
Q: What happened with “dlg_flag” parameter?
The parameter is considered obsolete. The only way to create a dialog is to call the create_dialog() function
Q: Where can I find more about OpenSIPS?
Take a look at http://www.opensips.org/.
Q: Where can I post a question about this module?
First at all check if your question was already answered on one of our mailing lists:
E-mails regarding any stable OpenSIPS release should be sent to users@lists.opensips.org and e-mails regarding development versions should be sent to devel@lists.opensips.org.
If you want to keep the mail private, send it to users@lists.opensips.org.
Q: How can I report a bug?
Please follow the guidelines provided at: https://github.com/OpenSIPS/opensips/issues.
Contributors
Section titled “Contributors”By Commit Statistics
Section titled “By Commit Statistics”Top contributors by DevScore(1), authored commits(2) and lines added/removed(3)
| # | Name | DevScore | Commits | Lines++ | Lines— |
|---|---|---|---|---|---|
| 1. | Bogdan-Andrei Iancu (@bogdan-iancu) | 375 | 225 | 11669 | 3035 |
| 2. | Vlad Paiu (@vladpaiu) | 227 | 131 | 5305 | 3024 |
| 3. | Razvan Crainea (@razvancrainea) | 82 | 63 | 1386 | 394 |
| 4. | Liviu Chircu (@liviuchircu) | 45 | 25 | 1542 | 375 |
| 5. | Stefan Darius (@dariusstefan) | 38 | 5 | 2661 | 544 |
| 6. | Ovidiu Sas (@ovidiusas) | 29 | 20 | 576 | 203 |
| 7. | Dan Pascu (@danpascu) | 27 | 22 | 210 | 156 |
| 8. | Anca Vamanu | 17 | 7 | 755 | 122 |
| 9. | Daniel-Constantin Mierla (@miconda) | 16 | 13 | 76 | 66 |
| 10. | Henning Westerholt (@henningw) | 16 | 10 | 172 | 187 |
All remaining contributors: Andrei Dragus, Walter Doekes (@wdoekes), John Riordan, Ionut Ionita (@ionutrazvanionita), Carsten Bock, Hugues Mitonneau, Tavis Paquette, Jerome Martin, Klaus Darilion, Michel Bensoussan, Richard Revels, Elena-Ramona Modroiu, Andrei Datcu (@andrei-datcu), Jeffrey Magder, Ron Winacott, Andy Pyles, Julián Moreno Patiño, Konstantin Bokarius, Dusan Klinec (@ph4r05), Nick Altmann (@nikbyte), Damien Sandras (@dsandras), Alex Massover, Norman Brandinger (@NormB), UnixDev, Alex Hermann, Ryan Bullock (@rrb3942), Eliot Gable, Edson Gellert Schubert.
(1) DevScore = author_commits + author_lines_added / (project_lines_added / project_commits) + author_lines_deleted / (project_lines_deleted / project_commits)
(2) including any documentation-related commits, excluding merge commits
(3) ignoring whitespace edits, renamed files and auto-generated files
By Commit Activity
Section titled “By Commit Activity”| # | Name | Commit Activity |
|---|---|---|
| 1. | Stefan Darius (@dariusstefan) | Jun 2026 - Jul 2026 |
| 2. | Razvan Crainea (@razvancrainea) | Aug 2010 - Jun 2026 |
| 3. | Liviu Chircu (@liviuchircu) | Aug 2012 - Jan 2017 |
| 4. | Bogdan-Andrei Iancu (@bogdan-iancu) | Apr 2006 - Dec 2016 |
| 5. | Vlad Paiu (@vladpaiu) | Oct 2010 - May 2016 |
| 6. | Julián Moreno Patiño | Feb 2016 - Feb 2016 |
| 7. | Dusan Klinec (@ph4r05) | Dec 2015 - Dec 2015 |
| 8. | Ionut Ionita (@ionutrazvanionita) | Oct 2014 - Nov 2014 |
| 9. | Walter Doekes (@wdoekes) | Apr 2010 - Oct 2014 |
| 10. | Andrei Datcu (@andrei-datcu) | Jul 2014 - Jul 2014 |
All remaining contributors: Ovidiu Sas (@ovidiusas), Nick Altmann (@nikbyte), Norman Brandinger (@NormB), Damien Sandras (@dsandras), Ryan Bullock (@rrb3942), Anca Vamanu, Alex Massover, Andrei Dragus, John Riordan, Hugues Mitonneau, Richard Revels, UnixDev, Dan Pascu (@danpascu), Alex Hermann, Henning Westerholt (@henningw), Carsten Bock, Klaus Darilion, Daniel-Constantin Mierla (@miconda), Konstantin Bokarius, Edson Gellert Schubert, Jerome Martin, Tavis Paquette, Michel Bensoussan, Eliot Gable, Andy Pyles, Elena-Ramona Modroiu, Jeffrey Magder, Ron Winacott.
(1) including any documentation-related commits, excluding merge commits
Documentation
Section titled “Documentation”Contributors
Section titled “Contributors”Last edited by: Razvan Crainea (@razvancrainea), Liviu Chircu (@liviuchircu), Bogdan-Andrei Iancu (@bogdan-iancu), Julián Moreno Patiño, Vlad Paiu (@vladpaiu), Walter Doekes (@wdoekes), Ionut Ionita (@ionutrazvanionita), Norman Brandinger (@NormB), Anca Vamanu, Andrei Dragus, Hugues Mitonneau, Klaus Darilion, Henning Westerholt (@henningw), Ovidiu Sas (@ovidiusas), Daniel-Constantin Mierla (@miconda), Konstantin Bokarius, Edson Gellert Schubert, Dan Pascu (@danpascu), Michel Bensoussan, Andy Pyles, Elena-Ramona Modroiu.
License
Section titled “License”All documentation files (i.e. .md extension) are licensed under the Creative Common License 4.0