search for: q931_connect

Is there a way to send DTMF's to a channel before the call is answered? For example, send DTMF's to a SIP channel after the 180 Ringing or 183 Session Progress have been received from it, but before the 200 OK, or in the E1 side, after the Q931_ALERTING is received, but before the Q931_CONNECT. If I use Dial(SIP/XXXX,D(my_dtmfs)), it will wait until SIP/XXXX have answered to send the tones, but I need to do it before that. Thanks a lot for your help. -- Attn. Alvaro Palma

I just updated libpri 1.4 on my system to the latest from that branch and my QSIG connection to an NEC SV8300 stopped working. The trace showing the problem is below: q931.c:5640 q931_connect: Call 7168 enters state 10 (Active). Hold state: Idle > DL-DATA request > Protocol Discriminator: Q.931 (8) len=21 > TEI=0 Call Ref: len= 2 (reference 7168/0x1C00) (Sent to originator) > Message Type: CONNECT (7) TEI=0 Transmitting N(S)=29, window is open V(A)=29 K=7 > Protocol D...

...logger.c: -- Accepting call from '3210' to '4062' on channel 1/7, span 1 [Mar 19 08:04:21] VERBOSE[12808] logger.c: -- Executing [4062 at from-pstn-deviate-custom:4] Answer("Zap/7-1", "") in new stack [Mar 19 08:04:21] VERBOSE[12808] logger.c: q931.c:2943 q931_connect: call 20968 on channel 7 enters state 10 (Active) [Mar 19 08:04:21] VERBOSE[12808] logger.c: > Protocol Discriminator: Q.931 (8) len=15 [Mar 19 08:04:21] VERBOSE[12808] logger.c: > Call Ref: len= 2 (reference 20968/0x51E8) (Terminator) [Mar 19 08:04:21] VERBOSE[12808] logger.c: > Message...

PRI debug of the entire call would be great, also, switchtype would be awesome as well. Thanks! Matthew Fredrickson On Thu, Mar 24, 2016 at 4:07 PM, Carlos Rojas <crt.rojas at gmail.com> wrote: > Hi > > Did you activate the pri debug on the cli asterisk? > > On Thu, Mar 24, 2016 at 12:59 PM, Carlos Chavez <cursor at telecomabmex.com> > wrote: >> >>

...== Channel 'Zap/45-1' jumping out of macro 'from-zaptel-45' -- Executing [s at app-announcement-1:1] GotoIf("Zap/45-1", "0?begin") in new stack -- Executing [s at app-announcement-1:2] Answer("Zap/45-1", "") in new stack q931.c:2698 q931_connect: call 21 on channel 21 enters state 10 (Active) > Protocol Discriminator: Q.931 (8) len=10 > Call Ref: len= 2 (reference 21/0x15) (Terminator) > Message type: CONNECT (7) > [18 03 a9 83 95] > Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0 >...

...number ${CALLERID(num)} --cid-name "${CALLERID(name)}" --dest-name "Sir/Madam"') *debug:* pbx3*CLI> -- Executing [receive at fax-rx:20] ReceiveFAX("DAHDI/1-1", "/var/spool/asterisk/fax/2011-06-18_12:52:44_8009806858.tif") in new stack q931.c:5088 q931_connect: Call 14288 enters state 8 (Connect Request). Hold state: Idle pbx3*CLI> pbx3*CLI> > DL-DATA request pbx3*CLI> > Protocol Discriminator: Q.931 (8) len=14 pbx3*CLI> > TEI=0 Call Ref: len= 2 (reference 14288/0x37D0) (Sent to originator) pbx3*CLI> > Message Type: CONNECT (...

...xt: 1 Coding: 0 Number Specified Channel Type: 3 > Ext: 1 Channel: 23 ] -- Accepting call from '2005000' to '123' on channel 0/23, span 1 -- Executing [123 at entryocgexternal:1] Answer("Zap/23-1", "") in new stack q931.c:2697 q931_connect: call 23 on channel 23 enters state 10 (Active) > [ 02 01 0c 08 08 02 80 17 07 18 03 a9 83 97 ] > Informational frame: > SAPI: 00 C/R: 1 EA: 0 > TEI: 000 EA: 1 > N(S): 006 0: 0 > N(R): 004 P: 0 > 10 bytes of data T_200 timer already going (2) > Protocol Discri...

...;GROUP()=INBOUND") in new stack [Jan 14 12:56:04] VERBOSE[12568] pbx.c: [Jan 14 12:56:04] -- Executing [4143446711 at from-pstn:3] Answer("DAHDI/i4/NPANXXXXXX-bb7", "") in new stack [Jan 14 12:56:04] VERBOSE[12568] chan_dahdi.c: [Jan 14 12:56:04] PRI Span: 4 q931.c:5660 q931_connect: Call 6918 enters state 8 (Connect Request). Hold state: Idle [Jan 14 12:56:04] VERBOSE[12568] chan_dahdi.c: [Jan 14 12:56:04] PRI Span: 4 [Jan 14 12:56:04] VERBOSE[12568] chan_dahdi.c: [Jan 14 12:56:04] PRI Span: 4 > DL-DATA request [Jan 14 12:56:04] VERBOSE[12568] chan_dahdi.c: [Jan 14 12:56:...

...ing all packets from 39 to (but not including) 41 -- ACKing packet 40, new txqueue is -1 (-1 means empty) -- Since there was nothing left, stopping T200 counter -- Nothing left, starting T203 counter -- Restarting T203 timer [Kmndemo*CLI> -- SIP/a_to_b-0174a060 answered Zap/23-1 q931.c:2951 q931_connect: call 4 on channel 23 enters state 8 (Connect Request) -- Finally transmitting 41, since window opened up (0) > [ 00 01 52 58 08 02 80 04 07 18 03 a9 83 97 1e 02 81 82 ] > Informational frame: > SAPI: 00 C/R: 0 EA: 0 > TEI: 000 EA: 1 > N(S): 041 0: 0 > N(R): 044 P:...

...>> Ext: 1 Channel: 23 ] > > -- Accepting call from '2005000' to '123' on channel > 0/23, span 1 > > -- Executing [123 at entryocgexternal:1] Answer("Zap/23-1", "") in > > new stack > > q931.c:2697 q931_connect: call 23 on channel 23 enters state 10 > > (Active) > > > >> [ 02 01 0c 08 08 02 80 17 07 18 03 a9 83 97 ] > > > >> Informational frame: > >> SAPI: 00 C/R: 1 EA: 0 > >> TEI: 000 EA: 1 > >> N(S): 006 0: 0 > >> N(R):...

I have a T1 link from asterisk 1.2.23 (also tried with 1.4.13) to a Meridian Option 61C. Calls either way drop with error "Channel 0/23, span 1 got hangup, cause 100". Can anyone offer insight into the cause and solution/workaround? (I tried upgrading to Ast 1.4.13, and upgrading matching zaptel & libpri, put the problem is identical). For testing, I tried a call from the