[Kamailio-Users] In-dialog request correlation without loose routing?

[Ovidiu Sas]

On Thu, Oct 16, 2008 at 1:13 PM, Alex Balashov
<abalashov at evaristesys.com> wrote:
> Ovidiu Sas wrote:
>>
>> On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas <osas at voipembedded.com>
>> wrote:
>>>
>>> On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov
>>> <abalashov at evaristesys.com> wrote:
>>>>>
>>>>> Post your config and the trace of a bad call (ngrep + kamailio logs).
>>>>
>>>> Config: http://pastebin.com/f28051a5
>>>>
>>>> My debug output: http://pastebin.com/d2f667520 (The profile size just
>>>> keeps
>>>> incrementing with every call that I make from 7709600101)
>>>>
>>>> Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b
>>>>
>>>> My debug output with loose routing: http://pastebin.com/d2b0fb533
>>>>
>>>> Packet trace: http://pastebin.com/d77297606
>>>
>>> Your config is bogus.  You are not doing proper record-routing (you
>>> commented out that section).
>>> In-dialog requests are matched during record-route handling,
>>> regardless of the dialog match mode.
>>>
>>
>> The documentation is a little bit fuzzy about this, but here's the hint:
>> http://kamailio.org/docs/modules/1.4.x/dialog#id2507978
>> http://kamailio.org/docs/modules/1.4.x/dialog#id2508031
>>
>> <quote>
>> This PV will be available only for sequential requests, after doing
>> loose_route().
>> </quote>
>>
>> So it means that you must perform loose_route() if you want to catch
>> in-dialog request and have a consistent dialog state.  With your
>> config, all the dialogs will just time out ...
>
> What?  I did not commend out the record_route section:
>
>        if(!is_method("REGISTER|OPTIONS"))
>                record_route();
>
> The reason I commented out the loose_route() section was specifically to
> illustrate that dialog correlation does not occur _without_ it.  I normally
> have it enabled.
>
> That was the topic of my original post:  how to correlate dialogs purely
> based on SIP attributes without the use of loose-routing.
>
> It would seem to follow from what you are saying, from the documentation
> hint you reference (which I read before), and from my examination of the
> source code to see how the dialog correlation works that the only way it
> could possibly work is through the use of a dialog correlate attribute in
> the Route: header.  That is why a call to loose_route() is necessary, and
> that is why subsequent in-dialog requests do not get correlated without it.

It seems that  I misunderstood your initial question ...
You must use loose_route because this will trigger the dialog callback.
Now how you match your dialog, it's a different story.

I thought that you were complaining about db_dialog_match_mode 2.