A Little Explanation In Understanding How SIP, Web

Question

I have spent many days learning more about WebRTC, SIP and PSTN and how they work together especially the ability to receive phone calls in browser. I have spent considerable amount of time on Twilio's website and i like the way they are able to make you receive a phone call From PSTN to your browser.

I really want to understand how they are able to let someone call a normal PSTN phone number and the call is directed to web browser.

I bumped into this question Incoming calls with SIP and WebRTC and got some little understanding but there are some things that are still missing and need someone to connect the dots for me so that i can have full understanding.

In order for you to understand my question and give a clear answer, let us take the following scenario::

1st Part ::: Let's assume i live in London and have my own SIP-server and SIP account and have a PSTN phone-number and the number is mapped to the SIP account. Now i want to be able to receive telephone calls from all over the world in my browser. When people call the PSTN number, the calls pass through my Telecom Provider. So how does the calls get to my browser? Do i have to connect my SIP server to the Telecom Provider systems before i can direct the calls to my browser?

Does it mean that to be able to direct a call to a browser the Telecom company system must know that for this particular PSTN number, the call must come to my SIP server or something like that?

I want to know all the steps that takes place for the call to get to my browser including softwares and (probably the hardwares) that come in between.

2nd part::: Twilio gives local numbers to those who wants them. I understand that Twilio signs agreement with the Telecom companies to get those numbers. Does Twilio system connects to all these Telecom companies systems before they are able to direct calls to users' browsers?

Thanks for your help.

Answer 1

Lets first look at the elements in an architecture of a voice environment that includes SIP and breakout to the PSTN.

• Voice switch: This will your soft switch / SIP Server. It may provide routing, media and applications services. Your users will REGISTER to this, or perhaps via a proxy/SBC to this node. This node could even have the webRTC module/node on it, or it could be separate.
• PSTN Gateway: This may also be included in the above soft switch. It allows your SIP calls to break out of your environment to the outside world (PSTN, GSM, etc).

This can be achieved with either one or both of:

• SIP Trunk: This is a SIP interconnection between your PSTNGW or soft switch to the CSP / Telecom Provider via SIP. You send any external calls to the SIP Trunk, and the CSP has connections to the rest of the world. They charge you for each call.
• You can build your own break-out to the PSTN by putting in analogue, GSM, SS7, ISDN cards into your softs switch or GW. External calls will then traverse these external networks.

Now an outbound call from one of your SIP users destined to the PSTN will hit the soft switch, and it will route it out via the SIP Trunk or PSTN GW. And for inbound calls from the PSTN, it will come in via the SIP Trunk or PSTN GW, and the soft switch will route it to your users. Your user could either be a standard REGISTERED SIP user, or a webRTC user. Either way, the call will be able to be routed to him.

In your examples:

1st Part::: You would need to connect your SIP server / soft swith to your Provider, either via a SIP Trunk or ISDN/GSM/Analogue connection. For a SIP Trunk, the Provider will provide you a DID number from their range, and map it to your SIP Trunk. Any calls to that number will be sent down the SIP trunk towards your SIP Server. Once it hits your SIP server, you can then easily send it to any SIP or webRTC users. Your SIP server could easily be a Asterisk box, running these modules:

• SIPML5 for WebTRC
• libPRI or DAHDI for PSTN breakout

2nd Part::: Twilio either has their own interconnects to the Telcos via SS7 or SIP, or they have partnered with a Telco to provide their breakouts.

Answer 2

For intercommunication between a SIP agent ( be it VOIP phone or WebRTC with SIP Websockets ) we require a PSTN gateway which is composed of primarily 3 components MGC ( Media Gateway Controller ) for control , SGW ( signalling gateway ) for converting signals ISUP from PSTN to SIP , MGW( Media Gateway controller ) for converting media from G711 /G729 to Opus / vp8 .

As for the number conversion the telecom service providers maintain a ENUM base for Mapping sipuri's to telephone numbers. Just in case you are a OTT players , you shall do a one time verification / input to store the mapped values .

I cant comment on twilio's process since I dont know What they do , but the architecture guidelines use of gateways for interconnection between IP world and GSM/ UMTS / PSTN world .

Answer 3

you can use plivo web SDK and develop your app. So that you don't have to worry about the telecom provider or the servers. Check out here https://plivo.com/docs/sdk/web/

Answer 4

Eddy,

I would say that your question can be split to 2 technical solutions required. First - Getting a call from PSTN to WebRTC Second - Incoming calls on the browser

Getting a call from PSTN to WebRTC

Doing this requires a Gateway (GW). There is nothing special here in WebRTC in this fact. Getting a PSTN call into any VoIP network (SIP, H.323, proprietary) will require a that will terminate PSTN calls and initialize VoIP calls. For WebRTC there are a few special requirements like security, WebSockets, Opus 9or G.711 which is common). Another special thing is that WebRTC doesn't specify the signaling. You may use SIP but many just use simple proprietary signaling. That is why many of the solutions create a kind of end-to-end solution of a GW and the WebRTC clients.

Incoming calls on the browser

That is a bit of a more complex requirement and it really depends on the overall application you have. If your browser is not running there is no simple way to get an incoming call on it. A solution could be some small application you make users install that will bring up the browser but then you miss the no install advantage yet it is better than a complete client installation that will require more updates than this small launcher application. Another case is that user is browsing your website, you see he is in trouble or looking to buy something (or pick any other use case) and you ask him to answer an incoming call. That is a much simpler case as you have your JS running already. So as said, it all depends on the exact application and scenario.

Amir