Browsed by
Category: VoIP

SIP Messages & Explanations

SIP Messages & Explanations

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

REGISTERTo 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.
INVITEStarts 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).
ACKUsed to verify that you received a final response to an INVITE request.
BYEReports that a communication has been terminated and ends the call.
CANCELCancels all pending requests. Used to end a call that is still ringing.
UPDATEChanges the state of the session without changing the state of communication.
REFERRequests the Recipient to make a request to transfer the call.
PRACKTemporary approval. It is sent in response to a temporary response.
SUBSCRIBEStarts a subscription for reporting events from a notification.
NOTIFYUsed to notify notifications of a new event to a subscriber.
PUBLISH Used to broadcast an event on the notification server.
MESSAGESends a text message. It is used in instant messaging applications.
INFOUsed to send mid-session information that does not change session state. This method is generally used for DTMF relay.
OPTIONSQueries 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.
openSIPS Installation Steps

openSIPS Installation Steps

openSIPS is a multi-purpose SIP server that is used by many telephony service providers and offers Class 4, Class 5, wholesale VoIP, enterprise PBX, virtual PBX, SBC, load balancing IMS platforms, call centers features and more. In this article, you can find the installation steps of openSIPS on Debian 10.

openSIPS is a high performance SIP server running on Linux that needs very little resources. Therefore, many telecom operators develop solutions with openSIPS. If you want to use openSIPS in your VoIP applications, you can follow the installation instructions below.

openSIPS Installation Steps

1. Components Used in openSIPS Installation & Versions:

  • Debian v10 (Buster) x64 minimal install (netinst)
  • OpenSips v3.0
  • OpenSips GUI v8.3.0
  • Apache v2.4
  • PHP v7.3
  • MariaDB v10

2. Pre Installation Tasks

To install openSIPS, you will first need a fresh Debian installation. You can download and install the amd64 netinst CD image from this link. Debian is very easy to install, you can also install it by following this video that I prepared.

After installing Debian, complete the installation of the following packages:

apt update && apt upgrade -y && apt -y install m4 git nano sudo curl dbus apache2 lsb-release

Normally, you can install the “monit” package as an option for monitoring, but at the time I wrote the article, it was removed from debian repos due to some vulnerabilities on the monit package. In case the situation changes, you can find the related setup command below:

apt -y install monit

3. PHP Installation

First install dependencies:

apt -y install curl apt-transport-https ca-certificates

Add PHP repo:

wget -O /etc/apt/trusted.gpg.d/php.gpg echo "deb $(lsb_release -sc) main" > \ /etc/apt/sources.list.d/php.list 

After that, install PHP packages:

apt update && apt -y install php7.3 php7.3-gd php7.3-mysql php7.3-xmlrpc php-pear php7.3-cli php-apcu php7.3-curl php7.3-xml libapache2-mod-php7.3 

Install PHP MDB2 library with pear:

pear install MDB2#mysql

Edit PHP.ini file and change short_open_tag variable to On:

sed -i "s#short_open_tag = Off#short_open_tag = On#g" /etc/php/7.3/apache2/php.ini

4. MariaDB Installation

Get gpg keys needed for MariaDB repo and install necessary packages:

apt-key adv --recv-keys --keyserver hkp:// 0xF1656F24C74CD1D8 curl -sS | sudo bash apt update && apt -y install mariadb-server 

After that edit my.cnf file as below:

nano /etc/mysql/my.cnf

To disable Strict mode and use default openSIPS latin1 character set, add these lines under [mysqld] header:

character-set-server = latin1 

Restart MariaDB service:

systemctl restart mariadb

5. openSIPS Installation

Add gpg key:

apt -y install dirmngr && apt-key adv --keyserver --recv-keys 049AD65B

Add openSIPS repos:

echo "deb $(lsb_release -sc) 3.0-releases" >/etc/apt/sources.list.d/opensips.list 
echo "deb $(lsb_release -sc) cli-nightly" >/etc/apt/sources.list.d/opensips-cli.list 

Install openSIPS packages:

apt update && apt -y install opensips opensips-cli opensips-*-module opensips-*-modules python3-mysqldb python3-sqlalchemy python3-sqlalchemy-utils 

6. Database Installation

