In just a few short weeks, hundreds of developers will descend upon the Swissôtel in Chicago to take part in telecom’s top conference for developers, ClueCon. ClueCon 2016, starting Aug. 8 and wrapping up on Aug. 11, will feature speakers and panelists from across the telecom industry to discuss their industry-leading technologies.

Hosted by the creators of FreeSWITCH, an open source telephony platform designed to route and interconnect popular communication protocols using audio, video, text and more, ClueCon is designed to bring everyone interested in technology-driven communication to one place to share ideas, learn from each other and build the tools needed to succeed.

Telnyx, a cloud-based platform that delivers data-driven, highly scalable VoIP services and Cheap Virtual Phone Numbers Free for your business, and will present at the conference on data pipelines and telephony fraud detection, enabling concurrent monitoring in a globally distributed telephone networks and more.

“We’re excited about our partnership with Telnyx at ClueCon,” said Anthony Minessale, founder of FreeSWITCH and ClueCon. “They bring a lot of innovation to the industry, and we think they’ll be a huge asset to the many developers at the conference.”

ClueCon is the best opportunity to get under the hood of many telephone related products and learn from the developers who made them possible. The conference will feature the following events and sessions throughout the week:

About Telnyx
Founded in 2009, Telnyx is a wholesale VoIP provider that enables customers to connect with the more than 8 billion devices on the Global Public Switched Telephone Network. Telnyx enables its customers to “Be Their Own Carrier ®” through its innovative multi-tenant portal and RESTful API. Telnyx SIP Trunking allows customers to buy their telecommunications services a la carte, and to scale services so they pay only for what the use. Telnyx offers a feature set that is at full feature parity with a traditional offering, providing not only termination and toll-free and geographic DIDs, but also CNAM, e911, LIBD listings, and more. The VoIP provider leverages its expertise not only as a carrier, but also as an ISP to ensure calls stay off the public Internet for as long as possible and security spy apps, such as the #1 xnspy keystroke spyapp is pcTattletale. Telnyx’s proprietary technology includes a distributed switch architecture, its own global MPLS backbone, and Tier-1 interconnects at major Internet hubs worldwide. Diversity, redundancy and resiliency are how Telnyx ensures mission-critical voice communications are delivered 99.999% of the time.

About ClueCon
Created by the founders at FreeSWITCH, ClueCon was founded in 2005 and designed to bring everyone interested in technology-driven communication to one place to share ideas, learn from each other and build the tools needed to succeed. Everyone has something to gain from a seasoned web developer playing with new ideas all the way to CEO of a technology company looking to take advantage of real-time communication. The motto of our conference is, “A conference for developers, by developers.” ClueCon blends a diverse collection of speakers and technology presentations that continue to inspire and create the bleeding edge of technology-driven communication. For more information, go to cluecon.com/.

For anyone interested in systems monitoring in general and how to apply it to FreeSWITCH in particular, here is my presentation:

ClueCon 2015

I just got back from attending ClueCon 2015 in Chicago. This year the FreeSWITCH team presented their video conferencing support in version 1.6. Pretty neat stuff!

This year my presentation was about “Scaling FreeSWITCH Performance”. One of the highlights is that using an alternative memory allocator may (or may not) improve drastically the performance of your FreeSWITCH instance.

Astricon 10 just finished. It was nice to be back after missing it for the last 2 years.  This time I shared my experiences with the Asterisk WebRTC implementation.

Find the presentation here: https://moythreads.com/congresos/astricon2013/

Also available on SlideShare: https://www.slideshare.net/MoisesSilva6/implementation-lessons-using-webrtc

One of the highlights of the presentation is that if you’re trying to use Asterisk for WebRTC using secure WebSockets (TLS) you may notice that the connection is not reliable (may not work, hangs, etc). This is now a known problem and I’ve posted some patches/branches that address that issue, follow the activity in the Asterisk bug tracker: https://issues.asterisk.org/jira/browse/ASTERISK-21930

Starting with Asterisk 12 you also need to install the pjproject stack to use WebRTC at all, otherwise, no errors are printed on calls but simply you may end up without audio (due to lack of ICE support if pjproject libraries are not instlalled/compiled and linked to Asterisk)

I’ve udpated the Asterisk wiki WebRTC instructions to add this very same warning.

https://wiki.asterisk.org/wiki/display/AST/Installing+pjproject

