How-To

How-To documents contain informations regarding the configuration of a specific feature or service.

Administrator FAQ

SOP

How to safely power off the SOP

  • Connect using ssh to the server using the IP address of the SOP and the admin/customer credentials you have received during the installation/ project handover
    • In case you don 't have your credentials to connect to the SOP via ssh you can contact our support department
  • When you are logged in to the shell you can follow the following guide Link

BLF (busy lamp field ) implementation + explanation

The SIP protocol includes a standardized mechanism to allow any SIP client to monitor the state of another device. Basically, it works like this: If client device A wants to be informed of changes to the status of device B, it sends a SUBSCRIBE request - either directly to device B or to a server that is aware of the state of device B. If the SUBSCRIBE request is successful, then every time device B changes state, device A is sent a SIP NOTIFY message telling it about the event or change of status. This is the mechanism that IP phones use to control BLF lamps.

Hints - How Asterisk supports the SUBSCRIBE/NOTIFY mechanism

Hints are a configurable mapping between an arbitrary name tag (we use the extension value) and a specific telephony device or application that Asterisk knows about. These hints are generated by the Application Selector used for a specific callflow. Be sure you use the dynamical application selector.

When Asterisk receives a SIP SUBSCRIBE request it checks for a hint in the dial plan that matches the name of the device to be monitored. The hint tells Asterisk which physical device this corresponds to. Hints usually map an extension number (or name) to a device.

Checking and debugging Asterisk hints

At the Asterisk CLI, type show hints to show a list of all defined hints. If this list is empty or does not contain the extension you want to supervise, check the Application Selector used for the callflow used by that extension. 

# THIS LIST IS TRUNCATED, EXAMPLE ONLY
00000249*CLI> show hints
    -= Registered Asterisk Dial Plan Hints =-
   115                 : SIP/SDP40004          State:Idle            Watchers  2
   114                 : SIP/SDP40028          State:Idle            Watchers  2
   113                 : SIP/SDP40003          State:InUse           Watchers  2
   111                 : SIP/SDP40002          State:Idle            Watchers  3
   110                 : SIP/SDP20014          State:Idle            Watchers  3
   135                 : SIP/SDP40001          State:Idle            Watchers  0
   108                 : SIP/SDP20013          State:InUse           Watchers  2
   103                 : SIP/SDP40043          State:Idle            Watchers  0
   102                 : SIP/SDP40041          State:Idle            Watchers  0
   101                 : SIP/SDP40051          State:Idle            Watchers  3
----------------
- 10 hints registered

To see which subscriptions are active (and the current status for each subscription), type sip show subscriptions at the CLI. 

# THIS LIST IS TRUNCATED, EXAMPLE ONLY
00000249*CLI> sip show subscriptions
Peer             User        Call ID      Extension        Last state     Type
192.168.22.167   SDP30001    51206110-27  232              Idle           xpidf+xml
192.168.22.117   SDP30003    18ca004d-f8  108              InUse          xpidf+xml
192.168.22.117   SDP30003    ebd0b1ea-ec  118              Idle           xpidf+xml
192.168.22.117   SDP30003    a68d2da3-ff  162              Idle           xpidf+xml
192.168.22.117   SDP30003    8d80fb90-cd  232              Idle           xpidf+xml
192.168.22.164   SDP30002    50aa6dbf-a7  108              InUse          xpidf+xml
192.168.22.164   SDP30002    b77ebf42-9b  118              Idle           xpidf+xml
192.168.22.164   SDP30002    c682f797-54  101              Idle           xpidf+xml
192.168.22.164   SDP30002    428485d0-9f  212              Idle           xpidf+xml
66 active SIP subscriptions
00000249*CLI>

If you are having problems with subscriptions not registering properly, it is probably best to use the sip debug mode to display the actual SIP messages being exchanged between your SIP client device and your Asterisk server. Note also that many SIP client devices do not keep re-subscribing. Subscriptions are sometimes only renewed after a very long time interval. Rebooting an IP phone will usually force it to re-subscribe with the Asterisk server.

To enable sip debug mode, type sip debug or sip debug ip_address_of_the_phone at the CLI. To switch it off again, type sip no debug.

Limitations

  • In a multi-SOP environment where not all extensions are known on the same SOP(s), the hints/subscribe mechanism will not work as the hints cannot be resolved.

