| Summary: | ASTERISK-24237: CDR: FRACK With PJSIP blonde transfer. | ||||
| Reporter: | Richard Mudgett (rmudgett) | Labels: | |||
| Date Opened: | 2014-08-14 20:02:39 | Date Closed: | 2014-09-19 10:13:43 | ||
| Priority: | Major | Regression? | Yes | ||
| Status: | Closed/Complete | Components: | CDR/General | ||
| Versions: | 13.0.0-beta1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) full_verb4_cdr_debug.txt ( 1) full_verb4_debug4_cdr_debug.txt | |||
| Description: | A calls B
B does a SIP blonde transfer to C C answers FRACK A, B, and C are PJSIP endpoints. {noformat} (gdb) bt #0 0x00f77422 in __kernel_vsyscall () #1 0x0064a681 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x0064dab2 in *__GI_abort () at abort.c:92 #3 0x0824c086 in ast_do_crash () at utils.c:2537 #4 0x0824c112 in __ast_assert_failed (condition=0, condition_str=0x8269873 "0", file=0x8269734 "cdr.c", line=1396, function=0x826b579 "base_process_dial_end") at utils.c:2567 #5 0x080e4514 in _ast_assert (cdr=0xb74c5604, caller=0x9e63374, peer=0x9e4f5c4, dial_status=0x9cb0ab0 "ANSWER") at /home/rmudgett/projects/sa/asterisk/starscream/include/asterisk/utils.h:810 #6 base_process_dial_end (cdr=0xb74c5604, caller=0x9e63374, peer=0x9e4f5c4, dial_status=0x9cb0ab0 "ANSWER") at cdr.c:1396 #7 0x080e6399 in handle_dial_message (data=0x0, sub=0xb72cea14, message=0x9ff7994) at cdr.c:1958 #8 0x0822896d in router_dispatch (data=0xb7569fe4, sub=0xb72cea14, message=0x9ff7994) at stasis_message_router.c:201 #9 0x08217075 in subscription_invoke (sub=0xb72cea14, message=0x9ff7994) at stasis.c:417 #10 0x08217c2a in dispatch_exec_async (local=0xb6196250) at stasis.c:666 #11 0x08232f84 in ast_taskprocessor_execute (tps=0xb752f9ac) at taskprocessor.c:764 #12 0x08231608 in default_tps_processing_function (data=0xb72215cc) at taskprocessor.c:184 #13 0x08248b45 in dummy_start (data=0xb755cd60) at utils.c:1178 #14 0x0087e96e in start_thread (arg=0xb6196b70) at pthread_create.c:300 #15 0x006f33fe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 {noformat} I suspect this is a result of recent changes in the DialEnd event ordering. (-r420794). On some investigation that patch wouldn't cause this since it was adding forwarding information. | ||||
| Comments: | By: Matt Jordan (mjordan) 2014-08-14 20:12:53.913-0500 Something isn't raising the right Dial Stasis messages. Enable 'cdr set debug on' and grab a full DEBUG log. That will show the state transitions. By: Richard Mudgett (rmudgett) 2014-08-14 21:16:01.411-0500 Attached debug logs. By: Matt Jordan (mjordan) 2014-08-22 23:29:36.567-0500 The reason why we get the FRACK here is because {{app_dial}} is raising the Dial message incorrectly: {noformat} [Aug 14 21:02:50] VERBOSE[15442][C-00000001] app_dial.c: PJSIP/202-00000003 answered PJSIP/100-00000000 [Aug 14 21:02:50] VERBOSE[15342] cdr.c: Dial End message for PJSIP/100-00000000, PJSIP/202-00000003: 1408068170.00131831 [Aug 14 21:02:50] VERBOSE[15342] cdr.c: 0xb4748e0c - Processing Dial End message for channel PJSIP/100-00000000, peer PJSIP/202-00000003 {noformat} {{app_dial}} is technically "right", but only because PJSIP/100 took the place of PJSIP/200. The Dial End message is thus incorrect for what was previously started: {noformat} [Aug 14 21:02:44] VERBOSE[15342] cdr.c: 0x9c6031c - Processing Dial Begin message for channel PJSIP/200-00000002, peer PJSIP/202-00000003 [Aug 14 21:02:44] VERBOSE[15342] cdr.c: 0x9c6031c - Updated Party A PJSIP/200-00000002 snapshot [Aug 14 21:02:44] VERBOSE[15342] cdr.c: 0x9c6031c - Updated Party B PJSIP/202-00000003 snapshot [Aug 14 21:02:44] VERBOSE[15342] cdr.c: 0x9c6031c - Transitioning CDR for PJSIP/200-00000002 from state Single to Dial {noformat} Every DialBegin must have a corresponding DialEnd. You can't just replace a channel with someone else and raise a DialEnd for a dial operation they didn't start. This isn't going to be fun to fix :-( By: Matt Jordan (mjordan) 2014-08-23 13:36:45.644-0500 As an interesting note: Pickup does a similar thing, except that it is the destination channel that is swapped out. In that case, however, the CDRs won't FRACK due to the Party B being masqueraded as opposed to the Party A. CDRs (and their state machine) are based on the Party A channel. I'm not sure if it is worth trying to alter the events for Pickup, as changing the destination channel in a DialBegin/DialEnd pair is far less explosive than changing the source of the Dial. Plus, in Pickup, there is a Pickup event informing the AMI client that a Pickup is occurring. It's not fun to have to maintain that bookkeeping, but unlike Blonde Transfers, there is at least some information conveyed to the client. | ||||