How to force G.711 for ephone with virtual voice gateway

NOTE! This is the second, updated version of this post. Some minor bugs still exist, but easy to fix. I do not recommend to deploy this configuration on production routers, only if it is your last option.

The best cisco-breeders state: use G.711 for local calls and some narrowband codec (like G.729) for remote calls. That is clear. But what if you have a free voice recording software that supports only G.711 (cause G.729 requires licensing) behind your router with CUCME? By default IP Phone will negotiate G.729 to avoid transcoding and save router DSP resources. So we have to force transcoding manually. But it is not so simple as it sounds (that's valid for IOS 12.4 and I don't expect significant change in nearest future).
The problem is clarified in CUCME System Administrator Guide: "Transcoding is enabled only if an H.323 call with a different codec from the remote phone tries to make a call to the remote phone. If a local phone on the same Cisco Unified CME as the remote phone makes a call to remote phone, the local phone is forced to change its codec to G.729 instead of using transcoding". The same is valid for SIP. It seems to be unsupported. But that doesn't mean it is not possible. There is one mad feature that can be useful in some cases. That is tunnel interface with source and destination on the same router. Yes, it works. And we'll use it to force transcoding by hair-pinning SIP and RTP sessions. Lets examine simple lab topology:

Here is the basic config for CUCME1 with basic dial-peers (part of configuration omited):

hostname CUCME1
!
ip dhcp pool VOICE
network 192.168.208.0 255.255.255.0
default-router 192.168.208.1
option 150 ip 192.168.254.254
!
voice service voip
sip
bind all source interface Loopback0
!
voice class codec 10
codec preference 1 g729r8
codec preference 10 g711ulaw
codec preference 11 g711alaw
!
interface Loopback0
ip address 192.168.254.254 255.255.255.255
!
interface FastEthernet0/1
description lab network
no ip address
!
interface FastEthernet0/1.192
decription to CUCME2
encapsulation dot1Q 192
ip address 192.168.192.1 255.255.255.0
interface FastEthernet0/1.208
description VOICE VLAN
encapsulation dot1Q 208
ip address 192.168.208.1 255.255.255.0
!
telephony-service
no auto-reg-ephone
codec g711ulaw
max-ephones 42
max-dn 144
ip source-address 192.168.254.254 port 2000
cnf-file location flash:
cnf-file perphone
load 7962 SCCP42.8-4-2S.loads
time-zone 32
time-format 24
date-format dd-mm-yy
max-conferences 8 gain -6
transfer-system full-consult
create cnf-files version-stamp Jan 01 2002 00:00:00
!
!
ephone-dn 1 dual-line
number #0#101 secondary 101 no-reg primary
label 101
name 101
!
!
ephone-dn 2 dual-line
number #0#102 secondary 102 no-reg primary
label 102
name 102
!
!
ephone 1
device-security-mode none
description EPHONE101
mac-address 2893.FEA3.C06F
speed-dial 1 102 label "local-call"
speed-dial 2 201 label "remote-call"
type 7962
button 1:1
!
!
!
ephone 2
device-security-mode none
description EPHONE102
mac-address 2893.FEA3.B736
speed-dial 1 101 label "local-call"
speed-dial 2 201 label "remote-call"
type 7962
button 1:2
!
!
dial-peer voice 1 voip
description INBOUND
huntstop
preference 1
voice-class codec 10
session protocol sipv2
incoming called-number .
!
dial-peer voice 201 voip
description OUTBOUND
preference 1
destination-pattern 2..$
codec g729r8
session protocol sipv2
session target ipv4:192.168.192.2

CUCME2 configuration is very simple (in fact it is just a gateway):

