SIP forwarding based on location - sip

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.

Related

Detect non-existing e-mail address without sending a message

I've read everything I could find on verifying e-mail addresses. The widely encountered solution is this, and it doesn't work (for one, actual nslookup output differs significantly from what the article shows, so I don't get an actual address to telnet to).
But then I thought: I don't need to verify the address. I just want to detect clearly bogus address (such an address that sending a message to it will yield "delivery failed" response). Is it possible to do in principle, and implement using C++ sockets or Java networking API in particular?
Depending on which operating system and tools you use, verifying the recipient's domain, and whether it is recorded in the DNS with a meaningful MX (mail exchange), you could use dig in place of nslookup. For foo#bar.com,
$ dig bar.com MX
Possibilities of detecting bogus eMail adresses are typically limited, though. Availability largely depends on how "generously" the MTA offers this information. Most don't, these days. The SMTP protocol includes some verbs you could then use, such as VRFY. On the other hand, spammers could do just that, hence … (That's one reason why a mail loop is run, in order to detect valid eMails fairly reliably; embedding, as I'm sure you know, a verification string to be sent back, or passed via URL to some web service.
SMTP, being a text protocol, would be used via some "transport layers" underlying higher level APIs like JavaMail. I'd look for programmability of these with the programming language used. Typically, there is some socket library, for sending and retrieving lines of text.

Kamailio and a connection to the PSTN via SIP

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.

socket design: Handling connection requests TCP/UDP

The challenge: We have a number of clients in distributed outposts that I have to manage with a central server. As some clients are located in DMZ or behind proxies, they should be connecting to the server!
As I only have to deal with one client at a time, the server doesn't necessarily have to be able to handle multiple clients simultaniously, however, I would like to see a list of the clients that are trying to connect to the server. Plus, I would like to see more information about the clients than just the IP address, for example the geographic location and some information, if the client has some files in a specific directory that the central server is interested in. My question is, how I best do smth like that.
Sure, I could simply show every client trying to connect in a listbox and accept only the one that I want to connect with, but is that really the way to go? I doubt I can get more information about the client than it's IP address?
I was wondering, if this calls for UDP. The clients send UDP datagrams that just inform the server that they are alive and that they want to connect. On the server, I see all these clients listed with the data they sent. I can then select one client, send an answer/"connection request" with UDP so that this particular client will connect via TCP to the server?
Is that possible?
This sounds like using a hammer to crack a nut. Just have them all connect via TCP. Then you get their presence, their IP address, anything else they care to send you. Deal with them all at once. It's not hard.

Peer 2 Peer call using PJSIP and PJSUA

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.

SIP relay for distributed calling

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..