[Asterisk-Users] incoming number truncated

Peter Svensson psvasterisk at psv.nu
Mon Sep 6 23:22:50 MST 2004


On Tue, 7 Sep 2004, Oliver Breidenbach wrote:

> Update:
> 
> editing "channels/chan_zap.c" and setting "#define DEFAULT_CIDRINGS 2" 
> and recompile seems to have fixed the problem although it still shows 
> only the higher 6 numbers in the CLI console...
> 
> Very, very, very esoteric.

I still think your pstn provider has configured the link to send the last 
two digits as overlap digits instead of using enbloc dialing (sending the 
whole number at once after dialing is completed). Did you try enabling 
overlap dialing on that line ("overlapdial=yes" in zapata.conf)?

The "Called Number" was not marked with "Sending Complete" by the pstn so 
there may be overlap digits sent as information elements. By setting 
DEFAULT_CIDRINGS I think you forced asterisk to wait a bit longer. Setting 
"overlapdial=yes" should make it wait until the pstn provider sends 
"Sending Complete".

For some reason asterisk is sending "Call Proceeding" which tells the 
other end of the isdn connection that no more digits is needed. It has 
enough information to process the call. Are you sure there are no rules 
that could match only the first 6 digits? If not i really do not see what 
is going wrong. Asterisk should accumulate digits until "Sending Complete" 
or a match is found in overlap mode.

If you run a "pri intense debug" on your modified asterisk with 
DEFAULT_CIDRINGS, do you see more digits coming in in information 
elements? 

If you fail to get asterisk to work correctly you could ask your pstn 
provider to configure the isdn link to send the called number indication 
enbloc. They should be able to configure that.

Peter

> 
> Cheers,
> 
> Oliver.
> 
> 
 On 07.09.2004, at 01:30, Oliver Breidenbach wrote:
> 
> > Peter,
> >
> > thanks for trying to help.
> >
> > I've enabled overlap dialing with no effect.
> >
> > "pri intense debug span 1" gives this output:
> >
> > < Informational frame:
> > < SAPI: 00  C/R: 1 EA: 0
> > <  TEI: 000        EA: 1
> > < N(S): 102   0: 0
> > < N(R): 105   P: 0
> > < 41 bytes of data
> > -- ACKing all packets from 104 to (but not including) 105
> > -- Since there was nothing left, stopping T200 counter
> > -- Stopping T203 counter since we got an ACK
> > -- Nothing left, starting T203 counter
> > < Protocol Discriminator: Q.931 (8)  len=41
> > < Call Ref: len= 2 (reference 102/0x66) (Originator)
> > < Message type: SETUP (5)
> > < [04 03 90 90 a3]
> > < Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer 
> > capability: 3.1kHz audio (16)
> > <                              Ext: 1  Trans mode/rate: 64kbps, 
> > circuit-mode (16)
> > <                              Ext: 1  User information layer 1: A-Law 
> > (35)
> > < [18 03 a9 83 81]
> > < Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, 
> > Exclusive Dchan: 0
> > <                        ChanSel: Reserved
> > <                       Ext: 1  Coding: 0   Number Specified   Channel 
> > Type: 3
> > <                       Ext: 1  Channel: 1 ]
> > < [1e 02 80 83]
> > < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard 
> > (0) 0: 0   Location: User (0)
> > <                               Ext: 1  Progress Description: Calling 
> > equipment is non-ISDN. (3) ]
> > < [6c 0b 21 83 38 39 38 39 34 33 39 39 30]
> > < Calling Number (len=13) [ Ext: 0  TON: National Number (2)  NPI: 
> > ISDN/Telephony Numbering Plan (E.164/E.163) (1)
> > <                           Presentation: Presentation allowed of 
> > network provided number (3) '123456789' ]
> >
> > =================================================================^
> > I changed this number to protect privacy. But it is 9 digits and it is 
> > correct.
> > =================================================================
> >
> > < [70 07 c1 38 34 30 30 35 33]
> > < Called Number (len= 9) [ Ext: 1  TON: Subscriber Number (4)  NPI: 
> > ISDN/Telephony Numbering Plan (E.164/E.163) (1) '876543' ]
> >
> > =================================================================^
> > I also changed this. len=9 should mean 9 digits, right? the number i 
> > dialed is "87654321", the "21" is missing.
> > =================================================================
> >
> >     Sending Receiver Ready (103)
> > > [ 02 01 01 ce ]
> > > Supervisory frame:
> > > SAPI: 00  C/R: 1 EA: 0
> > >  TEI: 000        EA: 1
> > > Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> > > N(R): 103 P/F: 0
> > > 0 bytes of data
> > -- Restarting T203 counter
> > -- Restarting T203 counter
> > > [ 00 01 d2 ce 08 02 80 66 02 18 03 a9 83 81 ]
> > > Informational frame:
> > > SAPI: 00  C/R: 0 EA: 0
> > >  TEI: 000        EA: 1
> > > N(S): 105   0: 0
> > > N(R): 103   P: 0
> > > 10 bytes of data
> > -- Restarting T203 counter
> > Stopping T_203 timer
> > Starting T_200 timer
> > > Protocol Discriminator: Q.931 (8)  len=10
> > > Call Ref: len= 2 (reference 32870/0x8066) (Terminator)
> > > Message type: CALL PROCEEDING (2)
> > > [18 03 a9 83 81]
> > > Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, 
> > Exclusive Dchan: 0
> > >                        ChanSel: Reserved
> > >                       Ext: 1  Coding: 0   Number Specified   Channel 
> > Type: 3
> > >                       Ext: 1  Channel: 1 ]
> >     -- Accepting call from '123456789' to '876543' on channel 0/1, 
> > span 1
> >
> > Any ideas?
> >
> > Cheers,
> >
> > Oliver.
> >
> >
> > On 07.09.2004, at 00:51, Peter Svensson wrote:
> >
> >> On Mon, 6 Sep 2004, Oliver Breidenbach wrote:
> >>
> >>> We are calling from a number in the same local area code and there
> >>> seems to be only the 6 most significant numbers of the target adress
> >>> arrive in Asterisk.
> >>>
> >>> For example, we are calling 99999123 and the CLI shows only the 
> >>> 999991
> >>> and tries to match that with a extension rule.
> >>>
> >>> (We've set up a rule for _99999XXX with StripMSD(5) and a rule for
> >>> extension 123.)
> >>>
> >>> The strange thing is that if I dial the number with the area code 
> >>> (i.e.
> >>> 089/99999123) or from a mobile fone it works and properly connects to
> >>> the correct extension.
> >>
> >> Perhaps the rest of the number is sometimes sent as overlap digits? 
> >> Try
> >> doing "pri intense debug span XXXX" and see if there are additioal 
> >> digits
> >> coming in as overlap. Or try enabling overlap dialing for that span.
> >>
> >> Peter
> >>
> >> _______________________________________________
> >> Asterisk-Users mailing list
> >> Asterisk-Users at lists.digium.com
> >> http://lists.digium.com/mailman/listinfo/asterisk-users
> >> To UNSUBSCRIBE or update options visit:
> >>    http://lists.digium.com/mailman/listinfo/asterisk-users
> >
> > _______________________________________________
> > Asterisk-Users mailing list
> > Asterisk-Users at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-users
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
> 

Peter
--
Peter Svensson      ! Pgp key available by finger, fingerprint:
<petersv at psv.nu>    ! 8A E9 20 98 C1 FF 43 E3  07 FD B9 0A 80 72 70 AF
------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...





More information about the asterisk-users mailing list