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