[SR-Users] Asterisk, unable to find dialog for ACK with route param and call-id

Tue Apr 5 11:02:08 CEST 2022

They do, all the values are different.  Even the To is different. Only 
the From header is the same.

NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
timestamp=1648611831;time_unix=1648611831.933;method=BYE;from_tag=as730369e7;to_tag=as3b06b3e2;call_id=53bad4f0034b61a5745163d82daef402;code=200;reason=OK

NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
timestamp=1648611832;time_unix=1648611832.115;method=BYE;from_tag=as292200a1;to_tag=as75834dc4;call_id=7cef233547dca0ac7882ce5249b3b54c;code=200;reason=OK

On 2022-04-05 1:43 a.m., Daniel-Constantin Mierla wrote:
> Hello,
>
> do the two legs have different Call-Id and From-tag values?
>
> Cheers,
> Daniel
>
> On 05.04.22 02:03, Trevor Peirce wrote:
>> Hi Daniel,
>>
>> Thanks for the reply.  I have verified that dlg_manage() is being
>> called for both legs of the call.  I have tested with dlg_match_mode
>> set to various values with no change in behaviour.
>>
>> The output I shared originally was with modparam("debugger",
>> "mod_level", "dialog=4") and I don't see any change when increasing
>> that to 5.
>>
>> I would like to re-iterate the oddness that leg A only has these
>> problems when leg B exists.  If leg B goes through a separate kamailio
>> instance, A seems to work fine.
>>
>> In these two scenarios, leg A works as expected:
>>
>> Leg A: SBC -> Kamailio -> Asterisk (handled internally)
>>
>> Leg A: SBC -> Kamailio -> Asterisk
>> Leg B: Asterisk -> Kamailio -> Locally registered SIP endpoint
>>
>> Here leg A does not work as expected:
>>
>> Leg A: SBC -> Kamailio -> Asterisk
>> Leg B: Asterisk -> Kamailio -> SBC
>>
>> It feels like Kamailio is thinking that Leg A and B are related, but
>> they shouldn't be.  They should appear as two completely independent
>> calls.
>>
>> I have tried with detect_spirals both on and off.
>>
>> Thanks,
>> Trevor
>>
>> On 2022-04-04 8:05 a.m., Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> be sure that you call dlg_manage() for all sip requests that can belongs
>>> to the call. Also, you can set the modparam to fallback on SIP
>>> attributes for dialog matching if did-param-based matching fails.
>>>
>>> For troubleshooting, try to increase the verbosity for dialog module
>>> using debugger module or do it globally with debug=3, then look at the
>>> logs printed by kamailio.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 30.03.22 06:14, Trevor Peirce wrote:
>>>> Hello,
>>>>
>>>> I'm having some trouble with what I think is the dialog module.
>>>>
>>>> I've got Kamailio 5.5.4 running well for some time. Recently I added
>>>> Asterisk to the mix and have come across an issue.
>>>>
>>>> Call to Kamailio.  Kamailio sends it to Asterisk.  Asterisk may decide
>>>> to "forward" the call.  To do this it will place a new outbound call
>>>> through Kamailio.  From the user perspective, this works absolutely
>>>> fine (invite, ringing, ok, bye).  The acc module handles it fine also.
>>>>
>>>> However dialog does not, and the events for ok and bye do not fire on
>>>> the original call.  They do fire for the forwarded call.
>>>>
>>>> I've added some logging output to try to isolate the problem, but I'm
>>>> no further ahead.  Here's what I have.  Any suggestions?
>>>>
>>>> ** Call initiated **
>>>>
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=100 ru=<null> tu=sip:destination at endpoint DLG_status=<null>
>>>> dlg-h-id=3360
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=100 ru=<null> tu=sip:fwddest at 0.0.0.1:5060 DLG_status=<null>
>>>> dlg-h-id=12036
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=183 ru=<null> tu=sip:fwddest at 0.0.0.1:5060 DLG_status=<null>
>>>> dlg-h-id=12036
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=183 ru=<null> tu=sip:destination at endpoint DLG_status=<null>
>>>> dlg-h-id=3360
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=200 ru=<null> tu=sip:fwddest at 0.0.0.1:5060 DLG_status=<null>
>>>> dlg-h-id=12036
>>>> CRITICAL: dialog [dlg_timer.c:200]: update_dlg_timer(): Trying to
>>>> update a bogus dlg tl=0x7fa0494006e8 tl->next=(nil) tl->prev=(nil)
>>>> ERROR: dialog [dlg_hash.c:1329]: update_dlg_timeout(): failed to
>>>> update dialog lifetime
>>>> CRITICAL: dialog [dlg_timer.c:200]: update_dlg_timer(): Trying to
>>>> update a bogus dlg tl=0x7fa0494006e8 tl->next=(nil) tl->prev=(nil)
>>>> ERROR: dialog [dlg_hash.c:1329]: update_dlg_timeout(): failed to
>>>> update dialog lifetime
>>>> ERROR: dialog [dlg_profile.c:1028]: dlg_set_timeout_by_profile():
>>>> Unable to set timeout on 3306:12036
>>>> NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
>>>> timestamp=1648611824;time_unix=1648611824.346;method=INVITE;from_tag=as292200a1;to_tag=as75834dc4;call_id=7cef233547dca0ac7882ce5249b3b54c;code=200;reason=OK
>>>>
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=200 ru=<null> tu=sip:destination at endpoint DLG_status=<null>
>>>> dlg-h-id=<null>
>>>> NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
>>>> timestamp=1648611824;time_unix=1648611824.354;method=INVITE;from_tag=as730369e7;to_tag=as3b06b3e2;call_id=53bad4f0034b61a5745163d82daef402;code=200;reason=OK
>>>>
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=200 ru=<null> tu=sip:destination at endpoint DLG_status=<null>
>>>> dlg-h-id=<null>
>>>> WARNING: dialog [dlg_handlers.c:1328]: dlg_onroute(): unable to find
>>>> dialog for ACK with route param '161.02d' [353:3360] and call-id
>>>> '53bad4f0034b61a5745163d82daef402'
>>>> WARNING: dialog [dlg_handlers.c:1328]: dlg_onroute(): unable to find
>>>> dialog for ACK with route param '161.02d' [353:3360] and call-id
>>>> '53bad4f0034b61a5745163d82daef402'
>>>>
>>>> ** The call is answered and endpoints can talk to each other **
>>>> ** Now the original caller hangs up **
>>>>
>>>> WARNING: dialog [dlg_handlers.c:1328]: dlg_onroute(): unable to find
>>>> dialog for BYE with route param '161.02d' [353:3360] and call-id
>>>> '53bad4f0034b61a5745163d82daef402'
>>>> NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
>>>> timestamp=1648611831;time_unix=1648611831.933;method=BYE;from_tag=as730369e7;to_tag=as3b06b3e2;call_id=53bad4f0034b61a5745163d82daef402;code=200;reason=OK
>>>>
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=100 ru=<null> tu=sip:fwddest at 0.0.0.1:5060 DLG_status=<null>
>>>> dlg-h-id=12036
>>>> INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE
>>>> rs=200 ru=<null> tu=sip:fwddest at 0.0.0.1:5060 DLG_status=<null>
>>>> dlg-h-id=12036
>>>> ERROR: <script>: got result for bye = Bye!; DLG_lifetime = 8
>>>> NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
>>>> timestamp=1648611832;time_unix=1648611832.115;method=BYE;from_tag=as292200a1;to_tag=as75834dc4;call_id=7cef233547dca0ac7882ce5249b3b54c;code=200;reason=OK
>>>>
>>>> ERROR: dialog [dlg_handlers.c:363]: dlg_terminated_confirmed(): failed
>>>> to get dialog from params!
>>>>
>>>> ** Everything ends cleanly on the other SIP endpoints **
>>>>
>>>> What can I do from here to try to isolate this further?
>>>>
>>>> Thanks,
>> -- Trevor Peirce
>> AcroVoice Solutions Inc
>>
>> www.acrovoice.ca - 1-888-606-3030 x701
>>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>  * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only
>> to the sender!
>> Edit mailing list options or unsubscribe:
>>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Trevor Peirce
AcroVoice Solutions Inc

www.acrovoice.ca - 1-888-606-3030 x701