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

Tue Mar 24 15:57:37 CDT 2009

Its definitely my fault on the dialplan logic. 
I narrowed it to the point to leaving just this in extensions.conf:

-------------- extensions.conf
[general]
static=yes
writeprotect=yes
autofallthrough=yes
clearglobalvars=yes

[globals]
priorityjumping=yes

[from-panasonic]
exten => 30252000,1,Dial(ZAP/g0/${EXTEN},60,tT)
exten => 30252000,n,Hangup()       
-------------- EOF extensions.conf

And that worked flawlessy.

> ----- 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 12:29
> 
> 
> You need to narrow down your dial plan, I can't spend much time trying
> to see the extensions matched in your incoming context. However I can
> say that if you dialed 30252000 and there is a proper single match for
> that number, it will work. If there is a match for longer numbers,
> then it may not work if the PBX is not configured to accept signal 5
> (accept call) at this stage. I see that Asterisk is accepting the call
> but your PBX decides to hangup. I don't think this works with unicall
> either, as libmfcr2 does the same thing in such situation AFAIR.
> 
> This sounds like a misconfiguration of your PBX.
> 
> Moy
> 
> On Tue, Mar 24, 2009 at 11:13 AM, Norman Schmidt
> <norman at omegatecnologia.com> wrote:
> > Sorry I didnt pasted any configs on the previous message...
> >
> > Here goes a fresh debug try, and the configs:
> >
> > zaptel.conf:
> > http://pastebin.com/m31ebeed3
> >
> > zapata.conf:
> > http://pastebin.com/m34beb207
> >
> > my extensions.conf:
> > http://pastebin.com/m7518c0a5
> >
> > And here is a debug case, I tried to dial "30252000" from a phone
connected
> > to the panasonic PBX:
> > logs:
> >
> > [Mar 24 12:03:23] NOTICE[16932]: chan_zap.c:961 zt_r2_on_call_init: New
> > MFC/R2 call detected on chan 32.
> > [Mar 24 12:04:25] NOTICE[16932]: chan_zap.c:1196 zt_r2_write_log: Chan
32 -
> > Far end disconnected. Reason: Normal Clearing
> > [Mar 24 12:04:25] NOTICE[16932]: chan_zap.c:1153
zt_r2_on_call_disconnect:
> > MFC/R2 call disconnected on chan 32
> > [Mar 24 12:04:25] NOTICE[16932]: chan_zap.c:1064 zt_r2_on_call_end:
MFC/R2
> > call end on chan 32
> >
> > [Mar 24 12:03:23] NOTICE[16932] chan_zap.c: New MFC/R2 call detected on
chan
> > 32.
> > [Mar 24 12:04:25] NOTICE[16932] chan_zap.c: Chan 32 - Far end
disconnected.
> > Reason: Normal Clearing
> > [Mar 24 12:04:25] NOTICE[16932] chan_zap.c: MFC/R2 call disconnected on
chan
> > 32
> > [Mar 24 12:04:25] NOTICE[16932] chan_zap.c: MFC/R2 call end on chan 32
> >
> > the call file chan-32-backward-0-20090324120323.call:
> > http://pastebin.com/m6b21ff7d
> >
> >> ----- 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
> >
> >
> >
> > _______________________________________________
> > --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