hostname CUCME2
!
voice service voip
sip
bind all source-interface FastEthernet0/0.192
!
voice class codec 10
codec preference 2 g729r8
!
interface FastEthernet0/0
description lab network
no ip address
!
interface FastEthernet0/0.192
description to CUCME1
encapsulation dot1Q 192
ip address 192.168.192.2
!
ip route 0.0.0.0 0.0.0.0 192.168.192.1
!
dial-peer voice 201 pots
destination-pattern 201$
port 0/2/0
!
dial-peer voice 1 voip
description INBOUND
huntstop
preference 1
voice-class codec 10
session protocol sipv2
incoming called-number .
!
dial-peer voice 100 voip
description OUTBOUND
preference 1
destination-pattern 1..$
voice-class codec 10
session protocol sipv2
session target ipv4:192.168.254.254
!
voice-port 0/2/0
station-id name FXS-201
station-id number 201

Now if you make a call, you'll see that g.729 is selected (also preferred for ephones by default is G.711ulaw):

CUCME1#sh voice call summary
CUCME1#sh voice call summary
PORT           CODEC     VAD VTSP STATE            VPM STATE
============== ========= === ==================== ======================
0/1/0                                             *shutdown*
0/1/1                                             *shutdown*
0/2/0                                             *shutdown*
0/2/1                                             *shutdown*
50/0/1  .1       g729r8     y  S_CONNECT             EFXS_CONNECT
50/0/1  .2       -          -  -                     EFXS_ONHOOK
50/0/2  .1       -          -  -                     EFXS_INIT
50/0/2  .2       -          -  -                     EFXS_INIT

Lets change that! The main idea is simple - we need to direct traffic somewhere with G.711 only dial-peer (that invoke transcoder) and than receive it back. We can use another gateway, cross-connected voice ports. But what if we don't have any spare physical device or module? Then we can create a "virtual voice GW". Actually virtual voice GW doesn't exist, but we can imagine it like this:

First of all it is necessary to configure CUBE and transcoding on CUCME1:

voice service voip
allow-connections sip to sip
!
voice-card 0
dspfarm
dsp services dspfarm
!
dspfarm profile 1 transcode
description transcoding
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
maximum sessions 4
associate application SCCP
no shutdown
!
!
sccp local lo0
sccp ccm 192.168.254.254 identifier 1 version 4.1
sccp
!
sccp ccm group 1
description transcoding
bind interface lo0
associate ccm 1 priority 1
associate profile 1 register TRANSCODE
!
telephony-service
sdspfarm units 1
sdspfarm transcode sessions 4
sdspfarm tag 1 TRANSCODE

It feels good:

CUCME1#sh dspfarm profile 1
Dspfarm Profile Configuration

Profile ID = 1, Service = TRANSCODING, Resource ID = 1
Profile Description : transcoding
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 4
Number of Resource Available : 4
Codec Configuration
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60
Codec : g729r8, Maximum Packetization Period : 60

Now the time has come to configure our "virtual voice gateway". But first of all it necessary to understand that it doesn't really exist. In fact the router have to be configured to send SIP and RTP packets to some destination and then receive these packets back, but with another source and destination IP. To archive this goal we'll use vrf-lite, tunnel interfaces and NAT. The main idea is simple - use tunnel interfaces to move traffic to another vrf and then back translating source and destination IP somewhere on the way. Here is the sample configuration for CUCME1 (AUX vrf was created only to hide lo1 and lo2 from Global):

