16 Oct
2008
16 Oct
'08
10:27 p.m.
Daniel-Constantin Mierla wrote:
On 10/16/08 22:07, Alex Balashov wrote:
That's what I figured; there was something in the callback architecture
that caused the module to otherwise not see the requests.
Cool - that explains it!
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
Ovidiu Sas wrote:
I got that.
So, why does matching not work unless I call loose_route(), regardless
of match mode? :-)
the matching is triggered by execution of Route processing callbacks
that happen only by calling loose_route().
The dialog module registers a function to be called when the Route
header is processed. In this function the dialog module does the
matching algorithm. To get independent of that, for matching mode 2, a
function should be exported by dialog for explicit call in the script,
something like:
if(dialog_match())
{
....
}
Cheers,
Daniel If it is
loose_route() that I need to correlate subsequent in-dialog
requests, why? As you said, if no RR cookies are being used, why
should the
proxy care about the Route: header?
I don't know how to put it better in other words :(
The proxy doesn't care about the Route header.
The proxy uses the record routing mechanism as a hook into the dialog
internals and the matching is done inside the dialog module. After
that, the dialog module will chose the matching mechanism.