Monitoring delay and jitter on an IAX trunk

DONE Navigate to: !SopShell > Diagnostics > Telephony > asterisk console

Execute the command "iax2 show channels" 

00000177*CLI> iax2 show channels
Channel               Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  JitBuf  Format
IAX2/foo@DDI-wav  192.168.0.10         foo         00008/00032  00007/00004  00032ms  0013ms  0000ms  ILBC

The delay in this example is 32ms, the jitter is 13ms.

-- 29 Jun 2010

Change IP address of the SOP

All the configuration is done on SMP. Also the change of an IP address.

  • Connect to the SMP
  • Go to Advanced Server Configuration
  • Make the necessary IP configuration change + Save
  • To Apply the Ip change done the in ther server configuration page you have to re-install the Network module
    • Go to SMP-Advanced- Module configuration
    • Indicate the network module for installation
    • Click install modules

When installing the module network the sop will get the IP address configured in the Server config page ( SMP-Advanced-Server config).

The IP address of a sop is used by different modules services like polycom , asterisk , application management server ,...

warning In order to let all other functionality/modules work correctly you need to re-install all the other modules warning

TIP The modification of IP using the Shell is only done in case of connectivity problems. All modules en functionalities will still use the old IP address when using this method.

More information can be found in the UCS Administration Guide

-- 29 Jun 2010

After a lot of transfer or blind transfer, the call is dropped

add the following global_parameter

MACRO_RECURSION=30

-- 29 Jun 2010

What is the max. number of phones that can be called by the CallUsersByGroup action?

  • The asterisk Dial() application can only have 255 character as Application Data. This means that more than 19 phones is not supported.
  • If you need more than 19 phones, you will need to implement a Queue and link the members of the queue with a specific callflow (Profile.Status) (See Queue Resource definition in SMP user interface.)

-- 29 Jun 2010

Outgoing call problem - Check outgoing caller ID

Phone/extension not able to call outside : Check outgoing caller ID ! Check if the outgoing caller ID is accepted by the provider

Take a Bri trace – use escall to call outside with different numbers

-- 30 Jun 2010

An outgoing call to an external number works, but not if a phone is forwarded to that same number.

It is possible that the operator doesn't accept RDNIS (Redirected Dialed Number Information Service) which is set by the phone when in forwarding mode. If you encounter this problem, you can suppress the RDNIS signal:

DONE Navigate to: SMP > Call Routing > Routes > Click on GOTO.Interface > Caller ID Policy > Select an option with "Clear RDNIS"

When connecting a PRI card, I get a yellow alarm in the SOP shell, option Diagnostics > Telephony > PRI status

It can be because you aren't using a CRC4 checksum where it is required, or the opposite. This option is available in the choice for each interface under the zaptel-asterisk module. Be sure to reboot the SOP after (re-)installing this module.

Does the SOP manage shutdown instructions sent by an UPS?

Some UPS models are supported, see the UPS Support Administrator Guide.

The parameter ExternalCall is not evaluated properly

ExternalCall depends on the length of your internal numbers, the correct length must be set in "Global parameters" > "Reserved" > "InternalNumberLength" If you checked that and it's still not working, launch the system task "ImportReservedGlobalParameter" . Note that this task must be launch with care. We recommend not to use it in a production environment.

Is it possible to define more than 31 pickup groups?

There are multiple ways of doing a pickup, please have a look at the Call Pickup documentation.

-- 25 March 2011

After installing a SOP, I see a lot of 'Lost some interrupts at 1024Hz'

Please make sure the high precision timer is disabled in the BIOS. At the time of writing, this should only be done for 4U and 2U TTEC machines. Have a look here

Prompts don't seem to work although they exist

Please make sure the high precision timer is disabled in the BIOS. At the time of writing, this should only be done for 4U and 2U TTEC machines. Have a look here

Using audio files in the SOP

There is a distinction between the prompts and a file used for the music on hold. Music on hold must have the mp3 format. Prompts can be uploaded on the SOP, but it must have a specific format. The recommended format is :
  • wav files with a rate of 8kHz, mono mode, 16 bit signed-integer PCM. On *nix system, it can be transformed with this command : 
sox inputfile.wav -r 8000 -c 1 -s outputfile.wav

  • For Windows users, use Audacity.

Time problems on the SOP

Where to install ntp module

You should install the NTP module on each kind of server (physical and virtual)

