P-Charge-Info for redirections is provided by the inbound SBC. This is not the best solution, ideally the P-Charge-Info on redirection should be provided e.g. in the 302 and re-used.
Actually: depending on business policies this can be arguable.
If an account is present in the local number record it may not be the same as the one present in the global number record. (For example because of authorization issues.)
However, generally speaking, the account that is being charged for the incoming call is the one that is present in the global number record (since that's the one used to generate the inbound CDR).
On the other hand there can be security issues e.g. if a client-side SBC is opened to the public. In this case we still need to be able to provide an account number for redirection, and the only place to provide one securily is to use the local number record. (We had a similar issue when giving voicemail the capability to dial outbound calls.)
Alternatively (if the 302 solution doesn't work -- I don't see how it would, how would we tell FreeSwitch to get the P-Charge-Info from the 302 and insert it into the new INVITE? What if the 302 isn't generated by the proxy, but by the customer, who would then be able to override the P-Charge-Info?)... the solution would be to run the call through a redirection server. (The original called-number is used to call the redirection server.) The redirection server does the lookup and inserts the P-Charge-Info.
This might also solve the issue of multiple redirections, where the audio path might not be easy to track (e.g. upstream-to-upstream redirections).
All-in-all, the fact of relying on data provided outside the client-side to charge a call breaks the Architectural model of independent carrier-side and client-side and needs to be fixed.
P-Charge-Infofor redirections is provided by the inbound SBC. This is not the best solution, ideally theP-Charge-Infoon redirection should be provided e.g. in the302and re-used. Actually: depending on business policies this can be arguable. If an account is present in the local number record it may not be the same as the one present in the global number record. (For example because of authorization issues.) However, generally speaking, the account that is being charged for the incoming call is the one that is present in the global number record (since that's the one used to generate the inbound CDR). On the other hand there can be security issues e.g. if a client-side SBC is opened to the public. In this case we still need to be able to provide an account number for redirection, and the only place to provide one securily is to use the local number record. (We had a similar issue when giving voicemail the capability to dial outbound calls.) Alternatively (if the302solution doesn't work -- I don't see how it would, how would we tell FreeSwitch to get theP-Charge-Infofrom the302and insert it into the new INVITE? What if the302isn't generated by the proxy, but by the customer, who would then be able to override theP-Charge-Info?)... the solution would be to run the call through a redirection server. (The original called-number is used to call the redirection server.) The redirection server does the lookup and inserts theP-Charge-Info. This might also solve the issue of multiple redirections, where the audio path might not be easy to track (e.g. upstream-to-upstream redirections).All-in-all, the fact of relying on data provided outside the client-side to charge a call breaks the Architectural model of independent carrier-side and client-side and needs to be fixed.