we get three different phone numbers from one provider.
Phone system works good but we have a problem with CDR records.
The value inside channel field in CDR CSV file is same for calls coming in three numbers.
Say we have numbers:
2333333
2444444
2555555
For calls coming on those three numbers the value inside channel field is something like SIP/2333333-00024c09
We have reporting system which is not working correctly because of this.
How can we solve the problem?
Why is this field incorrectly populated?
To stand a chance of having these associated with the “correct” trunk, you need to upgrade to chan_pjsip and enable the line option, although the provider isn’t guaranteed to honour this.
chan_sip will match on IP address and incoming traffic will be associated with the first matching peer in its search order (which, because of hashing, might not be the first in the configuration).
Line causes a line=xxx parameter to be added to the Contact URI. If the provider implements SIP correctly and returns the parameters, as well as user@domain, this will be used to match incoming calls to the correct endpoint, and, therefore, trunk.
If the DID is the only thing that differs, you need to add that to the CDR, possibly as some sort of custom field. You cannot fake the channel name in the CDR, to reflect the DID.
Many thanks for your answers. Previosly this configuration worked correctly. We had correct values in the Channel filed. Our reporting system was based on that. As we can judge something was changed on providers side, but he says, everything is ok. From our side nothing changed. What could the change be and how can we prove that to the provider and correct the problem?
Sure, the DID value is different, even in CDR Web log, but in the CDR CSV file the fileld is absent. How can we add it in the CDR CSV file? Cause we use the CSV file to upload to reporting system.
You would have to use a custom file. There is also a custom field, in the standard format, but I’m not sure whether FreePBX is already using that for something.
I’m not sure why it worked before; you would need to look at INVITEs from the two providers. The only thing I can think of is that the first one put the trunk name in their From user field, but that would be very unusual. Normally the caller ID goes there.
I’m assuming that, in the before case, they were still all at the same address. The problem only arises if you have multiple trunks with the same IP address.