Re: [asterisk-users] DAHDI/ZAP overlap dialing
--- On Mon, 11/2/09, Martin wrote: > I'd double check that you really have overlapdial=yes for > those > channels ... it should be declared > before channel => keyword in > zapata.conf/chan_dahdi.conf I declared overlapdial in zapata.conf: switchtype = euroisdn signalling = pri_cpe overlapdial=yes context=from-alcatel-custom group = 1 callgroup = 1 pickupgroup = 1 immediate=no echocancel=yes echotraining=yes echocancelwhenbridged=yes rxgain=2.0 txgain=1.0 busydetect=no facilityenable = yes ; pritransfer = ect ; either no, ect, or hangup channel => 1-15,17-31 Will try to change libpri versions or move to another 1.4 * server. Thanks for your time. Vieri ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DAHDI/ZAP overlap dialing
I can only tell you that it worked before... > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Extension '1004' in context > 'from-pstn-deviate-custom' from '7034' does not when you have overlapdial turned on it should have checked if there's a potential matching extension which you have it right there and asterisk should have sent SETUP_ACK message back. if you won't find the solution for this I might fix that as a bounty if you're interested I'd double check that you really have overlapdial=yes for those channels ... it should be declared before channel => keyword in zapata.conf/chan_dahdi.conf Martin On Mon, Nov 2, 2009 at 10:28 AM, Vieri wrote: > > --- On Sat, 10/31/09, Martin wrote: > >> On Sat, Oct 31, 2009 at 5:27 AM, >> Tzafrir Cohen >> wrote: >> > I'm not sure if handling of overlap hasn't changed >> since. >> > >> > But can you provide a trace of how Asterisk sees >> things? e.g. 'pri >> > intense debug span 1' >> > >> >> the intense debug is overkill we only need messages of >> layer 3 ... >> just do "pri debug span 1" >> >> Martin > > Here's the pri trace: > > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Protocol Discriminator: Q.931 (8) > len=38 > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Call Ref: len= 2 (reference > 16976/0x4250) (Originator) > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Message type: SETUP (5) > Nov 2 17:22:28 VERBOSE[11329] logger.c: < [04 03 80 90 a3] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Bearer Capability (len= 5) [ Ext: > 1 Q.931 Std: 0 Info transfer capability: Speech (0) > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Ext: > 1 Trans mode/rate: 64kbps, circuit-mode (16) > Nov 2 17:22:28 VERBOSE[11329] logger.c: < > User information layer 1: A-Law (35) > Nov 2 17:22:28 VERBOSE[11329] logger.c: < [18 03 a9 83 8b] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Channel ID (len= 5) [ Ext: 1 > IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 > Nov 2 17:22:28 VERBOSE[11329] logger.c: < ChanSel: As > indicated in following octets > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Ext: 1 > Coding: 0 Number Specified Channel Type: 3 > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Ext: 1 > Channel: 11 ] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < [1e 02 80 83] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Progress Indicator (len= 4) [ Ext: > 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0) > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Ext: > 1 Progress Description: Calling equipment is non-ISDN. (3) ] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < [6c 06 00 81 37 30 33 34] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Calling Number (len= 8) [ Ext: 0 > TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) > Nov 2 17:22:28 VERBOSE[11329] logger.c: < > Presentation: Presentation permitted, user number passed network screening > (1) '7034' ] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < [70 05 80 31 30 30 34] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < Called Number (len= 7) [ Ext: 1 > TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '1004' ] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < [7d 02 91 81] > Nov 2 17:22:28 VERBOSE[11329] logger.c: < IE: High-layer Compatibility (len > = 4) > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Making new call for cr 16976 > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Processing Q.931 Call Setup > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Processing IE 4 (cs0, Bearer > Capability) > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Processing IE 24 (cs0, Channel > Identification) > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Processing IE 30 (cs0, Progress > Indicator) > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Processing IE 108 (cs0, Calling > Party Number) > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Processing IE 112 (cs0, Called > Party Number) > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Processing IE 125 (cs0, > High-layer Compatibility) > Nov 2 17:22:28 VERBOSE[11329] logger.c: -- Extension '1004' in context > 'from-pstn-deviate-custom' from '7034' does not exist. Rejecting call on > channel 1/11, span 1 > Nov 2 17:22:28 VERBOSE[11329] logger.c: NEW_HANGUP DEBUG: Calling > q931_hangup, ourstate Call Present, peerstate Call Initiated > Nov 2 17:22:28 VERBOSE[11329] logger.c: > Protocol Discriminator: Q.931 (8) > len=9 > Nov 2 17:22:28 VERBOSE[11329] logger.c: > Call Ref: len= 2 (reference > 16976/0x4250) (Terminator) > Nov 2 17:22:28 VERBOSE[11329] logger.c: > Message type: RELEASE COMPLETE (90) > Nov 2 17:22:28 VERBOSE[11329] logger.c: > [08 02 81 81] > Nov 2 17:22:28 VERBOSE[11329] logger.c: > Cause (len= 4) [ Ext: 1 Coding: > CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local > user (1) > Nov 2 17:22:28 VERBOSE[11329] logger.c: >
Re: [asterisk-users] DAHDI/ZAP overlap dialing
--- On Sat, 10/31/09, Martin wrote: > On Sat, Oct 31, 2009 at 5:27 AM, > Tzafrir Cohen > wrote: > > I'm not sure if handling of overlap hasn't changed > since. > > > > But can you provide a trace of how Asterisk sees > things? e.g. 'pri > > intense debug span 1' > > > > the intense debug is overkill we only need messages of > layer 3 ... > just do "pri debug span 1" > > Martin Here's the pri trace: Nov 2 17:22:28 VERBOSE[11329] logger.c: < Protocol Discriminator: Q.931 (8) len=38 Nov 2 17:22:28 VERBOSE[11329] logger.c: < Call Ref: len= 2 (reference 16976/0x4250) (Originator) Nov 2 17:22:28 VERBOSE[11329] logger.c: < Message type: SETUP (5) Nov 2 17:22:28 VERBOSE[11329] logger.c: < [04 03 80 90 a3] Nov 2 17:22:28 VERBOSE[11329] logger.c: < Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Nov 2 17:22:28 VERBOSE[11329] logger.c: < Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Nov 2 17:22:28 VERBOSE[11329] logger.c:Protocol Discriminator: Q.931 (8) len=9 Nov 2 17:22:28 VERBOSE[11329] logger.c: > Call Ref: len= 2 (reference 16976/0x4250) (Terminator) Nov 2 17:22:28 VERBOSE[11329] logger.c: > Message type: RELEASE COMPLETE (90) Nov 2 17:22:28 VERBOSE[11329] logger.c: > [08 02 81 81] Nov 2 17:22:28 VERBOSE[11329] logger.c: > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Nov 2 17:22:28 VERBOSE[11329] logger.c: > Ext: 1 Cause: Unallocated (unassigned) number (1), class = Normal Event (0) ] Nov 2 17:22:28 VERBOSE[11329] logger.c: NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null Nov 2 17:22:28 VERBOSE[11329] logger.c: NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null The 'from-pstn-deviate-custom' context has lines such as: exten => _100[14567]XXX,1,... exten => _100[14567]XXX,n,... Any ideas? Vieri ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DAHDI/ZAP overlap dialing
On Sat, Oct 31, 2009 at 5:27 AM, Tzafrir Cohen wrote: > I'm not sure if handling of overlap hasn't changed since. > > But can you provide a trace of how Asterisk sees things? e.g. 'pri > intense debug span 1' > the intense debug is overkill we only need messages of layer 3 ... just do "pri debug span 1" Martin ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DAHDI/ZAP overlap dialing
On Fri, Oct 30, 2009 at 04:54:46AM -0700, Vieri wrote:
> Hi,
>
> I have a PRI euroisdn link between an Alcatel PBX and Asterisk.
>
> I'm having some trouble with overlap dialing.
>
> Suppose I dial '874053' from an Alcatel extension ('7034') where '87' is an
> Alcatel prefix of type "ARS Prof.Trg Grp Seiz.with overlap".
>
> I'm expecting Asterisk to receive '1004053' (where '100' is a prefix which
> always shows up in the euroisdn setup).
>
> However, Asterisk is only receiving '1004' which means that it's not reading
> the digits that follow.
>
> Are there issues with "receiving" overlap dials from zap channels?
>
> According to the Alcatel trace below, it looks like Asterisk is accepting the
> call before a "Sending complete" is released by Alcatel.
>
> I'm using libpri 1.2.8 and Asterisk 1.2.31.1.
I'm not sure if handling of overlap hasn't changed since.
But can you provide a trace of how Asterisk sees things? e.g. 'pri
intense debug span 1'
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.co...@xorcom.com
+972-50-7952406 mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DAHDI/ZAP overlap dialing
so you're either testing it wrong or it's been broken since that
worked fine years ago
you may try adding the "." after then extension ... I don't remember
maybe it's needed
eg:
exten => 1004000.,...
but better yet
exten => 100400XX,...
Martin
On Fri, Oct 30, 2009 at 10:08 AM, Vieri wrote:
> With overlapdial=yes set, when an Alcatel extension calls Asterisk, the
> Alcatel user doesn't even have time to dial the second digit because Asterisk
> connects it immediately instead of waiting for the rest of the digits.
>
> In Asterisk I have an incoming context [from-alcatel] with patterns such as:
> exten => 1004000,...
> exten => 1004001,...
> exten => 1004002,...
> exten => 1004053,...
> etc.
>
> Supposedly, Alcatel is doing "overlapdial", just like Asterisk.
> However, Asterisk only grabs the first digit and tries to match '1004'
> instead of '1004053'.
>
> Thanks anyway.
>
> --- On Fri, 10/30/09, Martin wrote:
>
>> it's not only for dialing in ...
>>
>> setup an extension that is shorter than the number ... and
>> also without the "."
>>
>> eg
>>
>> exten => 1000,1,Dial()
>>
>> also when you call out using the overlapdial circuit you
>> do
>>
>> dial(zap/g1/) or dial(zap/g1/10)
>>
>> and the rest of the digits should come over overlapdial
>> ...
>> at least that's how it was designed to work
>>
>> Martin
>>
>> On Fri, Oct 30, 2009 at 8:25 AM, Vieri
>> wrote:
>> >
>> > I forgot to mention that I already have
>> overlapdial=yes in zapata.conf. Besides, overlapdial=yes
>> is only for "dialing out" from Asterisk. Anyway, that option
>> is set.
>> >
>> > Any other ideas?
>> >
>> > --- On Fri, 10/30/09, Martin
>> wrote:
>> >
>> >> overlapdial=yes in
>> >> zapata.conf/chan_dahdi.conf
>> >> google it out
>> >>
>> >> Martin
>> >>
>> >> On Fri, Oct 30, 2009 at 6:54 AM, Vieri
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > I have a PRI euroisdn link between an Alcatel
>> PBX and
>> >> Asterisk.
>> >> >
>> >> > I'm having some trouble with overlap
>> dialing.
>> >> >
>> >> > Suppose I dial '874053' from an Alcatel
>> extension
>> >> ('7034') where '87' is an Alcatel prefix of type
>> "ARS
>> >> Prof.Trg Grp Seiz.with overlap".
>> >> >
>> >> > I'm expecting Asterisk to receive '1004053'
>> (where
>> >> '100' is a prefix which always shows up in the
>> euroisdn
>> >> setup).
>> >> >
>> >> > However, Asterisk is only receiving '1004'
>> which means
>> >> that it's not reading the digits that follow.
>> >> >
>> >> > Are there issues with "receiving" overlap
>> dials from
>> >> zap channels?
>> >> >
>> >> > According to the Alcatel trace below, it
>> looks like
>> >> Asterisk is accepting the call before a "Sending
>> complete"
>> >> is released by Alcatel.
>> >> >
>> >> > I'm using libpri 1.2.8 and Asterisk
>> 1.2.31.1.
>> >> >
>> >> > Alcatel trace:
>> >> >
>> >> >> t3
>> >> > --> Cleaning mtracer...
>> >> > --> Positionning t3 filters...
>> >> >
>> >>
>> ++---+++-+-+--+--+
>> >> > | filter | desti | src_id | cr_nbr | cpl_nbr
>> | us_term
>> >> | term_nbr | type |
>> >> >
>> >>
>> ++---+++-+-+--+--+
>> >> > | 0 | ** | ** | *
>> | **
>> >> | * | *** | 165 |
>> >> > | 1 | ** | ** | *
>> | **
>> >> | * | *** | 166 |
>> >> > | 2 | ** | ** | *
>> | **
>> >> | * | *** | 167 |
>> >> > | 3 | | |
>> |
>> >> | | |
>> |
>> >> > | 4 | | |
>> |
>> >> | | |
>> |
>> >> > | 5 | | |
>> |
>> >> | | |
>> |
>> >> > | 6 | | |
>> |
>> >> | | |
>> |
>> >> > | 7 | | |
>> |
>> >> | | |
>> |
>> >> >
>> >>
>> ++---+++-+-+--+--+
>> >> > Traces Analyser activated
>> >> >
>> >> > mtracer started ...
>> >> > (476142:01) MTRACER ♠©, version:
>> >> R9.0-h1.301-31-d-es-c7s2
>> >> > (476142:01) MTRACER num: 007, time:
>> 2009/10/30
>> >> 11:53:02, loss: 0%
>> >> >
>> >>
>> __
>> >> > | (476157:02) 1095: Send_IO1
>> (link-nbr=19, sapi=0,
>> >> tei=0) :
>> >> > | long: 51 desti: 0 source: 15 cryst: 0
>> cpl:
>> >> 19 us: 8 term: 0 type a5
>> >> > | tei: 0 message sent :
>> SETUP
>> >> [05] Call ref : 32 a8
>> >> >
>> >>
>> |__
>> >> > |
>> >> > | IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
>> >> > | IE:[18] CHANNEL (l=3) a9 83 9b -> T2 :
>> B
>> >> channel 27 exclusive
>> >> > | IE:[1e] PROGRESS_ID (l=2) 80 83
>> >> > | IE:[6c] CALLING_NUMBER (l=6) -> 00
>> 81 Num
>> >> : 7034
>> >> > | IE:[70] CALLED_NUMBER (l=5) -> 80
>> Num :
>> >> 1004
>> >> > | IE:[7d] HLC (l=2) 91 81
>> >> >
>
Re: [asterisk-users] DAHDI/ZAP overlap dialing
With overlapdial=yes set, when an Alcatel extension calls Asterisk, the Alcatel
user doesn't even have time to dial the second digit because Asterisk connects
it immediately instead of waiting for the rest of the digits.
In Asterisk I have an incoming context [from-alcatel] with patterns such as:
exten => 1004000,...
exten => 1004001,...
exten => 1004002,...
exten => 1004053,...
etc.
Supposedly, Alcatel is doing "overlapdial", just like Asterisk.
However, Asterisk only grabs the first digit and tries to match '1004' instead
of '1004053'.
Thanks anyway.
--- On Fri, 10/30/09, Martin wrote:
> it's not only for dialing in ...
>
> setup an extension that is shorter than the number ... and
> also without the "."
>
> eg
>
> exten => 1000,1,Dial()
>
> also when you call out using the overlapdial circuit you
> do
>
> dial(zap/g1/) or dial(zap/g1/10)
>
> and the rest of the digits should come over overlapdial
> ...
> at least that's how it was designed to work
>
> Martin
>
> On Fri, Oct 30, 2009 at 8:25 AM, Vieri
> wrote:
> >
> > I forgot to mention that I already have
> overlapdial=yes in zapata.conf. Besides, overlapdial=yes
> is only for "dialing out" from Asterisk. Anyway, that option
> is set.
> >
> > Any other ideas?
> >
> > --- On Fri, 10/30/09, Martin
> wrote:
> >
> >> overlapdial=yes in
> >> zapata.conf/chan_dahdi.conf
> >> google it out
> >>
> >> Martin
> >>
> >> On Fri, Oct 30, 2009 at 6:54 AM, Vieri
> >> wrote:
> >> > Hi,
> >> >
> >> > I have a PRI euroisdn link between an Alcatel
> PBX and
> >> Asterisk.
> >> >
> >> > I'm having some trouble with overlap
> dialing.
> >> >
> >> > Suppose I dial '874053' from an Alcatel
> extension
> >> ('7034') where '87' is an Alcatel prefix of type
> "ARS
> >> Prof.Trg Grp Seiz.with overlap".
> >> >
> >> > I'm expecting Asterisk to receive '1004053'
> (where
> >> '100' is a prefix which always shows up in the
> euroisdn
> >> setup).
> >> >
> >> > However, Asterisk is only receiving '1004'
> which means
> >> that it's not reading the digits that follow.
> >> >
> >> > Are there issues with "receiving" overlap
> dials from
> >> zap channels?
> >> >
> >> > According to the Alcatel trace below, it
> looks like
> >> Asterisk is accepting the call before a "Sending
> complete"
> >> is released by Alcatel.
> >> >
> >> > I'm using libpri 1.2.8 and Asterisk
> 1.2.31.1.
> >> >
> >> > Alcatel trace:
> >> >
> >> >> t3
> >> > --> Cleaning mtracer...
> >> > --> Positionning t3 filters...
> >> >
> >>
> ++---+++-+-+--+--+
> >> > | filter | desti | src_id | cr_nbr | cpl_nbr
> | us_term
> >> | term_nbr | type |
> >> >
> >>
> ++---+++-+-+--+--+
> >> > | 0 | ** | ** | *
> | **
> >> | * | *** | 165 |
> >> > | 1 | ** | ** | *
> | **
> >> | * | *** | 166 |
> >> > | 2 | ** | ** | *
> | **
> >> | * | *** | 167 |
> >> > | 3 | | |
> |
> >> | | |
> |
> >> > | 4 | | |
> |
> >> | | |
> |
> >> > | 5 | | |
> |
> >> | | |
> |
> >> > | 6 | | |
> |
> >> | | |
> |
> >> > | 7 | | |
> |
> >> | | |
> |
> >> >
> >>
> ++---+++-+-+--+--+
> >> > Traces Analyser activated
> >> >
> >> > mtracer started ...
> >> > (476142:01) MTRACER ♠©, version:
> >> R9.0-h1.301-31-d-es-c7s2
> >> > (476142:01) MTRACER num: 007, time:
> 2009/10/30
> >> 11:53:02, loss: 0%
> >> >
> >>
> __
> >> > | (476157:02) 1095: Send_IO1
> (link-nbr=19, sapi=0,
> >> tei=0) :
> >> > | long: 51 desti: 0 source: 15 cryst: 0
> cpl:
> >> 19 us: 8 term: 0 type a5
> >> > | tei: 0 message sent :
> SETUP
> >> [05] Call ref : 32 a8
> >> >
> >>
> |__
> >> > |
> >> > | IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
> >> > | IE:[18] CHANNEL (l=3) a9 83 9b -> T2 :
> B
> >> channel 27 exclusive
> >> > | IE:[1e] PROGRESS_ID (l=2) 80 83
> >> > | IE:[6c] CALLING_NUMBER (l=6) -> 00
> 81 Num
> >> : 7034
> >> > | IE:[70] CALLED_NUMBER (l=5) -> 80
> Num :
> >> 1004
> >> > | IE:[7d] HLC (l=2) 91 81
> >> >
> >>
> |__
> >> >
> >> >
> >>
> __
> >> > | (476157:03) Concatenated-Physical-Event
> :
> >> > | long: 24 desti: 0 source: 0 cryst: 0
> cpl: 19
> >> us: 0 term: 0 type a5
> >> > | tei: 0 message
> received : CALL
> >> PROC (02) Call ref : b2 a8
> >> >
> >>
> |
Re: [asterisk-users] DAHDI/ZAP overlap dialing
it's not only for dialing in ...
setup an extension that is shorter than the number ... and also without the "."
eg
exten => 1000,1,Dial()
also when you call out using the overlapdial circuit you do
dial(zap/g1/) or dial(zap/g1/10)
and the rest of the digits should come over overlapdial ...
at least that's how it was designed to work
Martin
On Fri, Oct 30, 2009 at 8:25 AM, Vieri wrote:
>
> I forgot to mention that I already have overlapdial=yes in zapata.conf.
> Besides, overlapdial=yes is only for "dialing out" from Asterisk. Anyway,
> that option is set.
>
> Any other ideas?
>
> --- On Fri, 10/30/09, Martin wrote:
>
>> overlapdial=yes in
>> zapata.conf/chan_dahdi.conf
>> google it out
>>
>> Martin
>>
>> On Fri, Oct 30, 2009 at 6:54 AM, Vieri
>> wrote:
>> > Hi,
>> >
>> > I have a PRI euroisdn link between an Alcatel PBX and
>> Asterisk.
>> >
>> > I'm having some trouble with overlap dialing.
>> >
>> > Suppose I dial '874053' from an Alcatel extension
>> ('7034') where '87' is an Alcatel prefix of type "ARS
>> Prof.Trg Grp Seiz.with overlap".
>> >
>> > I'm expecting Asterisk to receive '1004053' (where
>> '100' is a prefix which always shows up in the euroisdn
>> setup).
>> >
>> > However, Asterisk is only receiving '1004' which means
>> that it's not reading the digits that follow.
>> >
>> > Are there issues with "receiving" overlap dials from
>> zap channels?
>> >
>> > According to the Alcatel trace below, it looks like
>> Asterisk is accepting the call before a "Sending complete"
>> is released by Alcatel.
>> >
>> > I'm using libpri 1.2.8 and Asterisk 1.2.31.1.
>> >
>> > Alcatel trace:
>> >
>> >> t3
>> > --> Cleaning mtracer...
>> > --> Positionning t3 filters...
>> >
>> ++---+++-+-+--+--+
>> > | filter | desti | src_id | cr_nbr | cpl_nbr | us_term
>> | term_nbr | type |
>> >
>> ++---+++-+-+--+--+
>> > | 0 | ** | ** | * | **
>> | * | *** | 165 |
>> > | 1 | ** | ** | * | **
>> | * | *** | 166 |
>> > | 2 | ** | ** | * | **
>> | * | *** | 167 |
>> > | 3 | | | |
>> | | | |
>> > | 4 | | | |
>> | | | |
>> > | 5 | | | |
>> | | | |
>> > | 6 | | | |
>> | | | |
>> > | 7 | | | |
>> | | | |
>> >
>> ++---+++-+-+--+--+
>> > Traces Analyser activated
>> >
>> > mtracer started ...
>> > (476142:01) MTRACER ♠©, version:
>> R9.0-h1.301-31-d-es-c7s2
>> > (476142:01) MTRACER num: 007, time: 2009/10/30
>> 11:53:02, loss: 0%
>> >
>> __
>> > | (476157:02) 1095: Send_IO1 (link-nbr=19, sapi=0,
>> tei=0) :
>> > | long: 51 desti: 0 source: 15 cryst: 0 cpl:
>> 19 us: 8 term: 0 type a5
>> > | tei: 0 message sent : SETUP
>> [05] Call ref : 32 a8
>> >
>> |__
>> > |
>> > | IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
>> > | IE:[18] CHANNEL (l=3) a9 83 9b -> T2 : B
>> channel 27 exclusive
>> > | IE:[1e] PROGRESS_ID (l=2) 80 83
>> > | IE:[6c] CALLING_NUMBER (l=6) -> 00 81 Num
>> : 7034
>> > | IE:[70] CALLED_NUMBER (l=5) -> 80 Num :
>> 1004
>> > | IE:[7d] HLC (l=2) 91 81
>> >
>> |__
>> >
>> >
>> __
>> > | (476157:03) Concatenated-Physical-Event :
>> > | long: 24 desti: 0 source: 0 cryst: 0 cpl: 19
>> us: 0 term: 0 type a5
>> > | tei: 0 message received : CALL
>> PROC (02) Call ref : b2 a8
>> >
>> |__
>> > |
>> > | IE:[18] CHANNEL (l=4) e9 81 83 9b
>> >
>> |__
>> >
>> >
>> __
>> > | (476157:04) Concatenated-Physical-Event :
>> > | long: 28 desti: 0 source: 0 cryst: 0 cpl: 19
>> us: 0 term: 0 type a5
>> > | tei: 0 message received :
>> CONNECT (07) Call ref : b2 a8
>> >
>> |__
>> > |
>> > | IE:[18] CHANNEL (l=4) e9 81 83 9b
>> > | IE:[1e] PROGRESS_ID (l=2) 81 82
>> >
>> |__
>> >
>> >
>> __
>> > | (476158:05) 1095: Send_IO1 (link-nbr=19, sapi=0,
>> tei=0) :
>> > | long: 23 d
Re: [asterisk-users] DAHDI/ZAP overlap dialing
I forgot to mention that I already have overlapdial=yes in zapata.conf.
Besides, overlapdial=yes is only for "dialing out" from Asterisk. Anyway, that
option is set.
Any other ideas?
--- On Fri, 10/30/09, Martin wrote:
> overlapdial=yes in
> zapata.conf/chan_dahdi.conf
> google it out
>
> Martin
>
> On Fri, Oct 30, 2009 at 6:54 AM, Vieri
> wrote:
> > Hi,
> >
> > I have a PRI euroisdn link between an Alcatel PBX and
> Asterisk.
> >
> > I'm having some trouble with overlap dialing.
> >
> > Suppose I dial '874053' from an Alcatel extension
> ('7034') where '87' is an Alcatel prefix of type "ARS
> Prof.Trg Grp Seiz.with overlap".
> >
> > I'm expecting Asterisk to receive '1004053' (where
> '100' is a prefix which always shows up in the euroisdn
> setup).
> >
> > However, Asterisk is only receiving '1004' which means
> that it's not reading the digits that follow.
> >
> > Are there issues with "receiving" overlap dials from
> zap channels?
> >
> > According to the Alcatel trace below, it looks like
> Asterisk is accepting the call before a "Sending complete"
> is released by Alcatel.
> >
> > I'm using libpri 1.2.8 and Asterisk 1.2.31.1.
> >
> > Alcatel trace:
> >
> >> t3
> > --> Cleaning mtracer...
> > --> Positionning t3 filters...
> >
> ++---+++-+-+--+--+
> > | filter | desti | src_id | cr_nbr | cpl_nbr | us_term
> | term_nbr | type |
> >
> ++---+++-+-+--+--+
> > | 0 | ** | ** | * | **
> | * | *** | 165 |
> > | 1 | ** | ** | * | **
> | * | *** | 166 |
> > | 2 | ** | ** | * | **
> | * | *** | 167 |
> > | 3 | | | |
> | | | |
> > | 4 | | | |
> | | | |
> > | 5 | | | |
> | | | |
> > | 6 | | | |
> | | | |
> > | 7 | | | |
> | | | |
> >
> ++---+++-+-+--+--+
> > Traces Analyser activated
> >
> > mtracer started ...
> > (476142:01) MTRACER ♠©, version:
> R9.0-h1.301-31-d-es-c7s2
> > (476142:01) MTRACER num: 007, time: 2009/10/30
> 11:53:02, loss: 0%
> >
> __
> > | (476157:02) 1095: Send_IO1 (link-nbr=19, sapi=0,
> tei=0) :
> > | long: 51 desti: 0 source: 15 cryst: 0 cpl:
> 19 us: 8 term: 0 type a5
> > | tei: 0 message sent : SETUP
> [05] Call ref : 32 a8
> >
> |__
> > |
> > | IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
> > | IE:[18] CHANNEL (l=3) a9 83 9b -> T2 : B
> channel 27 exclusive
> > | IE:[1e] PROGRESS_ID (l=2) 80 83
> > | IE:[6c] CALLING_NUMBER (l=6) -> 00 81 Num
> : 7034
> > | IE:[70] CALLED_NUMBER (l=5) -> 80 Num :
> 1004
> > | IE:[7d] HLC (l=2) 91 81
> >
> |__
> >
> >
> __
> > | (476157:03) Concatenated-Physical-Event :
> > | long: 24 desti: 0 source: 0 cryst: 0 cpl: 19
> us: 0 term: 0 type a5
> > | tei: 0 message received : CALL
> PROC (02) Call ref : b2 a8
> >
> |__
> > |
> > | IE:[18] CHANNEL (l=4) e9 81 83 9b
> >
> |__
> >
> >
> __
> > | (476157:04) Concatenated-Physical-Event :
> > | long: 28 desti: 0 source: 0 cryst: 0 cpl: 19
> us: 0 term: 0 type a5
> > | tei: 0 message received :
> CONNECT (07) Call ref : b2 a8
> >
> |__
> > |
> > | IE:[18] CHANNEL (l=4) e9 81 83 9b
> > | IE:[1e] PROGRESS_ID (l=2) 81 82
> >
> |__
> >
> >
> __
> > | (476158:05) 1095: Send_IO1 (link-nbr=19, sapi=0,
> tei=0) :
> > | long: 23 desti: 0 source: 15 cryst: 0 cpl:
> 19 us: 8 term: 0 type a5
> > | tei: 0 message sent : CONNECT
> ACK (0f) Call ref : 32 a8
> >
> |__
> > |
> > | IE:[18] CHANNEL (l=3) a9 83 9b -> T2 : B
> channel 27 exclusive
> >
> |__
> >
> >
> > In Asterisk I see:
> >
> > Oct 30 11:48:02 VERBOSE[11329] logger.c: --
> Accepting call from '7034' to '1004' on channel 1/2
Re: [asterisk-users] DAHDI/ZAP overlap dialing
overlapdial=yes in zapata.conf/chan_dahdi.conf
google it out
Martin
On Fri, Oct 30, 2009 at 6:54 AM, Vieri wrote:
> Hi,
>
> I have a PRI euroisdn link between an Alcatel PBX and Asterisk.
>
> I'm having some trouble with overlap dialing.
>
> Suppose I dial '874053' from an Alcatel extension ('7034') where '87' is an
> Alcatel prefix of type "ARS Prof.Trg Grp Seiz.with overlap".
>
> I'm expecting Asterisk to receive '1004053' (where '100' is a prefix which
> always shows up in the euroisdn setup).
>
> However, Asterisk is only receiving '1004' which means that it's not reading
> the digits that follow.
>
> Are there issues with "receiving" overlap dials from zap channels?
>
> According to the Alcatel trace below, it looks like Asterisk is accepting the
> call before a "Sending complete" is released by Alcatel.
>
> I'm using libpri 1.2.8 and Asterisk 1.2.31.1.
>
> Alcatel trace:
>
>> t3
> --> Cleaning mtracer...
> --> Positionning t3 filters...
> ++---+++-+-+--+--+
> | filter | desti | src_id | cr_nbr | cpl_nbr | us_term | term_nbr | type |
> ++---+++-+-+--+--+
> | 0 | ** | ** | * | ** | * | *** | 165 |
> | 1 | ** | ** | * | ** | * | *** | 166 |
> | 2 | ** | ** | * | ** | * | *** | 167 |
> | 3 | | | | | | | |
> | 4 | | | | | | | |
> | 5 | | | | | | | |
> | 6 | | | | | | | |
> | 7 | | | | | | | |
> ++---+++-+-+--+--+
> Traces Analyser activated
>
> mtracer started ...
> (476142:01) MTRACER ♠©, version: R9.0-h1.301-31-d-es-c7s2
> (476142:01) MTRACER num: 007, time: 2009/10/30 11:53:02, loss: 0%
> __
> | (476157:02) 1095: Send_IO1 (link-nbr=19, sapi=0, tei=0) :
> | long: 51 desti: 0 source: 15 cryst: 0 cpl: 19 us: 8 term: 0 type a5
> | tei: 0 message sent : SETUP [05] Call ref : 32 a8
> |__
> |
> | IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
> | IE:[18] CHANNEL (l=3) a9 83 9b -> T2 : B channel 27 exclusive
> | IE:[1e] PROGRESS_ID (l=2) 80 83
> | IE:[6c] CALLING_NUMBER (l=6) -> 00 81 Num : 7034
> | IE:[70] CALLED_NUMBER (l=5) -> 80 Num : 1004
> | IE:[7d] HLC (l=2) 91 81
> |__
>
> __
> | (476157:03) Concatenated-Physical-Event :
> | long: 24 desti: 0 source: 0 cryst: 0 cpl: 19 us: 0 term: 0 type a5
> | tei: 0 message received : CALL PROC (02) Call ref : b2 a8
> |__
> |
> | IE:[18] CHANNEL (l=4) e9 81 83 9b
> |__
>
> __
> | (476157:04) Concatenated-Physical-Event :
> | long: 28 desti: 0 source: 0 cryst: 0 cpl: 19 us: 0 term: 0 type a5
> | tei: 0 message received : CONNECT (07) Call ref : b2 a8
> |__
> |
> | IE:[18] CHANNEL (l=4) e9 81 83 9b
> | IE:[1e] PROGRESS_ID (l=2) 81 82
> |__
>
> __
> | (476158:05) 1095: Send_IO1 (link-nbr=19, sapi=0, tei=0) :
> | long: 23 desti: 0 source: 15 cryst: 0 cpl: 19 us: 8 term: 0 type a5
> | tei: 0 message sent : CONNECT ACK (0f) Call ref : 32 a8
> |__
> |
> | IE:[18] CHANNEL (l=3) a9 83 9b -> T2 : B channel 27 exclusive
> |__
>
>
> In Asterisk I see:
>
> Oct 30 11:48:02 VERBOSE[11329] logger.c: -- Accepting call from '7034' to
> '1004' on channel 1/27, span 1
>
> If I change the Alcatel 87 prefix to use "ARS Prof.Trg Grp Seizure" (without
> overlap) then I get the following trace:
>
> __
> | (488410:60) 1093: Send_IO1 (link-nbr=19, sapi=0, tei=0) :
> | long: 55 desti: 0 source: 15 cryst: 0 cpl: 19 us: 8 term: 0 type a5
> | tei: 0 message sent : SETUP [05] Call ref : 33 52
> |
[asterisk-users] DAHDI/ZAP overlap dialing
Hi,
I have a PRI euroisdn link between an Alcatel PBX and Asterisk.
I'm having some trouble with overlap dialing.
Suppose I dial '874053' from an Alcatel extension ('7034') where '87' is an
Alcatel prefix of type "ARS Prof.Trg Grp Seiz.with overlap".
I'm expecting Asterisk to receive '1004053' (where '100' is a prefix which
always shows up in the euroisdn setup).
However, Asterisk is only receiving '1004' which means that it's not reading
the digits that follow.
Are there issues with "receiving" overlap dials from zap channels?
According to the Alcatel trace below, it looks like Asterisk is accepting the
call before a "Sending complete" is released by Alcatel.
I'm using libpri 1.2.8 and Asterisk 1.2.31.1.
Alcatel trace:
> t3
--> Cleaning mtracer...
--> Positionning t3 filters...
++---+++-+-+--+--+
| filter | desti | src_id | cr_nbr | cpl_nbr | us_term | term_nbr | type |
++---+++-+-+--+--+
|0 | ** | ** | *|** |*|*** | 165 |
|1 | ** | ** | *|** |*|*** | 166 |
|2 | ** | ** | *|** |*|*** | 167 |
|3 | ||| | | | |
|4 | ||| | | | |
|5 | ||| | | | |
|6 | ||| | | | |
|7 | ||| | | | |
++---+++-+-+--+--+
Traces Analyser activated
mtracer started ...
(476142:01) MTRACER ♠©, version: R9.0-h1.301-31-d-es-c7s2
(476142:01) MTRACER num: 007, time: 2009/10/30 11:53:02, loss: 0%
__
| (476157:02) 1095: Send_IO1 (link-nbr=19, sapi=0, tei=0) :
| long: 51 desti: 0 source: 15 cryst: 0 cpl: 19 us: 8 term: 0 type a5
| tei: 0 message sent : SETUP [05]Call ref : 32 a8
|__
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a9 83 9b -> T2 : B channel 27 exclusive
| IE:[1e] PROGRESS_ID (l=2) 80 83
| IE:[6c] CALLING_NUMBER (l=6) -> 00 81 Num : 7034
| IE:[70] CALLED_NUMBER (l=5) -> 80 Num : 1004
| IE:[7d] HLC (l=2) 91 81
|__
__
| (476157:03) Concatenated-Physical-Event :
| long: 24 desti: 0 source: 0 cryst: 0 cpl: 19 us: 0 term: 0 type a5
| tei: 0 message received : CALL PROC (02) Call ref : b2 a8
|__
|
| IE:[18] CHANNEL (l=4) e9 81 83 9b
|__
__
| (476157:04) Concatenated-Physical-Event :
| long: 28 desti: 0 source: 0 cryst: 0 cpl: 19 us: 0 term: 0 type a5
| tei: 0 message received : CONNECT (07) Call ref : b2 a8
|__
|
| IE:[18] CHANNEL (l=4) e9 81 83 9b
| IE:[1e] PROGRESS_ID (l=2) 81 82
|__
__
| (476158:05) 1095: Send_IO1 (link-nbr=19, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 0 cpl: 19 us: 8 term: 0 type a5
| tei: 0 message sent : CONNECT ACK (0f) Call ref : 32 a8
|__
|
| IE:[18] CHANNEL (l=3) a9 83 9b -> T2 : B channel 27 exclusive
|__
In Asterisk I see:
Oct 30 11:48:02 VERBOSE[11329] logger.c: -- Accepting call from '7034' to
'1004' on channel 1/27, span 1
If I change the Alcatel 87 prefix to use "ARS Prof.Trg Grp Seizure" (without
overlap) then I get the following trace:
__
| (488410:60) 1093: Send_IO1 (link-nbr=19, sapi=0, tei=0) :
| long: 55 desti: 0 source: 15 cryst: 0 cpl: 19 us: 8 term: 0 type a5
| tei: 0 message sent : SETUP [05]Call ref : 33 52
|__
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a9 83 8a -> T2 : B channel 10 exclusive
| IE:[1e] PROGRESS_ID (l=2) 80 83
| IE:[6c] CALLING_NUMBER (l=6) -> 00 81 Num : 7034
| IE:[70] CALLED_NUMBER (l=8) -> 80 Num : 1004053
| IE:[7d] HLC (l=2) 91 81
| [a1] S
