asterisk users - May 2007 - Outside lines are just not happening...

Two problems, possibly related:

Here's the configuration...my Asterisk box has a TDM844B in it; port 1-4
are FXS, 5-8 FXOs.

Here are the config files:

/etc/zaptel.conf:
--------
fxoks=1
fxoks=2
fxoks=3
fxoks=4
fxsks=5
fxsks=6
fxsks=7
fxsks=8

loadzone        = us
defaultzone     = us
--------
/etc/asterisk/zapata.conf:
--------
[channels]
language=en
usecallerid=yes
hidecallerid=no
callwaiting=no
threewaycalling=no
transfer=no
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
canpark=yes
rxgain=0.0
txgain=0.0

context=internal
signalling=fxo_ks
channel => 1-4

context=external
signalling=fxs_ks
channel => 5-8
--------

A snippet from /etc/asterisk/extensions.conf:
--------
[internal]
ignorepat => 9
exten => _9NXXXXXX,1,Dial(Zap/5/${EXTEN:1})
exten => _9NXXXXXX,2,Congestion()
exten => _9NXXXXXX,102,Congestion()
--------

The SIP phone is also in the internal context, and other things below
that in the context work just fine on the internal network.

I don't know if it's relevant or not, but dialtone stops after I press
9, which is not what I was led to believe would happen with the
ignorepat directive.

Problem A:  Dialing in.  If I call from my cell, the FXO picks right up,
and sends me to the voice menu that I have at the top of the [external]
context.  So far so good, but if the SIP that I get in touch with hangs
up, the FXO stays off-hook for more than a minute before dropping the
POTS line.  If I pick that SIP phone back up, and dial an outside
number, I can reconnect to the "dangling" call, which will hear the
tones after the 9...  The outside caller will finally get dropped after
about a minute of waiting.

Here's a transcript from the CLI:
(I pick up a phone not on the switch, and call the FXO:
    -- Starting simple switch on 'Zap/5-1'
    -- Executing Answer("Zap/5-1", "") in new stack
    -- Executing GotoIfTime("Zap/5-1",
"07:30-16:30|mon-fri|*|*?open|s|1") in new stack
    -- Goto (open,s,1)
    -- Executing DigitTimeout("Zap/5-1", "5") in new stack
    -- Set Digit Timeout to 5
    -- Executing ResponseTimeout("Zap/5-1", "10") in new
stack
    -- Set Response Timeout to 10
    -- Executing BackGround("Zap/5-1", "alc01") in new stack
    -- Playing 'alc01' (language 'en')
  == CDR updated on Zap/5-1
    -- Executing Macro("Zap/5-1", "stdext|102|SIP/102") in
new stack
    -- Executing Dial("Zap/5-1", "SIP/102|20") in new stack
    -- Called 102
(The SIP phone begins ringing)
    -- SIP/102-08184fa8 is ringing
    -- SIP/102-08184fa8 answered Zap/5-1
(Hang up SIP)
  == Spawn extension (macro-stdext, s, 1) exited non-zero on 'Zap/5-1'
in macro 'stdext'
  == Spawn extension (macro-stdext, s, 1) exited non-zero on 'Zap/5-1'
    -- Hungup 'Zap/5-1'
(Pick up SIP, dial 96653674)
    -- Executing Dial("SIP/102-08184808", "Zap/5/6653674")
in new stack
    -- Called 5/6653674
    -- Zap/5-1 answered SIP/102-08184808
(I heard the tones on the "outside" phone, which is still off-hook)
(hung up SIP)
    -- Hungup 'Zap/5-1'
  == Spawn extension (internal, 96653674, 1) exited non-zero on
'SIP/102-08184808'
(one more time, pick up SIP)
    -- Executing Dial("SIP/102-08184808", "Zap/5/6653674")
in new stack
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing Congestion("SIP/102-08184808", "") in new
stack
(Got fast-busy, so hung up SIP)
  == Spawn extension (internal, 96653674, 2) exited non-zero on
'SIP/102-08184808'
(about now, the outside line went back to dialtone.)

Sometimes, I can repeat that pick-back-up trick three or four times.

Problem B:  Dialing out.  From the SIP phone, if I dial out, here's the
transcript:

    -- Executing Dial("SIP/102-081854e0", "Zap/5/6653674")
in new stack
    -- Called 5/6653674
    -- Zap/5-1 answered SIP/102-081854e0
    -- Hungup 'Zap/5-1'
  == Spawn extension (internal, 96653674, 1) exited non-zero on
'SIP/102-081854e0'

Sometimes (about half the time) the phone I'm calling (in this case, a
cell) will give part of one ring, then report a missed call.  The SIP
phone hangs up after about 5 seconds.  But not always.  The rest of the
time, the SIP phone just eventually (15 or 20 secs) hangs up on its'
own, and the cell never reports a missed call.