The difference is:
  • Physical -> will correctly set the time on that server + sync phones connected to that server
  • Virtual -> will only sync the phones (it cannot set the date of the vSOP)
    • Setting the time of the vSOP is done by the vHOST

Installing the module "Localization" will allow you to define a set of parameters for the SOP such as Timezone. See the module documentation and the module installation guide.

If you are experiencing time problems, you can connect to the SOP Shell:

DONE Navigate to: !SopShell > Subsystems > Time

  • Resync NTP Client/Server will allow you to restart the NTP daemon and resync time.
  • Check NTP Sync will allow you to check if the SOP is synchronized with some NTP servers.
  • Current Time will allow you to check the SOP's current time and date.

Using the "Check NTP Sync" tool you can see which NTP source is chosen by the NTP clock selection algorithm. You'll see a star at the beginning of that line. If you see a "+" that means the source is a valid candidate.

If the ntp process choose to synchronise with the LOCAL clock that means that all the NTP servers configured are not usable. See below possible reasons:

  • Source is not configured to synchronise with a remote NTP server. You'll see ".LOCL." in the refid column and a stratum 1 (st column)
  • Source is out of sync with the remote NTP server (e.g. because just configured)
  • The root distance (on-half roundtrip root delay + root dispersion) of the source is higher than 1.5s
  • The source is configured to be synchronised with the SOP
  • The source is unreachable. You'll see ".INIT." in the refid column. (to be confirmed by a network capture when restarting the ntp process)

See also the NTP Server Probe documentation for more informations.

SMP

Asterisk module context - SIP trunk

SOP-A <---SIP trunk ---> SOP-B -- Provider

Not able to call from A to B to outside. Context of SIP trunk on SOP-B is not set correct.

2 solutions :

  • Reinstall asterisk module with context NoRestrict :everything can go to everything

  • Create specific SIP trunk and don 't use a mesh SIP trunk. Context Default is not enough for a SIP trunk, put it in NoRestrict

Do not forget to set Caller ID "set as in global parameters "

-- 30 Jun 2010

Where can I change the value of a profile parameter ?

  • Click on the small icon next to the profile name.
Profile-Parameter.png

How to begin to set up a reception callflow ?

Here is a list of questions that can be asked to guide the implementation of the reception callflow : ReceptionCallflowFramework

Phone specific

DHCP storm with polycom phones using your own DHCP server

When using your own DHCP server in combination with polycom phones it can lead to DHCP storm. This is observed when we are using option 43 in the DHCP-Server and this option contains incorrect values. To solve this just deactivate this option as its not required for phones connected to the ESCAUX phone

Reasons why local forward on the phone is discouraged

Here are some arguments that can be used within communications with customers:

* users can forget they configure it and complain their phone does not work anymore but Escaux cannot troubleshoot it as nothing can be seen in Asterisk console

* users can create undetectable loops between each other

* DND & Local Forward can only be setup on the phone itself, status can be changed by net.Desktop and the administrator

* Status can be seen by other users and net.Console (except Fusion CFU)

* Status works even if phone is disconnected or logged with another extension (PUM)

* Status applies to both primary and secondary phone

* ...

How to configure a switch (VLAN) & connect new phones

See ConnectingNewPhones. Consider also the network requirements

Doorphone + Cisco ATA

If the default configuration is not enough to let the door-phone work have a look to the following options : 

ringtone dial tone:  425@-19;10(*/0/1)
Interdigit Long Timer: 3

PC port blocked on Polycom phones

If you encounter a problem with the PC port on Polycom phones, it is most likely due to static electricity.

Please check the following before contacting support:

  1. Has the problem been happening since the phones were deployed or it started recently after a known change?
  2. Is the problem sporadic or happened during a specific activity on the PC (stand-by)?
  3. How often the problem has been happening?
  4. How many phones are affected on the network?
  5. Are the affected phones ALL situated in the same building or location?
  6. Has the problem being identified with a specific PC/Laptop model?
  7. Are the phones powered via PoE or PSU?
  8. Are the laptops attached to a docking station?
  9. When the PC port is blocked, do you see any activity on the network card such as the orange and green led light still on and showing activities?
  10. Did you try to plug the phone a different network (VLAN) to see if the problem follows?

What to do if a non-Cisco phone does not get its IP address while DHCP is running (environment : Cisco switch with VLANs)

