Hi Steve,> .. I'll try to sort all this out, and then I'll attackthis> problem. Hopefully, I get it all into svn before the next release of > 1.4...!Just wondering if any new CDR functionality made it into the 1.4.16.2 release? I have looked through the ChangeLog for the 1.4.15 and 1.4.16.2 releases but didn't spot anything to do with changes in CDR handling. I for one still have big problems with CDR's for blind transfer and attended transfer calls. - For Blind Transfers the destination in the CDR ends up being the destination transferred to. This means you could ring a mobile and when finished blind transfer to a free number and get a free call. - For Attended Transfers it's all very confused. I get two CDR's both with the destination of the latest call in the transfer. I've got some users that have cottoned onto this and not only ring the low value destination second but then email in complaining about duplicate billing to try and get one of the CDR's refunded. On a separate note does anyone know how to block transfers on a SIP channel? I can block REFER requests from my SIP Proxy but I have to support some transfers so that's not an option. Regards, Greyman. ----- Original Message ---- From: Steve Murphy <murf at digium.com> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> Sent: Monday, 15 October, 2007 6:22:45 PM Subject: Re: [asterisk-users] CDR Sorry! I've gotten some complaints on this; I will try this week to mod 1.4 so that you can choose to see the single-channel unanswered CDR's, in a new config file option. I've gotten complaints both ways, tho, so pardon me if I get a little confused about what users out there want from CDR's. My biggest trouble is that by forcing all channels to have a CDR at creation time solves problems with missing CDR's, but creates a problem by generating extra unanswered CDR's that weren't generated before... for instance, when you ring three phones via a dial command, you then get 3 CDR's, including the two phones that were rung, but not answered. Another problem is with Zap-based phones; you take the handset off-hook, and a channel is created and dialtone generated. If you hang up, you get a CDR there, also. I have not found an easy way to detect and drop these kinds of CDR's, as most folks really do not find them very useful. And, I've gotten a complaint that you end up with 'duplicate' CDR's, which is also an artifact of forcing all channels to have a CDR associated. If anybody thinks they have a magic spell that will calm down the CDR's, I will not mind the information at all! I worked all last week to try to iron out the 1.4 zap-transfer CDR issues. I have 12 cases I test with involving hook-flash and #-blindxfers, and so far, I've got 9 of the 12 working OK (as far as I'm concerned.), but I have 3 cases that come up with problems. For instance, if you hookflash, and dial a number, the CDR's will be different, if you hang up before the dialed party answers, versus hanging up afterwards... The diff between a blind xfer and an attended xfer (without the 3 way), I guess, but I lose the calling channel name... I'll try to sort all this out, and then I'll attack this problem. Hopefully, I get it all into svn before the next release of 1.4...! As far as xfers in 1.4 go, I'm trying to make sure that the source and destination channel names reflect the true dialing party, as this makes more sense from a billing perspective, at least to me. So, if A calls B, and B forwards the call to C, then the CDR's need to reflect a call from A to B, and a call from B to C, which you may or may not be seeing right now. AFAICT, transfers pretty much result in confused CDR's. I gave up totally on generating separate CDR's for any 3-ways that might occur. Such 3-ways will end up being billed to the dialing parties. Here's an interesting situation: A calls B, A then hookflashes, and then A calls C, and hookflashes again. It's now a 3-way call, between A, B, and C. A then drops out and B and C converse. My goal with this situation was to have two CDR's, one for A->B and one for A->c. Since A placed both calls, it seems only just that A pay for B's and C's conversation. Especially if A is in the US, for example, and B is in Uganda, and C is in Bangladesh! Getting the right info in the right field from the driver level is pretty tricky, and you can add the fact that there's definite timing issues at play. If I make changes to CDR's in channels A and B, near to the time a hangup occurs (and it's very commonly the case), I can end up with some pretty strange stuff happening! I found that adding debug logging statements to the driver can affect the way the CDR's are generated! I solved some of this by locking channels (which to me is pretty ugly, considering the number of locks involved). So, please, cut me some slack... and keep me informed about your "happiness" levels. I want this stuff to be good, solid, and useful to the majority. But also keep in mind that I fix something, someone out there is going to be unhappy, because they have code/backends/whatever that depends on the borked behavior! 1.4 ***IS**** a release, and I dare not do ANYTHING but fix bugs. But, wow, fixing a bug changes behavior, and my goal is minimal impact, but real and useful fixes. murf On Mon, 2007-10-15 at 10:40 +0200, Andrew Nowrot wrote:> Hi > > Thanks for reply > > Yes, there's a change. For me it's completely unacceptable,so> i > reverted the patch(bugs.digium.com/view.php?id=10659).> > > For me too. This bug occur in September. Is it still present in > asterisk 1.4.12.1. I also have asterisk 1.4.4 on a different box and > there everything works like in 1.2.21. > I need the old behaviour to have everything working flawlessly. > > Thanks > > Andrew > > > _______________________________________________ > --Bandwidth and Colocation Provided by api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > lists.digium.com/mailman/listinfo/asterisk-users-- Steve Murphy Software Developer Digium Make the switch to the world's best email. Get the new Yahoo!7 Mail now. yahoo7.com.au/worldsbestemail
On Thu, 2007-12-27 at 07:07 -0800, Grey Man wrote:> Hi Steve, > > > .. I'll try to sort all this out, and then I'll attack > this > > problem. Hopefully, I get it all into svn before the next release of > > 1.4...! > > Just wondering if any new CDR functionality made it into the 1.4.16.2 release? I have looked through the ChangeLog for the 1.4.15 and 1.4.16.2 releases but didn't spot anything to do with changes in CDR handling. > > I for one still have big problems with CDR's for blind transfer and attended transfer calls. > > - For Blind Transfers the destination in the CDR ends up being the destination transferred to. This means you could ring a mobile and when finished blind transfer to a free number and get a free call. > > - For Attended Transfers it's all very confused. I get two CDR's both with the destination of the latest call in the transfer. I've got some users that have cottoned onto this and not only ring the low value destination second but then email in complaining about duplicate billing to try and get one of the CDR's refunded. > > On a separate note does anyone know how to block transfers on a SIP channel? I can block REFER requests from my SIP Proxy but I have to support some transfers so that's not an option. > > Regards, >Greyman-- No real new functionality in 1.4, except a cdr.conf option that lets you control whether you see one-channel cdrs. I haven't been working on CDR's the last few months in favor of other projects that seem a little more urgent. Plus, I have some folks urging me NOT to proceed until some architectural issues are discussed, which might be wise. I have been working on one bug where I did make some substantive changes to how the CDR's are generated, but it is almost certain that these changes will only show up in trunk. I've reached the limit of what I can do in 1.4; it is simply impossible to do anything with CDR's in 1.4 without tearing the very fabric of time and space, and just plain getting everybody upset... at least, those who were not erased from existence by the tear... on a more serious note, the changes are intrusive enough, the behavior changes big enough, that they really don't qualify to be applied to a current release. It's a huge job! My past work was just in the ZAP channel driver code, and because it's so asynch, and all split up into different code, it's really tough to get the right pieces in the right places at the right time in the right way. What this all says is that I'm most likely NOT doing it the right way. And what worries me most is that there might not be any "right" way. But I'm still new to this, and will get back around to it hopefully fairly soon. murf> Greyman. > > ----- Original Message ---- > From: Steve Murphy <murf at digium.com> > To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> > Sent: Monday, 15 October, 2007 6:22:45 PM > Subject: Re: [asterisk-users] CDR > > Sorry! > > I've gotten some complaints on this; I will try this week to > mod 1.4 so that you can choose to see the single-channel unanswered > CDR's, in a new config file option. I've gotten complaints both ways, > tho, so pardon me if I get a little confused about what users out there > want from CDR's. > > My biggest trouble is that by forcing all channels to have a CDR at > creation time > solves problems with missing CDR's, but creates a problem by generating > > extra unanswered CDR's that weren't generated before... for instance, > when you > ring three phones via a dial command, you then get 3 CDR's, including > the > two phones that were rung, but not answered. > > Another problem is with Zap-based phones; you take the handset > off-hook, > and > a channel is created and dialtone generated. If you hang up, you get a > CDR there, also. > > I have not found an easy way to detect and drop these kinds of CDR's, > as > most folks really do not find them very useful. > > And, I've gotten a complaint that you end up with 'duplicate' CDR's, > which is also an artifact of forcing all channels to have a CDR > associated. If anybody > thinks they have a magic spell that will calm down the CDR's, I will > not > mind the information at all! I worked all last week to try to iron out > the 1.4 zap-transfer CDR issues. I have 12 cases I test with involving > hook-flash and #-blindxfers, and so far, I've got 9 of the 12 working > OK > (as far as I'm concerned.), but I have 3 cases that come up with > problems. For instance, if you hookflash, and dial a number, the CDR's > will be different, if you hang up before the dialed party answers, > versus hanging up afterwards... The diff between a blind xfer and an > attended xfer (without the 3 way), I guess, but I lose the calling > channel name... I'll try to sort all this out, and then I'll attack > this > problem. Hopefully, I get it all into svn before the next release of > 1.4...! > > As far as xfers in 1.4 go, I'm trying to make sure that the source and > destination channel names reflect the true dialing party, as this makes > more sense from a billing perspective, at least to me. So, if A calls > B, and B forwards the call to C, then the CDR's need to reflect a call > from A to B, and a call from B to C, which you may or may not be seeing > right now. AFAICT, transfers pretty much result in confused CDR's. I > gave up totally on generating separate CDR's for any 3-ways that might > occur. Such 3-ways will end up being billed to the dialing parties. > > Here's an interesting situation: A calls B, A then hookflashes, and > then > A calls C, and hookflashes again. It's now a 3-way call, between A, B, > and C. A then drops out and B and C converse. My goal with this > situation was to have two CDR's, one for A->B and one for A->c. Since A > placed both calls, it seems only just that A pay for B's and C's > conversation. Especially if A is in the US, for example, and B is in > Uganda, and C is in Bangladesh! > > Getting the right info in the right field from the driver level is > pretty tricky, and you can add the fact that there's definite timing > issues at play. If I make changes to CDR's in channels A and B, near to > the time a hangup occurs (and it's very commonly the case), I can end > up > with some pretty strange stuff happening! I found that adding debug > logging statements to the driver can affect the way the CDR's are > generated! I solved some of this by locking channels (which to me is > pretty ugly, considering the number of locks involved). > > So, please, cut me some slack... and keep me informed about your > "happiness" levels. I want this stuff to be good, solid, and useful to > the majority. But also keep in mind that I fix something, someone out > there is going to be unhappy, because they have code/backends/whatever > that depends on the borked behavior! > 1.4 ***IS**** a release, and I dare not do ANYTHING but fix bugs. But, > wow, fixing a bug changes behavior, and my goal is minimal impact, but > real and useful fixes. > > > murf > > > > > > > > On Mon, 2007-10-15 at 10:40 +0200, Andrew Nowrot wrote: > > Hi > > > > Thanks for reply > > > > Yes, there's a change. For me it's completely unacceptable, > so > > i > > reverted the patch > (bugs.digium.com/view.php?id=10659). > > > > > > For me too. This bug occur in September. Is it still present in > > asterisk 1.4.12.1. I also have asterisk 1.4.4 on a different box and > > there everything works like in 1.2.21. > > I need the old behaviour to have everything working flawlessly. > > > > Thanks > > > > Andrew > > > > > > _______________________________________________ > > --Bandwidth and Colocation Provided by api-digital.com-- > > > > asterisk-users mailing list > > To UNSUBSCRIBE or update options visit: > > lists.digium.com/mailman/listinfo/asterisk-users-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3239 bytes Desc: not available Url : lists.digium.com/pipermail/asterisk-users/attachments/20071227/af337366/attachment.bin
----- Original Message ----> From: Steve Murphy <murf at parsetree.com> > To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com> > Sent: Thursday, 27 December, 2007 5:44:01 PM > Subject: Re: [asterisk-users] CDR > > Greyman-- > > No real new functionality in 1.4, except a cdr.conf option that > lets >you> control whether you see one-channel cdrs. > > I haven't been working on CDR's the last few months in favor of other > projects that seem a little more urgent. Plus, I have some folks urging > me NOT to proceed until some architectural issues are discussed, which > might be wise. I have been working on one bug where I did make some > substantive changes to how the CDR's are generated, but it is almost > certain that these changes will only show up in trunk. > > I've reached the limit of what I can do in 1.4; it is simply impossible > to do anything with CDR's in 1.4 without tearing the very fabric > of >time> and space, and just plain getting everybody upset... at least, > those >who> were not erased from existence by the tear... on a more serious note, > the changes are intrusive enough, the behavior changes big enough, that > they really don't qualify to be applied to a current release. > > It's a huge job! My past work was just in the ZAP channel driver code, > and because it's so asynch, and all split up into different code, it's > really tough to get the right pieces in the right places at the right > time in the right way. > > What this all says is that I'm most likely NOT doing it the right way. > And what worries me most is that there might not be any "right" > way. >But> I'm still new to this, and will get back around to it hopefully fairly > soon. > > murfHi Steve, Thanks for the update. I agree it's complicated and looks like it does require a look at the design of Asterisk and where CDR's are generated. As you've already documented and lots of us have discovered generating a single CDR for each bridged call is not suitable when CDR's are used for billing and blind and attended transfers are taking place. For any SIP (can't speak for other channels but most likely the same) service providers running Asterisk that are not aware of this problem you will not be getting correct CDR's on blind and attended transfers. Also depending on your dial plan users may be able to send a 302 Redirect response (301 or 302) to an incoming call and get a free outgoing call. This has the potential to cost you money which is very dangerous if any of your users cotton on to it. The easiest way to check your susceptibility is to do call an expensive destination, blind transfer to a free destination and then check the CDRs and pay close attention to the call durations of each CDR. I'll go back to trying to find a way to detect and block dangerous REFER requests at the SIP Proxy before they get to Asterisk. Regards, Aaron Make the switch to the world's best email. Get the new Yahoo!7 Mail now. yahoo7.com.au/worldsbestemail
Grey Man wrote:> On a separate note does anyone know how to block transfers on a SIP > channel? I can block REFER requests from my SIP Proxy but I have to > support some transfers so that's not an option.I'd put the SIP devices in a separate context that doesn't include any [twkTWK] in the Dial application.