Browse Category

Technical Hints

How to: Resolve Snom Meeting Point DTMF Issue

We have reports of issues with DTMF tones on a snom Meeting Point, particularly when (but not limited to) dialling in to hosted conference facilities.

The user types the access code or conference PIN in correctly, but they are advised that the code is incorrect.
This is because the microphone on the Snom Meeting Point is picking up the DTMF that is played back when the user types a digit. The phone then sends this code twice (once from the actual key press using RFC2833 and once from the microphone using inband DTMF).

There are a couple of settings you can change on the Meeting Point to stop this happening depending on your users preference:
Please Note: The Meeting Point must be on firmware 8.7.3.25 or newer or the settings will not be present in the device

1) DTMF Volume:

http://wiki.snom.com/Settings/dtmf_volume

Reducing this to a lower setting (1 or 2) may be enough, but setting it 0 will stop the playback of the DTMF tones. This may not be desirable if the customer wants to hear the DTMF being played back to them so they know the key press has definitely registered.

2) DTMF Microphone Delay:

http://wiki.snom.com/Settings/dtmf_micro_delay

This setting temporarily disables the microphone when a DTMF key is pressed, to stop it from picking up the tone being played back through the speaker. Set this to 1000 so that it delays for 1 second (it is off by default).

The settings do not appear in the web interface so you will need to use the dummy setting URL to save these changes. Simply type either of the following URLs into the web browser on your PC (that is connected to the same network as the Snom):

http://ip.addr.of.snom/dummy.htm?settings=save&dtmf_volume=0

http://ip.addr.of.snom/dummy.htm?settings=save&dtmf_micro_delay=1000

You need to change ‘ip.addr.of.snom’ to the actual local IP of the Snom Meeting point.

Thats it! Your Meeting Point should now connect to hosted conference rooms without issue.
If you have followed the steps above and are still having issues please email support@provu.co.uk.

Configuring Gigaset Hybird PBX with Sangoma Vega 50 FXO Gateway

This guide is intended to show how to route calls to your Vega 50 4FXO Gateway and out over your PSTN Line. It also includes the settings to route inbound calls from the PSTN line to phones registered to the Gigaset Hybird PBX.

This guide assumes that you have already connected the Gigaset PBX and Vega Gateway to your network and have access to the web interface of each device. If your units are not already plugged in with access to the web interface, please consult the relevant product manuals to get to this stage.

This guide also assumes that you have registered one or more SIP phones to the PBX and configured them as Users on the system. If you have not already done so please consult the Hybird manual for details.

Configuring the Vega 50 4FXO Gateway

To configure this unit, use the Quick Config wizard on the Vega Web Interface. The settings need to be changed as follows:

VoIP Tab

Registration Mode: Off
Outbound Proxy Used: No
SIP Domain: IP Address of your Gigaset PBX
SIP Server IP/Name: IP Address of your Gigaset PBX

FXO Tab

These settings are applied for Interface 0201, assuming that you have connected your analogue line to the FXO1 port on the box.

Numeric Caller ID: Your Analogue Line Telephone Number
DID to Forward to SIP: Your Analogue Line Telephone Number

Once this has been done you need to click Submit, then Apply Changes and finally Save.
This is all the configuration that needs to be done on the Vega, we now need to configure the Hybird.

Configuring the Hybird

To configure this unit via the Web UI, follow the steps below:

Step 1

Go to the VoIP > Settings page and click New to add a new provider, configure the provider as follows:

Description: Vega
Authentication ID: Your Analogue Line Telephone Number
Password: Leave this blank
User Name: Your Analogue Line Telephone Number
Domain: IP Address of the Vega Gateway
Registrar: IP Address of the Vega Gateway

Click Advanced Settings

Proxy: IP Address of the Vega Gateway
Provider Without Registration: Enabled

Click OK to save the setup.

Back on the VoIP > Settings page, click the Locations tab:

Set Default Behaviour: No Registration and click OK to save the setup

