It’s a good time to work / collaborate remotely without traveling, or video chat with your loved ones to prevent the spread of the world-threatening Coronavirus (COVID-19). You can do this with the video conferencing server that I have presented to everyone in the link below.
You do not need to register or enter any user information. You can easily create a video call room by clicking the link below:
After creating and joining a video call room, you can select and copy the page URL in your browser and share it with other participants so they can join the same room. 🙂
Note: This page works best with Chrome / Chromium and Opera.
Google Meet and Noise Canceling Solution with Artificial Intelligence
Because of the pandemic period, you know that web video conferencing systems have become very popular with working from home. Although Zoom is dominating the market, Google is also one of those who want to increase it’s market share. It aims to add new features to its platform day by day. Thanks to noise canceling feature recently added to Google Meet, Google seems to have made an innovation in this area.
In April 2020, Google announced that Meet’s noise canceling feature is available for G Suite Enterprise and G Suite Enterprise for Education. We should also point out that the father of the idea of this feature is G Suite Product Management Director Serge Lachapelle. Serge Lachapelle has worked on video conferencing technologies for 25 years, (13 of which are on Google) and he is quite experienced.
Beginning of the Project
Basically, this project starts with acquisition of Limes Audio in January 2017. The main idea arises from the difficulties experienced in the meetings held with the participants in different time zones (sounds of children and pets of home workers, breakfast sounds, etc.).
How to Prevent Noise in Google Meet?
Maybe there are those who use it, some headphones and smartphones have noise canceling mechanisms that use multiple microphones. This method basically works by extracting the sound signal received from far end microphone than the sound signal received from main microphone. The feature offered in Google Meet is implemented using a completely cloud-based infrastructure and machine learning, independent of user device.
A machine learning model (denoiser) needs to be trained to find out what is speech and what is not speech, to understand the difference between noise and speech, and then to filter only speech. Serge and his team use their own meetings to train the model, then the algorithm is matured by Youtube videos which includes many people and then manual verification methods. Ultimately, the system can intelligently filter background distractions such as dog barking, pen clicking and much more.
As you can see in the video below, while talking, Serge shows how the feature works by making noise with things like a nut bag, a pen and a glass-spoon. Non-routine noises are heard loud as soon as they start, but over time these noises are damped:
Google Meet Noise Cancellation Demo
As you can appreciate, your voice needs to be listened by Google in order to use a noise canceling system with artificial intelligence. The voice encrypted by the user is decoded and analyzed in Google data centers, and the filtered voice is also encrypted and transmitted to the users. Although the analysis of the sound by listening is a question mark on the part of the user, it is stated that this analysis is made only within denoiser. I think that it is very important to realize these transactions in a short time, especially for real-time communications.
To activate this feature, just click the three dots on the bottom right during the meeting and activate Noise cancellation from Settings:
Google Meet Noise Cancellation Settings
Last Words
The method of processing data in the center (in the cloud), which is a method that Google loves, and leaving the user side more lean, has also emerged in another area. For now, this service, which is still limited to G Suite Enterprise and G Suite Enterprise for Education customers, will be available to all Google Meet users soon. In the future, I think that Google may offer it to other service providers as a cloud service.
PS: If you need professional assistance about installing & configuring Jitsi Meet, you can contact me via contact link.
Jitsi Meet is a very usable and simple WebRTC based open-source multi-platform video conferencing solution. It can be even cloud based solution or you can install it on your premises. In this blog post, I will explain how to install Jitsi server on your Ubuntu based linux platform.
Installing Jitsi Meet is very easy if you want to install it on Ubuntu linux platform. In this guide you can find how to install Jitsi Meet on Ubuntu by using .deb packages.
I assume that you can install Ubuntu linux and I will continue from that point.
First, let’s install base packages like sudo & ssh, so set that up first. Log in from console as root, then install the necessary packets.
Add your non-root user (mine is ferikci) to /etc/sudoers file.
ferikci ALL=(ALL:ALL) ALL
Now you can continue with your user by using sudo commands.
(Optional) Enable UFW firewall and open the needed ports:
ufw allow in ssh
ufw allow in http
ufw allow in https
ufw allow in 10000/udp
ufw enable
I have to warn you that if you are connected to your linux machine via SSH, enter “ufw enable” command after entering “ufw allow in ssh” command, otherwise you may lose your current SSH connection.
If you will use your Jitsi server with a hostname, please be sure that /etc/hosts file includes your hostname:
127.0.0.1 localhost jitsi.test.local
Now re-login with your non-root user via SSH for the rest of the setup.
On Ubuntu systems, Jitsi requires dependencies from Ubuntu’s “universe” package repository. To do this, add the universe repos with the following command:
Now you’re ready for Jitsi server installation. Use the command below to install jitsi-meet with dependencies:
sudo apt-get -y install jitsi-meet
You will be asked your hostname but do not only write your hostname, you MUST write as FQDN, otherwise you will encounter with problems. By the way, be sure that the FQDN can be addressable with your DNS server (Or you can insert the FQDN to your host file.).
Jitsi Hostname Configuration
After that you will be asked for certificate. In this installation I will use self-signed SSL certificate, so select the first option.
Jitsi SSL Certificate Configuration Menu
The installation will be completed after a while and it will put you to the command prompt. Reboot your linux machine:
sudo reboot
Now it’s time to connect to your video conference GUI. Use https://FQDN to go to the main page of Jitsi server:
https://jitsi.test.local
You will see a greeting page with a room name input field. Just enter a room name and click Go button.
Jitsi Meet Greeting Page
That’s it! You can add more participants with the same procedure or by using URL https://FQDN/roomname
https://jitsi.test.local/testroom
Finally Jitsi Meet is Alive!
Running Jitsi Meet Behind a NAT
If you wish to use your Jitsi server behind a NAT, you must configure your router to forward the following ports to your Jitsi Meet server:
80/TCP
443/TCP
10000/UDP
Next you have to add following lines to /etc/jitsi/videobridge/sip-communicator.properties file:
As you know in video conferencing and collaboration technologies, Cisco is the hardware and software manufacturer with the highest market share. However, as software-based solutions have emerged over the past 1-2 years, there has been an increasing demand for integrated video conferencing devices as well as audio and video transceivers. While Logitech took the lead in this market, there were many innovative products on the market (I also reviewed the most innovative Jabra Panacast in this article). Cisco will also want to take a share in this market that last January it made a serious introduction with its new product, Webex Room USB.
Cisco Webex Room USB is a device that turns any endpoint (Laptop, Desktop, SFF PC etc.) into a video collaboration center. The software you use does not even need to be Cisco, you can use this device with any collaboration platforms (eg. Microsoft Teams, S4B, Zoom, Slack, Jitsi etc.). Let’s examine the features of this device in more detail.
Cisco Webex Room USB Features
Cisco Webex Room USB is an ideal device for meeting rooms with 2-5 participants thanks to its 120 degree view camera. Basically, the device is in the form of a soundbar with embedded camera and placed on top of the screen. Apart from that, it has a remote control and a USB cable. There are also kits for display and wall mounting, a physical privacy cover for the camera, and two cables for HDMI and Ethernet connectivity. The prominent features of the device are as follows:
Camera Quality: Cisco Webex Room USB has a 4K UltraHD camera that can shoot video at 60 frames per second. It can automatically adjust the brightness and white balance supported by the 8MP image sensor for maximum clarity. With the artificial intelligence technology it contains, it has the feature to intelligently frame the image and a number of analytical functions for meetings so that everyone can be clearly seen by automatically detecting the meeting participants.
Sound Quality: There are integrated microphones and speakers on the device. Thanks to it’s automatic noise reduction feature, it can filter out distracting ambient sounds such as paper rustling and tea sugar mixing sounds. With the speaker design, it offers a more saturated sound experience, especially at low frequencies where human voice is dominant. To listen to the difference in sound with other manufacturers (Logitech), you can check out the video in this link.
Digital Signage Display: I think this feature is the most important feature of Cisco Webex Room USB that distinguishes it from other competitors. It can be used to turn connected PC displays into a digital signage when the device is not in use. You can use this feature for sharing corporate news, creating brand awareness, etc.
Content Sharing: It supports 4K content sharing as well as wireless content sharing via the web browser. In this way, you can find the opportunity to reflect your content on the screen easily.
You Can Also Use Webex Room USB As A Digital Signage Display
Apart from these, you can access more detailed technical features through the datasheet in this link.
Comparison With Other Vendors
As I said at the beginning, there are a few players in this market, especially Logitech. In the table below you can find comparison with the two most common devices:
Product /Feature
Cisco Webex Room USB
Logitech MeetUp
Poly Studio
USB Camera, Speakers & microphone
Yes
Yes
Yes
Intelligent Camera & Sound
Yes
No
No
Device Settings
Yes (via Webex Control Hub)
No
No
Wireless content Sharing
Yes (via Webex or a web browser
No
No
Digital Signage Display
Yes (via Webex Control Hub)
No
No
In the video below you can see how you can connect Webex Room USB to your computer and use it as an audio and video device:
Cisco Webex Room Kit Mini USB
Cisco Webex Room USB Price
If you have a software solution or a service subscription for your video calls, you can get this device, which provides a Webex Room Kit Mini quality call experience, at a list price of $ 2,750 (of course, this is not the actual sale price). Compared to the Webex Room Kit Mini, the price of Room USB is less than half the price of Mini.
Last Words
For small businesses and organizations that want to switch to video communication, it might be a good idea to start with Cisco Webex Room USB and then turn it into a Room Kit Mini with an upgrade kit. In this way, you can both keep the initial investments very low and have a solution that will provide the highest level of video call experience.
SIP is a communication protocol that is very similar to HTTP, and the SIP messages within this protocol are very similar to HTTP messages. Just like in HTTP, SIP messages have 3-digit codes starting with the numbers 2, 3, 4, 5 and 6. Let’s examine the most common and used SIP messages before proceeding to detailed descriptions of these messages:
Most Common SIP Messages & Their Explanations
REGISTER
To register the URI listed in the To header field to a SIP server and associate it with the network address given in the Contact header field.
INVITE
Starts a communication to search. The request is sent to a SIP server by a user client (eg. IP phone). When sent during a currently established communication (RE-INVITE), it changes the session (eg. put the call on hold).
ACK
Used to verify that you received a final response to an INVITE request.
BYE
Reports that a communication has been terminated and ends the call.
CANCEL
Cancels all pending requests. Used to end a call that is still ringing.
UPDATE
Changes the state of the session without changing the state of communication.
REFER
Requests the Recipient to make a request to transfer the call.
PRACK
Temporary approval. It is sent in response to a temporary response.
SUBSCRIBE
Starts a subscription for reporting events from a notification.
NOTIFY
Used to notify notifications of a new event to a subscriber.
PUBLISH
Used to broadcast an event on the notification server.
MESSAGE
Sends a text message. It is used in instant messaging applications.
INFO
Used to send mid-session information that does not change session state. This method is generally used for DTMF relay.
OPTIONS
Queries the capabilities of an endpoint. It is often used for NAT and keepalive.
You can also find SIP messages starting with 3-digit codes below:
SIP Messages Beginning with 1XX
These are informational responses. It reports that the request is valid and has been processed. It is used to report temporary situations such as Trying or Ringing.
100 Trying : Dispatched in response to INVITE message. It may take some time to find out where the target is, so the SIP proxy sends this response.
180 Ringing : Target user agent (dialed number) received INVITE and rings the phone.
181 Call Is Being Forwarded : Servers can optionally send this response to indicate that a call is forwarded.
182 Queued : Indicates that the destination is temporarily unavailable, so the server queues the call (on hold) until the destination is available. A server can send more than 182 responses to update the queue progress.
183 Session Progress : This response is used to send additional information for a call that is currently being established.
199 Early Dialog Terminated : Used by a User Agent Server to indicate that an early communication has been terminated to the upstream SIP entities.
SIP Messages Starting with 2XX
Indicates that the request was successfully completed. Indicates that a call has been made in response to an INVITE message. Indicates a recent success. The most common code is 200 OK.
200 OK : Indicates that the request was successful.
202 Accepted : Indicates that the request has been accepted for processing, but the transaction has not been completed.
204 No Notification : Indicates that the request was successful, but no response is received.
SIP Messages Beginning with 3XX
These codes are used if call forwarding is required to complete the request. With these codes, the request will be completed on a new target. It is also used to indicate a malfunction, but also contains information about the user’s new location or alternative places that can answer the call. These are typical responses generated by IP phones when features such as Forward All Calls or Do Not Disturb are enabled on the phone.
300 Multiple Options : The address indicates that the user or client listed in the message body or the Contact fields of the message has been resolved to one of several options to choose from.
301 Moved Permanently : The original request indicates that the URI is no longer valid, and its new address is given in the Contact header field. The client should update the original request URI records with the new value.
302 Moved Temporarily : The request should retry with the address in the Contact field. If there is an Expires field, the client can cache the result for this time.
305 Use Proxy : Indicates that there is a proxy in the Contact field that must be used to reach the desired destination.
380 Alternative Service : Indicates that the call has failed but there are alternatives in the message body.
SIP Messages Beginning with 4XX
It is the most crowded message code family. If the incoming request cannot be completed on the server for various reasons, it is used to indicate the error status, but it is a condition caused by the SIP Proxy that generates this message. This means that some other SIP Proxies, if any, can successfully process the request.
400 Bad Request : Dispatched when the request cannot be understood due to malformed syntax.
401 Unauthorized : Dispatched when user authentication is required for the request. This answer is given by UAS and SIP registrar.
402 Payment Required: Dispatched when payment is required for the request. (reserved for future use)
403 Forbidden : Dispatched when the server understands the request but refuses to fulfill it. It can also mean that the call was rejected by the recipient.
404 Not Found : The server sends this message when the user is not in the domain specified in the Request-URI. This is also returned if the domain in the Request URI does not match any of the domains processed by the recipient of the request.
405 Method Not Allowed : Dispatched when the method specified in the Request-Line is understood but not allowed for the address defined by RequestURI.
406 Not Acceptable : Dispatched when there is an unacceptable status according to the Accept header information sent in the request.
407 Proxy Authentication Required : Dispatched when user authentication is required for the request. This answer is given by proxies.
408 Request Timeout : Dispatched when the user specified in the request cannot be found within the required time. The client can repeat the request without making changes at any time.
409 Conflict : Dispatched when the user is already registered. (Deprecated due to subsequent removal from RFCs.)
410 Gone: Dispatched when this once existing user is no longer available.
411 Length Required : Dispatched when the server will not accept the request without a valid Content-Length. (Deprecated due to subsequent removal from RFCs.)
412 Conditional Request Failed : Dispatched when the specified prerequisite is not met.
413 Request Entity Too Large : Sent when the body of the request message is too large.
414 Request URI Too Long : Dispatched to indicate that the server refuses to service this service if the request is longer than the server can interpret.
415 Unsupported Media Type : Dispatched when the body of the request message is of an unsupported format.
416 Unsupported URL Scheme : Dispatched when the Request-URI is not supported by the server.
420 Bad Extension: Dispatched when an invalid SIP Protocol extension is used, when not understood by the server.
421 Extension Required : Dispatched when the server needs a specific extension not listed in the Supported header.
422 Session Interval Too Small : The request received is sent when it contains a Session-Expires header field with a time below the minimum timer value.
423 Interval Too Brief : Dispatched when the source’s Expiration time is too short.
424 Bad Location Information : Dispatched when the location content of the request is malformed or otherwise inadequate.
428 Use Identity Header : Dispatched when the server configuration requires an Identity header header and this value is not provided in the request.
429 Provide Referrer Identity : Dispatched when the server does not receive a valid Referred-By token on request.
430 Flow Failed : Dispatched when a specific stream of a user agent fails while other streams are successful. This response is designed to be used between proxy devices and should not be seen by the end device (if it is seen by it, it should be considered as 400 Bad Request).
433 Anonymity Disallowed : Indicates that the request was rejected because it is anonymous.
436 Bad Identity-Info : Dispatched when the request has an Identity-Info header and the URI schema record in this header is not understood.
437 Unsupported Certificate : Dispatched when the server cannot verify a certificate for the domain signing the request.
438 Invalid Identity Header : Dispatched when the server has a valid certificate for the request to sign the request but cannot verify this signature.
439 First Hop Lacks Outbound Support : Dispatched when the first outbound prox that the user attempts to register does not support the “outbound” feature of the RFC 5626, although the register supports it.
440 Max-Breadth Exceeded : If a SIP proxy determines that a response context has insufficient Incoming Max-Breadth value to execute a desired parallel fork, and the proxy does not want to compensate by forcing it or by sending a redirect, 440 response of this proxy should send. A client receiving the 440 response may cause his request to fail to reach all possible targets.
469 Bad Info Package : If a SIP UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 response, which contains a Recv-Info header field with Info Packages for which the UA is willing to receive INFO requests.
470 Consent Needed : If the source of the request is not allowed to make such a request for the buyer It skinned.
480 Temporarily Unavailable : This message is sent when the called number is temporarily unavailable.
481 Call / Transaction Does Not Exist : Dispatched when the server receives a request that cannot match the request with any dialog box or transaction.
482 Loop Detected : Dispatched when the server detects a loop.
483 Too Many Hops : Dispatched when the call passes over too many hops (when the Max-Forward header reaches ‘0’).
484 Address Incomplete : Dispatched if the request-URI header is missing.
485 Ambigious : Dispatched if the request-URI header is uncertain.
486 Busy Here : Dispatched if the called number is busy.
487 Request Terminated : Dispatched when the request is terminated by BYE or CANCEL.
488 Not Acceptable Here : Dispatched when Session Description or Request-URI parameters are not accepted.
489 Bad Event : Dispatched when the server does not understand an event packet in the Event header.
491 Request Pending : Dispatched when the server has other pending requests from the same dialog box.
493 Undecipherable : Dispatched when the server cannot decrypt the MIME body in the incoming request.
494 Security Agreement Required : Dispatched when the server receives a request that requires a negotiated security mechanism and the response contains a list of appropriate security mechanisms or digest authentication issues that the requester can select.
SIP Messages Starting with 5XX
Messages that are received when the server fails to fulfill a valid request, including server internal errors. Used to indicate that the PBX server encountered an internal error.
500 Internal Server Error : Dispatched when the server is unable to fulfill the request due to an unexpected situation.
501 Not Implemented : The server sends this message if it is not capable of fulfilling the request because it does not recognize the request method.
502 Bad Gateway : The server can send this message if it behaves like a gateway or proxy and received an invalid response from a sub-server when trying to fulfill the request.
503 Service Unavailable : Sends this message if the server is under maintenance or temporarily overloaded and therefore cannot process the request. With the Retry-After header, Sunuu can specify when the client can retry the request.
504 Server Timeout : The server sends this message if it tried to access another server while trying to process the request and did not receive a response.
505 Version Not Supported : The server sends this message if it does not support this version of the SIP protocol.
513 Message Too Large : Sends this message if the length of the server request message is longer than the server can handle.
555 Push Notification Service Not Supported : The server sends this message if a ‘pn provider’ does not support the push notification service defined in the SIP URI parameter.
580 Precondition Failure : Sends this message when the server is inadequate or unwilling to meet some of the restrictions mentioned in the offer.
SIP Messages Beginning with 6XX
Indicates a general error, including the rejection of the call by the target. The final is used to indicate an error condition and indicate that it is of a general nature, and indicates that this request cannot be handled by any other SIP Proxy under any circumstances.
600 Busy Everywhere : All possible locations are busy. Unlike the 486 response, this response indicates that the target knows that there are no alternative destinations (such as a voicemail server) that can accept the call.
603 Decline : Sends this message when the destination does not want to participate in the call or knows that there are no alternative destinations (such as a voicemail server) who wants to make the call and also the destination accepts the call. A better search is specified in the Retry-After header field in the response.
604 Does Not Exist Anywhere : The server sends this message if it knows that the requested user is not found anywhere.
606 Not Acceptable : Indicates that the user’s agent has been successfully communicated, but some values such as desired media, bandwidth, or addressing style of the session description are unacceptable.
607 Unwanted : If the called party does not want this call of the calling party, this message is sent. It is likely that future calls of the calling party will be similarly rejected.
608 Rejected : This message is delivered when an agent rejects the machine or process call attempt. This is different from the 607 (Unwanted) SIP response code, where the called party rejected the call. The response can include contact information that blocks the call in the Call-Info header.