Create opensips user on MariaDB and grant rights:

mysql -p 
CREATE USER 'opensips'@'localhost' IDENTIFIED BY 'opensipsrw'; 
GRANT ALL PRIVILEGES ON opensips.* TO 'opensips'@'localhost'; 

Run database installation script:

opensips-cli -x database create 

The script will ask you the database URL. Enter mysql://opensips:opensipsrw@localhost and choose default (install all tables).

7. Generating Configuration File

Run configuration generator script to generate configuration file:


Choose GenerateOpenSIPS Script > Residential Script > Configure Residential Script. Choose all items other than TLS by using space bar. Use Q to go to previous menu and schoose Generate Residential Script. Script will generate a configuration file and will promt the file name on screen. Replace opensips.cfg file with the generated one and give necessary rights:

mv /etc/opensips/opensips.cfg /etc/opensips/opensips.cfg.orig 
cp /etc/opensips/[üretilen konfig dosyası] /etc/opensips/opensips.cfg 
chmod 644 /etc/opensips/opensips.cfg 

8. Additional Configurations:

Write server IP address in opensips.cfg file:

nano /etc/opensips/opensips.cfg

write server IP addresses in two lines starting with listen= :


Then check if the configuration file is valid or not:

opensips -C /etc/opensips 

If there is an error in the file, it will appear on the screen. Correct the errors, otherwise run the opensips service with the new configuration file by using the following command:

systemctl restart opensips 

9. GUI Installation

Download openSIPS GUI via git:

git clone -b 8.3.0 /var/www/opensips-cp

Create openSIPS GUI table on database:

cd /var/www/opensips-cp/config 
mysql -p opensips < db_schema.mysql 

10. Regular Collection of Statistics

Add the necessary script into cron.d folder and restart cron service:

cd /var/www/opensips-cp/config
cp tools/system/smonitor/opensips_stats_cron /etc/cron.d/
systemctl restart cron

11. Monit Configuration (Optional)

Add the necessary line into monitrc file and restart monit service:

echo -e "set httpd port 2812 and\nallow localhost" >> /etc/monit/monitrc
systemctl restart monit

12. Global Configurations

Open GUI config PHP file and edit as follows:

nano +30 /var/www/opensips-cp/config/ 
// monit host:port 

13. Apache Configuration

Define Virtual Hosts on Apache by using the commands below:

cat >> /etc/apache2/sites-available/opensips.conf << EOF 
<VirtualHost *:80> 

DocumentRoot /var/www/opensips-cp 

<Directory /var/www/opensips-cp/web>
     Options Indexes FollowSymLinks MultiViews
     AllowOverride None
     Require all granted 

<Directory /var/www/opensips-cp>
     Options Indexes FollowSymLinks MultiViews
     AllowOverride None
     Require all denied 
Alias /cp /var/www/opensips-cp/web 

<DirectoryMatch "/var/www/opensips-cp/web/tools/.*/.*/(template|custom_actions|lib)/">
      Require all denied 



Disable default site, enable openSIPS GUI site, change owner of the folder and restart Apache:

a2dissite 000-default 
a2ensite opensips 
chown -R www-data. /var/www/opensips-cp 
systemctl restart apache2 

Finally the installation is finished. Use http://ipadress/cp URL with admin / opensips credentials to access openSIPS GUI.

How to Install & Configure TURN Server (coTURN)

How to Install & Configure TURN Server (coTURN)

This blog page covers how to install and configure coTURN server for your SIP or WebRTC projects (like Jitsi Meet) to allow users behind restrictive firewalls or proxies to connect.

What is TURN?

TURN stands for Traversal Using Relays around NAT. Similar as STUN, it is a network protocol / packet format (IETF RFC 5766) used to assist in the discovery of paths between peers on the Internet. It differs from STUN in that it uses a public relay to transfer packets between peers. TURN is used to exchange media packets when no other option is available. So that it consumes server resources and has an increased latency due to the extra hop in peer to peer connection.

The time when you must use TURN is when one of the peers is behind a symmetric NAT and the other is behind either a symmetric NAT or port-restricted NAT. The frequency of cases where a relay is necessary is around %10 of the overall connections, since STUN is enough for most cases.

Install coTURN Server