Step 2

Go to the Numbering > Trunk Settings page. You should see a Trunk called Vega with the External Port set to SIP Provider. If this is not there, please check that you have completed Step 1 successfully.

Go to the Trunk Numbers tab and click New to create a new Trunk Number, configure it as follows:

Trunk: Vega
Type of Number: Single Number (MSN)
Displayed Name: Your Analogue Line Telephone Number
Single Number (MSN): Your Analogue Line Telephone Number

Click OK to save this Trunk Number

Now go to the Trunk Groups tab and click New to create a new Trunk Group, configure it as follows:

Description: Vega
Sequence in Trunk Group: Vega

Click OK to save this Trunk Group

Step 3

This step assumes that your SIP Phones/Users are all using the CoS Default rule. If they are using a different CoS rule then please use the appropriate rule in the steps below

Go to the Numbering > User Settings > Class of Services tab and edit the CoS Default rule, and set as follows:

Automatic Outside Line: Enabled
Trunk Line Selection with Line Access Number: Click Add and select Vega from the drop down.

Click Apply to save the config.

Step 4

Go to Numbering > Call Distribution and on the Incoming Distribution tab you will see an entry of Type Single Number MSN, with your Analogue Line Telephone Number as the number. Edit this line and set as follows:

Assignment: Internal Number
Internal Number: Your SIP phone User number that you want to dial.

Setting it up as above will route any inbound calls directly to that specific phone. If you want to route it elsewhere then change the Assignment and route it accordingly, there are numerous ways to configure this which will not be covered in this guide.

Thats it!

You should now be able to dial out over your analogue line and inbound calls to your number will route according to your setup in Step 4.

Note: Step 3 configures the setting Trunk Line Selection with Line Access Number. This means that you will have to dial the access number to use this trunk. This setting can be found in the System Management > Access Codes. There is a setting there called Trunk Group Selection, click Add and select Vega from the Trunk Group drop down list. Set the Access Code to whichever number/numbers you want to use to route calls over your Vega/Analogue line.
e.g. Entering 9 in this box will require you to prefix your dialled number with a 9 in order to use this line.

If you have problems setting this up, please email support@provu.co.uk explaining which step you are up to and the problems you are facing.

Wireless Headsets with Polycom phones

There is a very useful PDF guide on setting up Plantronics, Jabra and Sennheiser wireless EHS headsets with Polycom phones here:

Polycom PDF

You need to have bought the relevant EHS cable for Polycom phones and the headset you are using. We can source these cables, please give our sales people a call.

Two things I noticed when testing:

  • If you have a Polycom IP321 or IP331 phone then you need an rj9-2.5mm jack convertor (when using a Sennheiser headset at least). We can sell you this, part code is RJ9-2.5MM-5PK. This goes between the rj9 connector on the EHS adaptor and the 2.5mm jack headset port on the phone.

  • The PDF tells you to go into these menus on the phone:

    Menu > Settings > Basic > Preferences > Headset > Analog Headset

    On the phone I used which was on 4.1.0 firmware the actual menu sequence was:

    Menu > Settings > Basic > Preferences > Headset > Hookswitch Mode

      • Make sure to pay attention to the headset mode settings on the headset itself by turning the dial(s) or DIP switch as per the Polycom PDF.

Sangoma Vega gateway using RFC2833 DTMF

In some of the newer Sangoma Vega firmware, it seems like there was a default setting for the DTMF signalling which had changed from previous firmware builds.

Enter the following commands in the Vega console:

set .media.pkt_profile.1.voice.out-of-band-dtmf=on
apply
save

Upgrading Sangoma Vega firmware from the command line

It is possible to upgrade the firmware on a Sangoma Vega gateway from the command line.

You can connect to it using telnet, ssh or a serial console cable. Note – the console cable is the same as a Cisco console cable.

To upgrade firmware you will need a tftp server running on the network local to the Vega gateway.

