search for: release_complete

...IN STACK P[ 1] I IND :SETUP oad:056230210 dad: pid:2 state:none P[ 1] --> channel:1 mode:TE cause:16 ocause:34 rad: cad: P[ 1] --> info_dad: onumplan:0 dnumplan: rnumplan: cpnnumplan:0 P[ 1] --> caps:Audio 3.1k pi:3 keypad: sending_complete:1 P[ 1] --> Call Waiting on PMP sending RELEASE_COMPLETE P[ 1] I SEND:RELEASE_COMPLETE oad:056230210 dad: pid:2 P[ 1] --> channel:1 mode:TE cause:16 ocause:16 rad: cad: P[ 1] --> info_dad: onumplan:0 dnumplan: rnumplan: cpnnumplan:0 P[ 1] --> caps:Audio 3.1k pi:3 keypad: sending_complete:1 P[ 1] $$$ CLEANUP CALLED pid:2 P[ 1] GOT IGNORE SET...

Hello everyone! I've just switched from Asterisk 1.6.0-beta9 to 1.6.0.1 and my mISDN is not working. Here's what happens, if I try to call the line: bach >> P[ 1] --> !! lib: No free channel! P[ 1] --> we have already send Release_complete I haven't changed the configuration fles. Should I change something there? If you need more info, just tell me and I'll provide it, if I can. Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: =====...

...work since mISDN 1_1_8 and Asterisk 1.4.18. This is the message I get in Asterisk when the third call tries to come in: P[ 4] channel with stid:10020400 in use! P[ 4] channel with stid:10010400 in use! P[ 4] There is no free channel on port (4) P[ 4] --> !! lib: No free channel! P[ 4] I SEND:RELEASE_COMPLETE oad: dad: pid:0 P[ 4] --> channel:0 mode:TE cause:0 ocause:0 rad: cad: P[ 4] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0 P[ 4] --> we have already send Release_complete asterisk/extensions.conf (relevant part): http://pastebin.com/a9nihVKt mISDN.conf: http://pastebin.co...