Audio / Video based services requires a wide range of UDP ports to be available for WebRTC. In some network restricted sites, such as those behind NAT or a firewall that restricts outgoing UDP connections, users may be unable to make outgoing UDP connections to your media server.

TURN protocol is designed to allow UDP communication flows to bypass NAT or firewalls by forcing the client to connect to the TURN server, and then force TURN server to connect to the destination on their behalf.

Using a TURN server under your control improves the success of connections to your multimedia application and also improves user privacy, since it acts like a proxy so that peers will no longer be sending their IP address information to a public STUN server.

Required Hardware

TURN protocol is not really CPU or memory intensive. Additionally, since it’s only used during connection setup (for STUN) and as a fallback for users who would otherwise be unable to connect, the bandwidth requirements aren’t particularly high. For a moderate number of connections, a single small VPS configuration is usually enough. Here you can find my reccomendations to install coTURN:

  • At least two vCPUs
  • 4GB Memory.
  • 20GB HDD. SSD can be used, but not mandatory.
  • The most important thing is the networking performance.
    • Low jitter (less than 30ms)
    • Low latency (less than 150ms)
    • Enough bandwidth to handle relayed media streams in both directions.

Having the server behind NAT (like on Amazon EC2) is OK, but all incoming UDP and TCP connections on any port (TCP 80 & 443, UDP 3478, 10000-20000) must be forwarded to coTURN server and not firewalled.

Required Software

I recommend using a minimal server installation of Debian with netinst or Ubuntu. Since coTURN software uses port TCP 443, the server which coTURN will be installed cannot have any other web applications running.

coTURN is already available in the Debian and Ubuntu repositories and it can be installed with apt-get:

$ sudo apt-get update
$ sudo apt-get install coturn

Please note that coTURN will not start automatically until the configuration is finished. You can find the configuration tasks in below.

DNS Entry For coTURN

You need to setup a fully qualified domain name (FQDN) that resolves the external IP address of your coTURN server. You’ll use this domain name to generate a TLS certificate.

Generating TLS Certificates

You can use certbot to generate free TLS certificates from Let’s Encrypt. To setup certbot, enter the following commands on your coTURN server:

$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot

Note: If you face with add-apt-repository command not found error, please use sudo apt-get install software-properties-common command to install the necessary packets.

You can then run a certbot command like the following to generate the certificate, replacing with the domain name of your TURN server:

$ sudo certbot certonly --standalone --preferred-challenges http \
    --deploy-hook "systemctl restart coturn" \

Current versions of the certbot command set up automatic renewal by default. Note that when certbot renews the certificate, it will restart coTURN service, so coTURN will start to use the updated certificate files. This will cause an interruption on any ongoing TURN connections. You may change the certbot renewal schedule or disable automatic renewal if you like.

Configure coTURN

coTURN configuration is stored in /etc/turnserver.conf file. There are a lot of options and all of them are documented in comments in that file. I include a sample configuration below with comments as the recommended settings, also with notes in places where customization is needed.

You can replace the contents /etc/turnserver.conf with the file below and make these changes:

  • Replace with the hostname of your TURN server
  • Change the values in bold with your choices.

You can see an example config file below:
external-ip= #or just write the external ip 

You can now start the COTURN service with this command:

$ systemctl start coturn

Running coTURN as a Service

The Debian / Ubuntu package for coTURN requires that you edit a file to enable at startup. Edit /etc/default/coturn file and uncomment the following line:


That’s it! coTURN install is complete. Now you have an up and runnning TURN server!

Testing Your TURN Server

To test your coTURN server, you can use Trickle-Ice testing tool. Go to trickle-ice webpage and enter following:

STUN or TURN URI : turn:Your Public IP Address:3478
TURN username: Username
TURN password: Password

Then click Add Server button and then click Gather Candidates button. If everything works well, you should see Done as final result.

What is ENUM? ENUM Syntax

What is ENUM? ENUM Syntax

ENUM (Telephone Number Mapping, E.164 Number to URI Mapping) is an addressing protocol that converts telephone numbers to URI format (name@domain). This allows you to access a SIP, H.323 or other Internet phone user by dialing a phone number.

