Re: [SR-Users] How to connect two legs of a call

IP address scarcity we have to use large scale NAT in our network. In order for our local customers to call each other and have good call quality we wish to connect their ATA's directly to each other rather than have the RTP proxied 6000 miles across the public internet. I'm wondering about the best way to program an outbound proxy to monitor the calls and bypass the ITSP's B2BUA for local calls. We want to rely on the ITSP's server for authentication (so we would only REGISTER our UA's locally after we get an OK from the remote server. Or perhaps we would not need a local registrar at all.) The remote server is also where the users manage their account. So we only want to attempt to connect the 2 UA's directly after the callee has sent an "OK" response to the INVITE from the ITSP. (The callee may have set "Do not disturb" on his account at the ITSP, and it needs to handle voicemail, forwarding etc.) We have other constraints. The server hardware needs to be very low power to be installed at our solar-powered head end. Thus for potentially several hundred clients it needs to handle only SIP, no media. We could potentially install a media relay server elsewhere, but hopefully we won't need to do any media proxying at all. The NAT assignment is all handled by a Mikrotik router at our head end.  I've looked at the milkfish configuration file and it seems like in some ways, ours should be simpler. Milkfish assumes it is running on the gateway, so when it sets up an rtpproxy it doesn't cost anything. For us, it doesn't seem like we should have to do any NAT fixup or any media proxying. If the connection is local, the 2 UA's should connect directly with each other. Otherwise, the connection will be directly between our UA and whatever the ITSP sets up as the other end, and the ITSP already knows how to traverse our NAT very well. One idea I had is that, for local calls, when the initial INVITE is forwarded from the caller to the ITSP, the caller's original SDP payload is stashed away somewhere.  Then when the INVITE comes through on the way to the callee, replace the ITSP's SDP info with the stashed original.  Then when the callee responds with an "OK", I forward the response directly to the caller instead of the ITSP. There would have to be some fixup of loose ends, also. How to let the ITSP that its proxy services are no longer needed? (It could have decided to forward the call to voicemail in the meantime, etc.) Can you query the SER transaction database by Call-ID to find the other side of the call and extract information from it? Perhaps I'm barking up the wrong tree, but I'm sure there's a correct way to do this. Any help would be appreciated.