Call Accounting w/ Translation Profile

[srpm]

I recently started playing with call accounting on a voice gateway.  When I opened the CSV file today to look at yesterday's calls I noticed that a number passing through a dial-peer did not have the translation profile reflected in the call accounting file.  For example, the outgoing pots dial peer has a destination pattern of 86T and a translation profile that has a rule of /^86/ /0/

In the call accounting file I see one record with the number of 8622xxxxxx.  I then see the next record of just 22xxxxxx.  Technically everything worked as it should because the call lasted 20+ minutes.  But I would just like to understand the mechnanics going on with the call accounting.  I would expect the 2nd record in the call-accounting file to reflect 022xxxxx, but it wasn't.

Anybody have any idea what's happening behind the scenes?

[srpm]

Anybody have any input on this?

[Brian Meade]

It sounds like the data is reflecting the default digit-strip behavior of the dial-peer and ignoring the translation-profile configuration.  That may be the expected behavior.  I believe outgoing translation-profile matching is done after digit-strip so it might be that the translation-profile isn't being hit at all.  Did you confirm the calls are indeed prefixing the 0?

[srpm]

The 0 is being prefixed as the call would fail without the leading 0.

[Brian Meade]

Further research looks like digit-strip is done after outgoing translation-profile is applied so that's why the 0 is still being added.