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

Daniel-Constantin Mierla miconda at gmail.com
Sat Mar 10 12:01:32 CET 2012


Hello,

On Tue, Mar 6, 2012 at 10:12 PM, Chester Wood <chet at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120310/a809ccbe/attachment.htm>


More information about the sr-users mailing list