I have a client who occasionally sends calls where there is a npdi=yes tag (and there may or may not be a rn=VALUE tag present with it), BUT the answer these two tags are providing is wrong! That is, the number in question has or hasn't been ported, but the information provided in the INVITE message doesn't match reality. Either a rn=VALUE should have had value X and it instead has value Y, OR there is no rn=VALUE at all, and there should have been one, OR the number hasn't actually been ported, and no rn=VALUE should have been sent at all but we got a junk one, that probably isn't the right LRN for the true destination of the call. Because of these wrong npdi=yes tags, our PSTN gateway switch ends up failing these incorrectly-marked call, because it takes the provided rn=VALUE or lack of one to be correct and so it doesn't do its own LNP query, and the one provided in the SIP INVITE is sometimes just flat out wrong. If the PSTN gateway switch had ignored these suspect npdi=yes and rn=VALUE tages and simply done the LNP query itself, in virtually all cases these otherwise doomed calls would have completed successfully. For this particular customer, the problem of bogus values appears to be a permanent artifact. They either don't know how to fix it, or don't think it is important, of they are spoofing it to avoid being billed for LNP queries. Whatever the reason, it causes trouble tickets. So, we would like to have SER strip the npdi=yes and any rn=VALUE tags from the INVITE when it is this customer (known by src ip), so that the PSTN switch will do the LNP query itself on the SS7 side and get the call routing right. (We have already determined that getting the outfit that is sending the junk to do the right thing isn't going to happen any time soon.) Does anybody have any suggestions as how to write the ser.cfg code to edit-out a npdi=yes and rn=VALUE if they are present in INVITEs? We just want to always throw npdi=yes and any rn=VALUE that shows up if the call is coming from this given customer, basically treating all npdi=yes and rn= tags coming from this customer as being untrustworthy. There has to be an easier way than stripping the thing down and reassembling a new one with repeated strip(1) type operations, which looks to be extremely inefficient for this task and probably really meant only for stripping country codes and such off the phone numbers, not for cleaning up bad tags. Thanks, in advance!