Please check if CDP is deactivated on the phone

-- 29 Jun 2010

How to disable buttons on the Eyebeam or Xlite softphone (version 1.5)

To disable the record, the following three lines need to be added to the user's ui.cps file: 

     <section name="tog_record">
       <setting name="disable" value="1"/>
     </section>

These need to go between the tags. If the "tog_record" section is already there (unlikely, but possible), just the 'setting name="disable"' string needs to be added. Also, eyeBeam can't be running when modifying the .cps files as it reads them on start and writes them on exit: any changes will be overwritten when the user restarts eyeBeam if it's running when you the changes.

The .cps files are stored, by default, in the hidden directory C:\Documents and Settngs\\Local Settings\Application Data\CounterPath\*\ Other buttons have similar XML names, such as tog_aa, tog_ac,...

-- 29 Jun 2010

Factory reset of Cisco 79xx Skinny Phone

  • Press # for a long time while the phone is booting.
  • Enter then 123456789*0#
  • Press 2 to confirm to erase the config.

-- 29 Jun 2010

Incorrect winter/summer time on various phones

  • For Grandstream phones this can be solved by upgrading the Grandstream resource version to at least version 2.4 (remember to always check dependencies). Also set daylight saving parameter to yes. It could happened that the time is changed a week in advanced.

  • For Cisco phones (7912 & 7905) the local time is computed by subtracting the local time on the SMP from the UTC. So if the time is not correct on those phones, try to make an apply change when the time shift have been done and reboot the phones.

Another problem with my phone

Have a look at the IP Phone troubleshooting guide.

-- 23 Nov 2011

net.Desktop

Can I run Escaux desktop applications on Citrix or other desktop virtualization technologies?

Please refer to the Virtual Desktop Infrastructure Application Note

When I modify the directory in the SMP, I don't see any changes in my net.Desktop

net.Desktop is not automatically synchronized with the SMP directory. You have to synchronize your data at net.Desktop start-up or when net.Desktop is running.

At start-up, you will have a prompt asking you if you want to synchronize your data. Answer yes if there were changes in the SMP.

While net.Desktop is running, click on the Data Synchronization button and answer yes.

You will now see the data that was added.

-- 21 Feb 2011

Fax

Fax connected on an ATA using G.711

Sending or receiving faxes that are connected to an ATA might work fine at first. But eventually you may start to notice that faxing just doesn't seem to work as well as you remember it working on the old phone line.

Generally the problem rests in one of two matters. The first possibility is what is called “lossy” audio compression (codec). The second is what is known as “jitter”.

Before understanding why lossy compression and jitter can be a problem for faxing, it is important to first understand what happens in fax communication.

If you'd like to skip the technical explanation, go straight to the conclusion.

How a fax works

Faxing involves two fax devices communicating generally for the purpose of passing one or more pages of image data from the sender to the receiver. This kind of data, as is most digital data, is ones and zeros. To communicate data over audio channels such as a phone line the data must be “modulated” ­ meaning that the data is transformed into an audio waveform that will be decodable by the other end to reproduce the ones and zeros that the data really is. Listening to this modulated audio you may describe it as “beeps”, “squawks”, “screeching”, or “static hiss”. Although indecipherable by a human ear, to the listening fax machine those noises have significant meaning.

Here is a picture representation (the audio waveform) of both sides of a fax call.

The audio from the fax receiver in the picture is on top, and the audio from the fax sender is on the bottom. Notice that most of the signaling is coming from the sender and that most of the time the receiver spends listening to the sender. Notice also that there are basically three different kinds of audio being represented: message signaling (the thick­ bar areas that are smooth on the top and bottom), image data signaling (the rough or fuzzy areas), and silence (the flat line). Lastly, notice that the fax machines do not send signaling at the same time. One sends signaling while the other listens. The listening machine knows that it is time to respond to a signal when silence begins after a period of signaling by the other end.

Lossy compression and jitter

Okay, so what is lossy compression and how does it affect fax calls?

Compression is when a string of source data is taken and then converted in some way into a smaller string. The interpreter on the other end must decompress the string to retrieve the original data. These different ways of compressing audio data are called codecs. Some codecs are called “lossless” which means that there is no loss in detail of the data when undergoing the compression and decompression exchange. Some codecs are called “lossy” which means that there is a loss of detail when undergoing the compression and decompression exchange; some detail is sacrificed in order to achieve a tighter compression (smaller compressed result).

