
I am working with a provider that wants to see PAI and not RPID, however we receive calls from a different provider that sends us RPID. Can I simply copy the RPID header into PAI so that all the necessary screen= and privacy= parameters are preserved when forwarding the call from the second provider to the first? Is there a better way of going about this? Thanks for your help. David

The best thing is to ignore RPID altogether and pretend it doesn?t exist. It?s a draft that expired like a decade and a half ago?despite some trigger-happy market adoption?and anyone who still insists on imbuing it with any sort of meaning is a poopie head. ? Sent from mobile, with due apologies for brevity and errors.
On Dec 20, 2021, at 7:49 PM, Zilk, David <David.Zilk at cdk.com> wrote:
? I am working with a provider that wants to see PAI and not RPID, however we receive calls from a different provider that sends us RPID. Can I simply copy the RPID header into PAI so that all the necessary screen= and privacy= parameters are preserved when forwarding the call from the second provider to the first?
Is there a better way of going about this?
Thanks for your help.
David _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

Best to use PAI across the board and convince your RPID loving carrier to change it to PAI. RPID is a failed outdated standard indeed as Alex just indicated (similar to 0.0.0.0 SDP hold method :) ) But if you have to, you can not map it one-to-one. RPID has all caller ID related info in one line including privacy indicator. While P-Asserted-Identity: only carries caller id name / number, and privacy is expected in a separate Privacy: header (with somewhat different set of values). So if you were to do it, you need to do some parsing of what you get in RPID and re-populate the info into two separate headers (PAI and Privacy) and do some mapping of the values along the way. This may or may not be implemented well in your equipment. On 2021-12-20 7:45 p.m., Zilk, David wrote:
I am working with a provider that wants to see PAI and not RPID, however we receive calls from a different provider that sends us RPID. Can I simply copy the RPID header into PAI so that all the necessary screen= and privacy= parameters are preserved when forwarding the call from the second provider to the first?
Is there a better way of going about this?
Thanks for your help.
David
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

I agree with the previous two respondents.?? RPID should have been dead a long time ago. PAI is supposed to be the new normal. In addition, you need to consider STIR / SHAKEN? if you are in the business of sending calls to the USA or Canada where the calling number purports to be from the USA or Canada.? STIR / SHAKEN is the laws.? Regulations in the USA and Canada require? the originating carrier must digitally sign and attest the validity of the calling number in the PAI header.? RPID is obsolete. Originating Carriers must be either signing calls, or engaging in other steps as they pursue the ability to sign.?? Additional scrutiny applies to International Gateways for calls to the USA. Evidently your correspondent is unaware of? SS requirements, or they wouldn't be talking about RPID.?? This is serious stuff. The FCC is handing out record level fines.? If you would like further discussion, please contact me directly John S. Robinson Communichanic Consultants, Inc. jsr at communichanic.com On 12/20/2021 18:45, Zilk, David wrote:
I am working with a provider that wants to see PAI and not RPID, however we receive calls from a different provider that sends us RPID. Can I simply copy the RPID header into PAI so that all the necessary screen= and privacy= parameters are preserved when forwarding the call from the second provider to the first?
Is there a better way of going about this?
Thanks for your help.
David
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (4)
-
abalashov@evaristesys.com
-
David.Zilk@cdk.com
-
jsr@communichanic.com
-
victor.chukalovskiy@gmail.com