Hello, On Tue, Mar 6, 2012 at 10:12 PM, Chester Wood <c...@dewachen.org> wrote:
> 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. > what you can try is to use htable module to store in memory the sdp based on caller/callee or call-id (if preserved by provider when returning the invite/200ok). Then use textops module to set the body with the sdp taken from htable. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