Faxing cannot occur on lossy codecs because it will consistently remove data from the audio waveform. If you can get some faxes through then this is not the problem you're having.

A lossless channel does use more bandwidth than a lossy one. Consequently you would need to upgrade your network connection bandwidth if ever you have quality problems with the VoIP service. However, consider that a normal lossless phone call­ quality channel uses 64 kilobits per second of bandwidth. Chances are good, too, that your broadband connection is much bigger than that. But know that it is quite likely that more bandwidth will not resolve your VoIP quality problems. Usually fax problems on VoIP channels occur due to what is known as “jitter”, and usually an increase in available bandwidth does not necessarily reduce jitter.

Here are three visual examples of jitter found in faxes sent with a ATA. Pay close attention as to how they differ from the example above.

Notice that the message signal is interrupted with small gaps of near ­silence. Realize that the largest gap in that signal is only five one ­hundredths of one second (5/100 sec). The human ear would not likely detect it. Notice, however, that the receiving fax machine did notice it, and justly assumed that the transition to silence indicated that it was time for it to respond. Consequently both the sender and receiver start signaling at the same time and thus become asynchronous.

Here is another example of nearly the same thing, except that this time both the message signal and the image data signal are broken. Depending on how the receiving device is programmed a single instance of either of these problems may not necessarily doom a fax session. However, once the two fax endpoints lose synchronization the risk of failure is significantly increased because one or both of the endpoints cannot immediately hear correct signaling from the other. Unfortunately, even if they do resynchronize more jitter is likely to disrupt the communication again in the same call.

In this example of jitter the gaps in the audio stream appear only during the image data signal. In this case the receiver detected the end­ of signal at the first gap and then began patiently waiting for the message signal that should follow the image data signal. After enough time passed without yet detecting the message signal it gave up and disconnected.

Jitter on the network

In a VoIP call the audio is “streamed” between the two endpoints. This varies slightly from how, for example, downloading a music file from the internet works. All data sent across the internet is put into little pieces called “packets”, each packet has enough information on it to tell where it came from and where it's going. These packets are sent across the internet network and each of the various “hops” through the internet each station can potentially send the packet through a different route to reach the final destination. On the receiving end the receiver is expected to reassemble all of the packets to reproduce the original data.

Ultimately what happens in that process is that sometimes a station cannot handle a particular packet at a particular time. That station can delay the routing of that packet momentarily if needed. And, depending on the type of packet that the sender used, that station can even ignore and not relay the packet entirely.

Typical internet communications, like browsing an average web page or downloading a music file will not use the type of packet that can be ignored. If the internet stations are unable to relay it then it will be retransmitted. However, VoIP communications, much like most other “streamed” communications, use the type of packet that the internet stations are allowed to ignore if necessary. This is done to keep the audio from pausing at various points and to keep the audio as real­time as possible, like on a phone call with a typical phone line.

This typically works out perfectly fine for voice audio because the human ear does not pick up on the missing audio. And some ATAs, noticing the missing audio, will even synthesize some audio to fill in the gap (this is called a “jitter buffer”). However, both missing and synthesized audio constitute a corruption of the audio data from when it left the sender, and there is no immediate way for the receiver to recover the missing audio data. This is why the jitter you see represented above in the pictures shows up as gaps of silence. An intelligent jitter buffer may close or fill­in the gaps enough to prevent premature detection of a signal­end, however, there still will be missing audio. This missing audio is primarily what makes it difficult for fax to work over ATAs.

How this is different from traditional line behavior

On a traditional phone line audio data comes and goes on the network in a sequential manner that virtually guarantees that the audio sent from one end will be received by the other in the same order and timing as it left. Static and noise does, sometimes still occur on traditional phone lines. This is what it may look like:

In this case the three pages of this transmitted fax were ultimately received and delivered to the receiver exactly as the sender had sent them with no visual errors whatsoever. They were perfect copies of what the sender transmitted. So, why did the noise clearly visible here not affect the fax reception? There are at least these three reasons:

  • The audio corruption did not involve gaps of silence as commonly seen with faxes sent through an ATA.
  • The moments of noise actually consist of the true audio signal plus some added distortion. Fax machines are typically capable of filtering out many kinds of noises when added to the true audio signal.
  • The fax machines employed an error correction method (ECM) to request, retransmit, and recover any image data that did not make it through.