A free tftp server for a Windows PC is Pumpkin.

In Linux/Unix(/OSx??) install tftpd.

Place the firmware file into the root folder of the tftp server. Get the firmware from the Sangoma wiki.

The filename will be something like “VEGA_R100S043.bin” depending on which gateway it’s for and what the version of firmware is. Note that Vega 100/200/400 gateways use different firmware than Vega 100G/200G/400G.

Connect to the command line of the Vega gateway.

You need to tell the Vega where your tftp server is. They will usually look at DHCP Option 66 but in many cases you’ll need to manually tell it using this command:

    set .tftp.ip="xxx.xxx.xxx.xxx"

With the correct IP address! Then:

    apply

and if you want the setting to survive a reboot:

    save

To do the actual firmware upgrade:

    upgrade

    download enable

    download firmware _filename_

    reboot system

Where _filename_ is the entire file name of the firmware file in the tftp server root folder. E.G. VEGA_R100S043.bin

Changing music on hold on a sark pbx (including sark200)

If you want to change the music-on-hold that comes as standard on a SARK PBX, the main stumbling block is getting the audio file(s) in the correct format.

There are several you can use, the best is a wave file with the following format audio:

RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 8000 Hz

This should work on any SARK PBX, including the SARK200.

It is also possible to use MP3 but you may need to also install MP3 decoding software and it will put a small amount of extra load on to the system.

A number of free tools can be used to convert your audio files into this format such as “sox” or “audacity”.

The simplest way of replacing the existing MoH on SARK is to connect to it using ssh/scp (or WinSCP if using Windows) and go into the folder:

/usr/share/asterisk/moh

Then delete or move any audio files in there and copy your new file(s) in to there.

Note – if you have an older sark system then the location will be /var/lib/asterisk/moh

Then reload Asterisk by clicking on the “commit” button in the web interface or using the command “moh reload” at the Asterisk CLI.

One last thing, you cannot use copyrighted music unless you have a PRS license. So make sure you are using music with no copyright (there are a couple of online libraries for this) or music you’ve had professionally produced.

SARK PBX Firewall manual control

The firewall used on modern SARK PBX is a freely available firewall called ‘shorewall’. It also uses an automatic intrusion detection system which blocks IP addresses on the fly.

This system can sometimes block things you don’t want blocking – the most common one is a password typed into a SIP phone incorrectly getting blocked out.

There are a few simple commands that can be used to check for and fix this. These need to be ran from the SARK command line. So you can either ssh/putty into it or connect a monitor & keyboard (sark850+ only).

To check the list of IP addresses that have been auto-blocked:

  shorewall show dynamic

To unblock an IP:

  shorewall allow xxx.xxx.xxx.xxx

Replacing the xs with the IP to unblock.

Also if you want to actually manually block an IP yourself then you can do:

  shorewall drop xxx.xxx.xxx.xxx

Note: some early sark200s had a slightly different firewall configuration. In case the above doesn’t work and you’ve had your sark200 since the early days, this should work to unblock an IP:

  iptables -D fail2ban-ASTERISK -s xxx.xxx.xxx.xxx -j DROP

No ringback from a Vega gateway connected to an ISDN phone system

I’ve come across this issue a few times, it seems very confusing but is an easy fix.

The scenario is:

– ISDN PBX connected to a Vega 100/200/400 gateway using a SIP provider for inbound & outbound calls.

– When ringing an inbound number that comes in over SIP, through the gateway and to the ISDN PBX, the call works fine but no ring-back is heard.

The reason:

The ISDN system is sending a progress indicator message to the gateway tell it that it will send in-band media. The Vega gateway translates this into a “183 Session Progress” message which would be the SIP equivalent.

However, the PBX then clearly isn’t actually sending any audio so the caller just hears silence till the call is answered by someone.

I suspect that the reason this problem doesn’t occur on a real ISDN line is that BT et al. just ignore these messages and generate ringing whether the PBX said it was going to send it’s own or not.

