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?
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?
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.