asterisk users - Oct 2012 - Automatic jump from line to line for incoming calls and the problem in DAHDI

Dears;

I am facing the following problem:

Already we requested from the service provider to enable the auto jumping
service for our analoge telephone lines, so because we have 4 telephone lines
from the service provider, then if you called line # 1 and it was busy, then the
call will be sent to any available line #2 or #3 or #4, and if you call line # 3
and it was busy then the call will be sent via any available line of these four
lines.

This feature is causing a problem at the Asterisk PBX, so some calls are not
handled properly (it is ringing and we do not hear the welcome message), also
the outgoing calls are facing a problem because it seems that there is a
confusing happening in dahdi to determine the available line.

I do not know really how the automatic jumping feature is working at the service
provider and what is the effecting on the DAHDI and Asterisk that is causing to
not responding for the DAHDI channels properly.

For more details to be sure that I described the behaviour of the auto jumping
feature that I took it from the service provider, let us assume my number is
22446789, when I call this number and I look for asterisk CLI, I can see that
the call came via DAHDI/3-1 and then I do another call to this line, I can see
it via DAHDI/4-1 and I do another call to this line and I will see it via
DAHDI/2-1.

Also, not all my calls are failed ... but some are succeed and some are fails,
so the responding is not perfect. I am sure because of the auto jumping feature
from the service provider.

Appreciate the kindly help and advise.

Regards
Bilal

On Wednesday 17 October 2012, bilal ghayyad wrote:
> Dears;
> 
> I am facing the following problem:
> 
> Already we requested from the service provider to enable the auto jumping
> service for our analoge telephone lines, so because we have 4 telephone
> lines from the service provider, then if you called line # 1 and it was
> busy, then the call will be sent to any available line #2 or #3 or #4, and
> if you call line # 3 and it was busy then the call will be sent via any
> available line of these four lines.
> 
> This feature is causing a problem at the Asterisk PBX, so some calls are
> not handled properly (it is ringing and we do not hear the welcome
> message), also the outgoing calls are facing a problem because it seems
> that there is a confusing happening in dahdi to determine the available
> line.
> 
> I do not know really how the automatic jumping feature is working at the
> service provider and what is the effecting on the DAHDI and Asterisk that
> is causing to not responding for the DAHDI channels properly.
> 
> For more details to be sure that I described the behaviour of the auto
> jumping feature that I took it from the service provider, let us assume my
> number is 22446789, when I call this number and I look for asterisk CLI, I
> can see that the call came via DAHDI/3-1 and then I do another call to
> this line, I can see it via DAHDI/4-1 and I do another call to this line
> and I will see it via DAHDI/2-1.
> 
> Also, not all my calls are failed ... but some are succeed and some are
> fails, so the responding is not perfect. I am sure because of the auto
> jumping feature from the service provider.
If you have multiple lines, and they are all paid for in the same name, then 
your telco really should have set it up so they are all accessible by dialling 
the same number.

Way back in the clicky-clicky days, having multiple lines connected to the 
same switchboard would have been done at the exchange by allocating sequential 
lines on the same selector, which was modified to step on until it found a non-
engaged line  (or go to engaged tone, if the last in the set were engaged).  
For instance, Radio Derby's main switchboard number was 361111; but 361112, 
361113, 361114, 361115 or 361116 might also reach the switchboard  (depending 
whether or not that line was already in use).

Digital exchanges don't have such requirements, of course; and since we went
over to System X, which does not impose a 1:1 mapping between  (logical)  
numbers and  (physical)  lines, 361112  (at least)  has been allocated to 
another subscriber.  And there are many lines numbered 361111.

If you have several lines and they are properly grouped by the telco, you may 
get a call coming in via a differently-numbered line than what the other 
subscriber actually dialled.  

The way top deal with this in Asterisk is as follows:  Have one context that 
handles incoming calls from the PSTN  (usually  [from-pstn]  but you may have 
changed this).  In this context, you just need to handle calls for any 
extension the same.  (Or make sure, by using a catch-all such as the
"s"
extension or "_X.")

For calling out, make sure all your DAHDI channels are in the same group in 
chan_dahdi.conf, and use something in your Dial() command like 
Dial(DAHDI/g1/${EXTEN}) or Dial(DAHDI/r1/${EXTEN}) .  The "g" form
will try
always to use the lowest-numbered available channel; the "r" form will
keep a
track of which channel was used last and try to cycle through channels in turn 
from lowest to highest.  (Capital G1 and R1 will try always to use the highest 
number, and cycle through from high to low respectively).


-- 
AJS

Answers come *after* questions.

Actually I am not talking on how to handle it in the extensions.conf because I
am doing same as you wrote. But even so, I am facing a problem that some calls
are captured and some calls are not captured.

Currently, I set the callwaiting=no in the chan_dahdi.conf, it seems it is
working fine. But I am not sure if this is really the required configuration to
fix it or there is something else.

Any advise.

