I set up my own asterisk voip server and i was able to make calls to my extension but how do i get it so I would have an actual phone number people from the outside can call in. lets say i want the phone number
555-1234 and if someone calls that number it gets routed to my voip server then i process it and etc..
I was presuming that this would work similarly like DNS where you go buy a number and then point it to your server with an A record. Then from there nginx processes the server request and provides appropriate web pages and so on.
Some information on this would be fantastic as I have no idea where to go for this kind of stuff and google hits isnt revealing a lot.
You need to get a DID (Direct Inward Dialing) from a VoIP provider. There are many ITSP providers up there that can provide DID and then send it to your Asterisk server (called SIP Trunking) and from there you can configure Asterisk to terminate the call on specific extension or IVR.
Also, DIDs are usually provided by tier 1 carrier (companies like Bell Canada, AT&T, Verizon etc). Again, DID (Direct Inward Dialing) is not something you can simply advertise from your Asterisk server unless of course you want to allow people to call you by IP. For example, 5551234#YourAsteriskIP will make sure extension ring. But users from a non sip devices (ie landline) cannot call your number.
Related
I want to set up a Bluetooth mesh with one client and 30+ servers. The client needs to individually address each of the servers.
Is it possible for the client to have just one element that each of the clients subscribes to? The client would need a way to identify each of the servers. Or does the client need to have a separate element for each of the servers and address them individually using each of the elements?
You can use single client and set publishing address for each of servers individually. This means you would need to change publish address each time to send something to the particular server.
If you are using Nordic SDK, you probably would be interested in this discussion.
I was wondering if gmail(Google mail in general) has any limits for number of simultaneous connections that can be open from a single server for different accounts?
The use case is that, I'm trying to write a email engine from backend. I would like to connect to different email accounts from a single server.
I tried to look around on web for this, but couldn't find anything related to this. All I found was the limit on number of connections that can be open for an account(which is 15).
Anybody have any idea on the limit for number of connections that can be open from a server? Is there any such limit at all?
The number of connections allowed to an IMAP server directly is going to be in the billions. I don't think that Google is going to do any checking to see if your server is sending to many.
The fifteen limit per account kind of makes scene. However you need to consider how many email systems run on servers these days. Its going to be normal that a lot of incoming request come from the same server however are directed to different accounts.
This is just my opinion i don't think your going to find any documentation on Googles side telling you that you can spam there server as much as you want.
I have been in a project which need to know the user last location from VLR(Visitor Location Register). I have seen many online SMS providers offer a special service called HLR Lookup. Some websites offer VLR lookup e.g txtnation. VLR lookup may be possible by using the flaw of a poor design choice of the Signaling System No. 7, the global network that powers your calls, in which all GSM operators tap to communicate with each other.
SS7 is really old, and nobody bothered to replace it as technology advanced in the GSM world. It is quite impossible to replace/disable/remove it now because everything is based on it.
MAP Signaling is an SS7 protocol that provides an application layer for the various nodes in GSM. Yate is a partial open source implementation of MAP.
But there is not any service for getting VLR response. So would you please advice me
How could I create my own VLR lookup system?
What type of resource I need to develop this system e.g server
Is it related to VOIP? Should I need to setup SIP server?
Thanks a lot in advance.
Firstly, I think that the service you have linked to is really just providing a HLR lookup rather than a VLR lookup from a quick look at their API - i.e. there does not seem to be anything returned by the API which a regular HLR lookup would return.
It would also be odd for a carrier to allow communication to a VLR directly from an entity outside their network - this is not really what the VLR were intended for.
To create a HLR lookup service, the most important thing you need is the access to some operators SS& network, or else to a service that will proxy SS7 requests and responses from you.
If you have this access then building on an opensoure SS7 gateway would seem a sensible starting point, for example a SIP-SS7 gateway as I think you suggest.
I'm looking for a SIP client based on linux (console only, debian if possible) for one simple goal : To let my CRM app know what is the incoming call number.
There is no need to use voice, autoresponder, etc., I just need to get the incoming call number send somewhere (fill a file with the number, add a row in a sql database, a curl request to my CRM or anything else like that)
Do you know a SIP client that can let me do this ?
Is your intent to receive a SIP INVITE and identify the calling number using this? Because you mentioned you don't need Voice or anything else, a simple SIPP kind of test tool should be fine.
Or do you want to test it over the mobile Network and hence want to use a VoIP Client. or just use the freeware of Xlite etc from either a desktop or mobile device.
I understand many of the fine details of NAT hole punching, ICE, and SIP VOIP calls. I've answered quite a few questions on SO on these topics. Now I have a question.
I am trying to understand the need for the RE-INVITE message that is documented for SIP+ICE after the call is already established.
Assume a topology of VOIP devices that signal over SIP and using ICE (with STUN/TURN) for establishing media connectivity. After the ICE connectivity checks are performed, both endpoints should have ascertained the best address candidate pairings (IP,port) and should be ready to stream media in both directions.
But my experience with SIP and plenty of documentation suggests that after the callee sends a 200 OK message to indicate he's in the answered state, the caller is to expected send a RE-INVITE with an SDP containing the specific address candidate selected by the connectivity checks.
Some links that describe the RE-INVITE with ICE are here and here (step 8). Rosenberg's tutorial (page 30) discusses that the RE-INVITE "ensures that middleboxes have the correct media address". I'm not sure why that's important.
Upon receiving a RE-INVITE, is the callee expected to reconfigure his ICE stack to switch sockets or addresses based on the new SDP received? Or is the RE-INVITE just a protocol formality to formally acknowledge the call has been established? If the RE-INVITE step was skipped and both sides started streaming media, what could go wrong?
The reason why I ask is because I am exploring using ICE over a signaling service that is not SIP. I'm trying to figure out if the RE-INVITE needs to be emulated.
One example of middlebox, which may be interested in the result of the ICE negotiation is a bandwidth manager.
Imagine an enterprise deployment, with endpoints inside the corporate firewall and others roaming around on the Internet, or behind private home firewalls. The deployment also includes a publicly accessible TURN server. Then let's imagine an endpoint inside the corporate firewall making a call. If the destination happens to be reachable on the same network, the call will go host to host and the TURN server will not be used (i.e. bindings will be de-allocated). This is a local network, and no bandwidth limitation needs to be imposed. On the other hand, if the call goes out to a roaming endpoint, then the TURN server will get involved, and data will flow through the corporate firewall, through what probably is a limited bandwidth uplink. We can very well imagine some policy that would want to limit the call's bandwidth. One way of doing it, is for the bandwidth manager to remain in the signaling path (using SIP record-routes) and look into the SDP of any INVITE going through, re-writing bandwidth values depending on media addresses.
I believe the general intention was, that legacy equipment of that type, which is not ICE aware, should keep working in a mixed environment introducing ICE endpoints. To keep this backwards compatibility, ICE should only introduce new processing (STUN checks, etc), but from the point of view of non-ICE-aware elements, it should not remove any existing rules (re-INVITEs are still needed to change the destination of a media stream).
In Rosenberg's tutorial I believe the re-INVITE is sent because the sockets chosen by ICE are different from those in the media and connection (m/c-lines) lines of the original SDP AND in order for any network elements that are in between the two user agents to be informed of the actual sockets that will be used RTP a re-INVITE is sent with the ICE selected socket(s) in the media and connection lines of the SDP.
If the ICE selected sockets were the same as the ones in the original INVITE request's SDP m/c lines then there would be no need for the re-INVITE request. Or if you know there are no "middleboxes" that need to be informed of the changes to the RTP sockets then there would also be no need to send the re-INVITE.