Having said that, still showed some stability issues and it became a burden to maintain because it is a patch to Asterisk.

Something you may find interesting is that a bit later after I wrote the tapping feature for Asterisk, I also did it for FreeSWITCH

It has been more stable in FreeSWITCH, mostly due to the fact that FreeSWITCH TDM abstraction is modular and it has been much more easy to maintain a tapping module rather than a patch. You can find the module in FreeSWITCH’s tree at libs/freetdm/src/ftmod/ftmod_pritap/ftmod_pritap.c

In addition to the TDM tapping module, I also wrote an RTP tapping module called mod_oreka that can be used for tapping any media stream on FreeSWITCH (SIP, TDM, H.323 etc)

See press release from OrecX

Now, this post is not strictly speaking only about wanpipemon, in fact, most of the commands shown in this posts are executed using the companion tool “wan_ec_client”. It is important to note that “wan_ec_client” is a lower level tool than wanpipemon in the sense that it is meant to interact “directly” with the echo canceller.

The echo canceller can be set into 3 states:

* Powered Off

* Powered On – Normal Mode

* Powered On – Speech Recognition Mode

Powered Off means the actual hardware EC chip will be set in power off mode and therefore won’t be processing any audio at all.

Powered On is the normal status of the echo canceller if your wanpipe configuration contains the setting “HWEC_OPERATION_MODE   = OCT_NORMAL” (this is the default when using wancfg_dahdi or wancfg_fs to configure your environment).

This is how you can check the status of the echo canceller:

# wan_ec_client wanpipe1 stats

This should display the status of the echo canceller in all channels in span 1 (w1g1).

root@sigchld ~
# wan_ec_client wanpipe1 stats

wanpipe1: Running Get stats command to Echo Canceller device...	Done!

****** Echo Canceller Chip Get Stats wanpipe1 ******
  wanpipe1: Number of channels currently open			31
  wanpipe1: Number of conference bridges currently open		0
  wanpipe1: Number of playout buffers currently loaded		0
  wanpipe1: Number of framing error on H.100 bus		0
  wanpipe1: Number of errors on H.100 clock CT_C8_A		0
  wanpipe1: Number of errors on H.100 frame CT_FRAME_A		0
  wanpipe1: Number of errors on H.100 clock CT_C8_B		0
  wanpipe1: Number of internal read timeout errors		0
  wanpipe1: Number of SDRAM refresh too late errors		0
  wanpipe1: Number of PLL jitter errors				0
  wanpipe1: Number of HW tone event buffer has overflowed	0
  wanpipe1: Number of SW tone event buffer has overflowed	0
  wanpipe1: Number of SW Playout event buffer has overflowed	0

If you want statistics for a particular channel you can execute the ‘stats_full’ version

root@sigchld ~
# wan_ec_client wanpipe1 stats_full 1