Regards
Bilal
--------------------
> > Dears;
> > 
> > I am facing the following problem:
> > 
> > Already we requested from the service provider to
> enable the auto jumping
> > service for our analoge telephone lines, so because we
> have 4 telephone
> > lines from the service provider, then if you called
> line # 1 and it was
> > busy, then the call will be sent to any available line
> #2 or #3 or #4, and
> > if you call line # 3 and it was busy then the call will
> be sent via any
> > available line of these four lines.
> > 
> > This feature is causing a problem at the Asterisk PBX,
> so some calls are
> > not handled properly (it is ringing and we do not hear
> the welcome
> > message), also the outgoing calls are facing a problem
> because it seems
> > that there is a confusing happening in dahdi to
> determine the available
> > line.
> > 
> > I do not know really how the automatic jumping feature
> is working at the
> > service provider and what is the effecting on the DAHDI
> and Asterisk that
> > is causing to not responding for the DAHDI channels
> properly.
> > 
> > For more details to be sure that I described the
> behaviour of the auto
> > jumping feature that I took it from the service
> provider, let us assume my
> > number is 22446789, when I call this number and I look
> for asterisk CLI, I
> > can see that the call came via DAHDI/3-1 and then I do
> another call to
> > this line, I can see it via DAHDI/4-1 and I do another
> call to this line
> > and I will see it via DAHDI/2-1.
> > 
> > Also, not all my calls are failed ... but some are
> succeed and some are
> > fails, so the responding is not perfect. I am sure
> because of the auto
> > jumping feature from the service provider.
> 
> If you have multiple lines, and they are all paid for in the
> same name, then 
> your telco really should have set it up so they are all
> accessible by dialling 
> the same number.
> 
> Way back in the clicky-clicky days, having multiple lines
> connected to the 
> same switchboard would have been done at the exchange by
> allocating sequential 
> lines on the same selector, which was modified to step on
> until it found a non-
> engaged line? (or go to engaged tone, if the last in
> the set were engaged).? 
> For instance, Radio Derby's main switchboard number was
> 361111; but 361112, 
> 361113, 361114, 361115 or 361116 might also reach the
> switchboard? (depending 
> whether or not that line was already in use).
> 
> Digital exchanges don't have such requirements, of course;
> and since we went 
> over to System X, which does not impose a 1:1 mapping
> between? (logical)? 
> numbers and? (physical)? lines, 361112? (at
> least)? has been allocated to 
> another subscriber.? And there are many lines numbered
> 361111.
> 
> If you have several lines and they are properly grouped by
> the telco, you may 
> get a call coming in via a differently-numbered line than
> what the other 
> subscriber actually dialled.? 
> 
> The way top deal with this in Asterisk is as follows:?
> Have one context that 
> handles incoming calls from the PSTN? (usually?
> [from-pstn]? but you may have 
> changed this).? In this context, you just need to
> handle calls for any 
> extension the same.? (Or make sure, by using a
> catch-all such as the "s" 
> extension or "_X.")
> 
> For calling out, make sure all your DAHDI channels are in
> the same group in 
> chan_dahdi.conf, and use something in your Dial() command
> like 
> Dial(DAHDI/g1/${EXTEN}) or Dial(DAHDI/r1/${EXTEN}) .?
> The "g" form will try 
> always to use the lowest-numbered available channel; the "r"
> form will keep a 
> track of which channel was used last and try to cycle
> through channels in turn 
> from lowest to highest.? (Capital G1 and R1 will try
> always to use the highest 
> number, and cycle through from high to low respectively).
> 
> 
> -- 
> AJS
> 
> Answers come *after* questions.

On Wednesday 17 October 2012, bilal ghayyad wrote:
> Actually I am not talking on how to handle it in the extensions.conf
> because I am doing same as you wrote. But even so, I am facing a problem
> that some calls are captured and some calls are not captured.
> 
> Currently, I set the callwaiting=no in the chan_dahdi.conf, it seems it is
> working fine. But I am not sure if this is really the required
> configuration to fix it or there is something else.
> 
> Any advise.
 
We need to determine the exact circumstances under which Asterisk is missing 
incoming calls, which is going to require some low-level hacking.

Wire up two LEDs back to back  (so whichever way the current is flowing, one of 
them will always light up).

*----->|-----*
*-----|<-----*

Put in series with this pair a 470 nF capacitor and a 100k? resistor:

*-----| |-----/\/\/\/-----[LEDs]-----*

When this contraption is connected across an analogue phone line, the LEDs 
will light up.  (One lights on the crest of the waveform and one on the 
trough, but this should be happening too fast for the eye to see, and it will 
just look like both are lit.)  The capacitor blocks DC on the line, so the 
LEDs will be off unless AC is present.  Make up 4 of these devices, so you can 
monitor the ringing status of each of the analogue lines going into your 
Asterisk box.  

In your extensions.conf, make sure that you have NoOp(${EXTEN}) somewhere in 
the [from-pstn] context, so you can see what number the upstream exchange was 
sending.  Be sure to include something which will keep a caller on the line 
for awhile.  Connect up a laptop with an SSH client to the network, so you 
have an Asterisk console *and* can see the ringing status of all 4 lines.

Lastly, you will need 4 mobile phones; and possibly volunteers to operate 
them, while you watch the Asterisk console and the LEDs.


Now you can investigate properly what is happening when you dial your analogue 
lines:

* Call a line which is not busy, by its own number.  Does Asterisk respond to 
the call?
* Call a line which *is* busy, by its own number.  Does the call automatically 
appear on another line?  Does Asterisk respond to it?
* Call a non-busy line while another line is busy.  Does Asterisk respond to 
the call?


You should be able to work out eventually just what is causing Asterisk to 
miss calls.


-- 
AJS

Answers come *after* questions.