I know this has been long, and wordy...hope someone can help.  We're
newbs around here, and trying to get things working.  My boss is *very*
impressed with the menus and such I've got set up and working, and we've
used soft phones via VPN and it works great...now we just need our
outside lines working!

Thanks a million!

J. David Bavousett
System Administrator
Abilene Library Consortium

On 5/15/07, J. David Bavousett <davidb@alc.org>
wrote:
>
> Two problems, possibly related:
>
> Here's the configuration...my Asterisk box has a TDM844B in it; port
1-4
> are FXS, 5-8 FXOs.
>
> Here are the config files:
>
> /etc/zaptel.conf:
> --------
> fxoks=1
> fxoks=2
> fxoks=3
> fxoks=4
> fxsks=5
> fxsks=6
> fxsks=7
> fxsks=8
>
> loadzone        = us
> defaultzone     = us
> --------
> /etc/asterisk/zapata.conf:
> --------
> [channels]
> language=en
> usecallerid=yes
> hidecallerid=no
> callwaiting=no
> threewaycalling=no
> transfer=no
> echocancel=yes
> echocancelwhenbridged=yes
> echotraining=yes
> canpark=yes
> rxgain=0.0
> txgain=0.0
>
> context=internal
> signalling=fxo_ks
> channel => 1-4

I recommend that you put in a group, like group=2

context=external
> signalling=fxs_ks
> channel => 5-8
> --------
>
> A snippet from /etc/asterisk/extensions.conf:
> --------
> [internal]
> ignorepat => 9

if you put in the group, you can dial out via:
exten => _9NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) to start with the lowest
available channel, or
                                  Dial(ZAP/G2/${EXTEN:1}) to start with the
highest available channel.

This will let you make more than one outgoing call at a time.

exten => _9NXXXXXX,2,Congestion()
> exten => _9NXXXXXX,102,Congestion()
> --------
>
> The SIP phone is also in the internal context, and other things below
> that in the context work just fine on the internal network.
>
> I don't know if it's relevant or not, but dialtone stops after I
press
> 9, which is not what I was led to believe would happen with the
> ignorepat directive.

Dial tone is generated by the SIP phone. You'll need to configure it
directly on whatever SIP device you're using. Now, if your analog phones
(like on ports 1-4) stop dial tone, you might need to be concerned.

Problem A:  Dialing in.  If I call from my cell, the FXO picks right
up,
> and sends me to the voice menu that I have at the top of the [external]
> context.  So far so good, but if the SIP that I get in touch with hangs
> up, the FXO stays off-hook for more than a minute before dropping the
> POTS line.  If I pick that SIP phone back up, and dial an outside
> number, I can reconnect to the "dangling" call, which will hear
the
> tones after the 9...  The outside caller will finally get dropped after
> about a minute of waiting.

This is "normal" when dealing with POTS lines. You can try to get
disconnect
supervision, try to trick zaptel into guessing what the state of the line
is, but in my experience, it just comes with the territory. Disconnect
supervision is, by far, the best solution, but most telcos stick their
fingers in their ears when it's requested...

That's one of the main reasons we use PRI where it makes sense, and have
people hang up the phones where it doesn't.

 <snip>
>
> Problem B:  Dialing out.  From the SIP phone, if I dial out, here's the
> transcript:
>
>     -- Executing Dial("SIP/102-081854e0",
"Zap/5/6653674") in new stack
>     -- Called 5/6653674
>     -- Zap/5-1 answered SIP/102-081854e0
>     -- Hungup 'Zap/5-1'
>   == Spawn extension (internal, 96653674, 1) exited non-zero on
> 'SIP/102-081854e0'
>
> Sometimes (about half the time) the phone I'm calling (in this case, a
> cell) will give part of one ring, then report a missed call.  The SIP
> phone hangs up after about 5 seconds.  But not always.  The rest of the
> time, the SIP phone just eventually (15 or 20 secs) hangs up on its'
> own, and the cell never reports a missed call.