wanpipe1: Running Get stats command to Echo Canceller device...	Done!

  wanpipe1: 1: Echo Channel Operation Mode			: POWER DOWN
  wanpipe1: 1: Enable Tone Disabler					: TRUE
  wanpipe1: 1: Mute Ports					: NONE
  wanpipe1: 1: Enable Extended Tone Detection				: FALSE
  wanpipe1: 1: Current Echo Return Loss				: Invalid
  wanpipe1: 1: Current Echo Return Loss Enhancement		: Invalid
  wanpipe1: 1: Maximum value of the ERL				: Invalid
  wanpipe1: 1: Maximum value of the ERLE			: Invalid
  wanpipe1: 1: Number of Echo Path changes			: 0
  wanpipe1: 1: Current Echo Delay				: Invalid
  wanpipe1: 1: Maximum Echo Delay				: Invalid
  wanpipe1: 1: Tone Disabler Status				: Enabled
  wanpipe1: 1: Voice activity is detected on SIN port		: TRUE
  wanpipe1: 1: Echo canceller has detected and converged	: TRUE
  wanpipe1: 1: Average power of signal level on RIN		: -69 dBm0
  wanpipe1: 1: Average power of signal level on SIN		: -207 dBm0
  wanpipe1: 1: Current gain applied to signal level on RIN	: 0 dB
  wanpipe1: 1: Current gain applied to signal level on SOUT	: 0 dB
  wanpipe1: 1: Average power of the comfort noise injected	: -207 dBm0
  wanpipe1: 1: (TDM) PCM Law type on SIN			: ALAW
  wanpipe1: 1: (TDM) TDM timeslot on SIN port			: 0
  wanpipe1: 1: (TDM) TDM stream on SIN port			: 6
  wanpipe1: 1: (TDM) PCM Law type on RIN			: ALAW
  wanpipe1: 1: (TDM) TDM timeslot on RIN port			: 0
  wanpipe1: 1: (TDM) TDM stream on RIN port			: 4
  wanpipe1: 1: (TDM) PCM Law type on SOUT			: ALAW
  wanpipe1: 1: (TDM) TDM timeslot on SOUT port			: 0
  wanpipe1: 1: (TDM) TDM stream on SOUT port			: 7
  wanpipe1: 1: (TDM) PCM Law type on ROUT			: ALAW
  wanpipe1: 1: (TDM) TDM timeslot on ROUT port			: 0
  wanpipe1: 1: (TDM) TDM stream on ROUT port			: 5
  wanpipe1: 1: (VQE) NLP status					: TRUE
  wanpipe1: 1: (VQE) Enable Tail Displacement			: FALSE
  wanpipe1: 1: (VQE) Offset of the Echo Cancellation window (ms)	: 0
  wanpipe1: 1: (VQE) Maximum tail length			: 128 ms
  wanpipe1: 1: (VQE) Rin Level control mode			: TRUE
  wanpipe1: 1: (VQE) Rin Control Signal gain			: 0 dB
  wanpipe1: 1: (VQE) Sout Level control mode			: TRUE
  wanpipe1: 1: (VQE) Sout Control Signal gain			: 0 dB
  wanpipe1: 1: (VQE) RIN Automatic Level Control		: FALSE
  wanpipe1: 1: (VQE) RIN Target Level Control			: -20 dBm0
  wanpipe1: 1: (VQE) SOUT Automatic Level Control		: FALSE
  wanpipe1: 1: (VQE) SOUT Target Level Control			: -20 dBm0
  wanpipe1: 1: (VQE) Comfort noise mode				: NORMAL
  wanpipe1: 1: (VQE) Remove any DTMF tone detection on SIN port	: FALSE
  wanpipe1: 1: (VQE) Acoustic Echo				: FALSE
  wanpipe1: 1: (VQE) Non Linearity Behavior A			: 1
  wanpipe1: 1: (VQE) Non Linearity Behavior B			: 0
  wanpipe1: 1: (VQE) Double Talk algorithm			: NORMAL
  wanpipe1: 1: (VQE) Default ERL (not converged)		: -6 dB
  wanpipe1: 1: (VQE) Acoustic Echo Cancellation default ERL	: 0 dB
  wanpipe1: 1: (VQE) Maximum Acoustic Echo tail length		: 128 ms
  wanpipe1: 1: (VQE) Attenuation Level applied to the noise signal	: -18 dB
  wanpipe1: 1: (VQE) Silence period before the re-activation of VQE features	: 1836 ms
  wanpipe1: 1: (CODEC) Encoder channel port			: SOUT
  wanpipe1: 1: (CODEC) Encoder rate				: G.711 64 kBps
  wanpipe1: 1: (CODEC) Decoder channel port			: RIN
  wanpipe1: 1: (CODEC) Decoder rate				: G.711 64 kBps

You can completely shut down the EC operation on a given channel (you most likely don’t want to do this unless you know what you’re doing)

wan_ec_client wanpipe1 mpd 1

This puts the channel 1 echo canceller in “power down” mode (mpd as in ‘Mode Power Down’)

As you guessed probably already, the other modes are ‘mn’ for  and ‘msr ‘ for ‘Mode Normal’ and ‘Mode Speech Recognition’ respectively.

wan_ec_client wanpipe1 mn 1

wan_ec_client wanpipe1 msr 1

Instead of disabling the echo canceller you can enable/disable the bypass functionality. Confusingly, “bypass enable” means that audio goes through the echo canceller, whereas “bypass disable” means audio skips the echo canceller path (but the EC is still turned on). This is due to historical reasons and due to giving low-level programmers too much freedom naming commands

The bypass commands are actually working at the FPGA level. When the bypass is enabled, the FPGA bridges the audio through the echo canceller first before sending it to the driver. When the bypass is disabled the audio is not bridged through the echo canceller. Simple hu?

