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

Tue Apr 5 10:43:01 CEST 2022

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

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
  * https://www.asipto.com/sw/kamailio-advanced-training-online/