MFC/R2 branches for Asterisk 1.2 and 1.4

July 5th, 2008

I just created 2 branches for MFC/R2 support in chan_zap for Asterisk 1.2 and 1.4, this branches replaced the patches and .tar.gz I previously published, is much easier to keep them up-to-date this way. If you still need the patches you can easily get them using svn diff.

Let’s say you need a patch against Asterisk 1.4.21.1

svn diff  http://svn.digium.com/svn/asterisk/tags/1.4.21.1 
http://svn.digium.com/svn/asterisk/team/moy/mfcr2-1.4 > asterisk-openr2-1.4.21.1.patch

That will create a patch to transform Asterisk 1.4.21.1 version into an OpenR2-enabled version. However this has other side-effect, changes that may have nothing to do with openr2 can be introduced. I therefore recommend using my branches directly.

OpenR2 back-ported to Asterisk 1.4 and 1.2

June 19th, 2008

I just back-ported the support for MFC/R2 signaling using the OpenR2 library to Asterisk 1.4 and 1.2, go and get it while is still hot!

http://www.libopenr2.org/

I also updated the site to use TextMotion, a new web publishing software (aka CMS), works pretty well, kudos to the TextMotion devs.

A Tale of Two Bugs

May 25th, 2008

It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the age of bug-hunting!

Recently I fixed 2 bugs, yeah, I know I spent a lot of time fixing bugs but this 2 were quite interesting to me, not because of the bugs itself, but rather because of some stuff I learned in the process like the implementation of variadic functions and how the C++ compiler optimizes certain stuff unveiling odd bugs.

Bug 1

Let’s analyze the first one, it was a bug I had with some Unicall R2 installation in 64 bits. The problem was simple, as soon as I loaded chan_unicall.so Asterisk crashed :-)
After running Asterisk with gdb I found the crash happened inside libc function strlen that was being called by uc_log(), the Unicall logging function. As most logging C functions, uc_log is a variadic function. uc_log does not do any complicated stuff, is mostly just a wrapper to vsnprintf and the variable arguments were just passed on to vsnprintf and there the crash was occurring, so, how can one see the arguments a variadic function receives using gdb? First, one must know how variadic functions are implemented by the compiler and platform you are working on.

Most common implementation of variadic functions in C is just to define va_list as an unsigned char* pointing to the last argument of the function and each call to va_arg() retrieves the next chunk of memory of the specified size and increment va_list to point to the start of the next argument, therefore, displaying arguments is just matter of printing the memory area after the last argument. However, AMD64 has a different implementation, va_list is an array of 1 structure with members:

.gp_offset
.fp_offset
.overflow_arg_area
.reg_save_area

gp_offset is how many bytes after reg_save_area the first argument is. To print the first variable argument that we know is an “int” we do:

(gdb) p *(int *)(((char *)arg_ptr[0].reg_save_area)+arg_ptr[0].gp_offset)

however, gp_offset will be only incremented after calling va_arg() macro, if you want to see more arguments you must increment reg_save_area by the number of bytes you know arguments take, in the case of uc_log, initial value of gp_offset is 24, probably because it receive 3 fixed arguments (8 bytes * 3). So, the first variable argument starts at .reg_save_area + 24, the second at .reg_save_area + 32 (we’re in a 64 bit machine).

So, what about .fp_offset and .overflow_arg_area?, well, it seems .reg_save_area is quite limited (possibly limited by the number of the processor registers) and you can never go beyond .gp_offset == 40, therefore that will only work for up to 6 arguments (including the fixed ones). .overflow_arg_area is used for any subsequent argument and .fp_offset is the pointer to the next argument on that memory area. Well, that’s enough, let’s get straight to the point, the crash was caused because unicall.h include the following prototype:

extern const char *uc_statet2str(int state);

That function returned the value passed to uc_log(…., uc_state2str()) … so what’s the issue? well, read once again the prototype and how uc_log used it. Is not a typo here in my blog, the prototype really is uc_statet2str, and the function call is uc_state2str, indeed there is a typo in the header file causing the compiler to default to the return value “int” and not const char* when compiling libmfcr2, for 64 bit platform there is 4 bytes of difference between char* and int causing a crash due to invalid memory read.