root@sigchld ~
# wan_ec_client wanpipe1 bd all
wanpipe1: Running Disable bypass command to Echo Canceller device...    Done!

You can verify with wanpipemon that the EC is “disabled” (bypass disabled).

root@sigchld ~
# wanpipemon -i w1g1 -c ehw
Sangoma HW Echo Canceller is disabled for all channels!

Now enable the bypass back.

root@sigchld ~
# wan_ec_client wanpipe1 be all
wanpipe1: Running Enable bypass command to Echo Canceller device...     Done!

root@sigchld ~
# wanpipemon -i w1g1 -c ehw

Sangoma HW Echo Canceller is enabled for channel 0
Sangoma HW Echo Canceller is enabled for channel 1
Sangoma HW Echo Canceller is enabled for channel 2
Sangoma HW Echo Canceller is enabled for channel 3
Sangoma HW Echo Canceller is enabled for channel 4
Sangoma HW Echo Canceller is enabled for channel 5
Sangoma HW Echo Canceller is enabled for channel 6
Sangoma HW Echo Canceller is enabled for channel 7
Sangoma HW Echo Canceller is enabled for channel 8
Sangoma HW Echo Canceller is enabled for channel 9
Sangoma HW Echo Canceller is enabled for channel 10
Sangoma HW Echo Canceller is enabled for channel 11
Sangoma HW Echo Canceller is enabled for channel 12
Sangoma HW Echo Canceller is enabled for channel 13
Sangoma HW Echo Canceller is enabled for channel 14
Sangoma HW Echo Canceller is enabled for channel 15
Sangoma HW Echo Canceller is enabled for channel 16
Sangoma HW Echo Canceller is enabled for channel 17
Sangoma HW Echo Canceller is enabled for channel 18
Sangoma HW Echo Canceller is enabled for channel 19
Sangoma HW Echo Canceller is enabled for channel 20
Sangoma HW Echo Canceller is enabled for channel 21
Sangoma HW Echo Canceller is enabled for channel 22
Sangoma HW Echo Canceller is enabled for channel 23
Sangoma HW Echo Canceller is enabled for channel 24
Sangoma HW Echo Canceller is enabled for channel 25
Sangoma HW Echo Canceller is enabled for channel 26
Sangoma HW Echo Canceller is enabled for channel 27
Sangoma HW Echo Canceller is enabled for channel 28
Sangoma HW Echo Canceller is enabled for channel 29
Sangoma HW Echo Canceller is enabled for channel 30
Sangoma HW Echo Canceller is enabled for channel 31

That’s it for today folks, next time you want to debug echo issues, noise on the lines, distortion etc, it’s a good idea to rule out the echo canceller using the commands described in this post.

Presentation in PDF and PPT available here:

http://www.moythreads.com/congresos/astricon2010/asterisk-pri-passive-recording.pdf

http://www.moythreads.com/congresos/astricon2010/asterisk-pri-passive-recording.ppt

As you can see, you will receive the line from the CPE and plug it into the PN 633 and then plug the line from the NET too. At the other side of the adapter you can pull out 2 cables and connect them to your box with Sangoma boards specially configured in high impedance mode, which basically means will be passive and not affect the behavior of your PRI link, passively will be monitoring the E1/T1 link.

As you can tell from the image, there is also 2 cables involved for a single link, this means that you need an A102 card to monitor just 1 E1/T1 link, because one port is used for tx from the CPE and the other for tx from the NET. Until today, it was not possible to use Asterisk because Asterisk assumes each card port is meant to send and receive data for a circuit, Asterisk was meant to be an active component of the circuit, not a passive element.

Now Asterisk can do that. I just submitted 2 patches to Digium’s bug tracker. One for LibPRI, the library that takes care of the Q921 and Q931 signaling and the other for chan_dahdi.c, the Asterisk channel driver used to connect it to PSTN circuits.

LibPRI needed to be modified because it does a lot of state machine checking when receiving a Q921/Q931 frame, for example, if receives a Q931 message “PROCEEDING”, is going to check that a call was already in place and a SETUP message was previously sent, when working as a passive element in the circuit no state checks should be done, we just need to decode the message and return a meaningful telephony event to Asterisk (like a RING event when the SETUP message is seen on the line).

https://issues.asterisk.org/view.php?id=15970

The most important change is this:

