Hello, SIP newbie here.
We are a new WISP offering voip to our residential customers. Due to
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.