[SR-Users] Dialog - timeout for dlg with CallID

[Julien Chavanton]

One little clarification that the impact of the match mode, the non-default
mode is forced with dlg_manage, meaning everyone will use it in this case.



int dlg_manage(sip_msg_t *msg)
...
                backup_mode = seq_match_mode;
                seq_match_mode = SEQ_MATCH_NO_ID;
                dlg_onroute(msg, NULL, NULL);


                seq_match_mode = backup_mode;
...


I just create a MR with the intent of preventing any mismatch caused by
empty to-tag.
https://github.com/kamailio/kamailio/pull/2484

On Fri, Sep 25, 2020 at 11:58 PM Henning Westerholt <hw at skalatan.de> wrote:

> Thank you Julien for digging into it. If its affects not the default match
> mode - this sounds indeed like the reason that it was not found earlier.
>
> Cheers,
>
> Henning
>
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
>
> ------------------------------
> *Von:* sr-users <sr-users-bounces at lists.kamailio.org> im Auftrag von
> Julien Chavanton <jchavanton at gmail.com>
> *Gesendet:* Samstag, 26. September 2020, 04:17
> *An:* Daniel-Constantin Mierla
> *Cc:* Kamailio (SER) - Users Mailing List
> *Betreff:* Re: [SR-Users] Dialog - timeout for dlg with CallID
>
> It seems I found the problem and I have a fix.
>
> The root cause is probably that the locally generated 408 is not updating
> the dialog to-tag.
>
> However, always checking for a to-tag match, before a non to-tag match
> will fix any such issue.
>
> I will prepare a merge request on Monday to start discussing the option
> always matching to-tag first.
>
> On Fri, Sep 25, 2020 at 11:27 AM Julien Chavanton <jchavanton at gmail.com>
> wrote:
>
>> I did catch the logs, and after looking at the trace, it seems like
>> dialog mismatch with a serial forking scenario :
>>
>> - log line 3 is telling us that a NO-ACK disconnection should be triggered
>> - log line 1-2 is telling us what happened when the ACK was received in
>> dlg_onroute(), oddly enough state 5 was old and new, could it be a
>> mismatch/confusio with the previous dialog, looking in this direction ...
>>
>> 1: 2020-09-25T16:30:16.896: dialog [dlg_handlers.c:1273]:
>> extra_ack_debug_info(): [ACK][1] state not changed >>>
>> call-id[562419_125824138_2072238224] to-tag[<sip:+14019991904 at anon.com
>> >;tag=gK02b68836]
>> 2: 2020-09-25T16:30:16.896: dialog [dlg_handlers.c:1440]: dlg_onroute():
>> [ACK] state not changed old[5]new[5]
>> ...
>> 3: 2020-09-25T16:32:22.674: dialog [dlg_hash.c:247]: dlg_clean_run():
>> dialog disconnection no-ACK
>> call-id[562419_125824138_2072238224][1601051416]<[1601051542 - 60]
>>
>>
>> After looking at the pcap trace, call-id 562419_125824138_2072238224 was
>> involved in serial forking :
>>
>> call attempt #1
>>
>> X >> INVITE >> Y   // no to-tag
>> X << 100
>> ...
>> X << 408           // to-tag=594d50c3218065a60bb91fd47a70fbc1-59edef02
>> (locally generated)
>> X >> ACK           // to-tag=594d50c3218065a60bb91fd47a70fbc1-59edef02
>>
>> call attempt #2
>>
>> X >> INVITE >> Z   // no to-tag
>> X << 100
>> X << 200    << Z   // to-tag=gK02b68836
>> X >> ACK    >> Z   // to-tag=gK02b68836 (Should be state old[3]new[4], I
>> wonder how it could possibly be state old[5]new[5])
>>
>>
>>
>> I did look at several occurrences and there is always a locally generated
>> 408/to-tag before, seems like I have a good lead to investigate further.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200928/d8354c45/attachment.htm>