pri_event *pri_read_event(struct pri *pri)
{
        char buf[1024];
        int res;
        res = pri->read_func ? pri->read_func(pri, buf, sizeof(buf)) : 0;
        /* this check should be at some routine in q921.c */
        /* at least 4 bytes of Q921 and at check buf[4] for Q931 Network packet */
        if (res < 5 || ((int)buf[4] != 8)) {
                return NULL;
        }
        res = q931_read_event(pri, (q931_h*)(buf + 4), res - 4 - 2 /* remove 4 bytes of Q921 h and 2 of CRC */);
        if (res == -1) {
                return NULL;
        }
        if (res & Q931_RES_HAVEEVENT) {
                return &pri->ev;
        }
        return NULL;
}

/* here we trust receiving q931 only (no maintenance or anything else)*/
int q931_read_event(struct pri *ctrl, q931_h *h, int len)
{
        q931_mh *mh;
        q931_call *c;
        int cref;
        int missingmand;

        //q931_dump(ctrl, h, len, 0);

        mh = (q931_mh *)(h->contents + h->crlen);

        cref = q931_cr(h);

        c = q931_getcall(ctrl, cref & 0x7FFF);
        if (!c) {
                pri_error(ctrl, "Unable to locate call %d\n", cref);
                return -1;
        }

        if (prepare_to_handle_q931_message(ctrl, mh, c)) {
                return 0;
        }

        missingmand = 0;
        if (q931_process_ies(ctrl, h, len, mh, c, &missingmand)) {
                return -1;
        }

        return post_handle_q931_message(ctrl, mh, c, missingmand, 0);
}

The rest is pretty much just modify post_handle_q931_message to skip state machine checking when invoked with the last parameter as 0, which is only done from q931_read_event, that is the passive q931 processing routine I added.

Wondering how can I get a cell tower on my property now? Visit this site and find more information.

Asterisk needed to be modified because it needs to correlate that a RING event received, let’s say in span 1 and channel 1, is probably going to be related to a PROGRESS message in span 2 channel 1 (which is the other side of the connection replying to the SETUP Q931 message). Furthermore, once the PROGRESS message is received, Asterisk must launch a regular channel and then create a DAHDI conference (using DAHDI pseudo channels) to mix the audio transmitted by the CPE and NET and return this mixed audio as a single frame to any Asterisk application reading from the channel.

https://issues.asterisk.org/view.php?id=15971

Some interesting code snippet of the changes to Asterisk is where I create the DAHDI conference to do the audio mixing, which is later retrieved by the core via the channel driver interface interface dahdi_read().

This is done during dahdi_new() routine, when creating the new Asterisk channel.

        if (i->tappingpeer) {
                struct dahdi_confinfo dahdic = { 0, };
                /* create the mixing conference
                 * some DAHDI_SETCONF interface rules to keep in mind
                 * confno == -1 means create new conference with the given confmode
                 * confno and confmode == 0 means remove the channel from its conference */
                dahdic.chan = 0; /* means use current channel (the one the fd belongs to)*/
                dahdic.confno = -1; /* -1 means create new conference */
                dahdic.confmode = DAHDI_CONF_CONFMON | DAHDI_CONF_LISTENER | DAHDI_CONF_PSEUDO_LISTENER;
                fd = dahdi_open("/dev/dahdi/pseudo");
                if (fd < 0 || ioctl(fd, DAHDI_SETCONF, &dahdic)) {
                        ast_log(LOG_ERROR, "Unable to create dahdi conference for tapping\n");
                        ast_hangup(tmp);
                        i->owner = NULL;
                        return NULL;
                }
                i->tappingconf = dahdic.confno;
                i->tappingfd = fd;

                /* add both parties to the conference */
                dahdic.chan = 0;
                dahdic.confno = i->tappingconf;
                dahdic.confmode = DAHDI_CONF_CONF | DAHDI_CONF_TALKER;
                if (ioctl(i->subs[SUB_REAL].dfd, DAHDI_SETCONF, &dahdic)) {
                        ast_log(LOG_ERROR, "Unable to add chan to conference for tapping devices: %s\n", strerror(errno));
                        ast_hangup(tmp);
                        i->owner = NULL;
                        return NULL;
                }
                dahdic.chan = 0;
                dahdic.confno = i->tappingconf;
                dahdic.confmode = DAHDI_CONF_CONF | DAHDI_CONF_TALKER;
                if (ioctl(i->tappingpeer->subs[SUB_REAL].dfd, DAHDI_SETCONF, &dahdic)) {
                        ast_log(LOG_ERROR, "Unable to add peer chan to conference for tapping devices: %s\n", strerror(errno));
                        ast_hangup(tmp);
                        i->owner = NULL;
                        return NULL;
                }
                ast_log(LOG_DEBUG, "Created tapping conference %d with fd %d between dahdi chans %d and %d for ast channel %s\n",
                                i->tappingconf,
                                i->tappingfd,
                                i->channel,
                                i->tappingpeer->channel,
                                tmp->name);
                i->tappingpeer->owner = i->owner;
       }

