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@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@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@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@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@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@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@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@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@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