ip vrf TRANSCODE-1
rd 1:1
ip vrf TRANSCODE-2
rd 2:2
ip vrf AUX
rd 1000:1000
!
int lo1
ip vrf forwarding AUX
ip addr 1.1.1.1 255.255.255.255
!
int lo2
ip vrf forwarding AUX
ip addr 2.2.2.2 255.255.255.255
!
int tun101
tunnel vrf AUX
tunnel so lo1
tunnel de 2.2.2.2
ip address 192.168.10.1 255.255.255.252
tunnel key 1
!
int tun102
tunnel vrf AUX
ip vrf forwarding TRANSCODE-1
tunnel source lo2
tunnel de 1.1.1.1
ip address 192.168.10.2 255.255.255.252
tunnel key 1
ip nat inside
!
int tun201
tunnel vrf AUX
tunnel so lo1
tunnel de 2.2.2.2
ip address 192.168.20.1 255.255.255.252
tunnel key 2
!
int tunnel 202
tunnel vrf AUX
ip vrf forwarding TRANSCODE-2
tunnel so lo2
tunnel de 1.1.1.1
ip address 192.168.20.2 255.255.255.252
tunnel key 2
ip nat inside
!
int tunnel 301
tunnel vrf AUX
ip vrf forwarding TRANSCODE-1
tunnel so lo1
tunnel de 2.2.2.2
ip address 192.168.30.1 255.255.255.252
tunnel key 3
ip nat outside
!
int tunnel 302
tunnel vrf AUX
ip vrf forwarding TRANSCODE-2
tunnel so lo2
tunnel de 1.1.1.1
ip address 192.168.30.2 255.255.255.252
tunnel key 3
ip nat outside
!
ip nat inside source static 192.168.254.254 192.168.168.169 vrf TRANSCODE-1 no-payload match-in-vrf
ip nat inside source static 192.168.254.254 192.168.168.168 vrf TRANSCODE-2 no-payload match-in-vrf
!
ip route 192.168.168.168 255.255.255.255 192.168.10.2
ip route 192.168.168.169 255.255.255.255 192.168.20.2
!
ip route vrf TRANSCODE-1 192.168.168.168 255.255.255.255 192.168.30.2
ip route vrf TRANSCODE-2 192.168.168.169 255.255.255.255 192.168.30.1
ip route vrf TRANSCODE-1 0.0.0.0 0.0.0.0 192.168.10.1
ip route vrf TRANSCODE-2 0.0.0.0 0.0.0.0 192.168.20.1

The first question is, why we have to use "no-payload"? The reason is simple, I don't know any way to make SIP ALG work correctly for this configuration (various IOS releases was tested). If it still exists, configuration can be greatly simplified.
The next step is to route calls to "virtual GW" IP - 192.168.168.168. We'll use translation-profiles to route calls correctly. As you can see in CUCME1 base configuration I've already configured #0# prefixes for ephones. We'll use #0# prefix to force transcoding for incoming and #1# for outgoing calls:

voice translation-rule 10
rule 10 /^.*$/ /#0#&/
!
voice translation-profile TRANSCODE-INCOMING
translate called 10
!
voice translation-rule 20
rule 5 /^1..$/ /&/
rule 10 /^.*$/ /#1#&/
!
voice translation-rule 30
rule 10 /^#0#/ //
!
voice translation-profile TRANSCODE-OUTGOING
translate called 20
translate calling 30
!
voice translation-rule 40
rule 10 /^#1#/ //
!
voice translation-profile TRANSODE-OUTGOING-REMOVE-PREFIX
translate called 40
!
ephone-dn 1 dual-line
preference 9
translation-profile incoming TRANSCODE-OUTGOING
ephone-dn 2 dual-line
preference 9
translation-profile incoming TRANSCODE-OUTGOING
!
dial-peer voice 101 voip
description force transcoding for incoming calls
preference 1
destination-pattern 101$
codec g711u
session protocol sipv2
session target ipv4:192.168.168.168
translation-profile outgoing TRANSCODE-INCOMING
!
dial-peer voice 102 voip
description force transcoding for incoming calls
preference 1
destination-pattern 102$
codec g711u
session protocol sipv2
session target ipv4:192.168.168.168
translation-profile outgoing TRANSCODE-INCOMING
!
dial-peer voice 20 voip
description force transcoding for outgoing calls
preference 1
destination-pattern #1#2..
codec g711u
session protocol sipv2
session target ipv4:192.168.168.168
translation-profile outgoing TRANSODE-OUTGOING-REMOVE-PREFIX

IMPORTANT! Now you can place calls in both directions. But if you take a look at sip debug and show output, you'll find that RTP sessions flow from loopback0 to loopback0. Actually it is just a hairpin. Debug ccsip errors always logs "Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL", but it works. If you want, you can remove all VRFs and tunnels and just point dial-peers 101, 102 and 20 to loopback0 address (192.168.254.254). I'm not sure, that it is not a bug. So just to rely on "have-to-work" features, I made up configuration with VRFs. Yes, this configuration is unsupported, it can stop working from release to release, but if it doesn't work - it's a bug, not the opposite.
The reason for hairpin is simple - there is no ALG. We'll configure SIP ALG emulation with sip-profiles to force correct RTP flow direction. Some useful links: Understanding SIP ALGs and NAT, RFC 3261 and sip debug. Furthermore, we have to configure additional inbound dial-peers for looped calls.

