Introduction

FreeTDM is a library implementing unified high level API for both signaling and I/O for multiple telephony boards (Digium and Sangoma are most popular). FreeSWITCH uses a module called "mod_freetdm". If you come from Asterisk world, think of FreeTDM as you think of chan_dahdi, with the major difference that FreeTDM is nicely structured as a library so it can be used in other applications.

FreeTDM uses a modular architecture to plug different signaling stacks below. For example, FreeTDM can use libpri for PRI support. However also can use other PRI stacks, like the telco-grade stack from Trillium that Sangoma offers (free of charge).

FreeTDM has been designed to work with multiple boards from multiple vendors. The most well known and used vendors are Digium and Sangoma. In order to expose a common API for different hardware I/O modules are needed. There are three I/O modules in FreeTDM as of this writing, one for every hardware layer supported.

I/O modules

Sangoma (ftmod_wanpipe): This module uses native Sangoma API (libsangoma) which is installed when you install the Wanpipe drivers. More information on the Wanpipe drivers can be found at Sangoma's wiki: http://wiki.sangoma.com/, this module can only be used with Sangoma cards and is the recommended option for anyone with a Sangoma card.

Zaptel/DAHDI I/O module (ftmod_zt): This module supports the DAHDI interface. It also supports the old Zaptel interface but its usage is discouraged and you are not likely to get support from developers if you use Zaptel. The DAHDI interface is used by several hardware vendors, including Digium, Redfone, Sangoma and Xorcom (although Sangoma can work in DAHDI mode, it's recommended to use the native Sangoma mode via ftmod_wanpipe).

PIKA (ftmod_pika): This module is intended for PIKA boards.

I/O modules take care of writing and reading raw data and executing commands in the boards, but do not do anything else. All high level intelligent telephony signaling is handled by the FreeTDM signaling modules.

Signaling modules

FreeTDM supports PRI, BRI, SS7, MFC-R2 and Analog (and some others) signaling. One thing to keep in mind is, there is no single module per signaling. You may have different options within the same signaling. So for example, for PRI you can choose between 3 different stacks. Hopefully the following description will help you decide.

ISDN Modules

Sangoma ISDN module (ftmod_sangoma_isdn): Offers telco-grade Trillium stack to provide both PRI and BRI signalling support (only supported with Sangoma cards). In order to install this you must have libsng_isdn already installed. For more information about installation and configuration for this module you can go here: http://wiki.sangoma.com/Freeswitch-FreeTDM-Sangoma-ISDN-Library

LibPRI module (ftmod_libpri): Offers support for PRI lines using the open source libpri stack for any type of card supported by FreeTDM (i.e. Sangoma and Digium). In order to install this module you must have libpri already installed. Now supports both PRI and BRI signalling (since 3d5ccf05 on 06th Nov). You must be using a version of libpri that supports BRI to get that support (libpri-1.4.12_beta1 or newer). As features are added to libpri, this module must be updated to support them.

Native ISDN module (ftmod_isdn): First stack ever supported by FreeTDM for PRI lines. This module is still under development and is not considered stable.

SS7 Modules

Sangoma SS7 module (ftmod_sangoma_ss7): Offers telco-grade Trillium stack to provide SS7 signaling support (only supported with Sangoma cards). In order to install this module you need libsng_isdn library from Sangoma and you also need to get a commercial license key. Contact Sangoma for more information.

MFC-R2

OpenR2 module (ftmod_r2): Offers MFC-R2 support in E1 lines for any type of card supported by FreeTDM (i.e. Digium and Sangoma). In order to compile this module you need to have the openr2 library installed (latest SVN trunk is required). http://www.libopenr2.org/

For more information about how to configure MFC-R2 support go here: FreeTDM_OpenR2

Custom protocols

Boost (ftmod_sangoma_boost): Deprecated module offering support for the boost protocol to access PRI, BRI and SS7 signaling daemons for Sangoma cards. In order to compile this module you need to have SCTP libraries and development headers. Again, this module is DEPRECATED, DO NOT USE IT, the best way to use a Sangoma board is using ftmod_sangoma_isdn for BRI and PRI, ftmod_sangoma_ss7 for SS7 signaling and ftmod_analog and ftmod_analog_em for Analog protocols.

Tapping

PRI tapping (ftmod_pritap): This module is used to tap (passive monitoring) PRI lines (you cannot place calls, just monitor calls from other T1/E1 links). It's been tested only on Sangoma cards, but it may work with other vendors. In order to compile this module you must have libpri installed and run the FreeTDM ./configure script with the option "--with-pritap"

Installation

FreeTDM is a library and as such can be installed alone, no need of FreeSWITCH. However, to do anything useful with it, you either need to write your own application, or use FreeSWITCH. As FreeTDM was born as a part of FreeSWITCH, the source code is still part of the FreeSWITCH main code repository. If you just want FreeTDM as an API there is no need to install FreeSWITCH.

Dependencies

Some FreeTDM modules depend on other libraries, and those libraries are detected during the ./configure step, therefore you must install the dependencies beforehand otherwise the modules you want won't be built.

ftmod_wanpipe depends on the Wanpipe headers and libsangoma to be installed. You must install the Wanpipe drivers before configuring the FreeTDM build if you want that module.

if the mod/ftmod_libpri.* files are not installed, you may need to specifically compile them... libpri now depends on dahdi. edit Makefile and look for the line that starts with 'UTILITIES='. Remove everything on the line except 'UTILITIES='. The test scripts are not needed if you are not using dahdi.

Low level drivers

In case of DAHDI, low level drivers have to be installed. Luckily there is a ready-to-be-built git tree to install the Digium DAHDI svn latest trunk + zaphfc driver + OSLEC echo canceller. However, DAHDI devices are owned by asterisk:asterisk by default. They must be changed to freeswitch:freeswitch before installing.

FreeTDM with FreeSWITCH

If you want to use FreeTDM along with FreeSWITCH, the installation is pretty easy. The FreeSWITCH ./bootstrap and ./configure scripts take care of configuring FreeTDM build too. The only additional step is open modules.conf and uncomment the line: ../../libs/freetdm/mod_freetdm, this will tell the build system you want mod_freetdm to be compiled. This module is necessary to glue FreeSWITCH with FreeTDM.

Having freeswitch working with freetdm and ftmod_sangoma_isdn you have to do this:

Download libsng_isdn version 1.2.0+

As root

Unpack

make install

Download wanpipe version 3.5.17+

Unpack

make freetdm

make install

Download Freeswitch (e.g. (git-d872408 2010-11-09 19-29-19 -0500))

bootstrap.sh

uncomment mod_freetdm in modules.conf

configure

make all; make install

Configure Wanpipe and FreeSWITCH for sangoma_isdn

As root

wancfg_fs

Maybe you want to check file permissions of conf/freetdm.conf, conf/wanpipe.conf and conf/autoload-configs/freetdm.conf.xml if you run FS as non-root user

Add d-channel in conf/freetdm.conf (e.g. d-channel => 1:16)

Start FS or load mod_freetdm

FreeTDM API

FILL ME!!

Configuration

Main Config files

/etc/freeswitch/freetdm.conf - sets up the spans from the driver and configures the library (the freetdm library)

/etc/freeswitch/autoload_configs/freetdm.conf.xml Sets context and several parameters

/etc/freeswitch/tones.conf Needed for dialout to work and more.

Each config is explained further below in it's own section

FreeTDM Configuration

The FreeTDM library takes care of opening the span devices and configuring the I/O options. No high level signaling configuration at all is done by the library at startup. This configuration file is called freetdm.conf and is a simple text file (the few people using the C API of FreeTDM have the option of configuring via API and not via configuration file if they want to). The exact path to the file depends on the --prefix= option provided to the FreeTDM ./configure script. If you used FreeSWITCH build system then it'll be the same --prefix option you used for FreeSWITCH, which by default is /usr/local/freeswitch, and the full path to the config is /usr/local/freeswitch/conf/freetdm.conf

freetdm.conf

The freetdm.conf file has a simple format (not XML) and in that file you configure which spans and channels to use, the trunk type, groups, audio gains.

Some rules for the syntax of the file are:

There is an optional [general] section that can be used for global configurations.

FreeTDM spans are channel containers and each span definition starts with the word span, its type and name within brackets (i.e. [span wanpipe mySpanName]).

Any channel must be placed within a single span configuration. The channels definition should be after the parameters the channel intents to use (order matters, just like Asterisk's chan_dahdi.conf).

If you start any line with either ';' or '#', the line will be ignored.

The special string "__END__" can be used at the beginning of a line to stop parsing the file (useful if you want to ignore the rest of the file at a given point).

The ';' character can be used for comments at any place within a line.

Both, '=' and '=>' can be used as the character to separate parameter name from parameter value.

How you configure this file will depend on which hardware layer you use (i.e. Wanpipe or DAHDI) and your particular scenario. The general syntax for the file is.

group - The group name for outbound dialing. You can put here any string, but it must start with a letter to avoid confusion with span numbers. Any channels below this group parameter will be added to the group for channel hunting during outbound dialing.

txgain - The audio gain for transmission. Any float value. Very big float values will result on clipping of the audio though. Typical values range from -5.0 to 5.0.

rxgain - The audio gain for reception. Any float value. Very big float values will result on clipping of the audio though. Typical values range from -5.0 to 5.0.

number - This is only used for FXO to set an incoming DNIS to a fixed number.

In addtion to the previous parameters, you must also define which type of channels to add to the span. Any parameters before the channel parameter will affect the channel settings (again, like Asterisk chan_dahdi.conf).

The valid value format for xx-channel parameters depends on the I/O type (hardware layer) (either wanpipe, zt or pika). Details are included in the next sections.

In addition to freetdm.conf, a few other files are optional configuration.

The following files are used by the I/O modules as global configuration:

zt.conf

wanpipe.conf

pika.conf

The settings in those files are global in nature and specific to the I/O module in question. All parameters must be below a [defaults] section.

zt.conf accepted parameters:

codec_ms - Number of milliseconds to configure the read/write rate for the channels. (defaults to 20)

wink_ms - How many milliseconds to wait to detect a wink. (defaults to 150)

flash_ms - Duration in millisecond of the flash (on-hook / off-hook).

echo_cancel_level - Echo cancellation level in the DAHDI driver.

rxgain - Tx gain in the DAHDI driver.

txgain - Rx gain in the DAHDI driver.

wanpipe.conf accepted parameters:

codec_ms - Number of milliseconds to configure the read/write rate for the channels. (defaults to 20)

wink_ms - How many milliseconds to wait to detect a wink. (defaults to 150)

flash_ms - Duration in millisecond of the flash (on-hook / off-hook).

Wanpipe mode

In this mode you do not need to have Zaptel nor DAHDI installed. You will need recent version of the Wanpipe drivers (using latest always recommended) and compile them in TDM Voice API mode, you can follow the ./Setup script instructions. You can also just "make freetdm && make install" in the Wanpipe drivers directory for a quick installation of the drivers in the proper mode.

So you can add either a single channel or a range of channels within a span. The wanpipe devices are populated in the Linux file system by "wanrouter start" Wanpipe command at the /dev/ directory. For Windows you can look at them using the Windows device manager.

As an example, for a range of channels from 1 to 23 in span 4, devices ranging from /dev/wanpipe4_if1 to /dev/wanpipe4_if23 will be created in Linux file system and you can add them to freetdm.conf like this:

[span wanpipe trunk1]
trunk_type => T1
b-channel => 4:1-23

The key here is "wanpipe" is set as the I/O type in the span definition and the xx-channel (in this case a b-channel) syntax is <wanpipe span number>:<range of channels>. Because in Wanpipe the devices are created per span, the channel count is not global for all spans, but rather per span (note the difference with DAHDI where the channel numbers keep growing across spans).

This is an example for 2 spans (span 7 and 10) that will be used as a T1 PRI link.

The wanpipe spans must have been previously configured in /etc/wanpipe/ by Sangoma configuration tools (check http://wiki.sangoma.com/ for details). Keep in mind only spans configured as TDM_VOICE_API in wanpipe*.conf can be used together with spans configured with I/O type wanpipe in freetdm.conf

DAHDI mode

DAHDI mode can be used by any hardware that implements the DAHDI interface, including Sangoma and Digium cards (yes Sangoma supports both Wanpipe and DAHDI modes in FreeTDM) and Redfone foneBRIDGE2 T1/E1 to Ethernet bridges. Sangoma cards are better used in Wanpipe mode. The only scenario where you may need to run a Sangoma card using DAHDI interface is when your particular card does not have HDLC engine (like Sangoma B601) and you need HDLC performed in the software drivers. Because the wanpipe drivers still do not perform the HDLC in software, if you have a Sangoma B601 you must use DAHDI mode, otherwise please use Wanpipe mode for better support with Sangoma cards.

Digium cards on the other hand should always be used in DAHDI mode.

DAHDI mode is most likely compatible with Zaptel mode, but Zaptel is deprecated. This mode depends on "ftmod_zt.so", which is always compiled, regardless of whether you have DAHDI or Zaptel headers. On runtime, FreeTDM will try to determine (checking the existence of /dev/zap/ctl or /dev/dahdi/ctl) which one are you using.

In a typical DAHDI installation, the freetdm.conf file will be a basic mirror of the contents /etc/dahdi/system.conf (or /etc/zaptel.conf if using zaptel), but you still need them because they are used by dahdi_cfg or ztcfg to configure the hardware.

As an example, for a range of channels from 1 to 23 in span 1, devices ranging from /dev/zap/1 to /dev/dahdi/23 will be created in Linux file system and you can add them to freetdm.conf like this:

[span zt trunk1]
trunk_type => T1
b-channel => 1-23

The key here is "zt" is set as the I/O type in the span definition and the xx-channel (in this case a b-channel) value is just a range of channels. Because in DAHDI the channel count is global for all spans, so the next span will start at channel 25 (assuming span 1 has 24 channels).

This is an example for 2 spans (span 1 and 2) that will be used as a T1 PRI link.

As you see, in DAHDI the syntax for the xx-channel parameters is just a range of channels which is global for the whole system, no span is specified (as opposed to wanpipe mode where the span is specified).

You can setup freetdm.conf to have channels like the system.conf, however in at least one instance this caused problems with calls over channel 16. Splitting the channels out over a few lines solved that issue.

freetdm.conf.xml Configuration

Once the library is configured, if you are using FreeSWITCH (other users may use only the library to build custom TDM applications), you have to tell FreeSWITCH which signaling settings to use and where to send the incoming calls to. This is done through /usr/local/freeswitch/conf/autoload_configs/freetdm.conf.xml (assuming you have default installation path for FreeSWITCH).

The name attribute of the tag *MUST* match a span name in freetdm.conf, this is how FreeSWITCH knows which span you want to configure with that signaling.

Many parameters on the section depend of the signaling module section where they live. Every span must be inside a signaling module tag. Each signaling module has its own unique tag identifier.
The dialplan and context parameter are accepted by all signaling modules. But other than that every span must be configured with parameters supported by its signaling module. These are the signaling module
tags that you can use in freetdm.conf.xml

<analog_spans> </analog_spans> - Spans will be configured by the signaling module ftmod_analog.

<analog_em_spans> </analog_em_spans> - Spans will be configured by the signaling module ftmod_analog_em.

<boost_spans> </boost_spans> - Spans will be configured by the custom protocol module ftmod_sangoma_boost to access SS7, PRI and BRI lines.

Refer to the samples included in the freetdm sources inside the conf/ directory for more information on the parameters for the spans on each signaling section.

There are a lot of fields/parameters to configure - for a full list look at the source code of appropriate module.
For example, for ftmod_sangoma_isdn - look at [FSW_dir/libs/freetdm/src/ftmod/ftmod_sangoma_isdn/ftmod_sangoma_isdn_cfg.c :: ftmod_isdn_parse_cfg(2)]. For example, to send CONNECT ACK for outgoing calls (which is optional according to ITU-T Q.931, Figure A.2/Q.931 – Overview protocol control) use "send-connect-ack" parameter.

Here is one working example for HFC-S BRI PCI cards. There are still problems with other devices on the S0-bus, but it works as a single device on the S0 so far.

tones.conf

Some components in freetdm (mainly the ftmod_analog module) uses tones.conf for tone generation and detection. The dial tone is particularly crucial for dialing out. If you use analog interfaces and you want to dial out you must make sure the configuration in tones.conf is correct for your country, otherwise FreeTDM won't dial in lines without dial tone (or a dial tone that cannot detect).

Dial Plan

When using mod_freetdm to use FreeTDM with FreeSWITCH. You need to add dial plan rules to use your FreeTDM lines.

Ascending vs. Descending Channel Selection

FreeTDM supports automatic selection of the channel within the span. Use "a" for ascending (lowest-numbered channel available) and "A" for descending (highest-numbered channel available).

Examples:

<!-- Ascending, i.e. start at channel 1 and work up -->
<action application="bridge" data="freetdm/1/a/${destination_number}>
<!-- Descending, i.e. start at "the top" (e.g. 23 in T1) and work down -->
<action application="bridge" data="freetdm/1/A/${destination_number}>

Sangoma A200 with Software Echo Cancellation

If you have a non-D series A200 card, it will be unusable without software echo cancellation. As of 03/11 the native wanpipe docs on the sangoma wiki do not account for this. It is not possible to use a Sangoma A200 series with software echo cancellation in "Wanpipe-native" mode. Instead, use wanpipe with dahdi. (Also, hangup detection may not work without software echo cancellation. It may work better once mg2 cancellation is working, and it may just work right with oslec. This has been reported with Gentoo-64.)

HINT: Build in wanpipe-native mode, then return here and try this:

STEPs 1:
Compile and install dahdi, dahdi-tools, and libpri

STEPs 2:
Compile and install the latest wanpipe driver with "./Setup dahdi" in the wanpipe driver source dir. Ignore the parts about "Asterisk"

... same thing with Oslec instead of mg2 software echo cancellation

STEP 3:
Set "echocanceller=oslec,X", where X is the span number of your A200, in /etc/dahdi/system.conf.

Sangoma G.722 ISDN calls

As of May 19th 2011, Sangoma cards may be used to make and receive TDM calls using G.722 codec (or any other codec that can fit in the TDM 64kbps data stream).

The way it works is based on the "unrestricted digital" bearer capability available in ISDN circuits. A typical voice call will be sent to the telco (or the telco will send it to us) using the default bearer capability "speech". However, using "unrestricted digital" is understood that the data in the B channel could be just about anything. You must configure FreeSWITCH to decide the codec to use, in this case G.722. In your Sangoma span XML configuration (for example, just below <param name="context" value="xx" />) you set this parameter:

<param name="unrestricted-digital-codec" value="G722@8000h" />

That instructs FreeTDM to setup G.722 codec for all unrestricted digital calls.

In order to originate calls with bearer capability "unrestricted digital", you must call the bridge application like this:

Delivered by ftmod_sangoma_isdn API

ftmod_sangoma_isdn is basing on Sangoma's libsng_isdn library. You have to download and install it befor you run FS's configure script.

To enable partial runtime decoding of q921 or q931 messages on a span

ftdm sangoma_isdn trace <q921|q931> <span_name>

Call this for both q921 and q931 to have both decoded

To disable decoding of q921 and q931 messages on a span

ftdm sangoma_isdn trace disable <span_name>

To get layer 1 statistics from span (derived from wanpipe I guess)

ftdm sangoma_isdn l1_stats <span_name>

To get a short status report of each span

ftdm sangoma_isdn show_spans

SIP-Headers

If parameter "sip_headers" is enabled in freetdm.conf.xml the you can control mod_freetdm with the following headers:

X-FreeTDM-CallerName

X-FreeTDM-CallerNumber

X-FreeTDM-ANI

X-FreeTDM-ANI-TON

X-FreeTDM-ANI-Plan

X-FreeTDM-ANI2

X-FreeTDM-DNIS

X-FreeTDM-DNIS-TON

X-FreeTDM-DNIS-Plan

X-FreeTDM-RDNIS

X-FreeTDM-RDNIS-TON

X-FreeTDM-RDNIS-Plan

X-FreeTDM-Screen

X-FreeTDM-Presentation

Channel Variables

Info

freetdm_span_name

freetdm_span_number

FreeTDM span number for an incoming call.

freetdm_chan_number

FreeTDM channel number for an incoming call.

ftdm_usage 1 1

Checks if span 1 channel 1 has 0 calls so we know if the line is free to make a call. Note there is an inherent small race between the time you check and the time you try to use the channel, but likely good enough for the real world. Could be applied in dialplan as:

<condition field="${ftdm_usage 1 1}" expression="^0$">
</condition>

Control

freetdm_bearer_capability

freetdm_bearer_layer1

freetdm_outbound_ton

freetdm_custom_call_data

Applications

disable_ec

Disable echo cancelation on this call.

disable_dtmf

Disable DTMF detection on this call.

enable_dtmf

Enable DTMF detection on this call.

Mailing List FAQ

This is a collection of questions and answers from the FreeSWITCH mailing list.

FreeTDM partial spans, group dialing and trunks

I have oodles of FXO ports configured on Xorcom Astribanks. On the Astribank
each set of 8 FXO ports forms a zaptel/openzap/freetdm span.
Now if a trunk consists of an integral multiple of 8 FXO ports it is easy to
just dial out on the first available channel:
<action application="bridge" data="freetdm/1/a/$1|freetdm/2/a/$1"/>
This grabs the first available channel out of 16 FXO ports.
But what is the "right" way to do it when I need to use 1.5 spans (i.e. 12
FXO ports)?
Is there such a thing as a virtual span that can be built out of individual
FXO ports?

The answer:

You can create spans with channels from any other span (as long as the
signaling is the same).
[span zt xorcomSpan]
; channels from 1.5 trunks
fxo-channel => 1-12
Then dial:
<action application="bridge" data="freetdm/xorcomSpan/a/$1/>
You can also just define a group for those channels and use the group
for dialing.
[span zt xorcomTrunk1]
trunk_type => FXO
group => xorcomg1
fxo-channels => 1-8
[span zt xorcomTrunk2]
trunk_type => FXO
group => xorcomg1
fxo-channels => 9-12
Then dial using the group name.
<action application="bridge" data="freetdm/xorcomg1/a/$1/>
This means spans and groups are strings within the same name space (as
far as hunting is concerned), and you should not make them conflict.

The question in this thread refers to "virtual spans". In FreeTDM, all spans declared in freetdm.conf are virtual or logical, however you want to call them. Meaning the FreeTDM span structure it's just a channel container. The actual channels may belong to different physical spans. You can do things like:

This freetdm.conf file creates a span containing B channels from 2 physical E1's. A span of type "wanpipe" was used for this example because is clearer that channels from 2 spans are being put in a single span. For zt I/O spans this looks like:

This super spans, or logical spans that are composed of channels across physical spans are actually used for some signaling types like "boost", which requires all b-channels in a single span. That module however is deprecated, and is not recommended to group channels like that (because some other signaling modules assume all channels in a span come from a single physical span).

Note that, although for analog modues it's supported to add channels from any physical span to any FreeTDM span, it's not recommended for other signaling modules (like PRI, BRI). Group dialing was introduced to stop using FreeTDM logical spans as dialing groups. If you need to group channels for dialing purposes, use the "group" parameter to add the channels to a given group.

FreeTDM Screening Indicator

Hi,
I have a server with FreeSWITCH (latest GIT revision) + FreeTDM with some
Sangoma A108 boards.
I have the necessity to set, for outgoing calls, the ISDN information
element "Screening Indicator" of calling party number.
I have see that some information element can be set in the
"freetdm.conf.xml" file (i.e. calling and called typer of number or
numbering plan) but I have not found any reference to the screening
indicator.
If there is no way to specify this information element for each trunk, it's
possible to change its default value (that is 01=user provided, verified and
passed)?
Thanks,

The answer:

To check the value on incoming call, try the screen_bit variable from the dial plan:
${screen_bit} which will be either true or false.
To set it for outgoing calls, try using the privacy application that FreeSWITCH has.
<action application="privacy" data="on" />

Can you check what type of L1 errors you are seeing:
from FS cli:
ftdm sangoma_isdn l1_stats wp1
Can you also check if wanpipemon is reporting errors:
wanpipemon -i w1g1 -c Ta
(repeat a couple times to see if any of the alarms are continuously
toggling or the number of errors at the bottom keep incrementing)

How to identify whether a port in a card is a problem

The question:

How to check whether there is a problem with the ports in the Sangoma card that you have?

The Answer:

You need to check by using loopback.

Single port loopback:

+-------+
| |
1 2 4 5
| |
| |
+-------+
You need to configure the port as MASTER to get the clock signal. Otherwise tx will expect clock
from rx and rx will expect clock from tx, and port won't show "Connected" status.
If it shows "Connected" then most probably there is no problem in the port

If you are using a CSU with the sangoma card, you can simply put the CSU in loopback mode and start sending out the test patterns

What is YELLOW alarm

The question:

What is meant by YELLOW alarm? Will I be able to simulate to get better understanding?

The Answer

Of-course yes. You can generate the YELLOW alarm as follows.
Make a Loopback cable as follows:
PORT A PORT B
+---------------------------------------+
| +-----------------------+ |
| | | |
1 2 4 5 1 2 4 5
| | | |
| +-----------------------+ |
+---------------------------------------+
Configure the clock of PORT A as "NORMAL" and PORT B as "MASTER".
Remove the 1 and 2 pins, in PORT B. You will get "YELLOW" alarm on PORT B.
In PORT A, it will have "Remote Alarm Indication" = "ON". ( wanpipemon -i w1g1 -c Ta )
PORT A will be in "Connected" state ( since it gets the packet sent by PORT B.
PORT B will be in "Disconnected" state.

Here is the explanation:

Once PORT B is unable to receive any message from PORT A, it will send a indication saying that
"I'm unable to receive you" in the Tx (pins 4,5), and it will set the "YELLOW" alarm on. Then
PORT A finds that, PORT B is not receiving packets which is sent by PORT A, and it will enable the "RAI".
(Red Alarm Indicator). Alarm recovery time can vary from equipment to equipment. Yellow alarm is also
known as AIS on some equipment.