First of all some clarifications:
- From and To have nothing to do with routing
- The requirement to not touch From and To has nothing to do with SER implementation, rather with standards
- The tags in From and To together with Call-Id form a dialog and is important for matching SIP messages in a transaction (ex. an INVITE - OK - ACK sequence) and a dialog (ex. later reINVITEs, BYE etc)
http://www.tech-invite.com/Ti-sip-abnf-hf.html#from [1]
Thus, in order to be RFC3261 compliant, you need to:
1. NOT touch the tags in From and To
2. NOT touch the remainder of From and To
If you break #1, you mess up transaction and dialog matching and pretty much everything breaks. If you break #2, you violate the requirement to be backwards compatible.
That being said, if ALL your UAs and gateways support and use RFC3261, changing From and To names/uris (while leaving tags) will probably work, but as all subsequent SIP related IETF documents and implementation try to be RFC3261 compliant, it is assumed that From and To are only changed two places:
a. In the UAs
b. In a B2BUA, i.e. a server that terminates a dialog with UA1 and creates another one with UA2 and thus is a go-between
New SEMS can be used for b.
So, regardless of using uac module or subst for replacing From/To, you will be MUCH better off if you follow the intentions of the RFCs, i.e. change the From/To in the UAs through the provisioning systems you use. Having lots of non-compliant SER installations is a recipe for trouble in the future.
RFC3323 does permit the display name and uri in the From header to be rewritten for privacy concerns providing the tag is maintained. So rewriting the From header to somthing like the following is acceptable for applications such as caller ID blocking.
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=873345996
That being said this technique for caller ID blocking presents problems with call detail record generation if you use From/To. With this form of caller ID blocking the CDR record shows the called number but the calling number is the word "anonymous". To get around this you can use the Remote-Party-ID headers with a display name of "anonymous" but a uri which preserves the original calling number. Many gateways support Remote-Party-ID, however there is a newer standard that will eventually take over: the header P-Asserted-Identity.
Thanks to Steve Blair for RFC3323 and use of anonymous@anonymous.invalid info.