voice class sip-profiles 100
request ANY sip-header To modify "192.168.168.168" "192.168.254.254"
request ANY sip-header From modify "192.168.254.254" "192.168.168.169"
request ANY sip-header Call-ID modify "192.168.254.254" "192.168.168.169"
request ANY sip-header Via modify "192.168.254.254" "192.168.168.169"
request ANY sip-header SIP-Req-URI modify "192.168.168.168" "192.168.254.254"
request ANY sip-header Contact modify "192.168.254.254" "192.168.168.169"
request ANY sip-header Remote-Party-ID modify "192.168.254.254" "192.168.168.169"
response ANY sip-header To modify "192.168.254.254" "192.168.168.169"
response ANY sip-header From modify "192.168.168.168" "192.168.254.254"
response ANY sip-header Call-ID modify "192.168.254.254" "192.168.168.169"
response ANY sip-header Via modify "192.168.168.168" "192.168.254.254"
response ANY sip-header Contact modify "192.168.254.254" "192.168.168.169"
response ANY sip-header Remote-Party-ID modify "192.168.254.254" "192.168.168.169"
request ANY sdp-header Audio-Connection-Info modify "192.168.254.254" "192.168.168.169"
request ANY sdp-header Session-Owner modify "192.168.254.254" "192.168.168.169"
request ANY sdp-header Connection-Info modify "192.168.254.254" "192.168.168.169"
response ANY sdp-header Connection-Info modify "192.168.254.254" "192.168.168.169"
response ANY sdp-header Audio-Connection-Info modify "192.168.254.254" "192.168.168.169"
response ANY sdp-header Session-Owner modify "192.168.254.254" "192.168.168.169"
voice class sip-profiles 200
response ANY sip-header To modify "192.168.254.254" "192.168.168.168"
response ANY sip-header From modify "192.168.168.169" "192.168.254.254"
response ANY sip-header Via modify "192.168.168.169" "192.168.254.254"
response ANY sip-header Contact modify "192.168.254.254" "192.168.168.168"
response ANY sip-header Call-ID modify "192.168.168.169" "192.168.254.254"
response ANY sip-header Remote-Party-ID modify "192.168.254.254" "192.168.168.168"
request ANY sip-header To modify "192.168.168.169" "192.168.254.254"
request ANY sip-header From modify "192.168.254.254" "192.168.168.168"
request ANY sip-header Via modify "192.168.254.254" "192.168.168.168"
request ANY sip-header Contact modify "192.168.254.254" "192.168.168.168"
request ANY sip-header Call-ID modify "192.168.168.169" "192.168.254.254"
request ANY sip-header Remote-Party-ID modify "192.168.254.254" "192.168.168.168"
response ANY sdp-header Connection-Info modify "192.168.254.254" "192.168.168.168"
response ANY sdp-header Audio-Connection-Info modify "192.168.254.254" "192.168.168.168"
response ANY sdp-header Session-Owner modify "192.168.254.254" "192.168.168.168"
request ANY sdp-header Connection-Info modify "192.168.254.254" "192.168.168.168"
request ANY sdp-header Audio-Connection-Info modify "192.168.254.254" "192.168.168.168"
request ANY sdp-header Session-Owner modify "192.168.254.254" "192.168.168.168"
!
dial-peer voice 20 voip
voice-class sip profiles 100
dial-peer voice 101 voip
voice-class sip profiles 100
dial-peer voice 102 voip
voice-class sip profiles 100
!
dial-peer voice 2 voip
permission orig
description INBOUND2
huntstop
preference 1
voice-class codec 10
voice-class sip profiles 200
session protocol sipv2
incoming called-number #0#...
dial-peer voice 3 voip
permission orig
description INBOUND3
huntstop
preference 1
voice-class codec 10
voice-class sip profiles 200
session protocol sipv2
incoming called-number 2..

