Trixbox with Premicell - outbound calls hangup when answered

The only explanation I can think of is that the Premicell is signalling that the call was answered by momentarily reversing the line voltage. This is used as a signalling technique on analogue circuits, but the event that triggers a polarity reversal may not always be the same and depends on the equipment.

I believe the default behaviour for Asterisk is to interpret polarity reversal as a hangup which would trigger the "hangupcall" that you see. If so, you should be able to modify the Dahdi settings to make Asterisk interpret polarity reversals correctly. The relevant parameters in /etc/asterisk/chan_dahdi.conf are shown below (a snippet copied from the sample chan_dahdi.conf file included with Asterisk 1.6) but you will probably find that Trixbox has a greatly reduced version of this file. If so, you can simply edit the file, add the missing parameters then restart Asterisk.

; Use a polarity reversal to mark when a outgoing call is answered by the
; remote party.
;
answeronpolarityswitch=yes
;
; In some countries, a polarity reversal is used to signal the disconnect of a
; phone line.  If the hanguponpolarityswitch option is selected, the call will
; be considered "hung up" on a polarity reversal.
;
hanguponpolarityswitch=no
;
; polarityonanswerdelay: minimal time period (ms) between the answer
;                        polarity switch and hangup polarity switch.
;                        (default: 600ms)

Hi feptias - thanks for the suggestion but that's not worked either, albeit in a slightly different way.

WIth answeronpolarityswitch=yes and hanguponpolarityswitch=no I end up with a CHANUNAVAIL and then the call is made through the SIP trunk. Log as follows:

    -- Executing [s@macro-dialout-trunk:19] Dial("SIP/162-b7706c38", "DAHDI/g0/07xxxxxxxxx,300,") in new stack
    -- Called g0/07xxxxxxxxx
    -- Hungup 'DAHDI/1-1'
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [s@macro-dialout-trunk:20] Goto("SIP/162-b7706c38", "s-CHANUNAVAIL,1") in new stack
    -- Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)
    -- Executing [s-CHANUNAVAIL@macro-dialout-trunk:1] GotoIf("SIP/162-b7706c38", "1?noreport") in new stack
    -- Goto (macro-dialout-trunk,s-CHANUNAVAIL,3)


I don't see a 'DAHDI/1-1 answered' entry at all but the mobile rings and as soon as I answer it the SIP phone I'm calling from hangs up, and a second later the mobile hangs up. (the call through the SIP trunk actually comes through before the first call has hung up on the mobile)

Not sure that we have the kit/expertise to listen in on the line. We'll probably look into a SIP to GSM device as you've suggested, though out of interest is there any way to get additional debugging information in the asterisk logs? I've tried a couple of suggestions including settig a value of '1' in '/sys/module/dahdi/parameters/debug', and 'options dahdi debug=1' in '/etc/modprobe.conf' but neither seem to make any difference.

I always use the Command Line Interface (CLI) when debugging asterisk. You access it from the Linux prompt using the command "asterisk -r". Then you should see a CLI> prompt. At the CLI prompt, you can list every command by typing "help". Useful commands are:
core set verbose 3                                     // sets the general debug output level to detailed
core set verbose 1                                     // sets it back to quiet
dahdi show status                                     // shows general status of dahdi cards
dahdi show channels                                 // shows status of the dahdi channels
sip show peers                                          // shows the status of sip peers and IP phones
sip show registry                                       // status of registrations Asterisk has made to other peers
sip set debug on                                       // traces all sip packets
sip set debug peer <peername>              // only traces SIP packets to/from specified peer
sip set debug off                                       // turns sip packet tracing off again

Just type "help" and scan through the list to see what looks interesting. You can filter the help output by typing "help <something>". For example:
help dahdi show                                   // only lists the commands that start "dahdi show"

Unfortunately, I don't know of any debug methods that show what is happening on analogue channels when they are doing call progress analysis, but setting "core set verbose 3" will give you some info.

No further joy with the Premicell so we have opted for a temporary bluetooth solution using chan_mobile as a temporary option while we have a look into SIP to GSM.

As a side point when we initially set up chan_mobile it worked fine with both inbound and outbound calls, but no audio when an external (SIP) call was re-directed out through the mobile. Setting 'progressinband=yes' on the SIP Trunk has fixed this but am wondering if there are any issues with doing this?

Expert's suggested alternative solution was useful