Ok, but I still don't understand the purpose of
such new callback.
What/ would be useful for? an example?
This callback is useful for dialog clients (like qos) in order to be monitored
when a spiraled request is received. A way to achive the existing behaviour
without the "allow_multiple_dialogs_for_spiral" parameter.
Ok, but how would work such callback? This is, a dialog is generated
for the first time an INVITE arrives to the proxy and later a spiral
occurs. A special callback is invoked. And what? what does it mean?
How do the info about the dialog look after such callback has been
invoked? does it change?
It shouldn't change at all. Its sole purpose is to allow dialog users to
get to know about spiraled routing and, if desired, the INVITE message
that is being spiraled. From a dialog event perspective, it is effectively
the same as creating a new dialog in the multiple-dialogs approach except
for the fact that no additional dialog will be created.
The pseudo-code would be something like this:
dlg_onreq() {
if (no_dlg_exists(callid, fromtag)) {
create_new_dlg();
return;
}
// spiraling
if (cbs_exist(DLGCB_SPIRALED)) {
run_dlg_callbacks(DLGCB_SPIRALED);
}
For further illustration, let me get back to Ovidiu's spiraling example:
UA1 --> P1 --> P2 --> P1 --> UA2
P1 is supposed to run the qos module, and P2 should relay media using,
say, the mediaproxy module. Now, if the qos module requires to hook up
to both P1's first (non-spiraled) and second (spiraled) INVITE message,
it will initially register for DLGCB_CREATED and receive a callback on
reception of the first one. There, the qos module would simply register
for DLGCB_SPIRALED events associated with the just-created dialog, and
in consequence, receive another callback when the second (spiraled)
INVITE is transferred. This will allow to complete SDP-based tracking
without the need for creating a duplicate dialog state in the dialog
module.
Cheers,
--Timo
