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.

thanks.