Now turn on debug and place a test call.
First INVITE from CUCME2 to CUCME1, called number 101, proposed codec is g729, CUCME1 sends TRYING:

CUCME1#debug ccsip messages
SIP Call messages tracing is enabled
CUCME1#
Nov 19 09:15:33.208: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:101@192.168.254.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.192.2:5060;branch=z9hG4bK12B2009
Remote-Party-ID: "FXS-201" ;party=calling;screen=no;privacy=off
From: "FXS-201" ;tag=5D830560-11D1
To:
Date: Fri, 19 Nov 2010 10:52:49 GMT
Call-ID: FC37D492-F30111DF-82DDE011-8C262CA1@192.168.192.2
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 4231397249-4076933599-2195251217-2351312033
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1290163969
Contact:
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 241

v=0
o=CiscoSystemsSIP-GW-UserAgent 7336 4090 IN IP4 192.168.192.2
s=SIP Call
c=IN IP4 192.168.192.2
t=0 0
m=audio 17230 RTP/AVP 18 19
c=IN IP4 192.168.192.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:19 CN/8000
a=ptime:20

Nov 19 09:15:33.248: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Date: Fri, 19 Nov 2010 09:15:33 GMT
From: "FXS-201" ;tag=5D830560-11D1
Allow-Events: telephone-event
Timestamp: 1290163969
Content-Length: 0
To:
Call-ID: FC37D492-F30111DF-82DDE011-8C262CA1@192.168.192.2
Via: SIP/2.0/UDP 192.168.192.2:5060;branch=z9hG4bK12B2009
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE

Then outbound dial-peer pointing to voice loop is matched, called number is modified by translation-profile. CUCME1 sends SIP INVITE (modified by sip-profile) to CUCME1 (but it thinks that it is another voice gateway), called party #0#101, proposed codec g.711ulaw:

Nov 19 09:15:33.236: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:%230%23101@192.168.254.254:5060 SIP/2.0
Date: Fri, 19 Nov 2010 09:15:33 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
From: "FXS-201" ;tag=823874-240E
Allow-Events: telephone-event
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Remote-Party-ID: "FXS-201" ;party=calling;screen=no;privacy=off
Cisco-Guid: 4231397249-4076933599-2195251217-2351312033
Timestamp: 1290158133
Content-Length: 224
User-Agent: Cisco-SIPGateway/IOS-12.x
To:
Contact:
Expires: 180
Content-Disposition: session;handling=required
Content-Type: application/sdp
Call-ID: 65721D38-F2F411DF-807DF116-36B64920@192.168.168.169
Via: SIP/2.0/TCP 192.168.168.169:5060;branch=z9hG4bK211502
CSeq: 101 INVITE
Max-Forwards: 69

v=0
o=CiscoSystemsSIP-GW-UserAgent 9271 4622 IN IP4 192.168.168.169
s=SIP Call
c=IN IP4 192.168.168.169
t=0 0
m=audio 17214 RTP/AVP 0 19
c=IN IP4 192.168.168.169
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20

And then CUCME1 receives translated request back:

Nov 19 09:15:33.248: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:%230%23101@192.168.254.254:5060 SIP/2.0
Date: Fri, 19 Nov 2010 09:15:33 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
From: "FXS-201" ;tag=823874-240E
Allow-Events: telephone-event
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Remote-Party-ID: "FXS-201" ;party=calling;screen=no;privacy=off
Cisco-Guid: 4231397249-4076933599-2195251217-2351312033
Timestamp: 1290158133
Content-Length: 224
User-Agent: Cisco-SIPGateway/IOS-12.x
To:
Contact:
Expires: 180
Content-Disposition: session;handling=required
Content-Type: application/sdp
Call-ID: 65721D38-F2F411DF-807DF116-36B64920@192.168.168.169
Via: SIP/2.0/TCP 192.168.168.169:5060;branch=z9hG4bK211502
CSeq: 101 INVITE
Max-Forwards: 69

