[Serusers] Cleaning bad npdi=yes and rn=VALUE tags from INVITEs

[Frank Durda IV]

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!