Kamailio and a connection to the PSTN via SIP - 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.

Related

SIP forwarding based on location

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.

Is there any way to use same IP for several requests with GAE Sockets API?

I'm using third party service that has own notion of session and expects all requests in session to come from same IP. They claim that it's a required security measure and suggest to use proxy, LOL.
Is there any way to use same IP for several requests with Socket API?
Interval between requests in session is ~10 seconds, so keeping connection alive and reusing it should work. I've tried to setup proxy module that runs single instance and uses HttpClient with connection pool. Logging shows that after first request connection is properly released and stored in pool. While doing second request I see that pool has 1 connection, but HttpClient says that there in no free connection for route and opens new. Probably route changes somehow?
It goes against the way App Engine is meant to work, scale-ability. Spawning instances closets to the consumers and multiple instance will mean different IP's. If you want a static IP you will need to switch to Compute Engine. Its a server VM that can have a static IP address. Or if your 3rd party service can take range you get get them from the link.
App Engine does not currently provide a way to map static IP addresses to an application. In order to optimize the network path between an end user and an App Engine application, end users on different ISPs or geographic locations might use different IP addresses to access the same App Engine application. DNS might return different IP addresses to access App Engine over time or from different network locations.
Actually, I solved this issue. Solution that I described in question was missing one step. As my connection was SSL authenticated, I had to use same context for all requests that I make.

Possible to send data between two iOS devices?

I've read tons of questions about this all over the web, and can't seem to find a solid answer. If I have an iPhone that's running on cellular data and another iOS device on wifi (in two separate locations), is it possible for them to send data to each other directly without sending it first to a web server, then retrieving it? Are the only options sending and receiving from a server/Apple's iCloud? What if I knew the devices' ip addresses? Note that the iPhone has WiFi disabled.
I'm not looking to put this in the app store, it is for personal use. I know NSNotificationCenter isn't an option.
Using the gamekit framework you can send data between two iOS devices. It is easy to implement. Other than that I don't think there is any other way to send data between two iOS devices.
Actually, it IS possible. You may want to google for something called "UDP hole punching" or "TCP hole punching".
The main approach in short: Assuming you got something like a relay server, that is some server in the internet that is publicly addressable from every private LAN that is connected to the www. No you have your two clients A and B in (different) private LANs, with some Network address translation (NAT) going on, that want to establish a peer to peer connection.
First of all both will tell the server their IP address and the port they have in their own LAN. In the UDP or TCP packet, the server will find the public address and port of the device (or the NAT (router)). So the server knows the private and the public IP address as well as the ports.
If now A wants to communicate with B, it asks the server for help. The server will send a message to B that A wants to communicate with her telling her A's public and private IP and port. A gets back B's public and private information and port.
Now here is where the magic happens. Both clients now send packets out to establish a connection simultaneously to the private and public addresses of the other party and thus punching a whole in their NATs such that incoming connections will not be blocked. Even if one party's connection establishing packets will arrive before this whole is created, the other's packets will get through to such that a connection can be created.
Beware of some NATs that scan the data for IP addresses and translate them as well, but if you encrypt your data or change the appearance of the address (complement, ...) you will be fine.
Now the master question, how can the server communicate with one of the clients without an active connection. Well in this case you can use "connection reversal" and apple's "push notifications". Use the "push notifications" (pn) to tell a client behind a NAT that there is something of interest going on and that it should contact the server. Once it has done that the connection is active and can be used in the previous described fashion.
I hope this helps some people that get to this problem although the post is quite old!
You can only use direct IP address communications if the IP address are publicly reachable IP addresses accessible over the internet, and they are static (enough) so that they are not changing on you regularly as devices get assigned to addresses dynamically. In many (most) cases, that won't be true because your devices will be assigned their IP address dynamically and those addresses are frequently going to be self-assigned IP addresses that aren't publicly addressable.
As others have commented, using Apple-provided mechanisms like iCloud are probably the easiest options. If that's not something you'd like to entertain, there are probably ways to make use of a dynamic DNS service like DynDNS to manage the actual IP addresses of your devices. With something like that you might be able to use a direct IP connection between devices based on a named DNS lookup. You'd probably have to jump through some hoops to make that happen though and I'm not sure you'd want to go to that extent.
I think that Bluetooth would be a good option for you

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