...] --> l3id:80003 P[ 4] --> cause:16 P[ 4] --> out_cause:16 P[ 4] --> state:CONNECTED P[ 4] Channel: mISDN/4-1 hanguped new state:CLEANING P[ 4] $$$ CLEANUP CALLED pid:3 P[ 4] $$$ Cleaning up bc with stid :10010400 pid:3 P[ 4] ec_disable P[ 4] Sending Control ECHOCAN_OFF P[ 4] I IND :RELEASE_COMPLETE oad: dad: pid:3 state:CLEANING P[ 4] --> channel:0 mode:TE cause:16 ocause:16 rad: cad: P[ 4] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0 P[ 4] --> caps:Speech pi:0 keypad: sending_complete:0 P[ 4] ast_hangup already called, so we have no ast ptr anymore in event(RELEAS...

...ONE P[ 1] --> info_dad: onumplan:2 dnumplan: rnumplan: P[ 1] --> screen:0 --> pres:0 P[ 1] --> channel:2 caps:Speech pi:0 keypad: P[ 1] --> urate:0 rate:16 mode:0 user1:0 P[ 1] --> pid:277 addr:50020102 l3id:200ad P[ 1] --> b_stid:10020100 layer_id:50020180 P[ 1] I SEND:RELEASE_COMPLETE oad:022432646516 dad: P[ 1] --> mode:TE cause:16 ocause:16 rad: P[ 1] --> facility:FAC_NONE out_facility:FAC_NONE P[ 1] --> info_dad: onumplan:2 dnumplan: rnumplan: P[ 1] --> screen:0 --> pres:0 P[ 1] --> channel:2 caps:Speech pi:0 keypad: P[ 1] --> urate:0 rate:16 mod...

...addr:0 l3id:a0001 P[ 5] --> b_stid:0 layer_id:0 P[ 5] --> bc:821d7ac h:0 sh:0 P[ 5] P[ 5] Sending msg, prim:34d80 addr:0 dinfo:a0001 GOT SETUP OK P[ 5] MGMT: Short status dinfo 2000001 P[ 5] MGMT: SSTATUS: L2_ESTABLISH P[ 5] handle_frm: frm->addr:42000503 frm->prim:35a82 P[ 5] I IND :RELEASE_COMPLETE oad:04656708 dad:0465670127 P[ 5] --> mode:TE cause:-1 ocause:1 rad: cad: P[ 5] --> facility:FAC_NONE out_facility:FAC_NONE P[ 5] --> info_dad: onumplan:2 dnumplan:2 rnumplan: cpnnumplan:0 P[ 5] --> screen:0 --> pres:0 P[ 5] --> channel:1 caps:Speech pi:0 keypad: P[ 5] --&g...

...I port in nt_pmtp mode, but when I want to call out via the te_pmtp port, then the following line is written in the log: For incoming call: Sat Jan 13 16:33:04 2007: P[ 1] Extension can never match, so disconnecting For outgoing call: Sat Jan 13 16:41:18 2007: P[ 1] --> we have already send Release_complete and the line is "BUSY". The phones on the NT line works fine, and SIP <-> mISDN (NT) calls has no problems. All comment lines has been removed to keep mail size reasonable. /etc/misdn-init.conf: card=1,0x4,dtmf te_ptmp=1,2 nt_ptmp=3,4 option=1,master_clock poll=128 dsp_poll=128...

...2130 dad: ?146472130 pid:2 state:none P[ 4] EXPORT_PID: pid:2 Mar 23 09:35:28 WARNING[6725]: chan_misdn.c:4750 chan_misdn_log: Extension can never match, so disconnecting P[ 4] I SEND:RELEASE oad:!?145201798p ?146472130 dad: ?146472130 pid:2 P[ 4] --> bc_state:BCHAN_CLEANED P[ 4] I IND :RELEASE_COMPLETE oad: dad: pid:2 state:EXTCANTMATCH P[ 4] hangup_chan P[ 4] -> hangup P[ 4] * IND : HANGUP pid:2 ctx:default dad: ?146472130 oad:!?145201798p ?146472130 State:EXTCANTMATCH P[ 4] --> cause:2 P[ 4] --> out_cause:2 P[ 4] --> state:EXTCANTMATCH P[ 4] Channel: mISDN/4-u0 hangup...

I hadn't used FWD for quite a while. A customer sent me an email last week, "Is FWD broken when one tries to use it with IAX?" I have been playing around, and indeed seems to be the case. Is there anyone out there successfully using the two of them together? Thanks. B. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be

...ew chan is Listroot I SEND:SETUP pid:-1 mode:NT addr:51300101 --> dad: 100 oad channel 0 port 1 $$$ bc already upsetted stid :10000101 --> pid 25 --> oad dad 100 channel 1 lib: Event_ind:SETUP CONFIRM [NT] : new L3ID is 9afff0 * SEND: State Dialing pid:25 -- Called 1/100 I IND :RELEASE_COMPLETE pid:25 mode:NT addr:51300101 --> dad: 100 oad channel 1 port 1 --> cause 18 $$$ Bchan deActivated addr 51300101 * REMOVE CHANNEL pid:25 ctx:Intern dad: oad:100 * --> State Down * --> In State Calling|Dialing * --> Queue Hangup * Dequeuing chan 0x80cb358 from List 0x4254eaa8 * Its...

...th the Billion ISDN card. I am using mISDN. But when I call on the CLI apears this: -- Executing Dial("SIP/101-081805b8", "mISDN/1/943833473|45|tTwW") in new stack -- Called 1/943833473 P[ 1] empty_chan_in_stack: cannot empty channel 255 P[ 1] --> we have already send Release_complete == Everyone is busy/congested at this time (1:0/0/1) -- Executing Hangup("SIP/101-081805b8", "") in new stack == Spawn extension (SOME, 943833473, 102) exited non-zero on 'SIP/101-081805b8' I dont't know what happen. Some can help me??? Thanks to everybody....

...ISDN_FsmAddTimer: timer already active! lapd 2 mISDN_FsmAddTimer already active! I've got 4 of these pairs... None of them show up on times which can be related to any specific Asterisk activity. 6. Last, but not least, this one... DSS1 1 mISDN dss1 sending RELEASE_COMPLETE without proc pr=35a80 dinof(90001) ...which I already know shows up after every call. The question: does it make any sense to fill the kernel message buffer with them ? Shouldn't they rather be sent to a log file only, and only if activated ? I'd like to thank e...

...t; channel:1 caps:Speech pi:0 keypad: P[ 1] I IND :TIMEOUT oad:0010618115711 dad:4680041618269314 # Sudden Timeout?!? P[ 1] --> mode:NT cause:16 ocause:16 rad: P[ 1] --> info_dad:4680041618269314 onumplan:2 dnumplan: rnumplan: P[ 1] --> channel:1 caps:Speech pi:0 keypad: P[ 1] I SEND:RELEASE_COMPLETE oad:0010618115711 dad:4680041618269314 P[ 1] --> mode:NT cause:16 ocause:16 rad: P[ 1] --> info_dad:4680041618269314 onumplan:2 dnumplan: rnumplan: P[ 1] --> channel:1 caps:Speech pi:0 keypad: P[ 1] I IND :CLEAN_UP oad: dad: P[ 1] --> mode:NT cause:16 ocause:16 rad: P[ 1] --> i...

Hello, Following my first mail about this issue [1], I think I know now what the problem is. When I have both lines being used and a third call comes in, the person calling doesn't get a busy tone, he gets something like line unavailable. I've been debugging mISDN and I think the reason is because asterisk is sending the release cause as 0. P[ 3] --> channel:0 mode:TE cause:0

...ly >to a SETUP after having sent a CALL PROCEEDING is probably not allowed by >the state transitions listen in q.931. > > I've commented out a few lines of code to make sure * sends DISCONNECT but I'm getting identical results. Seems like it doesn't matter if I skip to RELEASE_COMPLETE or not. >The in-band announcement is more related to whether we have sent a >progress information element which states that in-band audio is available. >I think Asterisk sends such a progress message almost as soon as possible. >However, in this case the problem is a CALL PROCEEDIN...