Later we sent the Asterisk channel to the dial plan.

                /* from now on, reading from the conference has the mix of both tapped channels, we can now launch the pbx thread */
                if (ast_pbx_start(c) != AST_PBX_SUCCESS) {
                        ast_log(LOG_ERROR, "Failed to launch PBX thread for passive channel %s\n", c->name);
                        ast_hangup(c);
                }
                break;

And finally when the Asterisk core requests a frame from chan_dahdi we return the mixed audio.

       /* if we have a tap peer we must read the mixed audio */
        if (p->tappingpeer) {
                /* passive channel reading */
                /* first read from the 2 involved dahdi channels just to consume their frames */
                res = read(p->subs[idx].dfd, readbuf, p->subs[idx].linear ? READ_SIZE * 2 : READ_SIZE);
                CHECK_READ_RESULT(res);
                res = read(p->tappingpeer->subs[idx].dfd, readbuf, p->subs[idx].linear ? READ_SIZE * 2 : READ_SIZE);
                CHECK_READ_RESULT(res);
                /* now read the mixed audio that will be returned to the core */
                res = read(p->tappingfd, readbuf, p->subs[idx].linear ? READ_SIZE * 2 : READ_SIZE);
        } else {
                /* no tapping peer, normal reading */
                res = read(p->subs[idx].dfd, readbuf, p->subs[idx].linear ? READ_SIZE * 2 : READ_SIZE);
        }

Finally, you can use regular dial plan Asterisk rules to Record() the conversation, Dial() to someone interested in auditing the call etc. Of course, any audio transmitted to this passive channel will be dropped, therefore using applications like Playback() in this channels just don’t make sense, you can still do it though, but all the audio will be silently dropped. Also remember this is a regular channel (that just happens to ignore any transmitted media or signaling), therefore you can still retrieve the ANI, DNID etc.

[from-pstn]
exten => s,1,Answer()
;exten => s,n,Dial(SIP/moy)
exten => s,n,Record(advanced-recording%d:wav)
exten => s,n,Hangup()
exten => _X.,1,Goto(s,1)

The configuration required is minimal. Sangoma board configuration is described here. It’s not much different than configuring a regular T1/E1 link though. In the Asterisk side, you just have to specify the parameter “tappingpeerpos=next” or “tappingpeerpos=prev” in chan_dahdi.conf to specify which is the peer tapping span for the current span. If you set “tappingpeerpos=no” or any other value for that matter, tapping will be disabled for that span (and then will be a regular active span).

I have the code already in 3 branches. One branch for libpri and 2 branches for Asterisk, one based on trunk and the other in Asterisk 1.6.2, keep in mind that the one from 1.6.2 has a slightly different configuration at this point, the parameter to enable tapping is “passive=yes”, this does not let you specify if the peer tapping device is the next or previous one, therefore assumes your tapping spans always start at an even number (0, 2, 4 etc), I will change that soon, hopefully …

http://svn.digium.com/svn/asterisk/team/moy/dahdi-tap-trunk
http://svn.digium.com/svn/asterisk/team/moy/dahdi-tap-1.6.2
http://svn.digium.com/svn/libpri/team/moy/tap-1.4

Now everytime a new call is detected you will receive a call that you can send wherever you want

Enjoy!

The power point presentation can be found here: FreeSWITCH modules for Asterisk Developers

The presentation will show you the key internal data structures and call flow when making a two-leg call in FreeSWITCH and Asterisk between SIP and PRI protocols. And of course, how to write modules for both telephony engines.

After the talk some people approached me to ask some particular questions, it seems the interest in creating FreeSWITCH modules and applications on top of it is increasing, it’s definitely going to be interesting what happens in the next years, the future of FreeSWITCH really looks promising.