New downloads section & MOH fix coming

Downloads section is now available, including a package with the proper versions for Asterisk 1.2.21.Some people reported a problem with chan_unicall and MOH ( Music On Hold ). I had access to a server to test it and confirm there is a problem with the driver and Asterisk 1.4.X . Asterisk 1.4 changed a bit the way in which the “onhold” event is processed. In Asterisk 1.2, onhold event was processed by the channel driver receiving the onhold event. In 1.4 the bridged channel is the one responsible for handling that. Thus, a change in unicall_indicate routine is needed to support HOLD UNHOLD events. I have added the change, however I am also doing some code clean-up and other small fixes before posting the new version.

Other people has reported problems with private callerid. However that problem is on the libmfcr2 side, not on the channel driver itself, so that one is going to have to wait a couple of weeks more until I have a proper test server.

10 Responses to “New downloads section & MOH fix coming”

  1. awerflli2 says:

    Hi, thanx for this great work

    I am quit new using asterisk and I already ve installed the complete astunicall-1.4.9-0.1.tar on centos5 and i did not do any patch or copy to any file

    but when restart the asterisk by asterisk -vvvvvgc

    it seems it does not load the chan_unicall.so

    even i did manully as following

    *CLI> module load chan_unicall.so

    [Nov 6 13:21:09] WARNING[3394]: loader.c:360 load_dynamic_module: Error loading module ‘chan_unicall.so’: /usr/lib/asterisk/modules/chan_unicall.so: cannot restore segment prot after reloc: Permission denied
    [Nov 6 13:21:09] WARNING[3394]: loader.c:637 load_resource: Module ‘chan_unicall.so’ could not be loaded.

    thanks in advance

  2. moy says:

    I wish I had more time to see what exactly that means. My guess is that you have SELinux enabled ( http://en.wikipedia.org/wiki/SELinux ). I am not an expert on that area, and I am not quite sure which restrictions impose, but I remember I had a similar ( if not the same ) issue in CentOS and I had to disable SELinux. Probably a less brute force solution exists. Try disabling SELinux and let us know.

  3. awerflli2 says:

    Hi moy
    first of all thanx for every thing
    and as you said after disableing the selinux setting that restric
    the actions for the installed software it is working probally now

    in fact i am trying to to do testing for the mfcr2 configuration by
    connetd two asterisk servers as master/ slave together using

    astunicall-1.4.9-0.1.tar.gz
    TE110P digium card2 in each server
    and e1 crosscable

    so for each server it semmes like it is working probally as following samples

    – Registered channel 1, mfcr2 signalling ………. channel 31, mfcr2 signalling

    followed by
    Parsing tone set

    followed by
    chan_unicall.c:2589 handle_uc_event: Unicall/1 event Detected…….: Unicall/31 event Detected

    chan_unicall.c:2589 handle_uc_event: Unicall/1 event Local end unblocked– Unicall/31 local unblocked

    chan_unicall.c:2589 handle_uc_event: Unicall/1 event Far end unblocked …Unicall/31 event Far end unblocked

    after connetcting the cable it gives some error message in master server and” i am not sure if the problem with asterisk unicall
    or other thing ” it gives error and blocking and unblocking continuouslly as shown in following error samples

    ERROR[2972]: chan_unicall.c:2593 handle_uc_event: Unicall/27 protocol error. Cause 32773
    NOTICE[2972]: chan_unicall.c:2589 handle_uc_event: Unicall/28 event Protocol failure

    chan_unicall.c:2589 handle_uc_event: Unicall/18 event Far end disconnected
    chan_unicall.c:2874 handle_uc_event: CRN 32769 – far disconnected cause=Normal, unspecified cause [31]
    chan_unicall.c:2589 handle_uc_event: Unicall/18 event Drop call
    chan_unicall.c:2589 handle_uc_event: Unicall/2 event Release call — Unicall/2 released
    chan_unicall.c:2589 handle_uc_event: Unicall/18 event Release call — Unicall/18 released

  4. moy says:

    How many calls are you placing when you start to see this errors?

  5. awerflli2 says:

    Hi moy
    sorry i am not sure about meaning of the number of placed calls ,but as mush as i understand , i did one sip (soft-phone ) attached to asterisk servers A ,and another soft sip for the other asterisk server B , and the call has been established via both directions with no problem,(thanks for astunicall developers team) but while there is no calls it is continuouslly showing the above message ,and this is my test i thionk it is very simple configuration files in both sides

    unicall.conf
    [channels]
    context=default
    usecallerid=yes
    hidecallerid=no
    callwaitingcallerid=yes
    threewaycalling=yes
    transfer=yes
    cancallforward=yes
    callreturn=yes
    echocancel=yes
    echocancelwhenbridged=yes
    rxgain=0.0
    txgain=0.0

    group=1

    callgroup=1
    pickupgroup=1
    immediate=no
    callerid=175
    ;loglevel=255
    protocolclass=mfcr2
    protocolvariant=my,3,3
    protocolend=cpe
    group=1
    channel => 1-15
    channel => 17-31

    extension.conf at server A
    [general]
    static=yes
    writeprotect=yes
    [default]
    exten => 180,1,Dial(Unicall/g1/180)
    exten => 176,1,Dial(SIP/176)

    extension.conf at server B

    [general]
    static=yes
    writeprotect=yes
    [default]
    exten => 176,1,Dial(Unicall/g1/176)
    exten => 180,1,Dial(SIP/180)
    thanx alot

  6. moy says:

    There is no astunicall development team :) , this is software created by Steve Underwood ( http://www.soft-switch.org ), I just patch it a bit and put together versions that are likely to work.

    Now, having said that. If you want me to help give me ssh access and contact me by messenger at ( moises dot silva at gmail dot com )

  7. coppice. says:

    What do you mean by “Other people has reported problems with private callerid.”? If you means the restriction features, though can be a bit variant specific. You’ll need to check the variant in use, and we might need to clean up an entry or two in the MFC/R2 code.

  8. moy says:

    Yes I meant “group_i_end_of_ANI_restricted”, I just asked for some traces to a Anton Krall, he has several R2 installations with libmfcr2. I have not confirmed the issue, but users mention enabling ANI digits cause dropped calls with restricted ANI, so they either put 0 as ANI digits or have to live with some dropped calls. I will review the traces an let you know what the fix is ( at least for México variant ) so you can add the change to libmfcr2.

  9. bingo sites says:

    bingo sites…

  10. real roulette…

Leave a Reply