On 15 April 2010 18:11, Steve Davies <[email protected]> wrote: > Hi, > > I am migrating some billing code from 1.2 to 1.6 cdr output. Mostly > this is not too bad, but I have a scenario where some data appears to > be "lost" > > Call from SIP/100 to SIP/200, but the SIP/200 device is programmed to > send a redirect to extension 1234. chan_sip creates a > Local/1...@context call, which has its own CDR. > > In 1.2, the CDR records look something like: > > 1) channel=SIP/100 dstchannel=Local/1...@context-deadbeef,1 > 2) channel=Local/1...@context-deadbeef,2 dstchannel=DAHDI/1-1 > > This allowed the 2 Local/... values to be matched and the 2 legs of > the call can be correctly billed. > > In 1.6, the CDR data is different: > > 1) channel=SIP/100 dstchannel=DAHDI/1-1 > 2) channel=Local/1...@context-deadbeef;2 dstchannel=DAHDI/1-1 > > and we lose the ";1" half of the local channel pair and the data is > virtually useless :( Is this an intentional change, and can I put it > back somehow? I am wondering if I need to add "/n" to the channel > string that is built by chan_sip so that the bridge does not destroy > the local channel? > > Thanks, > Steve
Following up to my own post... Sorry. I also notice that if I Dial(Local/1...@context) in the dialplan, I still get the old style (correct) data whether I use /n on the local channel or not. The only difference I can see is the SIP call_forward request to emulate a SIP "hairpin". I thought this call forward mechanism basically destroyed the original call and replaced it - I am not sure how or why that would affect the cdr of the original inbound call? Regards, Steve -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