Bug 2

This one is easier to explain with a chunk of code, can you tell what’s wrong with it and what possible outputs will have when running it as “./test t”?


#include <stdio.h>
#include <string.h>

#define SIZE 100

int main(int argc, char *argv[])
{

        char *bufptr = NULL;
        if (argc == 2) {

                char inblock_buff[SIZE];
                bufptr = inblock_buff;
                strcpy(bufptr, “some buffer”);
        }

        printf(“buffer: %sn”, bufptr);
        if (argc == 2 && argv[1][0] == ‘t’) {

                char otherbuff[SIZE];
                otherbuff[0] = 0;
        }

        printf(“buffer: %sn”, bufptr);
        return 0;
}

Indeed, the output will depend on how you compile it and even probably will depend on the compiler implementation? The thing is, that if you compile this code in Linux with gcc 4.1.2 as gcc -O2 bug.c -o bug, and then run it as ./bug t

The output is:

buffer: some buffer
buffer: some buffer

But, compiling without optimizations gcc -O0 bug.c -o bug the output is:

buffer: some buffer
buffer:

When the second if() block is optimized-out the value of the block variable inblock_buff is not overwritten and therefore bufptr remains pointing to “some buffer” and the code seems to “work”, but when -O0 the second if() block is not optimized and the bug arise, bufptr will point to char 0 printing nothing. In my particular case this buffer was the input of the keyboard of a 5250 session, hence, in some cases the keyboard input was just ignored.Paregoric
Bad side effects of viagra
Phentermine sale
Thiphenamil
Phentermine in the uk
Mesalamine
Generic cialis online
Adipex p phentermine
Meridia weight loss pill
Lincomycin
Online consultations and prescriptions phentermine
Xanax anxiety relief pills order here
Natural viagra substitutes
Generic cialis price
Cheap phentermine no prescription
Taking xanax while pregnant
Sulindac
Xanax xr 3 mg
Prozac soma
Tramadol narcotic
Phendimetrazine versus phentermine
Carteolol
Mivial valve prolapse viagra
Glucotrol
Free viagra without a perscription
Cialis drug impotence
Norethindrone
Capoten
Generic cialis india
Does phentermine speed up metabolism
Aminophylline
Pal pay phentermine
Flavoxate
Mail order viagra
Xanax dosage
Buy viagra online
Viagra and levivia
Guanethidine
Phentermine 180
Viagra results
Phentermine 37.5 no prescription
Methantheline
Fluvastatin
Celiprolol
Buy cialis in uk
Ecotrin
Discount online viagra
Low cost phentermine
Accutane
Natural supplement for viagra
Canada generic viagra
Dovonex
Long term side effects of phentermine
Gemfibrozil
Vicodin picture
Phentermine by cod
Liothyronine
Nitroglycerin
Mexican pharmacy viagra
Xanax prescription online
Xanax online cheap
Enoxacin
Levivia viagra
Xanax anxiety
Xanax no prescription required
Chep phentermine
Ambien addiction
Ethosuximide
Motrin
Tetrabenazine
Cheapest phentermine pills
Phenprocoumon
Cefatrizine
Book hydrocodone sport
Free ambien
Cheap phentermine canada
Phentermine overnight shipping
Phentermine pharmacies online
Viagra buy viagra
Cialis info
Asparaginase
Xanax online without prescription
Pediacare
Furazolidone
Amphetamine
Use of viagra
Diovan
Echinacea
Imuran
Information medical phentermine
Delavirdine
Vicodin and alcohol
Chlorthalidone
Alternative viagra
Tramadol cod
Mixing cocaine and viagra
From generic india viagra
Klonopin versus xanax
Viagra patent infringement reexam
Buy Zyban
Buprenorphine
Norvasc
Free viagra sample before buying
Losartan
Overnight shipping viagra
Maker of viagra
Language phentermine ru
Viagra online consultation
Aspirin
Cheep tramadol paris france
Tramadol uses
Hydrocodone
Restoril
Tramadol hc
Buy discount viagra online
Discount generic cialis
Phentermine drug test
Hydrocodone bitartrate
Recreational viagra use
Xanax pills
Imdur
Clonidine
Discount hydrocodone
Overnight viagra
Luvox
Fluorouracil
Diet hcl phentermine pill
Phenytoin
Taking phentermine with antidepressants
First viagra commercial network tv
Phentermine hoodia
Viagra herbal
Dyazide
Klonopin vs xanax dosage
Impotence pill viagra
Isotretinoin
Phentermine free consultation
Buy tramadol online without a prescription
Cefpodoxime
Oxycontin xanax bars percasettes and lor tabs
Isosorbide
Levivia versus viagra
Canada xanax
Ionamin
Nadroparin
Drug test tramadol
Novobiocin
Xanax lethal dose
Pictures of mylan xanax
Fluvoxamine

