| Summary: | ASTERISK-21495: 302 Moved Temporarily CDR Incorrect | ||
| Reporter: | Ross Beer (rossbeer) | Labels: | |
| Date Opened: | 2013-04-17 12:40:46 | Date Closed: | 2013-05-10 16:45:10 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | 1.8.21.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | When a phone sends a 302 call forward, the CDRs contain the incorrect information.
For example a call record for the diversion part of the CDR shows the duration, however the billsec is 0. This is incorrect as this part of the call is established and therefore the billsec should be shown. The cdr shows a call to 'Local/012412542554@default-00000006;1', however I believe to resolve the issue the call needs to have the '/n' appended to the string before dialing. As this is in the chan_sip directly, this needs to be done in the source. Example CDR is: calldate,channel,dstchannel,duration,billsec 2013-04-17 18:35:49,SIP/<exten>-000dc1ee,Local/<mobile>@from-internal-00000007;1,55,40 2013-04-17 18:35:56,Local/<mobile>@from-internal-00000007;2,SIP/sipprvider-000dc1fb,8,0 The second entry is the call to the mobile, however the call is bridged and the CDR added to the DB. However the call is still in progress. The call should not be bridged when answered, instead the two CDRs should continue until the call ends. | ||
| Comments: | By: David Woolley (davidw) 2013-04-18 11:59:36.566-0500 You should be using call event logging for all but the simplest of calls. It was created because fixing one thing in CDRs kept breaking another. By: Rusty Newton (rnewton) 2013-04-23 14:05:47.801-0500 I agree with David, Unfortunately for CDR there is much undefined behavior in various scenarios (often transfer scenarios). That is a big reason why CEL (Channel Event Logging) https://wiki.asterisk.org/wiki/display/AST/CEL+Design+Goals was created. This makes it difficult to tell what is a bug and isn't, and even if developers attempt to fix it then it's likely to break something else for you. The whole scenario is definitely something the development team is trying to address in Asterisk 12 and beyond https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification Did this behavior change within the 1.8 branch? Is there a previous 1.8 version where it behaves differently? By: Rusty Newton (rnewton) 2013-05-10 16:45:10.240-0500 I'm going to close this as a feature request (since its undefined behavior) and there is no patch. If someone wants to attempt fixing it, provide a patch and then show some testing to demonstrate how it doesn't break other things in CDR then we'll look into it. | ||