So the fix is to force the Vega gateway to always send a “180 Ringing” message no matter what the ISDN side says. This tells the SIP server upstream to generate it’s own Ringing rather than expect to get some audio from the gateway.

In the Vega web interface:

  • go to Expert Config

  • click on SIP

  • scroll right to the bottom and click Advanced SIP

  • find the setting called “183 Session Progress if media present. If =2, send 183 instead of 180 with sdp”

  • change it to 1 (a number one) instead of the default value of 2

Apply the changes and save the config.

That should work around the issue.

SIP Registration Expiry

How Registration expiry and Re-Registering works seems to be one of the most mis-understood concepts in SIP.

Registration Expiry

A SIP UAC (such as your SIP telephone) sends a Registration request to a SIP UAS (such as your PBX or hosted platform).

This Registration request has an Expires header in it (which can be an individual header or a tag in the Contact header). The value used is nearly always a configurable setting in the UAC itself.

The UAS responds to the Registration request accordingly (usually there is a process of Authentication that goes on which I wont go into here). At the end, if the Registration is accepted, the UAS will send an OK message to the UAC which contains the actual Registration expiry time (again, either an individual Expires header or as a tag in the Contact header).

The important thing to note is that it is the UAS which decides what the expiry will be, not the UAC which is where most people go wrong. The assumption is often that if you set an expiry of 600 seconds in the UAC settings then that’s what gets used. Not necessarily the case, the UAS has the final say.

Often a SIP PBX will have settings to control minimum & maximum permissible values for the Registration Expiry. Then a UAC is allowed to use any value inside this range. Outside the range, the UAS decides what gets used. Sometimes there is a default expiry to use when a UAC selects something outside of the permissible range.

Re-Registering

Once a UAC is Registered, it has to decide when to re-Register. The Expiry is not a timer to start re-Registering, it’s the time when the UAS will assume the UAC isn’t there any more. Think of it as a Re-Registration deadline.

So, a UAC must have completed it’s re-Registration before this Expiry time or calls will stop working. There is no definitive strategy for doing this in SIP, it seems to be up to the UAC manufacturers to decide what they think is best.

Some halve the Expiry and then start to Re-Register from that point onwards, so with an Expiry of 180 seconds, you’ll start to see more Register messages after 90 seconds. This gives more than enough time for the Re-Registration to complete before the previous Registration expires.

Other UACs choose different times either based on some percentage of the Expiry, a set number of seconds before Expiry etc…etc…

Due to this second misunderstanding, many people think that they can alleviate Registration problems by setting a very low Expiry. In reality this nearly always makes it much worse as the UAC now has less time to actually get Re-Registered.

Generally, I wouldn’t set Registration Expiry to less than 600 seconds. There can be some circumstances when it makes sense to use a lower setting (e.g. a mobile roaming handset moving from network to network regularly might need a shorter Expiry) but in general it should be avoided.

Trying to use a very short Re-Registration timer for overcome NAT mapping issues (where a NAT router is destroying NAT mappings too quickly), isn’t the correct way of doing it. Any decent UAC will have a NAT keep-alive setting somewhere (or often this happens automatically). Then the UAC will send out a SIP Options message or sometimes just a blank packet on port 5060 to keep a NAT mapping open. Use this as very short Expiry will often cause others problems as described above.

Gigaset DECT Repeater Mode

Gigaset have recently released Firmware 42.194 for the N300 and N510 DECT Base Stations. With this release comes a change to the Repeater Mode setting, which is necessary for pairing DECT repeaters.

In the handset menu, under System > Settings, the Repeater Mode setting has been replaced by Encryption. This setting relates to the new Gigaset DECT repeaters in the EU which use encryption.
These are not available in the UK so you will most likely be using a DECT repeater that does not use encryption. You should therefore turn this setting OFF, to allow you to register the DECT repeater to the base station.

If you are still having trouble registering your repeater to the base, please take a look at our handy guide.