Trixbox with Premicell - outbound calls hangup when answered

We have a Nokia Premicell connected via a X100P to Trixbox (2.8.0.3) and configured to handle all mobile calls. Incoming calls work fine but for outbound calls, the call is hung up as soon as the recipient answers.

The log file is below - after the 'DAHDI/1-1 answered' the recipent phone starts ringing. As soon as the call is answered I see the 'hangupcall'

-- Called g0/077xxxxxxxx
    -- DAHDI/1-1 answered SIP/162-b7307fc8
    -- Executing [h@macro-dialout-trunk:1] Macro("SIP/162-b7307fc8", "hangupcall,") in new stack
    -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/162-b7307fc8", "vw") in new stack
    -- Executing [s@macro-hangupcall:2] NoCDR("SIP/162-b7307fc8", "") in new stack
    -- Executing [s@macro-hangupcall:3] GotoIf("SIP/162-b7307fc8", "1?skiprg") in new stack
    -- Goto (macro-hangupcall,s,6)
    -- Executing [s@macro-hangupcall:6] GotoIf("SIP/162-b7307fc8", "1?skipblkvm") in new stack
    -- Goto (macro-hangupcall,s,9)
    -- Executing [s@macro-hangupcall:9] GotoIf("SIP/162-b7307fc8", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,11)
    -- Executing [s@macro-hangupcall:11] Hangup("SIP/162-b7307fc8", "") in new stack
  == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/162-b7307fc8' in macro 'hangupcall'
  == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'SIP/162-b7307fc8'
    -- Hungup 'DAHDI/1-1'
  == Spawn extension (macro-dialout-trunk, s, 19) exited non-zero on 'SIP/162-b7307fc8' in macro 'dialout-trunk'
  == Spawn extension (from-internal, 9077xxxxxxxx, 4) exited non-zero on 'SIP/162-b7307fc8'

Open in new window

neilballantyneAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

feptiasChief DudeCommented:
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)
neilballantyneAuthor Commented:
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)
feptiasChief DudeCommented:
Its very difficult to understand the details of what is happening from this. I would say it is significant that changing those polarityreversal parameters has made a difference to the behaviour of the system so it suggests that a polarity reversal was happening. Have you tried with answeronpolarityswitch=no?

The only other thing I can suggest is that you use a test butt to monitor the line and see if you can hear what is happening on the analogue line. Presumably, Asterisk has to analyse the ringback tones it receives on the line to determine if the call was answered etc - so-called Call Progress Analysis. As the call progress indication tones will vary from one country to another and from one attached device to another, perhaps the tones sent by the Premicell are not matched to the country settings on the Trixbox. Are there any settings on the Premicell that you can tweak? Perhaps it is playing some weird tones back to Trixbox while the call is being re-dialed to the mobile.

Is the SIP trunk set as an alternative trunk in the "trunk sequence" section of the Outbound Route? If so, it is not very relevant other than showing that Asterisk thinks the call failed using the first trunk in the sequence - and that Trixbox believed the failure happened very early in the process (before the Premicell had actually re-dialed to the mobile phone). You really need to find a way of listening to the call on that analogue line connecting the Trixbox to the Premicell.

Analogue is a rubbish protocol for telephony signalling of course. Couldn't you replace the Premicell with a SIP-to-GSM device? SIP signalling would be much more reliable.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
OWASP: Forgery and Phishing

Learn the techniques to avoid forgery and phishing attacks and the types of attacks an application or network may face.

neilballantyneAuthor Commented:
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.
feptiasChief DudeCommented:
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.
neilballantyneAuthor Commented:
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?
neilballantyneAuthor Commented:
Expert's suggested alternative solution was useful
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IP Telephony

From novice to tech pro — start learning today.