Given the following use case: A company runs multiple sub companies through a single SIP trunk. Some extensions or ranges of extensions are dedicated to specific sub companies. Incoming calls are prefixed depending on which sub company was called. Outgoing calls use the same prefixes to identify the user identity and will replace the extension. This can currently not be done in 3CX natively because SIP trunks miss the ability to rewrite the number scheme of both originating caller id and called destination id at the same time. This can currently only solved by using PSTN gateways like BeroNET which support such a feature. Of course, this only works as long as the gateway can be used. After switching to native SIP, such a configuration can apparently no longer be applied. I propose to add the following feature to the SIP trunk configuration: (http://3cx-ip:5000/#/app/trunk_editor/XX/formatting) For outgoing and incoming direction, modify the rewrite patterns from: Source Pattern | Replace Pattern to: Originating Caller ID Source Pattern | Orig. Caller ID Replace Pattern | Called Destination Src Pattern | Called Dest Replace Pattern That way we could implement the following number transforms for outgoing: Orig-CID Src | Orig-CID Repl | Dest CID Src | Dest CID Repl (.) | \1 | 1(.) | \1 <--  (.) | 01234-20 | 2(.) | \1 <--  : When user dials 10123456, removes prefix 1 and dials 0123456, identity of user unchanged : When user dials 20123456, removes prefix 2, dials 0123456, sending 01234-20 as user's identity For incoming, we would reverse the process and add a prefix to the calling id: Dest CID Src | Dest CID Repl | Orig-CID Src | Orig-CID Repl (01234-20) | 2\1 | (.) | \1 (.) | 1\1 | (.) | \1 Of course, it is important to run these rules in a specific order, so that more specific rules match first. It is sufficient if the user does this ordering manually. This could also replace the various multiple location where you currently would configure number rewrites, except here it is in one place and there's a relation between the calling id and the called id. It also has no functional downsides because you can still do the same at only minor less simplicity. But we had much more flexibility and functions now: You can rewrite source and destination at the same time depending on any combination of conditions in source and destination at the same time. Thanks.