<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [sr-dev] Proposal: New Dialog Module Design</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>>>> Ok, but I still don't understand the purpose of such new callback.<BR>
>>> What/ would be useful for? an example?<BR>
>><BR>
>> This callback is useful for dialog clients (like qos) in order to be monitored<BR>
>> when a spiraled request is received. A way to achive the existing behaviour<BR>
>> without the "allow_multiple_dialogs_for_spiral" parameter.<BR>
><BR>
> Ok, but how would work such callback? This is, a dialog is generated<BR>
> for the first time an INVITE arrives to the proxy and later a spiral<BR>
> occurs. A special callback is invoked. And what? what does it mean?<BR>
> How do the info about the dialog look after such callback has been<BR>
> invoked? does it change?<BR>
<BR>
It shouldn't change at all. Its sole purpose is to allow dialog users to<BR>
get to know about spiraled routing and, if desired, the INVITE message<BR>
that is being spiraled. From a dialog event perspective, it is effectively<BR>
the same as creating a new dialog in the multiple-dialogs approach except<BR>
for the fact that no additional dialog will be created.<BR>
<BR>
The pseudo-code would be something like this:<BR>
<BR>
dlg_onreq() {<BR>
if (no_dlg_exists(callid, fromtag)) {<BR>
create_new_dlg();<BR>
return;<BR>
}<BR>
<BR>
// spiraling<BR>
if (cbs_exist(DLGCB_SPIRALED)) {<BR>
run_dlg_callbacks(DLGCB_SPIRALED);<BR>
}<BR>
<BR>
<BR>
For further illustration, let me get back to Ovidiu's spiraling example:<BR>
<BR>
UA1 --> P1 --> P2 --> P1 --> UA2<BR>
<BR>
P1 is supposed to run the qos module, and P2 should relay media using,<BR>
say, the mediaproxy module. Now, if the qos module requires to hook up<BR>
to both P1's first (non-spiraled) and second (spiraled) INVITE message,<BR>
it will initially register for DLGCB_CREATED and receive a callback on<BR>
reception of the first one. There, the qos module would simply register<BR>
for DLGCB_SPIRALED events associated with the just-created dialog, and<BR>
in consequence, receive another callback when the second (spiraled)<BR>
INVITE is transferred. This will allow to complete SDP-based tracking<BR>
without the need for creating a duplicate dialog state in the dialog<BR>
module.<BR>
<BR>
<BR>
Cheers,<BR>
<BR>
--Timo</FONT>
</P>
</BODY>
</HTML>