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

[Trevor Peirce]

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