FreeSWITCH status on LED display using socket connection

It is a simple experiment to show  FreeSWITCH  status on LED display using socket connection. Here is Video :

What You Need

1.Raspberry pi-3

2.MAX-7219 based 8×8 LED Matrix Displays(4.No’s or more).

Those available in kit form and assembled form. And we can purchase through on- line marketing like Amazon etc.

In my case 4 modules are powered from GPIO pins of Raspberry . It is good to use separate power for modules for more than 2 modules.

3.Female to Female connector wires

to connect GPIO pins and MAX7219 LED modules.

Next What to do(installing FreeSWITCH)

1.Prepare SD card and load Raspbian and install FreeSWITCH.  For details

https://www.algissalys.com/how-to/freeswitch-1-7-raspberry-pi-2-voip-sip-server

2.Install Display drivers for MAX7219. 

git clone https://github.com/rm-hull/max7219.git
sudo python max7219/setup.py install

3.Do wiring.

(as given below) between GPIO of Raspberry pi and MAX 7219 matrix LED displays.

Pin        Name       Remarks            RPi Pin          RPi Function

1            Vcc          +5V Power              2                        5V0

2            Gnd           Ground                  6                        Gnd

3            DIN            Data In                 19                GPIO 10 (MOSI)

4             CS          Chip Select              24                 GPIO  8 (SPI CS0)

5            CLK           Clock                      23                GPIO 11 (SPI CLK)

4.Run demo program.

Edit matrix_demo.py according to no. of matrix devices used  i.e cascaded= n, in my case n=4.

device = max7219(serial, cascaded=4 or 1, block_orientation=block_orientation).

sudo python max7219/examples/matrix_demo.py

At Last

Use ESL connection between FreeSWITCH and Max7219demo program. For details

https://freeswitch.org/confluence/display/FREESWITCH/Python+ESL

Here is my source file.

 

 

WebRTC

WebRTC provides Real-Time Communications directly from better web browsers and devices without requiring plug-ins such as Adobe Flash nor Silverlight.

FreeSWITCH is a WebRTC gateway because it’s able to accept encrypted media from browsers, convert it, and exchange it with other communication networks  that use different codecs and encryptions, for example, PSTN, mobile carriers, legacy systems, and others. FreeSWITCH can be a gateway between your SIP network and applications and billions of browsers on desktops, tablets, and smartphones.

Configuration :

Look for the following in sofia profile and uncomment them:

Clients :

How it works :

By default, Sofia will listen on port 7443 for WSS clients. You may want to change this port if you need your clients to traverse very restrictive firewalls. Edit /usr/local/freeswitch/conf/sip-profiles/internal.xml and change the “wss-binding” value to 443. This number, 443, is the HTTPS (SSL) port, and is almost universally open in all firewalls.Remember that if you use port 443 for WSS, you cannot use that same port for HTTPS, so you will need to deploy your secure web server on another machine.

Example :

SIP signaling in JavaScript with SIP.js (WebRTC client)

Let’s carry out the most basic interaction with a web browser audio/video through WebRTC. We’ll start using SIP.js.

A web page will display a click-to-call button, and anyone can click. That call will be answered by our company’s PBX and routed to our employee extension (1000). Our employee will wait on a browser with the “answer” web page open, and will automatically be connected to the incoming call.

call.html :

call.js :

answer.html :

answer.js :

How it works :

Our employee (the callee, or the person who will answer the call) will sit tight with the answer.html web page open on their browser.

Our customer (the caller, or the person who initiates the communication) will visit the call.html webpage and then click on the Start Call button. This clicking will activate the JavaScript that creates the communication session using the invite method of the user agent, passing as an argument the SIP address of our employee.

use this to see if ws and wss work :

Web-based call control with mod_httapi

The mod_httapi module was built to allow you to make your call control and IVRs dynamic. With it you can generate custom IVRs based on user input. Freeswitch mod_httapi is a simple HTTP POST operation to send various bits of information to a web application for restful way to control freeswitch call flows.

This module provides an HTTP based Telephony API using a standard FreeSWITCH application interface as well as a cached http file format interface.

HTTAPI syntax :-

mod_httapi configuration file :-

The mod_httapi configuration file is found in conf/autoload_configs and is named httapi.conf.xml . It contains several settings parameters as well as a profiles section. The example configuration contains a default HTTAPI profile or you may create your own profiles.

Inside the profile tag you will notice a number of param entries. These control things such as default settings for various work actions, permissions control (see the following sections), and the default URL to use for HTTP requests.

Example :-

Example :-

You don’t need to answer the call in the dialplan before calling into httapi Both extensions below will make httapi requests to my application:

Below example call from web :-

In above example if call is successfully bridge than it give response like :

Permissions :-
With all the control that you have in httapi , sometimes it becomes necessary to little bit with permissions on things such as variables that shouldn’t be changed, or applications and APIs that you don’t want to execute. Permissions tag you’ll find many different permissions that you can enable, with even more fine-grained control over certain aspects of some of them.

Reference link :-

https://freeswitch.org/confluence/display/FREESWITCH/mod_httapi

SIP Request Methods Response Codes

SIP Request Methods Response Codes.

SIP Request Methods

There are several different Request methods to server different purposes. SIP borrowed headers and body format from the protocol HTTP. Like HTTP SIP also has different methods. following table will describe those request methods

 

SIP Request Methods
S.No Method Description
1 REGISTER Registers to receive inbound calls on registrar or SIP server
2 INVITE Established a new session
3 ACK Confirms that message/request has been received
4 BYE Ends Session
5 CANCEL Cancels establishing session
6 OPTIONS Queries capabilities of server
7 PARK Provisional Acknowledgement
8 SUBSCRIBE Subsribes for an Notifications from the Notifier
9 NOTIFY Notify the subscriber a new Event
10 PUBLISH Publish and event to the Server
11 INFO Sends mid-session information
12 REFERER Asks the recipient to issue call transfer
13 MESSAGE Transport Insant Message
14 UPDATE Modifies the state of a session without changing the state of the dialog.

….

SIP Responses

Like I mentioned earlier, SIP protocol borrowed few things from protocol HTTP. SIP borrowed response code from HTTP. Most of response codes are similar to HTTP and  SIP extends them codes to 6xx.

SIP Response Codes
S.No Code Description
1 1xx Informational responses
2 2xx Success Responses
3 3xx Redirect Responses
4 4xx Request Failure/Client Error
5 5xx Server Error
6 6xx Global Failures

A quick guide to install SIP monitoring tool sngrep

A simple quick quide to install SIP monitoring tool sngrep in seconds

To install sngrep download the source from github. Clone it

Go to cloned repo and configure it

Compile

You can run sngrep after you compile it (assuming you are in repo)

But to use it as installed command, you have to install it

Once you installation is finished you can monitor the SIP traffic and see the live call flow by simply running the command