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,
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
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
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,
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@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
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
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@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
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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 -
Trevor Peirce