Actually, in regards to:
"I can't use translation patterns for prefix called number and after that strip digits on pots dial-peer, because this translation is visible for subscribers."
I know what you ran into and you can accomodate this on the dial-peers. I had a similar requirement a while back and I handled it by prefixing a 3-digit access code (my own convention) on the called party number before handing it off to the gateway. Then I used a combination of forward-digits and called-party translations to give the PSTN what they wanted and also mask the pattern on the IP phone display. My scenario isn't exactly the same as yours, but maybe it will give you some ideas.
voice translation-rule 30
rule 1 /^101/ //
rule 2 /^102/ //
!
voice translation-profile normal-called-translate
translate called 30
!
dial-peer voice 91010 pots
destination-pattern 101.T !the 101 will get stripped
translation-profile outgoing normal-called-translate !this will "hide" the 101 from your IP phone display
!
dial-peer voice 91020 pots
destination-pattern 102.T
translation-profile outgoing normal-called-translate !this will "hide" the 101 from your IP phone display
!
The only problem is that none of the above triggers on "called party" information and you would have to do something on the CUCM. I suppose you could do something on the ingress side of the call signal received by the gateway. With the CUCM one approach would be to use a Standard Local Route Group (SLRG) config. But this is only viable if the 1111 and 2222 in your example are on two separate phones. If both lines are on the same phone then SLRG won't help and you would have to use line level CSS and translation/route patterns to have the same destination pattern do different called party transforms. Not incredibly scalable.
Anyway, some additional food for thought.
HTH.
Regards,
Bill
