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

[Moises Silva]

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