ECM should even be able to help some instances of fax & ATA trouble. However, that really depends on the frequency and regularity of the occurrence of jitter. If even a small amount of jitter occurs once every second then it will be extremely difficult for the fax session to succeed, even with ECM enabled. In fact, many fax machine manufacturers will advise you to disable ECM if you experience communications trouble.This advice really isn't a true solution to the problem. Rather, it merely tells the fax machines to accept imperfect page image data and worry more about letting the sender have the chance to transmit all of the pages instead of worrying about getting all of the page image data through perfectly. If imperfect or missing page image data is acceptable to you, then disabling ECM might help. Then again, it may actually make things worse (in the case that ECM was actually helping things).

What can be done?

Sending or receiving faxes using an ATA with the G.711 codec should be considered as a fallback mechanism. Alternatively:
  • Connect your fax to a T.38 compatible ATA
  • Connect your fax to a FXS card
  • Connect your fax to a dedicated analogue/ISDN line
  • Use the ESCAUX Fax server.

To increase your chances of success, try the following things:
  • Reduce the fax speed to 9600 bps
  • If the ATA does not support T.38, make sure it only uses the G711 codec
  • Disable the echo canceller and jitter buffer on the ATA
  • Try enabling or disabling ECM
  • Make sure the network link between the SOP and ATA is of optimal quality
  • Try different fax devices

Even with these tweaks, faxes over ATA remains less reliable than true TDM based connectivity.

This information is based on documentation from the Hylafax project.

-- 21 Jun 2011

Fax connected on an ATA using T.38

Fax over IP

Summary
Faxing over VoIP networks is unreliable. Sometimes things can be arranged so a fairly high percentage of faxes get through OK. It's occassionally possible to create setups that work 100% of the time. These are rare and unrepeatable setups. We need to use a proper fax over IP protocol, thanks to the T.38 standard it's possible to achieve consistent and reliable faxing across IP networks.

Don't believe faxing over VoIP protocols won't work? Heard that things will work OK if you use the G.711 u-law or A-law codec? Read on if you want to learn why things are much more complex than that.

Trying to live with faxing over VoIP networks

Sending faxes over VoIP networks usually fails. It is human nature to look for simple reasons for that, and simple cures. In reality, there are a number of reasons, and no certain universal cures. VoIP networks are designed to do a good job with speech. Carrying any sound other than a single voice speaking is not generally a system requirement. It shouldn't be too surprising if it works rather poorly.

Speed and codec limitations

The most common problem with sending a fax over VoIP networks is the easiest to deal with. A low bit rate voice codec is unable to carry a fast modem signal without severe distortion. Would you really expect an 8kbps G.729 codec to convey a 9.6kbps fax modem signal correctly? The only common codecs capable of adequately preserving fax modem signals up to 14400bps (V.17) are u-law and A-law.

Modern fax machines support even higher speeds, up to 33600bps (V.34bis). This rate is unlikely to work with any reliability across any VoIP connection, even when an A-law or u-law codec is used. The codecs will maintain the required signal quality, but the delay and jitter across the VoIP channel, even if it is a stable delay, will prevent the echo cancelers in most modems from training well enough.

(Fax)Modems don't like relativity

In the PSTN world, the network provides a constant delay for any particular call. The speed at which data enters the network is always the same as the speed at which it leaves. The end to end delay does not jitter, or make step changes in anything but exceptional circumstances (e.g. on automatic fail-over, if a fibre link fails). Modems require this. In an IP network jitter is a fact of life. It can be kept to a modest level, through the use of the QoS (quality of service) features available in a lot of IP equipment, but only if you control the network end-to-end. If the call passes across the open Internet there is no QoS control. So, in the long term the timing of a voice signal entering a VoIP network is the same as the timing as it leaves, but in the short term they can be very different.

