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(a)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