The ENUM function aims to ensure that users can be accessed anywhere in the world with the same number, best quality and the cheapest way. ENUM maps a phone number to an Internet address in the DNS system. Thus, a user with an ENUM number can broadcast the DNS record to which the call will be routed. Even different routes can be defined for different types of calls (fax, video, etc.).

It is possible to obtain an ENUM record as if it were a domain name. Nowadays, you can obtain this registration free of charge through many registration services and VoIP service providers.

ENUM Syntax

ENUM allows normal phone (E.164) numbers to be displayed as DNS names ending in A number can be decoded for one or more predefined services.

For example, a telephone number + 90-312-555-1234 will be displayed as after issuing rules defined in RFC 3761 and below:

  1. All characters except digits are removed. (“+90-312-555-1234” becomes “903125551234″)
  2. A period (“.”) Is placed between each number. (“”)
  3. The order of the numbers is reversed. (“”)
  4. is added to the end of the array. (“ a”)

To respond to this syntax, the DNS server must have a record that looks like this:

   NAPTR 10 100 "u" "E2U + sip" "! ^. * $! Sip:!" .
   NAPTR 10 101 & quot; u & quot; & quot; E2U + h323 & quot; .
   NAPTR 10 102 "u" "E2U + msg" "! ^. * $! Mailto:!" .

In this record you see three different routing sequences for the address The first is SIP, the second is H.323 and the third is the SMTP response. Device selects which service to communicate by using these records.

How It Works?

The operating principle of ENUM is similar to the DNS queries we use on the Internet. DNS NAPTR resource records are used in queries.

ENUM Query and Call
ENUM Query and Call
  1. The phone calls an E.164 number (+90-312-555-1234)
  2. Gateway translates it ( and asks the DNS server.
  3. The DNS server responds to this query with a URI (sip:
  4. The gateway sends the call to the SIP server as a SIP URI call.
  5. The SIP server rings the IP phone registered with the URI.
Cisco 730 Series Headset

Cisco 730 Series Headset

Cisco has also introduced 700 series headsets as well as new Webex series collaboration products at 2019 Partner Summit.

As you may know, Cisco has introduced many products and technologies in the field of unified communications and collaboration, and has entered the phone headset market with its 500 series headsets last year. This year at Partner Summit Cisco introduced the 700 series, which targets mobile workers segment.

Cisco Headset 730 Specifications

The 700 series is a series of headsets aimed primarily traveling mobile workers and 730 is the first model of the series. Especially in crowded environments, the noise canceling mechanisms ensure clear communication for both the headset and the called party. Below you will find detailed features of the Cisco 730 headsets:

  • Connectivity via Bluetooth 5.0, USB-A and 3.5mm
  • Premium Codec Support (SBC, AAC, aptX, aptXHD)
  • Active Background Noise Cancellation with 4 Microphones
  • Clear Voice Transmission with 2 Electret Condenser Microphone
  • Intelligent Sensor Technology (Mute on Earphone)
  • Boom-less Microphone
  • On-Ear Controls
  • Voice Activated AI
  • Cisco Headset App for Customized Experience (App Store & Google Play)
  • Automatic Firmware Upgrades

Here is a table that compares the Cisco 700 series headphones to the 500 series:

700 Series500 Series
Suitable For Mobile / Office Workers Office / Call Center Workers
Primary Connection Type Bluetooth 5.0 Wired/DECT Wireless
Talking Time15+ hrs9 hrs
Concurrent Connections 2 BT + 1 USBDepends on Base Station
Wireless Coverage65+ meters90+ meters
Ear Wearing StyleBinaural OnlyMonaural & Binaural
Color OptionsCarbon Black & PlatinumBlack
Active Noise CancellingYesNo
Noise Reduction MicrophoneYesYes
RJ-9 ConnectionNoYes
Cisco 730 Headset
Cisco 730 Series Headsets Have 2 Color Options

For more information about Cisco 730 series headsets, please refer to the datasheet page.


The price of the newly introduced Cisco 730 series headset has not been set yet, but considering that the list price of the 560 series wireless headphones is around $600, my guess is that the list price will be in the range of $800 – $900.

Last Words

With the 730 series headset, Cisco has provided a professional solution for both the consumer market and business purposes. Cisco 730 headset is a very useful product especially for frequent travelers.