If a VoIP network works only across a LAN or a QoS managed WAN link, there might be a near guarantee of zero packet loss, and fairly low jitter. Many people then assume the jitter buffer at the receiver will smooth out the modest jitter, and the received signal will perfectly match the transmitted one. They are often right, but there is no guarantee. There are many designs of jitter buffer. Most modern ones dynamically adapt the length of the buffer in some way, although many different algorithms are used. If the jitter is low, and dynamic jitter buffering is switched off, things may work well. If it cannot be switched off, the behaviour of dynamic buffering will generally upset a modem signal. Various algorithms will:

  • Guarantee some packet loss, by tuning the buffering until a small percentage of packets are declared late, and dropped. Dropping packets is actually built into these algorithms, and the results can be pretty good for voice. Trading a small number of dropped packets for somewhat less latency is a reasonable trade-off.
  • Adjust periods of silence in whole packet steps (typically 20ms). Certain silence periods in a fax signal are specified as 75+-20ms. 20ms jumps can push them out of specification.
  • Continuously adjust the timing of non-silent periods, using overlap and add techniques. This is the state of the art in jitter buffering for voice, but a complete disaster for a modem.

(Fax)Modems don't like silence suppression

Depending on its implementation in particular equipment, silence suppression can destroy a fax call. If silence suppression is enabled, a voice detector continuously monitors the call, looking for the presence of a real voice. Some of these are designed to focus purely on voice, and tend to reject other kinds of sound - e.g. modem tones. They may, therefore, not switch the audio path on and off cleanly when the modem signal starts and stops. Even if they do switch cleanly, the suppression algorithms usually modify the audio around the switching points.

During silent periods, comfort noise is usually introduced, to simulate the background noise you normally hear in a conversation. This might mean a period which should be silent, is actually significantly noisy. The receiving modem might not see a good enough "silence" for its signal detector to correctly declare the boundaries of the modem signal.

(Fax)Modems like a complete conversation

Modems need a continuous audio path. If there is packet loss the consequences are severe, but the actual effect depends a lot on the equipment in use. Lets say a 20ms packet of audio is lost in the middle of a page of fax. Obviously this is going to loose a bit of the image, but will it affect just a small stripe, or the rest of the page? If the receiving end emits 20ms of silence, the receiving modem will probably declare the end of the page. If the receiving end emits 20ms of some fill in sound, the receiving modem might be able to ride over the gap, depending on its design. If more or less than 20ms of some fill in sound is emitted, the remainder of the page will definitely not be received correctly. The receiving modem will not tolerate a jump in timing of that sort.

The bottom line

Fax, and other modem applications, operating over VoIP channels are quirky, and unreliable. This will not get better over time. It will get worse. In general, the more sophisticated the equipment gets in trying to make speech work smoothly, the worse it behaves for modems. In the near term (i.e. until all data applications are native IP applications) store and forward protocols, and protocols tailored to reasonably conveying modem data across an IP channel are the only way to achieve consistent results.

Fax over IP (FoIP) specifications

Most current fax machines lack an RJ-45 connector and a TCP/IP protocol stack. Few of even the latest models will connect directly to the Internet, even though the protocols for doing so have been standardised for several years. Only some quite high end machines seem to offer this. This means in a world increasingly moving to VoIP for telephony, support is needed for using conventional fax machines over IP channels until most of those machines are consigned to the scrap-heap. A standard has been developed for real time fax over IP : T.38.

So, what is T.38?

The T.38 recommendation is used for fax transmission in real time over the IP network. This means it is designed to work like traditional faxing. You call another fax machine, and send the fax as you want. Either fax machine could be a traditional fax machine connected to the PSTN, an ATA box, or similar; it could be a fax machine with an RJ-45 connector plugged straight into an IP network; it could be a computer pretending to be a fax machine.

There are some issues in trying to do FoIP well with traditional fax machines. Recent versions of the core fax protocol - T.30 - have introduced flags and features to allow newer fax machines to be Internet aware fax devices. These tie in to the T.38 specification. A few makers now say their fax machines are "Internet Aware" or "Internet Capable". This might mean the machines can connect directly to an IP network. It usually just means the machines are aware of the existence and qualities of T.38.

What does T.38 look like?

The original version of the T.38 specification defined two methods for transmission across an IP network based on UDP (UDPTL and RTP) - The version 1 added one method based on TCP (TPKT). At that time RTP was the emerging protocol for streaming media across IP networks. Instead of using that, T.38 defined its own method of packaging data within UDP packets, called UDPTL. This has now been accepted as a mistake, and an RTP based form of the protocol has been defined. The only method in widespread use is the non-RTP method, so that has to be implemented.

