The issue with one way audio was easier to figure out after setting up a packet capture.  The captured showed that the carrier was seeing the outbound audio RTP stream as coming from the IP of the loopback0 address and not the public ip of the WAN interface.  You will remember that we statically NATed the public IP of the GiG0/0/0 interface to the loopback0, which fixed sip messages, but breaks on audio.   I think we will now see if we can get a trunk from the carrier and reconfigure around a subinterface strategy and see how that works! At the end of the day, SIP and NAT just do not work will together!  ... View more

Yes, using extended ping shows no connectivity issues between devices.  The configuration looks like this. PSTN_IP=>(G0/0=>STATIC-NAT L0=>G0/1)=>LAN Internet_IP=>(G0/0=>NAT Overload =>G0/1)=>LAN Again SIP messages are exchanged in both directions; Audio is NOT heard by Caller but Inside Device hears Caller. No firewall is involved.  The SIP Trunk from CUCM is pointing at G0/1.  If I change it to point at L0, SIP breaks, so it is currently pointing at G0/1. ... View more

Kevin (and interest others) - I spoke to soon! (play on words?).  So moving sip to the loopback had the effect of enabling internet access and SIP to work.  There is however a major issue - ONE WAY AUDIO.   I have tried all combinations of NAT or NO NAT but I cant get the audio working from INSIDE to OUTSIDE.   So an inbound call, does NOT hear audio, but the caller hears the INSIDE person!    The running configuration, along with debug ccsip messages and ccapi inout and - as an additional bonus - output of the show voip rtp connections is also in the file. Anybody have  an idea, I am game to try it! ... View more

Kevin your config was exactly the same as ours.  Ultimately the solution was to use a new public ip to NAT Internet traffic on Gig interface and move the sip traffic  and public ip via static NAT to loopback0.  Given the amount of time wasted on this unsported configuration (NAT in CUBE) we will now make this a standard practice in these config issues. - DrVoIP.com ... View more

The NAT policy was the correct strategy however, we ran into an issue making it work.  We ultimately contacted TAC and received the following:  The problem details you have provided suggests that you have run into a known limitation with configuring an IOS-XE based router with a single IP address being used for both SIP and NAT. An enhancement request has been opened to provide this functionality, but it has not yet been implemented. See:   CSCuy82008    Support NAT and UC (CUBE) on same ASR1k                                             You may be able to workaround the issue as documented in the link above, by first removing all NAT configuration, reloading the router, and configuring SIP first. I have seen this workaround unsuccessful at times or the issue return after reloading the router. So, it is not a viable workaround in some circumstances.   I would instead recommend to configuring an additional interface, either a physical or a loopback, with a different public IP address than what is used for NAT . Thanks for you recommendation as it was correct.   I hope we all learned something here!  Regards, - DrVoIP ... View more

Configuration deleted to protect client privacy.  ... View more

https://youtu.be/j7jFLy2bRrA  this is a youtube video on a script we wrote using the strategy that @djlunberg seems to suggest.     ... View more