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

[Norman Schmidt]

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!