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

Tue Mar 24 16:14:03 CDT 2009

well, its kind of your fault, but not completely. If you set your dial plan as:

[from-panasonic]
exten => XXXXXXX,1,Dial(ZAP/g0/${EXTEN},60,tT)
exten => XXXXXXX,n,Hangup()
exten => XXXXXXXX,1,Dial(ZAP/g0/${EXTEN},60,tT)
exten => XXXXXXXX,n,Hangup()

You should see the problem as well. Each digit that is received from
the PBX will be checked against this dial plan, so, when we reach 8
digits and we check, Asterisk says, ok 8 digits is enough to make a
match, but, if we ask for another digit we may also match another
rule, therefore Asterisk tries to ask another digit, the problem is
that the PBX does not have another digit. Some R2 variants will
respond to our next digit request with a signal that means  "sorry, no
more digits" and then asterisk will quickly start executing the rule
that matched with 8 digits, however, the Brazilian variant and others,
do not have the signal "sorry, no more digits" and instead just ignore
the request, since openr2 knows this, it will timeout and when it time
outs attempts to continue and accept the call with a pulse tone, but
your PBX does not detect or does not like this pulse tone and hangs
up, I don't know why though.

Moy

On Tue, Mar 24, 2009 at 2:57 PM, Norman Schmidt
<norman at omegatecnologia.com> wrote:
> 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
>
>
>
> _______________________________________________
> --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