On 1/29/08, Richard Revels <[EMAIL PROTECTED]> wrote: > It's not Asterisk, it's SIP. Transfer takes the signaling off the > Asterisk box. > > In features.conf, replace blind transfer with a call to a macro. Then > redo your dialplan with the 'g' option on inward dial commands. When > the called party uses the transfer command, your macro should read the > digits to call and then store them in the db, a unique global, or GROUP > () variable. Then it should hang up. This will cause the calling leg > to exit the dial command to the next priority which should be a check > of the variable. If digits are present, use the dial command to call > them at your provider. No fuss, no muss. > > You should make sure the peer entry for the outbound side includes > canreinvite=yes so only the signaling remains on your box and the > media is invited off. > > You should also ignore calls to your macro that hit from the inbound > call leg. Just return immediately and neither side will ever know the > inbound call leg left for a moment. > > Sent from my iPhone > > On Jan 28, 2008, at 11:56 PM, Grey Man <[EMAIL PROTECTED]> wrote: > > > Hi All, > > > > PLEASE READ if you depend on Asterisk CDR's and support transfers. > > > > Apologies for the shout but I'm desperate to get others to agree > > Asterisk has a > > big problem with the CDR's that are generated for transfers. I can > > understand > > why not too many people are interested as transfers are complicated > > and > > messy. However for those of us having to support transfers and > > depending on > > Asterisk CDR's for our billing we are in a sticky predicament! For > > anyone > > using Asterisk in a provider environment unaware of any problem I > > urge you to > > do a simple blind transfer on your system and check your CDR's. Most > > Asterisk > > based providers I tested are blocking transfers but I did find some > > other > > providers out there missing billable call legs! > > > > My goal is to try and get acknowledgement that there is a serious > > problem > > here that warrants a re-think about how Asterisk CDR's are generated. > > > > In an effort to succinctly encapsulate the problem I've produced the > > call and CDR > > flows below. Hopefully they make sense but if not I'm more than > > happy to elaborate > > and share my test results (the flows below won't be legibile without > > a mono spaced > > font, copy and pasting into notepad will make them readable). > > > > Blind Transfer (1.2 and 1.4): > > > > Time Calls CDRs > > | Dest | Dur(s) | > > |-------|--------| > > T0 -| Alice --> * --> Bob | | | > > | | | | > > Tt -| Carol <-- * --> Bob -| Bob | Tt | > > | | | | > > Te -| End -| Carol | Te | > > > > > > Attended Transfer (1.2): > > > > Time Calls CDRs > > | Dest | Dur(s) | > > |-------|--------| > > T0 -| Alice --> * --> Bob | | | > > | | | | > > T1 -| Alice --> * --> Carol | | | > > | | | | > > Tt -| Carol <-- * --> Bob -| Bob | Tt | > > | | Carol | Tt - T1| > > | | s | Tt | > > | | | | > > Te -| End -| s | Te | > > > > > > Attended Transfer (1.4): > > > > Time Calls CDRs > > | Dest | Dur(s) | > > |-------|--------| > > T0 -| Alice --> * --> Bob | | | > > | | | | > > T1 -| Alice --> * --> Carol | | | > > | | | | > > Tt -| Carol <-- * --> Bob -| | | > > | | | | > > Te -| End -| Bob | Te | > > | Bob | Te - T1| > > > > To put it another way here are some examples of how Asterisk systems > > and > > transfers can be exploited. > > > > 1. Place a call to a mobile you plan on having a lengthy call to. As > > soon as the > > call is establised blind transfer it to a low or free cost > > destination. You will > > only be billed for the mobile call up to the time it takes you to do > > the transfer > > the remainder of the call will be billed at the low cost or free > > destination. > > > > 2. With Asterisk 1.4 place a call to two billable destinations and > > then transfer > > them together. You'll only be billed for each destination up until > > the time it takes > > you to transfer. > > > > 3. With Asterisk 1.2 place a call to a low cost or free destination. > > Then place a > > call to an expensive destination and do an attended transfer. You'll > > only be > > billed for the expensive destination up unitl the time it takes to > > do the transfer. > > > > I have opened a bug on the issue but I suspect without input from > > others having > > the same problem it will fade away. > > http://bugs.digium.com/view.php?id=11849 > > > > From my point of view the design solution to this problem would be > > as simple > > as changing the CDR generation from one CDR per bridge to generating > > a CDR > > for each end of a bridge. When the end of a bridge changes or the > > bridge is > > hungup a CDR(s) would be generated. The implementation would > > undoubtedly be a lot more difficult but if the design could be > > agreed upon at > > least those of us in between a rock and a hard place on this could > > decide > > to sponsor development, offer a bounty etc. > > > > Regards, > > > > Greyman.
Isn't this what's accountcode is for? You just need to set it in beginning (or have it automatically set from SIP users) and all CDR records will have the same accountcode - so correct user will get billed. Regards, Atis -- Atis Lezdins VoIP Developer, IQ Labs Inc. [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Work phone: +1 800 7502835 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
