Re: [asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
On Thu, Jun 26, 2008 at 10:21 PM, Steve Murphy [EMAIL PROTECTED] wrote: On Wed, 2008-06-25 at 22:50 +0100, Grey Man wrote: On Tue, Jun 24, 2008 at 4:28 PM, Steve Murphy [EMAIL PROTECTED] wrote: This is just a note that the fixes in the CDRfix4 and CDRfix6 branches are getting closer to being merged into 1.4, trunk, and 1.6.x. If CDR's are important to you, and you ignore this notice, then you deserve what you get! Hi murf, From some preliminary testing on the CDRfix4 branch it looks like the CDRs for attended transfers are now correct which is fantastic. For blind transfers the CDR for the first call leg is still incorrect with the duration only being recorded up until the point the transfer occurs. I did a blind xfer with my snom360, and got these two cdrs with **TRUNK**: Eventlist: 1. 101 dahdi (used to be zap) phone picked up and 200 is dialed for the snom360 2. 200 (snom360) picks up and answers the call 3. 200 (snom360) hits the Transfer button (101 gets MOH), dials 202 4. 200 (snom360) hits the checkmark button to send off the call (101 starts hearing ringing, 200 starts getting congestion). 5. 202 (eyebeam) answers (101 202 are connected) 6. 101 or 202 hang up. Conversation finished. fxs.01 101,101,200,extension,DAHDI/1-1,SIP/snom360-082c3f68,Dial,SIP/snom360,30,2008-06-26 11:04:08,2008-06-26 11:04:12,2008-06-26 11:05:56,108,104,ANSWERED,DOCUMENTATION,,1214499848.11,, fxs.01 101,101,201,extension,DAHDI/1-1,SIP/murf-eyebeam-082d95d8,Dial,SIP/polycom430SIP/murf-eyebeam,30,2008-06-26 11:06:06,2008-06-26 11:06:12,2008-06-26 11:06:56,50,44,ANSWERED,DOCUMENTATION,,1214499966.13,, Here are the two CDR's with their recorded event times: CDR start answer end 112 3 245 6 above, I called into the snom360, and hit the Transfer button, dialed 201, and got congestion (101 gets moh until I hit the check key), and hung up the snom (200). 201, the eyebeam, rings, I answer. 101 and 201 are connected. 101 hangs up, and the conversation ended. THE SAME PROCEDURE ON THE CDRfix6 branch: fxs.01 101,101,200,extension,DAHDI/1-1,SIP/snom360-0829e2d0,Dial,SIP/snom360,30,Tt,2008-06-26 12:16:37,2008-06-26 12:16:44,2008-06-26 12:17:01,24,17,ANSWERED,DOCUMENTATION,,1214504197.4,, fxs.01 101,101,202,extension,DAHDI/1-1,SIP/murf-eyebeam-082c2b70,Dial,SIP/murf-eyebeam,30,Tt,2008-06-26 12:17:01,2008-06-26 12:17:14,2008-06-26 12:17:49,48,35,ANSWERED,DOCUMENTATION,,1214504197.4,, CDR start answer end 112 4 245 6 Well, time 3 does get lost, but I thought it might be nice to be able to link 1 2 by the coincident times and say, hey, that looks like a blind transfer! One point of dissatisfaction I have with these is the fact that SIP/snom dialed the second CDR, not DAHDI/1. But, if I change it, you won't know that DAHDI/1 was the guy that murf-eyebeam was talking to... tough choices. So, I take it from your above words, that you'd like the 1,2,3; 4,5,6; times on the two CDR's? Can anyone lab this up for 1.2; I don't have enough phones, and I'm not eager to reconfigure the ones I've got for just one test ! I wonder how is this reflected in cdr_addon_mysql. It would show just duration and billsec (at least for 1.4), so i would defineately want this 1 second between 3 and 4 to show up in some record (preferrably in second CDR, as it's not talking time with first user anymore). Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
On 6/26/08, Grey Man [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 4:28 PM, Steve Murphy [EMAIL PROTECTED] wrote: This is just a note that the fixes in the CDRfix4 and CDRfix6 branches are getting closer to being merged into 1.4, trunk, and 1.6.x. If CDR's are important to you, and you ignore this notice, then you deserve what you get! Hi, I just wanted to say that we are working on testing our current functionality. We don't use attended transfers, but would like at some point. So, I'll try to report within next week if something else is broken. Hi murf, From some preliminary testing on the CDRfix4 branch it looks like the CDRs for attended transfers are now correct which is fantastic. For blind transfers the CDR for the first call leg is still incorrect with the duration only being recorded up until the point the transfer occurs. What's wrong with that? This fits perfectly for my needs. Is there a way how to exploit this? Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
On Wed, 2008-06-25 at 22:50 +0100, Grey Man wrote: On Tue, Jun 24, 2008 at 4:28 PM, Steve Murphy [EMAIL PROTECTED] wrote: This is just a note that the fixes in the CDRfix4 and CDRfix6 branches are getting closer to being merged into 1.4, trunk, and 1.6.x. If CDR's are important to you, and you ignore this notice, then you deserve what you get! Hi murf, From some preliminary testing on the CDRfix4 branch it looks like the CDRs for attended transfers are now correct which is fantastic. For blind transfers the CDR for the first call leg is still incorrect with the duration only being recorded up until the point the transfer occurs. I did a blind xfer with my snom360, and got these two cdrs with **TRUNK**: Eventlist: 1. 101 dahdi (used to be zap) phone picked up and 200 is dialed for the snom360 2. 200 (snom360) picks up and answers the call 3. 200 (snom360) hits the Transfer button (101 gets MOH), dials 202 4. 200 (snom360) hits the checkmark button to send off the call (101 starts hearing ringing, 200 starts getting congestion). 5. 202 (eyebeam) answers (101 202 are connected) 6. 101 or 202 hang up. Conversation finished. fxs.01 101,101,200,extension,DAHDI/1-1,SIP/snom360-082c3f68,Dial,SIP/snom360,30,2008-06-26 11:04:08,2008-06-26 11:04:12,2008-06-26 11:05:56,108,104,ANSWERED,DOCUMENTATION,,1214499848.11,, fxs.01 101,101,201,extension,DAHDI/1-1,SIP/murf-eyebeam-082d95d8,Dial,SIP/polycom430SIP/murf-eyebeam,30,2008-06-26 11:06:06,2008-06-26 11:06:12,2008-06-26 11:06:56,50,44,ANSWERED,DOCUMENTATION,,1214499966.13,, Here are the two CDR's with their recorded event times: CDR start answer end 112 3 245 6 above, I called into the snom360, and hit the Transfer button, dialed 201, and got congestion (101 gets moh until I hit the check key), and hung up the snom (200). 201, the eyebeam, rings, I answer. 101 and 201 are connected. 101 hangs up, and the conversation ended. THE SAME PROCEDURE ON THE CDRfix6 branch: fxs.01 101,101,200,extension,DAHDI/1-1,SIP/snom360-0829e2d0,Dial,SIP/snom360,30,Tt,2008-06-26 12:16:37,2008-06-26 12:16:44,2008-06-26 12:17:01,24,17,ANSWERED,DOCUMENTATION,,1214504197.4,, fxs.01 101,101,202,extension,DAHDI/1-1,SIP/murf-eyebeam-082c2b70,Dial,SIP/murf-eyebeam,30,Tt,2008-06-26 12:17:01,2008-06-26 12:17:14,2008-06-26 12:17:49,48,35,ANSWERED,DOCUMENTATION,,1214504197.4,, CDR start answer end 112 4 245 6 Well, time 3 does get lost, but I thought it might be nice to be able to link 1 2 by the coincident times and say, hey, that looks like a blind transfer! One point of dissatisfaction I have with these is the fact that SIP/snom dialed the second CDR, not DAHDI/1. But, if I change it, you won't know that DAHDI/1 was the guy that murf-eyebeam was talking to... tough choices. So, I take it from your above words, that you'd like the 1,2,3; 4,5,6; times on the two CDR's? Can anyone lab this up for 1.2; I don't have enough phones, and I'm not eager to reconfigure the ones I've got for just one test ! For people on the list following this bug my company got stung by this in the last week so there now appear to be some people out there actively looking for Asterisk systems to exploit. The incident for us was a user using attended transfers to place free calls through a 1.2 system. In the past we have had normal users stumble across the problem but in this case it was a directed attempt. So if like us you are a provider and use Asterisk and are required to support transfers it would be highly advisable to keep a close eye on things! Won't it be pleasant to slip in the fix and watch these guys get billed for calls they were thinking would be free! murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
On Thu, Jun 26, 2008 at 8:21 PM, Steve Murphy [EMAIL PROTECTED] wrote: On Wed, 2008-06-25 at 22:50 +0100, Grey Man wrote: Hi murf, CDR start answer end 112 4 245 6 Well, time 3 does get lost, but I thought it might be nice to be able to link 1 2 by the coincident times and say, hey, that looks like a blind transfer! One point of dissatisfaction I have with these is the fact that SIP/snom dialed the second CDR, not DAHDI/1. But, if I change it, you won't know that DAHDI/1 was the guy that murf-eyebeam was talking to... tough choices. So, I take it from your above words, that you'd like the 1,2,3; 4,5,6; times on the two CDR's? If i've understood your call flow correctly the CDR's required are 1,2,6 and 4,5,6. The key point being that the first call made is up until both call legs are hungup (which is 6) whereas the CDR is reporting its duration as the time up until the blind transfer was initiated (which is 3). As far as using the CDRs to identify that a blind transfer has taken place my opinion would be that that is a secondary concern compared to getting the call records accurate. There seem to be a lot of cases where people are experiencing pain because of the incorrect CDRs for their billing but I'm yet to see a post where someone is kicking up a fuss because they can't easily identify whether a particular CDR was involved in a transfer. It's would be a nice to have whereas incorrect durations on the CDRs cost money. Can anyone lab this up for 1.2; I don't have enough phones, and I'm not eager to reconfigure the ones I've got for just one test ! Do you mean compare the differences between the CRDfix4 branch and 1.2? At the moment the blind transfer CDRs are the same for 1.2, 1.4 and CDRfix4 with all being incorrect in the same spot which is the duration on the first call leg. In case it's of any help if you have a Windows box available I have a tool that can initiate SIP calls and carry out blind and attended transfers with Asterisk. It does make testing a lot easier, I got tired of playing hopscoth on my phones as well, now I just click a button. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
On Tue, Jun 24, 2008 at 4:28 PM, Steve Murphy [EMAIL PROTECTED] wrote: This is just a note that the fixes in the CDRfix4 and CDRfix6 branches are getting closer to being merged into 1.4, trunk, and 1.6.x. If CDR's are important to you, and you ignore this notice, then you deserve what you get! Hi murf, From some preliminary testing on the CDRfix4 branch it looks like the CDRs for attended transfers are now correct which is fantastic. For blind transfers the CDR for the first call leg is still incorrect with the duration only being recorded up until the point the transfer occurs. For people on the list following this bug my company got stung by this in the last week so there now appear to be some people out there actively looking for Asterisk systems to exploit. The incident for us was a user using attended transfers to place free calls through a 1.2 system. In the past we have had normal users stumble across the problem but in this case it was a directed attempt. So if like us you are a provider and use Asterisk and are required to support transfers it would be highly advisable to keep a close eye on things! Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
This is just a note that the fixes in the CDRfix4 and CDRfix6 branches are getting closer to being merged into 1.4, trunk, and 1.6.x. If CDR's are important to you, and you ignore this notice, then you deserve what you get! These branches address various long-standing bugs, most of which are regressions from 1.2. It is hoped that these fixes will solve most of the problems introduced by the various changes made in 1.4 and trunk, without losing the fixes made in those changes. To test out these branches, you can: svn co http://svn.digium.com/svn/asterisk/team/murf/CDRfix4 or svn co http://svn.digium.com/svn/asterisk/team/murf/CDRfix6 The above commands will create a directory called CDRfix4 (or CDRfix6) in the current directory, which contains an entire copy of the asterisk source. You can cd into this dir and do the configure/make menuselect/ make/make install thing there to your hearts content. The CDRfix4 branch is based on 1.4; The CDRfix6 branch is based on trunk (which is still close enough to 1.6.0 that it won't take much effort to merge it 1.6.0 also.) The bugs that will hopefully be addressed are: http://bugs.digium.com/view.php?id=10927 http://bugs.digium.com/view.php?id=11093 http://bugs.digium.com/view.php?id=12724 http://bugs.digium.com/view.php?id=12907 and perhaps others. The goal was to restore the code roughly to 1.2 behavior when it came to transfers, minus any bad behavior that 1.2 had. So, entire legs missing from transfers, missing or bad times, etc, seem to mostly solved. The fixes do NOT fulfil requests to further subdivide CDR's in xfer situations, as I'm not warm and fuzzy on a general consensus as to exactly what the new CDR's would say. I haven't been able to engage really anyone in getting details ironed out on these issues. Folks have made suggestions, good ones at that, but everyone seems to be of a mind that before we extend or upgrade the current CDR system, we should produce a specification, and see if the community can come to a consensus on that spec. So, I think I might make a proposal for enhancement of the existing CDR's to give more details about xfer situations, and we can hash out the details from there. This proposal can then serve as the spec for future enhancements. Also, keep in mind, that we have a new facility being groomed for merging into trunk: http://svn.digium.com/svn/asterisk/team/group/newcdr which will introduce some new concepts that will help in forming billing records; it is single-event based, and introduces a new channel value, linkedid, which is spread between channels that 'interact', thus allowing you to more easily collect events that are related via transfers, conferences, parking, holding, etc. So, please, please, please, test these branches against your implementations, and report any problems you see, so we can solve problems before they get merged! Problems and complaints can be added to the bugs mentioned above, choose the one that seems most closely related to the problem you are having. murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
