[asterisk-r2] R2 link not receiving complete DNIS...

[Carlos Chavez]

	Today we had a report from a new installation that they could not
receive international calls.  After looking at the logs we found that
the Telmex E1 was nos sending (or we were not receiving) the 4 digit
DNIS.  Here is an example:

Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - Bits changed from
0x08 to 0x00 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - CAS Rx <<
[SEIZE] 0x00 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - Initialized R2
MF detector 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - CAS Tx >> [SEIZE
ACK] 0x0C 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - CAS Raw Tx >>
0x0D 
> [Sep 29 15:54:58] VERBOSE[3877] chan_dahdi.c: New MFC/R2 call detected
on chan 31. 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Rx << 2 [ON] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - Getting DNIS
digit 2 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - DNIS so far: 2,
expected length: 4 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Tx >> 6 [ON] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Rx << 2
[OFF] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Tx >> 6
[OFF] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Rx << 2 [ON] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Tx >> 1 [ON] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Rx << 2
[OFF] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Tx >> 1
[OFF] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Rx << F [ON] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - Got end of ANI 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - Requesting next
DNIS with signal 0x35. 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Tx >> 5 [ON] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Rx << F
[OFF] 
> [Sep 29 15:54:58] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Tx >> 5
[OFF] 
> [Sep 29 15:55:03] DEBUG[3877] chan_dahdi.c: Chan 31 - calling timer 4
(mf_back_cycle) callback 
> [Sep 29 15:55:03] DEBUG[3877] chan_dahdi.c: Chan 31 - MF cycle timed
out, no more DNIS 
> [Sep 29 15:55:03] DEBUG[3877] chan_dahdi.c: Chan 31 - Requesting
change to Group II with signal 0x33 
> [Sep 29 15:55:03] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Tx >> 3 [ON] 
> [Sep 29 15:55:03] DEBUG[3877] chan_dahdi.c: Chan 31 - calling timer 5
(mf_back_resume_cycle) callback 
> [Sep 29 15:55:03] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Tx >> 3
[OFF] 
> [Sep 29 15:55:03] DEBUG[3877] chan_dahdi.c: Chan 31 - MF Rx << 2 [ON] 
> [Sep 29 15:55:03] VERBOSE[3877] chan_dahdi.c: MFC/R2 call offered on
chan 31. ANI = , DNIS = 2, Category = National Priority Subscriber
> [Sep 29 15:55:03] NOTICE[3877] chan_dahdi.c: MFC/R2 call on channel 31
requested non-existent extension '2' in context 'e1-incoming'. Rejecting
call. 
> 

	Here is what we use in chan_dahdi.conf for the E1:

mfcr2_variant=mx
mfcr2_category=national_priority_subscriber
mfcr2_get_ani_first=no
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_logdir=span1
mfcr2_logging=all
mfcr2_call_files=no

	Calls from inside the country get the 4 digit DNIS without any problem,
only international calls have the problem and receive only a singe digit
for DNIS.  Since my catchall route was _XXXX for any DID not listed my
server was rejecting the calls.  To solve the problem we put a _X rule
for a single digit to go to the main IVR but this means that any
international caller will not be able to get anything but the main IVR.
Do you think this is an R2 problem on Asterisk or is Telmex the one not
sending the proper info?  Basically the question is: Do I scream at
Telmex or do I debug the problem further?

-- 
Telecomunicaciones Abiertas de México S.A. de C.V.
Carlos Chávez Prats
Director de Tecnología
+52-55-91169161 ext 2001
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-r2/attachments/20100929/d58411db/attachment.pgp