v=0
o=CiscoSystemsSIP-GW-UserAgent 9271 4622 IN IP4 192.168.168.169
s=SIP Call
c=IN IP4 192.168.168.169
t=0 0
m=audio 17214 RTP/AVP 0 19
c=IN IP4 192.168.168.169
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20

After successful call setup we can see, that CUCME1 use g.711 for efxs and transcoding works correctly:

CUCME1#sh voice call summary
PORT           CODEC     VAD VTSP STATE            VPM STATE
============== ========= === ==================== ======================
0/1/0                                             *shutdown*
0/1/1                                             *shutdown*
0/2/0                                             *shutdown*
0/2/1                                             *shutdown*
50/0/1  .1       g711ulaw   y  S_CONNECT             EFXS_CONNECT
50/0/1  .2       -          -  -                     EFXS_ONHOOK
50/0/2  .1       -          -  -                     EFXS_INIT
50/0/2  .2       -          -  -                     EFXS_INIT
CUCME1#
CUCME1#sh voip rtp connections
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 54 55 18860 17230 192.168.254.254 192.168.192.2
2 55 54 17214 19022 192.168.254.254 192.168.168.168
3 56 57 19022 17214 192.168.254.254 192.168.168.169
4 58 59 18598 2000 192.168.254.254 192.168.254.254
5 60 59 19070 2000 192.168.254.254 192.168.254.254
Found 5 active RTP connections

CUCME1#sh sdspfarm sessions active
Stream-ID:1 mtp:1 192.168.254.254 18598 Local:2000 START
usage: Ip-Ip
codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:2

Stream-ID:2 mtp:1 192.168.254.254 19070 Local:2000 START
usage: Ip-Ip
codec:G729 duration:20 vad:0 peer Stream-ID:1


CUCME1#sh ip nat translations vrf TRANSCODE-1
Pro Inside global Inside local Outside local Outside global
tcp 192.168.168.169:5060 192.168.254.254:5060 192.168.168.168:30762 192.168.168.168:30762
tcp 192.168.168.169:11479 192.168.254.254:11479 192.168.168.168:5060 192.168.168.168:5060
udp 192.168.168.169:17214 192.168.254.254:17214 192.168.168.168:19022 192.168.168.168:19022
udp 192.168.168.169:17215 192.168.254.254:17215 192.168.168.168:19023 192.168.168.168:19023
--- 192.168.168.169 192.168.254.254 --- ---
CUCME1#sh ip nat translations vrf TRANSCODE-2
Pro Inside global Inside local Outside local Outside global
tcp 192.168.168.168:5060 192.168.254.254:5060 192.168.168.169:11479 192.168.168.169:11479
udp 192.168.168.168:19022 192.168.254.254:19022 192.168.168.169:17214 192.168.168.169:17214
udp 192.168.168.168:19023 192.168.254.254:19023 192.168.168.169:17215 192.168.168.169:17215
tcp 192.168.168.168:30762 192.168.254.254:30762 192.168.168.169:5060 192.168.168.169:5060
--- 192.168.168.168 192.168.254.254 --- ---

IOS compatibility list (platform - c2811):
advipservicesk9-mz.124-15.T8 - sip-profiles not supported; hairpin is possible
advipservicesk9-mz.124-22.T - works correctly; hairpin not tested
advipservicesk9-mz.124-24.T2.bin - correct setup, but no audio; hairpin is possible
advipservicesk9-mz.124-24.T3 - problem with NAT; hairpin not tested
adventerprisek9_ivs-mz.124-24.T4 - problem with NAT; hairpin not tested
advipservicesk9-mz.150-1.XA - call blocked; hairpin not tested

Additional notes:
1) Some problems can arise with # sign parsing in SIP network. You can use some other prefixes without # to avoid this problems, or you can hide # with sip-profiles and translation-profiles.
2) Local GRE with NAT can be useful not only for voice.
3) Only base call setup was tested.

Special thanks to Anton Zyablov for the assumption that "local" GRE can work.

Here is a post about Oreka voice recording server configuration.

If you'll notice some bugs, test other IOS release, etc. - please add a comment.
And if you know another, not so complex solution, it would be nice to share.