Hello,
I am seeing a crash within the latest ims modules using the example cfg
scripts. It also happened in 4.1
1) The s-cscf receives a request from an application server and runs
'assign_server_unreg' (cfg line 368) because the intended destination is
not registered.
2) The HSS returns an error '5012: Unable to comply' and the suspended
transaction is resumed into the UNREG_SAR_REPLY route (cxdx_sar.c:290)
3) The coredump shows that the AVP lists are nonsensical, so the action
to get $avp(s:saa_return_code) causes a crash.
Do the avp lists need to be re-initialised from the suspended
transaction, like in the 'success/done' section (cxdx_sar.c:252)?
Maybe someone who is more familiar with this code can shine some light
on this?
Also in this scenario I can't see a code path that will send a response
back to the application server e.g. '480 Temporarily Unavailable' -
Should this be done in the cfg before calling assign_server_unreg?
Regards,
Hugh
Backtrace:
(gdb) bt
#0 0x000000000053dc89 in match_by_name (avp=0x303630363a6d6f63,
id=116, name=0x7ffff29895f8) at usr_avp.c:391
#1 0x000000000053e411 in search_next_avp (s=0x7ffff29895f0,
val=0x7ffff2989630) at usr_avp.c:507
#2 0x000000000053e120 in search_avp (ident=..., val=0x7ffff2989630,
state=0x7ffff29895f0) at usr_avp.c:475
#3 0x000000000053de09 in search_first_avp (flags=1, name=...,
val=0x7ffff2989630, s=0x7ffff29895f0) at usr_avp.c:427
#4 0x00007fa8de2f5626 in pv_get_avp (msg=0x7ffff298a030,
param=0x7fa8de86b898, res=0x7ffff2989760) at pv_core.c:1475
#5 0x0000000000499270 in pv_get_spec_value (msg=0x7ffff298a030,
sp=0x7fa8de86b880, value=0x7ffff2989760) at pvapi.c:1266
#6 0x00000000004c5f03 in rval_get_int (h=0x7ffff2989ef0,
msg=0x7ffff298a030, i=0x7ffff2989d58, rv=0x7fa8de86b878, cache=0x0)
at rvalue.c:978
#7 0x00000000004c89f5 in rval_expr_eval_int (h=0x7ffff2989ef0,
msg=0x7ffff298a030, res=0x7ffff2989d58, rve=0x7fa8de86b870) at
rvalue.c:1918
#8 0x0000000000420648 in do_action (h=0x7ffff2989ef0,
a=0x7fa8de86eaa8, msg=0x7ffff298a030) at action.c:1219
#9 0x0000000000422878 in run_actions (h=0x7ffff2989ef0,
a=0x7fa8de86aa30, msg=0x7ffff298a030) at action.c:1599
#10 0x0000000000423017 in run_top_route (a=0x7fa8de86aa30,
msg=0x7ffff298a030, c=0x0) at action.c:1685
#11 0x00007fa8de59eae3 in t_continue (hash_index=15710,
label=170389234, route=0x7fa8de86aa30) at t_suspend.c:245
#12 0x00007fa8da1ebc98 in async_cdp_callback (is_timeout=0,
param=0x7fa8d5c68f40, saa=0x0, elapsed_msecs=1) at cxdx_sar.c:290
#13 0x00007fa8db23cacb in api_callback (p=0x7fa8d5c24d40,
msg=0x7fa8d5c5aca8, ptr=0x0) at api_process.c:115
#14 0x00007fa8db27ad87 in worker_process (id=2) at worker.c:330
#15 0x00007fa8db257aea in diameter_peer_start (blocking=0) at
diameter_peer.c:309
#16 0x00007fa8db25a02b in cdp_child_init (rank=0) at mod.c:237
#17 0x00000000004f7ec2 in init_mod_child (m=0x7fa8de841158, rank=0)
at sr_module.c:924
#18 0x00000000004f7d65 in init_mod_child (m=0x7fa8de841d00, rank=0)
at sr_module.c:921
#19 0x00000000004f7d65 in init_mod_child (m=0x7fa8de8420a8, rank=0)
at sr_module.c:921
#20 0x00000000004f7d65 in init_mod_child (m=0x7fa8de842458, rank=0)
at sr_module.c:921
#21 0x00000000004f7d65 in init_mod_child (m=0x7fa8de842ae8, rank=0)
at sr_module.c:921
#22 0x00000000004f7d65 in init_mod_child (m=0x7fa8de842f60, rank=0)
at sr_module.c:921
#23 0x00000000004f8048 in init_child (rank=0) at sr_module.c:948
#24 0x000000000046d57c in main_loop () at main.c:1694
#25 0x000000000047030b in main (argc=13, argv=0x7ffff298af78) at
main.c:2533
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#382 - dlg_end_dlg on a two-armed proxy only sends bye to one party
User who did this - Per Carlen (peca)
----------
No error messages found. However found some strange log entries regarding local messages so...
Did a tcpdump on lo interface - and when running the "dlg_end_dlg", a BYE was actually sent on lo (src address and dst address = ip on external interface, first value in route-header also equalled the external ip).
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=382#comment1236
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#382 - dlg_end_dlg on a two-armed proxy only sends bye to one party
User who did this - Daniel-Constantin Mierla (miconda)
----------
Do you get any error messages in syslog?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=382#comment1235
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Per Carlen (peca)
Attached to Project - sip-router
Summary - dlg_end_dlg on a two-armed proxy only sends bye to one party
Task Type - Bug Report
Category - dialog
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - The Proxy is configured with two NICs, one interface is connected to an internal SIP-server and the other to an external SIP-server.
A session is established successfully and RTP flows via an RTP-Proxy. So far everything is fine.
When issuing a "dlg_end_dlg"-command in the Proxy, this results in only one BYE being sent on the internal interface towards the SIP-server. No BYE on the external interface. This was verified with tcpdump on all NICs.
If, however, another SIP-Proxy with only one NIC is inserted in the chain between the internal SIP-server and the original SIP-Proxy, and the "dlg_end_dlg" is issued in this new Proxy, then a BYE is sent to both parties. Which to me appear to be the correct behaviour.
So, there seems to be an issue with "dlg_end_dlg" when the involved caller and callee are on different interfaces.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=382
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.