MFC/R2 branch for Asterisk is available

April 30th, 2008

I just created a branch for Asterisk that has everything required to test the chan_zap MFC/R2 support. Now the installation steps are easier.

1. Install zaptel from 1.4 branch http://svn.digium.com/svn/zaptel/branches/1.4

2. Install openr2 library from the trunk svn://libopenr2.org/openr2/trunk

3. Install Asterisk from the MFC/R2 branch: http://svn.digium.com/svn/asterisk/team/moy/mfcr2

Some people in brazil has now reported success with basic call setup. Configuration info is available at the bugtracker: http://bugs.digium.com/view.php?id=12509

The libopenr2.org site is up, but empty :-( , right now I just have the SVN server, but info will be added soon as well.

Asterisk with MFC/R2 in chan_zap

April 25th, 2008

I’ve been working lately in a library for the MFC/R2 telephony signalling. I named this library “OpenR2″. My goal is to include support for this signaling in the Asterisk project and eventually in FreeSwitch if possible. I just created a new issue in the bugtracker, that is the first patch I have to give MFC/R2 support in the Asterisk channel driver chan_zap. Hopefully this will eventually be the standard MFC/R2 implementation for Asterisk and finally it will “just work”.

If you are from the many people with R2 issues in Mexico or other country, you should consider to give this thing a try.

The code of the library is LGPL and is available temporarily to download from http://www.moythreads.com/openr2-april21.tar.gz.

I am in the process of getting an SVN account and will post later the link.

Patch for chan_zap: http://www.moythreads.com/chan_zap-mfr2.patch

All you have to do is download Asterisk from this branch: http://svn.digium.com/svn/asterisk/team/markster/mfr2

Then apply the patch. You will also need zaptel from this branch: http://svn.digium.com/svn/zaptel/branches/1.4

After applying the patch, please run ./bootstrap.sh in the Asterisk root directory. Then ./configure –prefix=/usr –with-openr2=/usr

Please report feedback in the bugtracker or contact me via e-mail or IM. My user at gmail it’s quite easy to remember: moises.silva

Zaptel Version

April 3rd, 2008

Quick note to myself: to check the version of the loaded zaptel module just cat /sys/module/zaptel/version

ViEmu Rocks

March 26th, 2008

Since I joined IBM a bit more than a year ago, I knew I would have to code for Windows sooner or later, it was sooner than I thought, it has been a year now since I started coding for both Linux & Windows. Coding C++ in Visual Studio is a pain, compared to using VIM and GDB in Linux, however, I just found a Visual Studio plugin that is more than worth the 80 bucks I paid: http://www.viemu.com/

If you are a fan of vim as I am, then you also will enjoy reading: http://www.viemu.com/a-why-vi-vim.html, that’s where I first saw the Vi Gang sign!

Vi Gang Sign

IJW (It Just Works) and COM Interop

March 26th, 2008

As I promised in my last post, today I am going to give an overview about how to call C# code from C++. After googling around a bit you will find there are at least 2 well-known ways to call C# from C++.

It Just Works

The first one I want to mention is “IJW” that stands for “It Just Works”. As the name implies, there is nothing much to discuss about IJW, is pretty easy to use, all one have to do is specify the /clr switch in the Microsoft VS compiler. This switch will cause your C++ code to be compiled to IL (Intermediate Language) and therefore will run in a managed environment. Nice isn’t it? However there is a catch, even though your code will be compiled to IL, the classes are not managed, which means among other things that the CLR will not take care of the memory. This is kind of obvious, since the original code was meant to take care of the memory itself, all the /clr switch does is give the opportunity to that old C++ code to run in managed environment.

Once that we have this C++ code working on a managed environment, there is some new fun stuff we can do with it.


#using <mscorlib.dll>
#using <myassembly.dll>

#include <stdio.h>

using namespace System;
using namespace MyNameSpace;

void callSomethingInMyAssembly()
{

    Console::WriteLine(“In Managed Environment!”);
    MyAssemblyClass::MyStaticMethod();
}

#pragma unmanaged


void oldAndCrappyFunction()
{
    callSomethingInMyAssembly();
}

The compiler pragma directive “managed” and “unmanaged” will help you to switch from managed to unmanaged and viceversa. This way you can call managed code from your old unmanaged code. Be aware that this solution will not work when you have an old DLL that other components depend on, since the resulting DLL will be a DLL with IL code and therefore not callable from other unmanaged DLLs.

COM Interop

To use COM Interop, the managed code, in this case, a C# class needs to allocate an UUID to be used when creating a COM instance. The following code shows how to create code with an interface and class with UUIDs.

using System;

using System.Runtime.InteropServices;

namespace ManagedNameSpace
{

/* The GUID should be generated using guidgen.exe */
[Guid(“EF870CF7-DA0F-4bf7-89DD-DE21E4701E21″)]
public interface IManagedComponent
{
        void ManagedMethod();
}

[Guid(“687EADD7-0B02-457a-85E5-84BEF198F7BA”)]

public class ManagedClass : IManagedComponent
{
        public void ManagedMethod()
        {

                Console.WriteLine(“in managed environment!n”);
        }
}

}

You can create a UUID using the tool guidgen.exe. The class should be compiled with

C:\csc /target:library mycomponent.cs

That will generate a mycomponent.dll assembly. In order to other COM components to use our C# class we must register the DLL, we can do so using regasm utility:

C:\regasm mycomponent.dll /tlb:mycomponent.tlb

Now that the DLL is registered you can use it from any language that supports COM, C++ included. Before proceeding to call this C# code from C++, you may be wondering about that mycomponent.tlb file specified as argument to regasm /tlb switch. That file is known as a “type library” and is used by the COM infrastructure to save meta-data about the types involved in the exported interfaces, that way any language that supports COM can interact with any other COM component, in this case, written in C#.

Finally let’s call our C# component from C++ code.

#include <windows.h>
#include <iostream>


using namespace std;

#import <mscorlib.tlb> raw_interfaces_only

#import “dtcom.tlb” no_namespace named_guids

int main(int argc, char *argv[])
{

        IManagedComponent *component;
        HRESULT hr;

        /* COM require an initialize routine */
        CoInitialize(NULL);

        hr = CoCreateInstance(CLSID_ManagedClass, NULL,
                        CLSCTX_INPROC_SERVER, IID_IManagedComponent, reinterpret_cast<void **>(&component));

        if ( FAILED(hr) ) {
                cerr << “Could not create component instance.” << endl;

                return -1;
        } 

        cout << “Calling managed methods.” << endl;
        component->ManagedMethod();

        /* COM Require to release the instance */
        component->Release();

        /* Close COM */
        CoUninitialize();

        return 0;
}

As you can see we use the CoCreateInstance COM function to create an object that references (indirectly via CCW ) to the C# object.

So, that’s it, you can learn more about COM at Wikipedia.

PInvoke ( How to Call C from C# )

February 4th, 2008

I will be coding some C# stuff for Windows this year. We have a bunch of C/C++ APIs which we want to make available to our customers from C#, however, since I have known of the Mono existence for a while, I quickly realized that 90% the C# interfaces I will code on Windows for our C/C++ APIs can be made available for our Linux product as well. This post will briefly show how to call C/C++ code from C#.

As most of the readers probably know, C# is one of the primary languages of the .NET platform, thus, runs in a managed environment and cannot call unmanaged code w/o some intermediate mechanism, but don’t fear, it is quite easy, that mechanism is PInvoke, that stands for Platform Invoke. Let’s see an example of how it is done, on Linux.

1. Create a C file, libtest.c with this content:


#include <stdio.h>

void print(const char *message)
{

        printf(“%s\n”, message);
}

That’s a simple pseudo-wrapper for printf. But represents any C function in the library you want to call. If you have a C++ function don’t forget to put extern “C” to avoid mangling the name.

2. Compile it as a shared library: gcc -fPIC -shared libtest.c -o libtest.so

3. Let’s create the C# file that will call our C API. It’s quite easy using PInvoke, all we need is define our entry points.

using System;

using System.Runtime.InteropServices;

public class Tester
{
        [DllImport(“libtest.so”, EntryPoint=“print”)]

        static extern void print(string message);

        public static void Main(string[] args)
        {

                print(“Hello World C# => C++”);
        }
}

We define a test class that declares a method “print”. However we do not write the body of the method since we declare it extern and static because it will not depend on the class instance data. Using C# attribute DllImport we specify the DLL ( in Linux, the shared object ) where the method will be defined.

4. Compile the C# file: mcs test.cs

5. Run it: mono test.exe

Unless you have the library libtest.so in a standard library path like “/usr/lib”, you are likely to see a System.DllNotFoundException, to fix this you can move your libtest.so to /usr/lib, or better yet, just add your CWD to the library path: export LD_LIBRARY_PATH=`pwd`

6. Run it again :) … now you should see the hello world C# => C++ message.

The DllImport attribute supports other arguments to tweak its behavior, refer to MSDN for DllImport documentation. Also keep in mind this is a extremely simple example, when more complex data types are involved we need to read about marshaling.

So that’s it, in my next post I will write about how to call C# code from C/C++ using COM Interop and managed C++.

Asterisk Asynchronous AGI

December 24th, 2007

I have been coding some new stuff for Asterisk lately, but the feature I like the most is Asynchronous AGI. I got the idea from MAGI, an old patch written by David Pollak that allowed AGI execution thru the manager interface. For those ignoring what AGI and AMI are, go read:

Asterisk Gateway Interface ( AGI )
Asterisk Manager API ( AMI )

So, my patch, allow users to execute AGI commands using “Action: AGI” and get the response reading “Event: AsyncAGI”. The manager header “CommandID” can be specified to match up the responses. Let’s see an example

In extensions.ael you would put something like this:

context sample-async-agi {
    test => {
        AGI(agi:async);
    };
};

That will put the channel to wait AGI commands. The channel will NOT do anything but wait for Hangup or any AGI command you ask it to execute. AGI commands can arrive from 2 sources. The most important and useful source of commands is the manager, but with my patch you can also execute AGI from the command line. Let’s see how it is done from the manager:

# telnet localhost 5038
Action: Login
Username: test
Secret: test

Action: AGI
Channel: SIP/33-blah
Command: EXEC Playback tt-monkeys
CommandID: MyCommandID

That would cause Asterisk to execute the “Playback” application on channel SIP/33-blah, which MUST be in AGI(agi:async) application. After executing the command you will be able to read an event with the AGI response url-encoded. If the channel is not in Async AGI, the command will not be executed and you will get an error response.

As I said, you can use the command line to execute Async AGI as well, just like this:

tcore*CLI> agi exec SIP/testing-09a5b960 “EXEC startmusiconhold”
tcore*CLI> agi exec SIP/testing-09a5b960 “EXEC stopmusiconhold”
tcore*CLI> agi exec SIP/testing-09a5b960 “EXEC Dial(Agent/23)”

That will start MOH, then stop it, and finally will dial to the Agent 23. This means you can implement a Queue without using native buggy Asterisk queues. You can receive calls and send them to Async AGI to put them on hold, then, when you detect availability of some of your Agents, Dial() to that agent.

If you want to learn more about this feature here is the mantis bug entry: http://bugs.digium.com/view.php?id=11282.

If you want the patch back-ported to 1.4, I have one here: http://www.moythreads.com/asterisk-1.4.15-async-agi.patch

In case you find this patch useful, please try it in trunk as well and provide feedback in mantis. Even when some people has found this patch useful, some of the top developers at asterisk-dev are hesitating in accepting it because similar results can be obtained thru the use of FastAGI, however, me and other people at asterisk-dev are trying to prove the patch also makes easier the implementation of some applications.

This is a hot discussion we got some weeks ago about it: http://lists.digium.com/pipermail/asterisk-dev/2007-December/031046.html

See you!