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.
1.2. 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”
- Section 1.5.6, “default_timeout (integer)”) and custom timeout (see
“timeout_avp” - Section 1.5.5, “timeout_avp (string)”). The
dialog timeout is reset each time a sequential (except ACKs) request
passes.
1.3. 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.
1.4. Dependencies
1.4.1. OpenSIPS Modules
The following modules must be loaded before this module:
TM - Transaction module
RR - Record-Route module
1.4.2. External Libraries or Applications
The following libraries or applications must be installed before
running OpenSIPS with this module loaded:
None.
1.5. Exported Parameters
1.5.1. 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)”.
Example 1.1. Set enable_stats parameter
...
modparam("dialog", "enable_stats", 0)
...
1.5.2. 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.
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”.
Example 1.2. Set hash_size parameter
...
modparam("dialog", "hash_size", 1024)
...
1.5.3. 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”.
Example 1.3. Set hash_size parameter
...
modparam("dialog", "log_profile_hash_size", 5) #set a table size of 32
...
1.5.4. 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”.
Example 1.4. Set rr_param parameter
...
modparam("dialog", "rr_param", "xyz")
...
1.5.5. timeout_avp (string)
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.
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)”.
Example 1.8. Set dlg_match_mode parameter
...
modparam("dialog", "dlg_match_mode", 1)
...
1.5.9. 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”.
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”.
Example 1.10. Set db_mode parameter
...
modparam("dialog", "db_mode", 1)
...
1.5.11. 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 intensiv database operations, a too large one will not notice short dialogs.
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.
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_”.
Example 1.41. Set profile_no_value_prefix parameter
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.
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.
Example 1.44. create_dialog() usage
...
create_dialog();
...
#ping caller
create_dialog("P");
...
#ping caller and callee
create_dialog("Pp");
#bye on timeout
create_dialog("B");
...
1.6.2.
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.
Example 1.45. match_dialog() usage
...
if (has_totag()) {
loose_route();
if ($DLG_status==NULL && !match_dialog() ) {
xlog(" cannot match request to a dialog \n");
}
}
...
1.6.3.
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 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). If the request is invalid,
the following return codes are returned :
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.47. fix_route_dialog() usage
...
if (has_totag()) {
loose_route();
if ($DLG_status!=NULL)
if (!validate_dialog())
fix_route_dialog();
}
...
1.6.5.
get_dialog_info(attr,var,key,key_val)
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.48. 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;
...
1.6.6.
set_dlg_profile(profile,[value])
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.
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.
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.51. 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");
}
...
1.6.9.
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.
Example 1.52. 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");
...
1.6.10.
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.
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.53. set_dlg_flag usage
...
set_dlg_flag("3");
...
1.6.11.
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
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.
Example 1.54. test_and_set_dlg_flag usage
...
test_and_set_dlg_flag("3", "0");
...
1.6.12.
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.
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.55. reset_dlg_flag usage
...
reset_dlg_flag("16");
...
1.6.13.
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.
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.56. is_dlg_flag_set usage
...
if (is_dlg_flag_set("16")) {
xlog("dialog flag 16 is set\n");
}
...
1.6.14.
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.
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.57. store_dlg_value usage
...
store_dlg_value("inv_src_ip","$si");
store_dlg_value("account type","prepaid");
# or
$dlg_val("account_type") = "prepaid";
...
1.6.15.
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).
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.58. fetch_dlg_value usage
...
fetch_dlg_value("inv_src_ip","$avp(2)");
fetch_dlg_value("account type","$var(account)");
# or
$var(account) = $dlg_val("account_type");
...
1.6.16.
topology_hiding()
Dialog module can also do a small overhead topology hiding. By calling this
function on an initial Invite, for the current dialog, the modules will
hide the topology, meaning that it will strip and restore all the Via,
Record-Route and Route headers and it will replace the contact with the
IP address of the interface where the request was received.
You must note however, that the detection of the future in-dialog requests(BYE, reInvite, etc.)
for these dialogs on which topology hiding is applied, is not done automatically.
Without topology hiding and only normal dialog, the detection was
done when loose_route was called. But now, for this dialogs where topology
hiding is applied, the in dialog requests reaching OpenSIPS won't have any Route headers
and the RURI will point to OpenSIPS machine.
So, to be able to match the in-dialog requests to the corresponding dialog, a script
function must be called. It's name is match_dialog and you can read
it's description above.
The in-dialog topology requests are requests with a to tag,
RURI pointing to opensips and with a method specific to a
Invite dialog. For this kind of requests you should call
match_dialog() function. If a dialog is found the function
returns success.
The great advantage of using the topology hiding functionality built inside
dialog module is that you can use all the dialog modules functionalities:
profiles, dialog variables, dialog timeouts, etc..
Optionally,the function also receives a string parameter, which holds string flags.
Current options for the string flags are :
U - Propagate the Username in the Contact header URI
Returns the number of current active dialogs (may be confirmed or
not).
1.7.2. early_dialogs
Returns the number of early dialogs.
1.7.3. processed_dialogs
Returns the total number of processed dialogs (terminated,
expired or active) from the startup.
1.7.4. expired_dialogs
Returns the total number of expired dialogs from the startup.
1.7.5. failed_dialogs
Returns the number of failed dialogs ( dialogs were
never established due to whatever reasons - internal error,
negative reply, cancelled, etc )
1.8. Exported MI Functions
1.8.1. dlg_list
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)
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_
1.8.3. 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
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.
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;
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;
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.
Will synchronize the information about the dialogs from the database
with the OpenSIPS internal memory. To be used mainly for transfering
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_
1.8.8. 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_
1.8.9. 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_
1.9. Exported pseudo-variables
1.9.1. $DLG_count
Returns the number of current active dialogs (may be confirmed or
not).
1.9.2. $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.
1.9.3. $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.
1.9.4. $DLG_flags
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.
1.9.5. $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.
1.9.6. $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.
1.9.7. $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.
1.9.8. $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.
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);”
Chapter 3. Frequently Asked Questions
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.
What happend 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.
3.3.
What happend with “dlg_flag”
parameter?
The parameter is considered obsolete. The only way to
create a dialog is to call the create_dialog() function
