[asterisk-users] SIP devide call-forward behaviour and CDRs

[Steve Davies]

On 15 April 2010 18:11, Steve Davies <davies147 at gmail.com> 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/1234 at context call, which has its own CDR.
>
> In 1.2, the CDR records look something like:
>
>    1) channel=SIP/100    dstchannel=Local/1234 at context-deadbeef,1
>    2) channel=Local/1234 at 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/1234 at 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/1234 at 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