Re[2]: [reSIProcate-users] ReSent: reSIProcate as a border server - does it fit for the task?
Alex, hi there and thanks a lot for your answer!
Configuration is very simple.
All of you need - it’s install resiprocate server and do some little changes in config file (change ip, port, e.t.c rows)
Start server, open ports and try check you setup with any utils.
Example, i used python script PyStun
I'm a bit confused here. I was under impression that repro is a SIP proxy solution in terms of not only serving as a SIP requests/responses routing but also in terms of (S)RTP relaying agent. I.e. I was expecting repro to be the endpoint for the RTP in and out streams for both "road warriors" and internal PBX server. Am I wrong on this?
From what I see you're writing about using STUN that is a nat traversal helper service that should be used in conjunction with ICE in terms of latest RFC. That implies that NAT traversal (ICE/STUN/TURN) expected to be used in addition to SIP proxy. But I'd like to avoid using ICE/STUN/TURN if possible. Argh, SIP, why wouldn't it be as simple as IAX2 in w.r.t. to NAT!? :-(
Just to reiterate, the scheme I'd like to achieve is like this:
Prereqs:
* "Edge server" having static public IP 1.2.3.4 and static internal IP 192.168.1.1. SIP proxy is to be installed here.
* "PBX host" having static internal IP 192.168.1.100 and serving as a SIP registrar for sip:*@192.168.1.100.
* Intranet SIP clients (VoIP stationary phones for the most part) directly connected to the 192.168.1.0/24 subnet.
* "Road warriors" roaming out there somewhere connected to the internet. For simplicity sake let's assume that
they all have public IPs (i.e. are not behind the NAT).
Register traffic flow I want to achieve:
1. "Road warrior" (RW) with public IP 5.6.7.8 in configured to register at sip:300@1.2.3.4 with some username and password.
2. RW sends SIP register request to 1.2.3.4, SIP proxy on 1.2.3.4 receives, rewrites to sip:300@192.168.1.100 and forwards it to PBX.
It also rewrites source in a way so PBX would send reply to 192.168.1.1 instead of 5.6.7.8.
3. PBX processes register request and send reply to 192.168.1.1.
4. SIP proxy receives reply from PBX, rewrites destination to 5.6.7.8, rewrites source with 1.2.3.4 and sends out reply to RW.
Call flow:
1. RW sends invite request to sip:200@1.2.3.4.
2. SIP proxy receives it, rewrites destination to be sip:200@192.168.1.100, changes SDP data so RTP IP would be 192.168.1.1 instead of RW's 5.6.7.8, rewrites SIP source IP to be 192.168.1.1 instead of 5.6.7.8 and forwards request to 192.168.1.100. It also starts listening for RTP traffic on appropriate port @192.168.1.1 interface.
3. PBX receives invite request, does it magic in connecting to called endpoint (200 in this case) and establishing SIP/RTP call and then replies to SIP proxy with ACK response (let's left out RINGING replies for simplicity sake).
4. SIP proxy replies to RW with ACK and established RTP stream with it. It acts as a proxy for both SIP and RTP traffic i.e. no NAT traversal being done in the traditional meaning of this concept.
In other words I want SIP proxy to act like a TURN server in means of being a relay for SIP and RTP traffic but I'd rather avoid configuring full blown ICE/STUN/TURN setup if possible.
Is solution like this possible in general? And would be the repro daemon a correct tool for the task?
Sorry for bothering you with all the bloody details but SIP vs. NAT IMO is a complicated topic that is not that easy to understand at once.
---
Regards,
Alexey Loukianov
*nix HPC engineer