Copyright © 2006-2009 voice-system.ro
| Revision History | |
|---|---|
| Revision $Revision: 6142 $ | $Date: 2009-09-16 19:33:54 +0200 (Wed, 16 Sep 2009) $ |
Table of Contents
enable_stats (integer)hash_size (integer)log_profile_hash_size (integer)rr_param (string)dlg_flag (integer)bye_on_timeout_flag (integer)timeout_avp (string)default_timeout (integer)dlg_extra_hdrs (string)dlg_match_mode (integer)db_url (string)db_mode (integer)db_update_period (integer)table_name (string)callid_column (string)from_uri_column (string)from_tag_column (string)to_uri_column (string)to_tag_column (string)caller_cseq_column (string)callee_cseq_column (string)caller_route_column (string)callee_route_column (string)caller_contact_column (string)callee_contact_column (string)caller_sock_column (string)callee_sock_column (string)h_id_column (string)h_entry_column (string)state_column (string)start_time_column (string)timeout_column (string)profiles_with_value (string)profiles_no_value (string)create_dialog()
validate_dialog()
fix_route_dialog()
get_dialog_info(attr,var,key,key_val)
set_dlg_profile(profile,[value])
unset_dlg_profile(profile,[value])
is_in_profile(profile,[value])
get_profile_size(profile,[value],size)
set_dlg_flag(idx)
test_and_set_dlg_flag(idx, value)
reset_dlg_flag(idx)
is_dlg_flag_set(idx)
store_dlg_value(name,val)
fetch_dlg_value(name,pvar)
List of Examples
enable_stats parameterhash_size parameterhash_size parameterrr_param parameterdlg_flag parameterbye_on_timeout_flag parametertimeout_avp parameterdefault_timeout parameterdlf_extra_hdrs parameterdlg_match_mode parameterdb_url parameterdb_mode parameterdb_update_period parametertable_name parametercallid_column parameterfrom_uri_column parameterfrom_tag_column parameterto_uri_column parameterto_tag_column parametercaller_cseq_column parametercallee_cseq_column parametercaller_route_column parameterto_route_column parametercaller_contact_column parametercallee_contact_column parametercaller_sock_column parametercallee_sock_column parameterh_id_column parameterh_entry_column parameterstate_column parameterstart_time_column parametertimeout_column parameterprofiles_with_value parameterprofiles_no_value parametercreate_dialog() usagevalidate_dialog() usagefix_route_dialog() usageget_dialog_info usageset_dlg_profile usageunset_dlg_profile usageis_in_profile usageget_profile_size usageset_dlg_flag usagetest_and_set_dlg_flag usagereset_dlg_flag usageis_dlg_flag_set usagestore_dlg_value usagefetch_dlg_value usageThe 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.
To create the dialog associated to an initial request, the flag
“dlg_flag” (Section 1.5.5, “dlg_flag (integer)”) must be set 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 (see “default_timeout”
- Section 1.5.8, “default_timeout (integer)”) and custom timeout (see
“timeout_avp” - Section 1.5.7, “timeout_avp (string)”). The
dialog timeout is reset each time a sequential (except ACKs) request
passes.
The module is able to cut/terminate the call from the middle (proxy side)
when the dialog gives timeout. By setting the
“bye_on_timeout_flag” -
Section 1.5.6, “bye_on_timeout_flag (integer)” on dialog creation, BYEs will be
automatically sent (in both directions) when the timeout event occurs.
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.
The following modules must be loaded before this module:
TM - Transaction module
RR - Record-Route module
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)”.
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.
IMPORTANT: If dialogs' information should be stored in a database, a constant hash_size should be used, otherwise the restored process will not take place. If you really want to modify the hash_size you must delete all table's rows before restarting OpenSIPS.
Default value is “4096”.
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”.
Example 1.3. Set hash_size parameter
...
modparam("dialog", "log_profile_hash_size", 5) #set a table size of 32
...
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”.
Flag to be used for marking if a dialog should be constructed for the current request (make sense only for initial requests).
Default value is “none”.
Message falg to be set if you want the dialog module to automatically send BYE requests (in both directions) when the dialog give timeout.
The flag must be set for the initial INVITE and before creating the dialog (before doing t_relay() or t_newtran()). You cannot change this option (of sending the BYEs at timeout event) during the dialog.
Default value is “none”.
The specification of an AVP to contain a custom timeout (in seconds) for the dialog. It may be used only in a request (initial or sequential) context
Default value is “none”.
The default dialog timeout (in seconds) if no custom one is set.
Default value is “43200 (12 hours)”.
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”.
Example 1.9. Set dlf_extra_hdrs parameter
...
modparam("dialog", "dlg_extra_hdrs", "Hint: credit expired\r\n")
...
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)”.
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”.
Example 1.11. Set db_url parameter
...
modparam("dialog", "db_url", "dbdriver://username:password@dbhost/dbname")
...
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 immediatly.
2 - DELAYED - the dialog information changes will be flushed into DB periodically, based on a timre routine.
3 - SHUTDOWN - the dialog information will be flushed into DB only at shutdown - no runtime updates.
Default value is “0”.
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 intensiv database operations, a too large one will not notice short dialogs.
Default value is “60”.
If you want to store the information about the dialogs in a database a table name must be specified.
Default value is “dialog”.
The column's name in the database to store the dialogs' callid.
Default value is “callid”.
Example 1.15. Set callid_column parameter
...
modparam("dialog", "callid_column", "callid_c_name")
...
The column's name in the database to store the caller's sip address.
Default value is “from_uri”.
Example 1.16. Set from_uri_column parameter
...
modparam("dialog", "from_uri_column", "from_uri_c_name")
...
The column's name in the database to store the From tag from the Invite request.
Default value is “from_tag”.
Example 1.17. Set from_tag_column parameter
...
modparam("dialog", "from_tag_column", "from_tag_c_name")
...
The column's name in the database to store the calee's sip address.
Default value is “to_uri”.
Example 1.18. Set to_uri_column parameter
...
modparam("dialog", "to_uri_column", "to_uri_c_name")
...
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”.
Example 1.19. Set to_tag_column parameter
...
modparam("dialog", "to_tag_column", "to_tag_c_name")
...
The column's name in the database to store the cseq from caller side.
Default value is “caller_cseq”.
Example 1.20. Set caller_cseq_column parameter
...
modparam("dialog", "caller_cseq_column", "column_name")
...
The column's name in the database to store the cseq from callee side.
Default value is “callee_cseq”.
Example 1.21. Set callee_cseq_column parameter
...
modparam("dialog", "callee_cseq_column", "column_name")
...
The column's name in the database to store the route records from caller side (proxy to caller).
Default value is “caller_route_set”.
Example 1.22. Set caller_route_column parameter
...
modparam("dialog", "caller_route_column", "column_name")
...
The column's name in the database to store the route records from callee side (proxy to callee).
Default value is “callee_route_set”.
Example 1.23. Set to_route_column parameter
...
modparam("dialog", "to_route_column", "column_name")
...
The column's name in the database to store the caller's contact uri.
Default value is “from_contact”.
Example 1.24. Set caller_contact_column parameter
...
modparam("dialog", "caller_contact_column", "column_name")
...
The column's name in the database to store the callee's contact uri.
Default value is “callee_contact”.
Example 1.25. Set callee_contact_column parameter
...
modparam("dialog", "callee_contact_column", "column_name")
...
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”.
Example 1.26. Set caller_sock_column parameter
...
modparam("dialog", "caller_sock_column", "column_name")
...
The column's name in the database to store information about the local interface receiving the traffic from callee.
Default value is “callee_contact”.
Example 1.27. Set callee_sock_column parameter
...
modparam("dialog", "callee_sock_column", "column_name")
...
The column's name in the database to store the dialogs' hash id information.
Default value is “hash_id”.
The column's name in the database to store the dialogs' hash entry information.
Default value is “hash_entry”.
Example 1.29. Set h_entry_column parameter
...
modparam("dialog", "h_entry_column", "h_entry_c_name")
...
The column's name in the database to store the dialogs' state information.
Default value is “state”.
The column's name in the database to store the dialogs' start time information.
Default value is “start_time”.
Example 1.31. Set start_time_column parameter
...
modparam("dialog", "start_time_column", "start_time_c_name")
...
The column's name in the database to store the dialogs' timeout.
Default value is “timeout”.
Example 1.32. Set timeout_column parameter
...
modparam("dialog", "timeout_column", "timeout_c_name")
...
The function creats the dialog for the currently processed request. The request must be an initial request.
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.
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 sequance 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).
This function can be used from REQUEST_ROUTE.
Example 1.36. validate_dialog() usage
...
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");
}
}
...
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.
Example 1.37. fix_route_dialog() usage
...
if (has_totag()) {
loose_route();
if ($DLG_status!=NULL)
if (!validate_dialog())
fix_route_dialog();
}
...
The function extracts a dialog value from another dialog - it search 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") - once found, it return in pvar "var" the value of the the dialog variable "attr" from the found dialog.
NOTE: the function does not require to be called in the context of a dialog - you can use it whenever / whereever for searching for other dialogs.
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.
Example 1.38. get_dialog_info usage
...
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 attributes
create_dialog();
$dlg_val(caller) = $fu;
$dlg_val(callee) = $ru;
...
Inserts the current dialog into a profile. Note that the profile does not supports values, this will be silently discarded. Also, there is no check for inserting the same dialog in the same profile for multiple times.
NOTE: the dialog must be created before using this function (use create_dialog() function before).
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.
Example 1.39. set_dlg_profile usage
...
set_dlg_profile("inbound_call");
set_dlg_profile("caller","$fu");
...
Removes the current dialog from a profile.
NOTE: the dialog must be created before using this function (use create_dialog() function before).
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 BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
Example 1.40. unset_dlg_profile usage
...
unset_dlg_profile("inbound_call");
unset_dlg_profile("caller","$fu");
...
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 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.
NOTE: the dialog must be created before using this function (use create_dialog() function before).
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.
Example 1.41. is_in_profile usage
...
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");
}
...
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.
Example 1.42. get_profile_size usage
...
get_profile_size("inbound_call","$avp(size)");
xlog("currently there are $avp(size) inbound calls\n");
...
get_profile_size("caller","$fu");
xlog("currently, the user %fu has $avp(size) active outgoing calls\n");
...
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.
NOTE: the dialog must be created before using this function (use create_dialog() function before).
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
Atomically checks if the dialog flag index idx is equal to value. If true, changes the value with the oppsosite 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).
NOTE: the dialog must be created before using this function (use create_dialog() function before).
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
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.
NOTE: the dialog must be created before using this function (use create_dialog() function before).
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
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.
NOTE: the dialog must be created before using this function (use create_dialog() function before).
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE and FAILURE_ROUTE.
Example 1.46. is_dlg_flag_set usage
...
if (is_dlg_flag_set("16")) {
xlog("dialog flag 16 is set\n");
}
...
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.
NOTE: the dialog must be created before using this function (use create_dialog() function before).
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.
Example 1.47. store_dlg_value usage
...
store_dlg_value("inv_src_ip","$si");
store_dlg_value("account type","prepaid");
# or
$dlg_val("account_type") = "prepaid";
...
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).
NOTE: the dialog must be created before using this function (use create_dialog() function before).
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.
Example 1.48. fetch_dlg_value usage
...
fetch_dlg_value("inv_src_ip","$avp(i:2)");
fetch_dlg_value("account type","$var(account)");
# or
$var(account) = $dlg_val("account_type");
...
Returns the total number of processed dialogs (terminated, expired or active) from the startup.
Lists the description of the dialogs (calls). If no paramter is given, all dialogs will be listed. If a dialog identifier is passed as paramter (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 paramter) - 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.1 AAdfeEFF33
:dlg_list:_reply_fifo_file_ 40 10
The same as the “dlg_list” but including in the dialog description the associated context from modules sitting on top of the dialog module.
Name: dlg_list_ctx
Parameters: see “dlg_list”
MI FIFO Command Format:
:dlg_list_ctx:_reply_fifo_file_ _empty_line_
Terminates an ongoing dialog by sending BYE in both directions.
Name: dlg_end_dlg
Parameters:
h_entry - hash entry of the dialog in the internal dialog table
h_id - hash id of the dialog on the hash entry
extra_hdrs - (optional) string containg extra headers (full format) to be added to the BYE requests.
The values for the h_entry and h_id can be get via the dlg_list MI command.
MI FIFO Command Format:
:dlg_end_dlg:_reply_fifo_file_ 342 56 _empty_line_
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_
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.
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_
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.
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_
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.
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.
Returns the dialog flags array (as a single interger 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.
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.
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);”
3.1. | What happend 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). | |
3.2. | Where can I find more about OpenSIPS? |
Take a look at http://www.opensips.org/. | |
3.3. | 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
If you want to keep the mail private, send it to
| |
3.4. | How can I report a bug? |
Please follow the guidelines provided at: https://github.com/OpenSIPS/opensips/issues. |