You may be getting reports from your customers saying that when they are on a call, the opposite party is telling them that their audio is too quiet, or maybe even too loud when they talk. Usually this isn’t a problem because the opposite party can adjust the volume of the person calling with their own phone, but what if the opposite party has already done that and it’s still too quiet or too loud?
If that is the case then you may be able to adjust three settings on the Yealink device. These can found on the web user interface by going to the ‘Features’ > ‘Audio’ page and adjusting the settings in the image below outlined in green.
An alternative way to think what these settings do is adjusting how sensitive the microphone is on the device. You can adjust the handset, headset and handsfree sensitivity to be weaker or stronger. The valid values are between -50 and 50. The higher the value, the louder it should be. The lower the value, the quieter it should be.
When adjusting this setting it is important to be cautious. Incorrectly configuring the value can have adverse effects on the audio quality so it’s advisable to gradually increase or decrease the value until you find the right spot.
If you control your own provisioning server and would like to configure this remotely you can use the provisioning parameters below:
The aim of this blog post is to provide a guide on configuring the software side of the 2N IP intercom’s to be in a state where they can make and receive calls. It will also detail how to change the door release code and other switch related settings.
This blog post was created with a 2N IP intercom using firmware version ‘22.214.171.124.7’. Previous or future releases may vary slightly.
It is advisable to read and fully understand the installation manual for your intercom before proceeding with this guide. The installation manual can be found on the 2N wiki by selecting your model from the listed devices.
Step 1 – Obtaining the IP Address
By default 2N IP Intercom units obtain an IP address via DHCP. There are a few ways to obtain the IP address of 2N intercoms such as the DHCP table on the networks router, alternatively you can use the 2N network scanner, or by pressing certain calling buttons on the intercom just after bootup.
More information can be read about the network scanner, or button sequence on the following 2N FAQ page.
Step 2 – Accessing the web user interface
Once you have the IP address of the intercom open your web browser and type the IP address in to the top search bar. Once you press enter it should load the login page as shown in the image below.
The default username is ‘admin‘ and the password is ‘2n‘. If successful it will force you to change your password before proceeding.
Note: Some browsers work better than others, if you have issues with Chrome or Edge, try firefox. You may also see a certificate warning. This is expected behaviour and clicking advanced or proceed should take you to the login page above.
Step 3 – Checking & downloading the latest firmware version
Once you have changed the admin password of the intercom it is advisable to make sure the unit is on the latest firmware version. You can do this easily by going to the ‘Maintenance’ section of the intercom.
To get to the maintenance section of the intercom you can use the ‘Maintenance’ button from the dashboard page
Alternatively click the ‘orange icon’ with 9 squares in it and choose ‘Maintenance’ from the list.
Once on the Maintenance page look for the ‘System‘ section shown in the image below. On this section it may already be reporting that there’s a new firmware version available next to ‘Firmware Status‘. If it doesn’t click the ‘Check Now‘ button.
If it reports a new firmware is available, read the ‘release notes’ carefully and if you are happy click proceed. The intercom will reboot during the upgrade. Once the upgrade is done this section should say the firmware is up to date.
Note: During the firmware upgrade do not remove the device from the network or interrupt the power to the intercom.
Step 4 – Configuring the SIP account & Call behaviour
Now the intercom is on the latest firmware version we can proceed to configure the SIP account on to the device. This is done via the ‘Services‘ section and from within here the ‘phone‘ page as shown in the image below.
On the phone page it automatically takes you to the tab to configure ‘SIP Account 1‘ but the same applies if you are adding two SIP accounts.
Hopefully you are familiar with applying SIP accounts to VoIP devices and the fields on this page already make sense. If they do, feel free to populate this page and get the SIP account Registered.
If you don’t have much experience and you have taken a hosted seat with an ITSP, and they have provided you with some account settings similar to the ones in the table below, you may not know where they need to go. The right column in the table shows where they would likely go on the 2N intercom.
Details from ITSP
Suggested 2N IP Intercom Fields
SIP Number/Account: 203
Phone Number (ID) field
SIP Password: Password
SIP Server: 192.168.2.131
Domain, Proxy address and Registrar field.
SIP Port: 5060
Proxy port & Registrar port
SIP Auth: WCXfg453SA
Note: The SIP Server can be an IP address, but most likely it’s the ITSP domain name.
The SIP Auth is not always provided. If you didn’t get one sent the SIP Auth is usually the same as the SIP Number/Account.
The images below show an example intercom being configured with a SIP account and the Registration status going to REGISTERED. If your Registration status goes to failed and you are sure the details are correct send an email to email@example.com and we’ll be able to help.
Now hopefully the SIP account is registered successfully with your ITSP or PBX. If it is we can continue with configuring the intercom’s call related settings.
You may want to configure the intercom to automatically answer incoming calls. This is useful for situations where someone maybe stood at the intercom and you want to talk to them without them having to press the calling button. Or this maybe beneficial if you was on a call with someone at the intercom and the call time limit was reached so the intercom disconnected the call.
This behaviour is achieved by changing ‘Call Answering Mode (SIP1)‘ to ‘Automatic‘. When set to ‘always busy‘ the intercom will always decline incoming calls.
Step 5 – Creating users for the Directory, a.k.a – Phonebook
The Directory is where we add users to the intercom and also configure unique/personal details for them such as an RFID keyfob or a Name and number which is what we are going to look at.
From the main dashboard click the icon below to get to the directory.
Or alternatively from the sub-menu navigation go to the section shown in the image below.
Once your on this page, to add a new user entry click the icon of a person as shown in the image below highlighted by the red box.
Once you click that button it will take you to a page asking for the Name, Email address, User phone numbers and user specific access settings. In this guide we’re just going to do the Name and Numbers. If this person has more than one number, add them in to the available number fields. If you want all three numbers to ring at the same time select the ‘group call to next number‘ and click ‘save‘ at the bottom of the page.
Repeat the above step for the desired amount of users. Once you’ve added some more users you should end up with a list when you go to the directory page.
Step 6 – Configuring the dialling buttons
This is the step where we program the calling button with the users to call. The system doesn’t automatically add the users because it may not be desirable to call every user.
You can get to this section by pressing the Hardware icon on the dashboard.
Or you can use the sub-menu navigation as shown in the image below:
Once you are on the ‘Buttons’ page you will see that there are no users added to the main button. To add a user you need to click the ‘+‘ symbol next to the empty field.
Once you click the ‘+‘ symbol it should bring up a new page with a list of the users from the directory, find the users you want to call, select them and click the add button. Example Image Below:
Once you’ve clicked add you should see the users appear against the main unit button. If you are happy with this click the ‘Save‘ button at the bottom of the page.
Now when the button on the intercom is pressed it should dial the programmed numbers via the SIP account configured in step 4.
A Handy tip, if the intercom isn’t nearby, to save yourself a walk you can click the ‘handset’ icon next to the assign user button to simulate a button press. (hopefully your near the phones to answer or hear them ringing).
Step 7 – Configuring the switch & activation code
The final step in this configuration guide is to edit the switch activation code and change some other settings that maybe relevant to your deployment. The default activation code is ’00*’ but it’s highly recommended to change this to something else.
To do this we need to get to the ‘Switches‘ page and we can do this straight from the ‘Button’ page by clicking ‘Switches‘ at the top. Once on this page we can change the switch code under ‘Activation Codes‘.
As the image shows above you can apply two switch codes to each switch but usually one is enough. In the image above I have changed the switch code to 4325. Notice that I didn’t defined the ‘*’ which is be required when entering the code via DTMF (During a phone call).
If desired you can set it so the intercom doesn’t require the ‘*’ to be entered for confirmation by clicking the ‘Advanced’ tab at the top of the page and enabling legacy switch code.
Legacy switch code is only applicable for switch code 1.
Depending on your installation you may also need to change the settings in the table below:
Description of Setting
Defines how long the switch will remain active in monostable mode. i.e – How long will the lock be released.
Defines which output is used for this switch when activated.
If you’ve connected a lock to the ‘relay‘ on the PCB, select this.
If you’ve connected the lock to the ‘output‘ on the PCB use this.
The type of lock being used will change which value needs to be applied.
‘Normal‘ is usually for a fail-secure lock, ‘Inverted‘ is usually for a fail-safe lock. ‘Security‘ is only applicable if the 2N security relay is being used.
To test your switch is working, you can click the ‘Test the switch‘ button on this page. If that works the setup is done. All you need to do now is make sure the intercom is working as expected.
Of course this is just a very basic guide covering the first steps on every intercom, if there are some additional requirements for the customer, or if your having issues with one of the stages above just send an email to: firstname.lastname@example.org
Also a very good place for 2N resources is the 2N Wiki and FAQ.
This blog post is going to show you how to configure a Polycom VVX device to capture the SIP traffic flowing between the device and SIP Server.
This can be useful to try and diagnose SIP registration, or outbound calling issues.
Step 1 – Accessing the web user interface
First we need to find the IP address of the Polycom device. This can be done by pressing the ‘Home‘ button (symbol of a house) on the phone and scrolling through the menu and selecting ‘Settings’ > ‘Status’ > ‘Network’ > ‘TCP/IP Parameters’ and on this page make a note of the values in the “IPv4 Addr” field.
Now we have the IP address of the device, we need to access the web user interface. This can be done by launching a web browser and inputing the IP address in to the top search bar. You DO need to define ‘https://‘ and port ‘443‘ as the transport type and communication port as shown in the image below:
Once you have entered the IP address it may present a warning saying the connection is not private:
This is to be expected and you are seeing this because the TLS certificate on the device is not signed by a certificate authority recognised by the browser. Click the ‘Advanced’ button and then click “proceed to (‘IP Address’)”. Once you have done that you should be at the login page as shown in the image below.
To login, select the ‘Admin’ user and enter the password. By default this is ‘456’.
Step 2 – Configuring the log level
Once logged in go to ‘Settings‘ > ‘Logging‘
Once the ‘Logging’ page loads set the ‘Global Log Level Limit‘ to ‘Debug‘ and set the ‘Log File Size‘ to ‘1000‘ as shown in the image below.
Next Expand the ‘Module Log Level Limits‘ section and change ‘SIP‘ to ‘Debug‘ as shown in the image below and click save at the bottom of the page.
Step 3 – Replicating the issue and downloading the log
Now the phone is configured to log the SIP packets flowing through the device it’s time to replicate the issue. If your issue is related to SIP Registrations a reboot of your device can be done to force a registration.
If your problem is with outbound calls not progressing you can go ahead and attempt to make a call.
Once the fault has been replicated, login to the web user interface and this time go to ‘Diagnostics‘ > ‘View & Download logs‘
Once on this page you can view the logging information, but if a support engineer at ProVu has asked you to capture these files, please export all three file types by using the radial button below to change which file is downloaded and then click the ‘Export’ button.
Important – Once you’ve exported the logs, be sure to go back to ‘Settings’ > ‘Logging’ and click the ‘Reset to ‘Default’ button at the bottom of the page to revert the changes we’ve made.
This blog post is going to outline the steps to take to source the required file. If you contact the ProVu support team experiencing Registration or Call issues with the Cisco CP series of phones, we will require a PCAP trace capturing the problem to help identify the cause of the issue.
Step 1 – Access the web user interface
In order to access the web user interface of your device you will need to find the IP address. There are a few ways this can be done such as logging in to your router and checking the DHCP table, but most likely the easiest method and the one this blog post is going to cover is to get it physically from the phone.
You’ll need to press the ‘Settings‘ button on the phone which has the symbol of a cog. Once you have pressed this button scroll through the options available and select ‘Status‘ > ‘Network Status‘ > ‘IPV4 Status‘ and make a note of the IP address.
Once you have the IP address, open a web browser and type the IP address in to the top search bar and press enter as displayed in the image below.
Once you have pressed enter it should take you to the ‘Info‘ page. On here you need to select the admin user and then advanced options by clicking the red outlined text in the image below.
(By default there is no admin password applied but if you have set one it will require this)
Once you have done that go to ‘Info‘ > ‘Debug Info‘ and you should be on the page below.
Step 2 – Capturing the ‘.pcap’ trace
On the ‘Info‘ > ‘Debug Info‘ page there is a section under ‘Problem Reports‘ that says “Packet Capture” with a button next to it. Follow the steps below to generate the file.
Press ‘Start Packet Capture‘ and select the capture filter to ‘All‘.
Replicate the issue – if your issue is related to outbound calls failing, attempt to place an outbound call. If your issue is related to Registration issues you can force a Registration by disabling and enabling the SIP Account:
To do this you need to go to ‘Voice’ > ‘Ext 1‘ and change ‘Line Enabled‘ to ‘No‘. Then click ‘Submit all Changes‘ at the bottom of the page. Wait 30 seconds for the web user interface to reload and then go back to ‘Voice‘ > ‘Ext 1‘ tab and change ‘Line Enable‘ to ‘Yes‘ and click ‘Submit all changes‘.
Press the button next to ‘Packet Capture‘ again (this time it should say “Stop Packet Capture“)
Once the trace has been stopped and generated you can download it from “Capture File” link outlined in the image below.
Once you have download the file please send it to the engineer requesting it, or to email@example.com if this is the first time reporting the issue.
When the CounterPath Bria Enterprise application is used on a mobile device the native operating system (Android or iOS) can close the application when it is running in the background to preserve battery life.
As this can happen, it is important to make sure the application is still receiving phone calls regardless of whether the application is open and running in the foreground, or if the application is:
Running in the background
Closed (Manually, or by the Operating System to save battery)
The Bria Enterprise Application ensures this by utilising the Bria Push Servers to take over the SIP registrations of the accounts. In most cases this is when the application is closed, or running in the background.
Now, because some SIP servers support multiple SIP Registrations per SIP extension and some only allow one SIP registration per extension it’s important to configure the CCS provisioning portal with the correct value to reflect your SIP servers registration method (otherwise your clients may end up missing calls).
The table below shows the setting that changes the application and Push servers behaviour. Hopefully from the information below you can choose the appropriate value. Remember after each change in the CCS portal each user needs to logout of their application and back in again to apply the changes.
Setting: accountN.briaPush.RegistrationMode (where N is a number from 1 to 5)
accountN.briaPush.RegistrationMode controls how the combination of the Bria Enterprise client and the Bria Push server interact with the SIP server. Continuous (2) and Standard (0) are used if your VoIP service provider supports multiple registrations. Single Device Takeover (3) and Single Device Emulation (1) are used if your VoIP service provider does not support multiple registrations.
0:Standard (Dual Instances Alternate): Allows both the Bria Push servers and the Bria Enterprise clients to register to a customer’s SIP account in an alternating manner. In this mode, there may be short overlaps of registration where both the Bria Push server and the Bria Enterprise client are registered to the SIP server. Some PBXs, SIP servers or SIP services may have issues with this registration overlap. If you encounter an issue with registering to the SIP server or receiving push notifications, select a different mode. This option is equivalent to the deprecated pushSingleRegistration setting set to False.
1: Single Device Emulation (Single Instance Alternate): Ensures that both the Bria Enterprise client and the Bria Push server unregister before the other one registers. In other words, the Bria Enterprise client and the Bria Push server never register to a PBX, SIP server, or SIP service at the same time. The Bria Enterprise client controls the registrations by requesting the Bria Push server to register only after the Bria Enterprise client has de-registered and alternately, by receiving confirmation that the Bria Push server has de-registered before the Bria Enterprise client registers directly to the SIP server.
The Bria Enterprise clients will also not register while they are in a call delivered through the Bria Push server so that they do not cause potential issues with the call in progress being terminated by the SIP Server. This option is equivalent to the deprecated pushSingleRegistration setting set to True.
Note that when in the Single Device Emulation mode, there are periods of time (typically fractions of a second) when neither the Bria Enterprise client or the Bria Push server will be registered to the PBX, SIP server or SIP service. This gap could lead to a missed call if the call is presented to the SIP server at the same time that neither element is actively registered. This is a downside of the requirement of the SIP server that only one element can be registered at any one time.
2: Continuous (App Foreground, Server Persistent): Ensures that the Bria Push server is always registered on behalf of the Bria Enterprise client. The Bria Enterprise client still registers directly to the SIP server when in the foreground, but the Bria Push server does not de-register from the SIP server. In this mode, all inbound calls and all outbound calls from the Bria Enterprise client are handled by the Bria Push server.
The Continuous mode, in particular, is used when a SIP server supports multiple registrations at the same time. This mode avoids any gap in SIP registration because the Bria Push server is always registered on behalf of the Bria Enterprise client. In the event of a call to the SIP account while the Bria Enterprise client is in the foreground, the Bria Enterprise client will receive an INVITE directly from the SIP server and via the Bria Push server. The Bria Enterprise client will filter out these duplicate events and only allow one of the call attempts to progress.
3: Single Device Takeover (Single Instance Takeover): This is an enhanced option of the Single Device Emulation mode. The Bria Enterprise client and the Bria Push server take over registrations from each other without unregistering first. Neither the Push server or the Bria Enterprise client sends SIP de-registration messages when transitioning from one element to the other. It aims to eliminate gaps that are present in the other registration mode. This mode is in some cases beneficial for SIP servers that only support single registration.
We have been getting a few reports of users who have been using the Bria Enterprise application without any issues. However, once the iOS device is upgraded to version 14, users have been experiencing 503 and 408 errors relating to the SIP account registering.
This appears to be due to an iOS setting and not the Bria application. If you are experiencing this issue please check that ‘Local Network’ has been enabled. This can be checked on the iOS device by going to:
Settings > Privacy > Local Network > Enable
If you are still experiencing issues after enabling this setting. Please proceed to generate an application support log as shown in this blog post.
If you contact the support team regarding an issue with your Yealink device and it was purchased with provisioning or redirection and this does not appear to be working it maybe due to an external factor that we have no control over, such as:
DNS related issues Local Provisioning (DHCP Option 66, PnP) Firewall Incorrect Time/Date on the device
In order for us to try and determine if there is an external factor involved we may ask you to provide some support logs from the device. These need to be captured in a specific sequence.
Generating the Support Logs
1) Web browse to the IP address of the device and login. After accessing the web user interface go to ‘Settings‘ > ‘Configuration‘.
On the Configuration page there will be a section called ‘Local Log‘. You will need to change the ‘Local Log‘ settings to match the image below:
Remember to press ‘Confirm’ at the bottom of the page after making the changes!
2) After changing the settings above, reboot the device and wait for around 2-3 minutes and come back to ‘Configuration‘ page. Once on the configuration page the ‘sys.log‘ and ‘boot.log‘ needs to be exported from the device.
You can export the files by selecting the log type from the ‘Export Local Log‘ field and pressing the ‘Export‘ button. (A popup should appear asking where you want to save them)
Make sure you export both the ‘sys.log‘ and ‘boot.log‘
3) After you have exported the logs. Send them to the support engineer you have been dealing with or to firstname.lastname@example.org
4) After you have sent the log files over to us, change the ‘Local Log’ settings back to match the image below:
If your service provider is Virgin Media and you are wanting to use a Draytek router to perform as it is designed to do and route your network traffic you can’t connect it straight to the outlet installed by Virgin Media. The Draytek router needs to be connected to the hub provided by Virgin Media.
It’s not as simple as connecting the units together and away you go, you need to make sure the following prerequisites have been done. Then you can follow the pairing steps at the bottom of this post.
To configure the Draytek router to operate in Ethernet WAN mode follow the steps below:
*If your Draytek Router does not have a dedicated WAN port it is possible on some models to configure LAN port 4 to behave as an Ethernet WAN port.
1) Web browse to the Draytek and go to ‘WAN‘ > ‘General Setup‘.
2) Once the general setup page loads click the ‘WAN2‘ index and it should take you to the page below. Once on the page below set ‘Enable‘ to ‘Yes‘ and ‘Active Mode‘ to ‘Always On‘ and press ‘OK‘.
3) After turning on Ethernet WAN and have waited for the unit to reboot go to ‘WAN‘ > ‘Internet Access‘. Once on the Internet Access page below change the ‘Access Mode‘ to ‘Static or Dynamic IP‘ and then click the ‘Details Page‘ button.
4) After clicking the ‘Details Page‘ button it’ll take you to the page below. Here you need to make sure it is set to ‘Obtain an IP address automatically‘ and also make sure the ‘Enable‘ radial button is selected and press ‘OK‘. The router may reboot to apply the changes.
Pairing the Virgin Media Hub and Draytek Router
Now you’ve configured the Virgin Media Hub to operate in modem mode and the Draytek to operate in Ethernet WAN mode they need to be paired via the following steps. If you don’t follow the steps below you may find the Draytek does not obtain an IP address from the hub.
1 – Poweroff the Virgin media hub and Draytek router.
2 – Connect the Draytek’s WAN port to any Virgin media hub port
3 – Power on the Draytek router and let it settle.
4 – Power on the Virgin media hub in modem mode and it should find the 3rd party router and assign an IP address.
Part 1 – Configure the unit to start logging in ‘DEBUG’ mode and replicate the issue
Login to the web user interface and select the ‘admin‘ user. After selecting the ‘admin‘ user go in to advanced mode by pressing ‘advanced‘ on the top right of the screen.
Once ‘advanced‘ mode is applied press the ‘voice‘ tab and also the ‘system‘ tab. Once on the ‘system‘ page scroll down until you get to ‘Optional Network Configuration‘ and in the drop down box next to ‘Debug Level‘ set this to ‘DEBUG‘ and press ‘Submit All Changes‘.
Now that the phone is logging everything in ‘DEBUG‘ mode you need to replicate the issue.
Part 2 – Generating the log
Now the you’ve replicated the issue we need to export the log.
To do this follow the steps below:
Login to the web user interface as before using ‘admin‘ and ‘advanced‘ mode. Once logged in select the ‘info‘ tab and also the ‘Debug Info‘ tab. Once you are on this page press the ‘Generate PRT‘ button.
Once you press the button you will get a popup box asking you to enter the date and time of the problem as well as selecting a description. If your problem isn’t listed select ‘Other‘ and press ‘Submit‘.
After pressing ‘Submit‘ and allowing the phone to generate the file you should get another popup notification saying the PRT file has been generated and can be access from the phone directly. Press ‘OK‘ and download the file by clicking on the PRT file link across from the ‘Generate PRT‘ button.
Note: Although this guide was created for Bria Stretto, it is still applicable to Bria Enterprise.
If you have contacted our support team regarding an issue with CounterPath’s Bria Stretto application we may require some logs from your application that you will need to generate.
This blog post should act as a rough guide on how to obtain the log as it may vary slightly depending on the application version and also the make and model of your device.
Step 1 – Open the Bria Stretto application and replicate the fault
Step 2 – Once the fault has been replicated press the ‘Cog’ icon. (Highlighted in the image below)
Step 3 – Once the new page loads, select ‘Advanced Settings’ (Highlighted in the image below)
Step 4 – Once the next page loads, scroll down until you reach ‘Application Logging’ and press ‘Send Log’. Don’t press ‘Call Statistics’. (Highlighted in the image below)
Step 5 – Once you press ‘Send Log’ it will display the image below. Once you are on this page press ‘Yes’ to generate the log
Step 6 – After the log has been generated and sent to CounterPath’s server it will display something similar to the image below with a ‘Log Reference’. (It is Important to make a note of this reference)
Step 7 – Contact us with the log reference and the user account this log belongs to so we can find it on the CounterPath Portal.
Important: You need to contact us once the log has been generated as they don’t stay on the portal for long.