The T.38 specification says some odd things about when the UDP form is more suitable and when the TCP form is more suitable. In fact it seems that the TCP form should be used between two IP devices. When one of the machines is connected to an analogue phone line, the UDP form probably has to be used for its nearer real-time streaming qualities. UDP is, however, an unreliable protocol, and that could compromises the benefits of T.38 over trying to use fax over VoIP. T.38 recommendation make use of redundancy with UDPTL.

In what ways does T.38 outperform fax over VoIP?

The TCP form of T.38 used between Internet aware fax machine is very robust, it basically solves all the problems of using VoIP for fax. It is more efficient when packet impediments are minimal and the bandwidth is limited.

If one of the UDP forms of T.38 is used, it is common for each packet to contain a copy of the main data in the previous packet. This is an option, but most implementations seem to support it. This redundancy option makes T.38 far more tolerate of dropped packets than using VoIP. It requires two or more (depending of the number of redundant packets) successive lost packets to actually loose any data. The overheads in T.38 are so big, the extra data sent in each packet is hardly noticeable. If two or more successive packets are lost, T.38 will still have trouble. However, if that is a common occurrence, the network is probably quite bad, and VoIP performance will be poor.

Loosing a packet in a stream based on T.38 does not cause the modems to loose synchronization. This means two successive lost packets should only corrupt a section of an image. If the optional fax error correction (ECM) mode is used, there is a good chance that with a retry or two, a perfect image will be transferred. Not ideal, but functional.

Much of the robustness of T.38 doesn't come from what the specification says, but from the potential it offers for smart implementation. The trick is to work out the smartest implementation, which will not cause trouble with the many buggy implementations of T.30 which exist in commercial fax products.

The T.30 specification allows transmission of a page to be paused just before the end of any row of pixels. This is used as a method of flow control, by fax machines with slow paper handling. It can also be used by a T.38 implementation, to wait for more data when a packet is delayed or lost. This means a T.38 gateway can start sending a page as soon as it gets some data, without performing any jitter buffering. When there is little jitter, transmission delay is minimised. When jitter is bad, things will be delayed only as much as necessary. If packets are lost, and FEC is in use, the outgoing gateway can simply wait a while, to try to reconstruct the stream from the redundant information available when further packets arrive. If the required data is irretrievably lost, due to a burst of lost packets, transmission can continue with only the minimum possible page corruption.

HDLC transmission, used for the fax control messages, offers no similar way to precisely control flow. However, it is possible to achieve pretty good results. The HDLC protocol only supports flow control between HDLC frames. The full HDLC protocol allows frames to be aborted midway, and restarted. However, the protocol as definition in the T.30 specification doesn't include the abort feature. If we wait until we have received the whole of a long frame, before starting to pass it on, we could introduce substantial delay. However, this is not a big problem for T.30 fax transmission. Most of the HDLC frames used in the T.30 specification are quite short, especially the ones which occur between pages. Delaying until we receive all the data for one of these messages will not significantly extend the call. To avoid long delays for very long frames we can apply rules like: if a frame is no more than 30 bytes (1 second) long we wait for the whole frame to be received before passing it on; if the frame is longer we start passing it on with a 1 second delay.

Source of this document: http://www.soft-switch.org/foip.html

Miscellaneous

Finding the operator for a Belgian DDI

The (Belgian) operator to which a DDI belongs to can be queried at http://www.crdc.be/

Do you need a certificate or special license for the usage of the "On-Hold" music ?

Escaux does not provide a certificate or special license: we sell our products in many countries and each country has its own laws with respect to on-hold music.

The default on-hold music ( "L'Attentive, EHMA") has the license "Art Libre 1.3". This license grants the user the permission to to use, copy and distribute the material. : http://artlibre.org/ . You will find the music on the following page: http://www.archive.org/details/LesTempsModernes

The audio files fpm-calm-river.mp3, fpm-sunshine.mp3 and fpm-world-mix.mp3 included in the Music On Hold module have been licensed to the company Digium in a way to authorize them to distribute the files worldwide free of charge with any Asterisk Installation. See below the LICENCE file : 

Music Provided By www.freeplaymusic.com. These sound files are provided by
Digium under license from Freeplay Music Corporation for use in conjunction
with the Asterisk software only.

Some more information on the Digium blog : http://blogs.digium.com/2009/08/18/asterisk-music-on-hold-changes/

How can I protect my system against abuse?

Please consult our security recommendations for general guidelines.

Copyright © Escaux SA