16 Oct
2008
16 Oct
'08
9:53 p.m.
That's what I thought too, looking at the traffic. My guess is it
correlates by to-tag and/or Call-ID GUID.
Are you using "record-route mechanism" and "loose-routing"
interchangeably? To me, they are very different things. Record-route
causes the subsequent in-dialog requests from both ends to be routed
through the server, which is something that I did have applied in my
configuration. Loose routing does what RFC 3261 says it does, and
specifically in this case, it processes the Route: header and modifies
the RURI if necessary.
What I commented out was loose-routing, and with that, request
correlation broke - even in dlg_match_mode 2. So, what I am assuming is
that loose routing is still necessary for the correlation to work, with
or without the cookie.
My question was why that was so, as there appeared to be no obvious
reason for this as long as record-routing is turned on.
-- Alex
Ovidiu Sas wrote:
The cookie attribute is not used at all in mode 2.
Inspect your
traffic and you will see that there are no rr coockes and the dialog
matching is working ok (in mode 2).
The record-route mechanism is used as a _hook_ by the dialog module to
intercept in dialog requests. I don't know how to put this better in
words ...
Hope that this clarifies your dialog matching issue.
So ... the dlg_match_mode works as advertised in the doc as long as
you have a proper implementation of the record rote mechanism.
For mode 0 and 1 you will have cookies in the Record-Route headers.
For mode 2 you will have no cookies in the Record-Route headers and
the matching will still work.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599