[asterisk-r2] Behaviour between chan_unicall and chan_zap with openr2?

Tue Mar 24 10:01:10 CDT 2009

Thats the odd thing. The call doesnt show up at the console when the PBX
doesnt send 13 digits. When the PBX sends a call with a 13 digits DNIS to
the Span at the PBX side there is a:

 -- Executing [021xxxxxxxxxx at from-panasonic:1] 
and the rest is textbook dialplan.

but with less than 13 digits, this never appears. Instead, after a long time
after dialing, what appears is:

[Mar 24 10:02:38] WARNING[13039] chan_zap.c: Chan 9 - Seize Timeout Expired!
[Mar 24 10:02:38] ERROR[13039] chan_zap.c: Chan 9 - Protocol error. Reason =
Seize Timeout, R2 State = Clear Forward Transmitted, MF state = MF Engine
Off, MF
DNIS = , ANI = 30252000, MF = 0x20
[Mar 24 10:02:38] ERROR[13039] chan_zap.c: MFC/R2 protocol error on chan 9:
Seize Timeout     

Chan 9 is a channel on the telco Span! Odd! To get to the other side of the
gateway, the call MUST pass the dialplan. But it doesnt show up!

Here is the call file:

[10:02:30:684] [Thread: 3056868272] [Chan 9] - Call started at Tue Mar 24
10:02:30 2009 on chan 9
[10:02:30:684] [Thread: 3056868272] [Chan 9] - CAS Tx >> [SEIZE] 0x00
[10:02:30:684] [Thread: 3056868272] [Chan 9] - CAS Raw Tx >> 0x01
[10:02:30:685] [Thread: 3056868272] [Chan 9] - Attempting to cancel timer
timer 0
[10:02:30:685] [Thread: 3056868272] [Chan 9] - Cannot cancel timer 0
[10:02:30:685] [Thread: 3056868272] [Chan 9] - CAS Tx >> [CLEAR FORWARD]
0x08
[10:02:30:685] [Thread: 3056868272] [Chan 9] - CAS Raw Tx >> 0x09
[10:02:38:702] [Thread: 3068488624] [Chan 9] - Attempting to cancel timer
timer 2
[10:02:38:702] [Thread: 3068488624] [Chan 9] - timer id 2 found, cancelling
it now
[10:02:38:702] [Thread: 3068488624] [Chan 9] - calling timer callback
[10:02:38:702] [Thread: 3068488624] [Chan 9] - Seize Timeout Expired!
[10:02:38:703] [Thread: 3068488624] [Chan 9] - Protocol error. Reason =
Seize Timeout, R2 State = Clear Forward Transmitted, MF state = MF Engine
Off, MF Group
= Forward MF init, CAS = 0x08
DNIS = , ANI = 30252000, MF = 0x20
[10:02:38:703] [Thread: 3068488624] [Chan 9] - Attempting to cancel timer
timer 0
[10:02:38:703] [Thread: 3068488624] [Chan 9] - Cannot cancel timer 0       

> ----- Mensagem Original -----
> Assunto: Re: [asterisk-r2] Behaviour between chan_unicall and chan_zap
with openr2?
> De: Moises Silva <moises.silva at gmail.com>
>  Para: "Norman Schmidt"
<norman at omegatecnologia.com>,asterisk-r2 at lists.digium.com
> Data: 24/03/2009 0:47
> 
> 
> Hello Norman,
> 
> This depends on what your dial plan is. Show me the dial plan and I
> can more accurately answer. OpenR2, or better said, the openr2
> implementation in Asterisk attempts to match the DNIS as is received,
> so, as soon as it matches a number in the incoming context and there
> is no other possible match in the plan it will stop requesting DNIS,
> this is more efficient and faster than waiting for timeout in the
> variants where timeout is used to signal end of DNIS.
> 
> Again, show me the dial plan and I will able to explain the behaviour
> of each one.
> 
> Moy
> 
> On Mon, Mar 23, 2009 at 6:30 PM, Norman Schmidt
> <norman at omegatecnologia.com> wrote:
> > For some months, I was using the following configuration for some
channels
> > at unicall.conf, at an Asterisk machine acting as a recording gateway
> > between a Panasonic PBX and the telco R2 E1:
> >
> > (...)
> > context=from-panasonic
> > protocolvariant=br,10,13
> > group=1
> > callgroup=1
> > pickupgroup=1
> > channel => 32-46,48-62
> >
> > After some tweaking, Im now using chan_zap with libopenr2 on the same
> > scenario, with the following settings on the same context:
> >
> > context=from-panasonic
> > mfcr2_variant=br
> > mfcr2_get_ani_first=no
> > mfcr2_category=national_subscriber
> > mfcr2_max_ani=10
> > mfcr2_max_dnis=13
> > ; starting here are some workarounds to get things better with the
Panasonic
> > PBX. i.e. "wild guesses"
> > mfcr2_mfback_timeout=3000
> > mfcr2_metering_pulse_timeout=-1
> > mfcr2_charge_calls=yes
> > mfcr2_allow_collect_calls=yes
> > mfcr2_double_answer=no
> > mfcr2_charge_calls=yes
> > mfcr2_forced_release=yes
> > group=1
> > callgroup=1
> > pickupgroup=1
> > channel => 32-46,48-62
> >
> > This works, but sometimes I face something that looks like a new
behaviour:
> > Using chan_unicall, when the Panasonic PBX send less than 13 DNIS
digits, I
> > was still able to deal with this on the Asterisk dialplan (it receives
ANI
> > and the less-than-13-digits DNIS, etc). Now using chan_zap with openr2,
the
> > call gets immediately disconnected when less than 13 digits are sent by
the
> > Panasonic PBX. Which behaviour is correct?
> >
> > If anybody has experience using libopenR2 with a Panasonic PBX, I would
love
> > to hear about!
> >
> >
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by http://www.api-digital.com--
> >
> > asterisk-r2 mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-r2
> >
> 
> 
> 
> -- 
> "I do not agree with what you have to say, but I’ll defend to the
> death your right to say it." Voltaire