I'm not sure on this one. It could be a bad line, the line may not be fully
reset from the previous call, or something completely different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20070515/740c5704/attachment.htm

David:  

Thanks for your tips...all but one issue, then, "solved" as best it
can
be solved.  Just the outbound dialing issue, now...

--David B.

>From yesterday:
-----Original Message-----

Here's the configuration...my Asterisk box has a TDM844B in it; port 1-4
are FXS, 5-8 FXOs.

Here are the config files:

/etc/zaptel.conf:
--------
fxoks=1
fxoks=2
fxoks=3
fxoks=4
fxsks=5
fxsks=6
fxsks=7
fxsks=8

loadzone        = us
defaultzone     = us
--------
/etc/asterisk/zapata.conf:
--------
[channels]
language=en
usecallerid=yes
hidecallerid=no
callwaiting=no
threewaycalling=no
transfer=no
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
canpark=yes
rxgain=0.0
txgain=0.0

context=internal
signalling=fxo_ks
channel => 1-4

context=external
signalling=fxs_ks
channel => 5-8
--------

A snippet from /etc/asterisk/extensions.conf:
--------
[internal]
ignorepat => 9
exten => _9NXXXXXX,1,Dial(Zap/5/${EXTEN:1})
exten => _9NXXXXXX,2,Congestion()
exten => _9NXXXXXX,102,Congestion()
--------

The SIP phone is also in the internal context, and other things below
that in the context work just fine on the internal network.

Problem B:  Dialing out.  From the SIP phone, if I dial out, here's the
transcript:

    -- Executing Dial("SIP/102-081854e0", "Zap/5/6653674")
in new stack
    -- Called 5/6653674
    -- Zap/5-1 answered SIP/102-081854e0
    -- Hungup 'Zap/5-1'
  == Spawn extension (internal, 96653674, 1) exited non-zero on
'SIP/102-081854e0'

Sometimes (about half the time) the phone I'm calling (in this case, a
cell) will give part of one ring, then report a missed call.  The SIP
phone hangs up after about 5 seconds.  But not always.  The rest of the
time, the SIP phone just eventually (15 or 20 secs) hangs up on its'
own, and the cell never reports a missed call.

I know this has been long, and wordy...hope someone can help.  We're
newbs around here, and trying to get things working.  My boss is *very*
impressed with the menus and such I've got set up and working, and we've
used soft phones via VPN and it works great...now we just need our
outside lines working!

Thanks a million!

J. David Bavousett
System Administrator
Abilene Library Consortium

--------------------

One other symptom:  I never, ever hear any ringing on the SIP phone
while it's dialing out.  No indication is ever given that it's ringing
on the other end.

Can *anyone* shed some light on this? 

--David

J. David Bavousett wrote:
> Problem A:  Dialing in.  If I call from my cell, the FXO picks right up,
> and sends me to the voice menu that I have at the top of the [external]
> context.  So far so good, but if the SIP that I get in touch with hangs
> up, the FXO stays off-hook for more than a minute before dropping the
> POTS line.  If I pick that SIP phone back up, and dial an outside
> number, I can reconnect to the "dangling" call, which will hear
the
> tones after the 9...  The outside caller will finally get dropped after
> about a minute of waiting.
You need to tell the telco to change the disconnect supervision or CPC
(Calling Party Control) parameters for your switch.

This can be tricky if your number is a residential number, depending on
the telco. If it's a business line, *demand* that they be changed. There
are still lots of people using key systems with analog lines, and they
need the same kind of disconnect supervision.

Here's what I do: I call the telco repair number and I open a trouble
ticket. I say I am having trouble with my equipment because of an
improper setting on the telco side; then I say that I need the
disconnect interval on calling party disconnect set to 5 seconds, and I
ask that the battery drop be extended to 500 ms (just to be safe). Once
those changes are made, it works really very well.

If you get dumbfounded responses ask to speak to someone in the
programming group (unless they are a tiny little phone company, they
will have one). If you open a ticket, it usually means they will
escalate the problem, even if the agent you are speaking with has no
idea what you are talking about. Best to be friendly with them!

98% of modern switches can do this (otherwise, how would it even know to
disconnect after one whole minute? It has to have some way of knowing
that the remote port has dropped; on most switches, 65 seconds is the
default; it's just a matter of changing that interval for your port) and
your biggest challenge will be finding someone who has a clue, but if
you do it right, it's not a big deal.

-Stephen-