Here is my problem. I do distributed calling with 10-15 Asterisk boxes. They each have a different IP address. My provider wants me to use IP based authentication, which can be a pain (the IP's change on a frequent basis).
I was thinking of setting up one Asterisk box to relay calls from all the others. That way I'd just need to set up the SIP trunk to the provider on this one box/IP.
Can anyone tell me anything special I would need to do to set this up - either in the dial plan or otherwise? I do not want all the media to run through the central box, I merely want it to set up the calls and allow the other boxes to talk directly to the provider once the call is set up.
Thanks in advance for any suggestions.
I believe a sip proxy like openser/kamailio or opensips would fit in best here. You could set the proxy up to relay all of the sip signalling to your cluster of asterisk boxes.
Here's an example for doing this with Kamailio.
Also:
I do not want all the media to run through the central box, I merely want it to set up the calls and allow the other boxes to talk directly to the provider once the call is set up.
Make sure that's groovy with your provider. A lot of ITSPs expect to signal and send media to pre-defined IP addresses. Generally they're talking to an SBC, which is expected to anchor the media and send it elsewhere..
Related
I have a DID from nexmo with voice support and I added SIP forwarding to one of my freeswitch servers (B). I have two freeswitch servers A (asia) and B (europe), If a caller calls from Asia, how do I make sure it gets routed to A server so its close to the user?
Based on my research I might need to do lua scripting for dynamic dialplan with redirect. But even this, I'm not even sure how to get the caller's location so I can decide if to which server to route the call.
Is there an easy way to do this?
what do you know about the caller?
If it's the IP address, then a lookup in WHOIS database should work. Also there are projects like freegeoip.net that deliver you the geographical location for an IP address.
Otherwise, if caller's phone number is only know, then you need to have a database of all country codes around the world, and build your lookup logic based on that.
I think about the following setup, but I do not know how to connect the main parts.
One the one side there is a Kamailio SIP server. This server provides VoIP connectivity within a certain network (non public intranet).
On the other side there is a SIP provider. This provider provides a single telephone number from the PSTN. Let's say the number is 0034-443322.
Both components are working fine so far.
I want to use that number as a dial-in to my private network. A user with number 8282 in my network should be reachable via 0034-443322-8282 from the outside world. Outgoing calls aren't necessary.
How to reach my goal? I don't know what to look for :/ Any ideas are very welcome :)
kind regards
K.A.
If your PSTN gateway can be reached by dialing the full number (including the extension), simply let the gateway forward every incoming call to your Kamailio instance which will forward the call to the appropriate user. For that, you need to create your users (known as subscribers in Kamailio) and they need to register to your Kamailio instance so that they can receive incoming calls. Regarding mapping extensions to users, you can simply let the extension be the username; or you can add extensions as aliases of the subscribers.
I setup an Active/Passive cluster with Pacemaker/Corosync/DRBD. I wanted to make an Asterisk server HA. The solution works perfectly but when the service fails on one server and starts on another all registered SIP clients with the active server will be lost. And the passive server show nothing in the output of:
sip show peers
Until clients make a call or register again. One solution is to set the Registration rate on clients to 1 Min or so. Are there other options? For example integrating Asterisk with a DBMS helps to save this kind of state in a DB??
First of all doing clusters by non-expert is bad idea.
You can use realtime sip architecture, it save state in database. Complexity - average. Note, "sip show peers" for realtime also show nothing.
You can use memory duplicating cluster(some solution for xen exists) which will copy memory state from one server to other. Complexity - very complex.
I am still learning about SIP and all its protocols, specifically trying to integrate PJSIP into an iPhone application to make p2p calls.
I have a question about a peer 2 peer connection using PJSUA. I am able to
make calls perfectly to other clients on my local network by calling directly using the URI:
sip:192...*:5060
I am curious if this will work for
making direct calls to other SIP URIs that are not on the local
network without using server configuration - if not this way, is there another way of making p2p calls without server configuration?
thanks in advance,
You can make calls without server configuration, as a general principle, but something needs configuring. As mattjgalloway points out in the comments below your question, the most robust solution is a can of worms involving ICE which provides a kind of "umbrella" protocol for things like STUN.
Last time I touched this issue, I had the requirement that I couldn't use internet-based SIP servers to help. I came up with the idea of a registry of sorts: your client can define a bunch of "address spaces" with particular routing requirements. For SIP URIs in your LAN, you define no routing; for URIs in your company's VPN-accessed network, you define a route passing through your VPN connection; for everything else you define a route through your internet router.
By "define a route", I mean that when you place a call to a URI in some particular address space, you store what IP will go into a Contact header, what Route headers you might need, and so on.
Thus, the process of making a call becomes:
Look up in the set of address spaces for a match.
Ask that address space for the suitable bits needed to make a workable INVITE (appropriate Contact header details, Route headers, etc.)
Construct a normal INVITE, mutating as necessary for the previous step.
Send the INVITE as normal.
This essentially reproduces half of what ICE would give you, in a manually administrated form. "Half", because this ensures that one SIP agent can make calls such that the SIP routing all works. The missing half is you still need some kind of registrar somewhere, and each agent in your contact list needs to have the necessary setup to receive incoming calls. (If an agent's behind a NATting internet router, the router would need to either run a SIP proxy, or forward ports 5060, 5061 to a particular machine (which might be an agent, or a proxy serving the LAN's agents).
It is, indeed, a large can of worms.
The basic issue is to solve the problem of getting transport ports anywhere on the internet for multimedia traffic.
Many companies/experts have tried to solve this situation. A possible way out of is to buy a domain and setup a basic registrar using YATE or Asterisk on an address accessible from the internet and configure it to also use ICE as needed. Your iphone application at both ends could register automatically to it upon start. Then make P2P calls.
A requirement for the SIP PBX I created for my company was to record all calls passing through it. I solved it by forcing all SIP message to pass through the PBX and to modify the SDP body so the stream passes through it and gets recorded. It works well.
I recently found out that this is not allowed.
Is there any other way to implement call recording and how "wrong" is this in regard to the protocol?
It sounds like you're describing a SIP proxy, more or less a Session Border Controller (SBC). A proxy can modify SDP, though it should be careful in doing so. Typically SBCs will set the media destination to themselves, and proxy the data to the destination. So this is perfectly legal spec-wise (assuming the devices are already coming to your server).
However, "Not allowed" could also mean "recording calls is legally not allowed", which varies a lot state-to-state.
A more conventional way to implement call recording would be to capture the RTP packets on the wire and put them together to create an audio file. There are quite a few tools around to do exactly that and it's even inbuilt into Wireshark.
As far as tweaking with the SDP goes it's definitely not something that is "not allowed" at least not on a technical level. A lot of SIP Proxy's are forced to mangle the IP addresses in SDP when user agents put private IP addresses in them. You'll find most SIP servers out there have some sort of capability in this regard and it's often call NAT mangling or similar.