ASTERISK-09173: "Dial(mISDN/g:te/${EXTEN})" don't set up L2Link but "Dial(mISDN/1/${EXTEN}" works

[Home]

Summary: ASTERISK-09173: "Dial(mISDN/g:te/${EXTEN})" don't set up L2Link but "Dial(mISDN/1/${EXTEN}" works

Reporter: Iñaki Baz Castillo (ibc) Labels:

Date Opened: 2007-04-03 06:43:12 Date Closed: 2007-11-16 02:57:04.000-0600

Priority: Major Regression? No

Status: Closed/Complete Components: Channels/chan_misdn

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) dmesg
( 1) misdn.conf
( 2) misdn-init.conf
( 3) verbosedebug.txt

Description: Asterisk 1.4.2 with Junghans QuadBri BRI-ISDN card handled with mISDN.

I have 3 BRI's in PTP mode configured as a "te" group in misdn.conf and incoming calls work perfectly.

Outgoing calls dialing the "te" group fail but outgoings calls dialing any mISDN port work. The following example shows what I mean:

- 940 exten is: Dial(mISDN/g:te/675511308)
- 941 exten is: Dial(mISDN/1/675511308)
- "te" group is:
[te]
ports=1,2,3
context=entrantes-analogicas
msns=*

I dial 940 and it fails:
-------------------------------------------
asterisk*CLI> misdn show stacks
BEGIN STACK_LIST:
* Port 1 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:0
* Port 2 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:0
* Port 3 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:0
-- Executing [940@desde-usuarios:1] Dial("SIP/ibc-tfno-ip-b5907340", "mISDN/g:te/675511308") in new stack
P[ 1] Port Down L2:0 L1:1
P[ 2] Port Down L2:0 L1:1
P[ 3] Port Down L2:0 L1:1
[Apr 3 12:16:08] WARNING[23210]: chan_misdn.c:5256 chan_misdn_log: Could not create channel on port:-1 with extensions:675511308
-------------------------------------------

I dial 941 and it works:
-------------------------------------------
asterisk*CLI> misdn show stacks
BEGIN STACK_LIST:
* Port 1 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:0
* Port 2 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:0
* Port 3 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:0
-- Executing [941@desde-usuarios:1] Dial("SIP/ibc-tfno-ip-b5900c90", "mISDN/1/675511308") in new stack
P[ 0] maxnum:2 -- Called 1/675511308
P[ 1] channel already in use:1
-- mISDN/1-u271 is proceeding passing it to SIP/ibc-tfno-ip-b5900c90
-------------------------------------------

If I call instantly 940 it works because there is at least one port with L2Link UP (port 1):
-------------------------------------------
asterisk*CLI> misdn show stacks
BEGIN STACK_LIST:
* Port 1 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:0
* Port 2 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:0
* Port 3 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:0
-- Executing [940@desde-usuarios:1] Dial("SIP/ibc-tfno-ip-b5900c90", "mISDN/g:te/675511308") in new stack
P[ 0] maxnum:2 -- Called g:te/675511308
P[ 1] channel already in use:1
-- mISDN/1-u275 is proceeding passing it to SIP/ibc-tfno-ip-b5900c90
-------------------------------------------

So my conclusion is:
- Dialing directly to a mISDN port works well and sets up port L2Link.
- Dialing to a mISDN group JUST works if there is a port with L2Link UP.

****** STEPS TO REPRODUCE ******

Wait for all the L2Links are DOWN and dial a mISDN group. It fails.

Wait for all the L2Links are DOWN and dial a mISDN port. It works.

****** ADDITIONAL INFORMATION ******

I attach the "verbosedebug.txt". I have added in that file some comments explaining what I'm doing. I hope it's enough self-explanatory.

Comments: By: crich (crich) 2007-04-03 07:07:15

your conclusion is correct, that is how the group dial mechanism works.
By: crich (crich) 2007-04-03 07:19:24

what provider are you using? are you sure that you have a PTP Link?
By: Iñaki Baz Castillo (ibc) 2007-04-03 08:16:04

> what provider are you using?

I'm using Telef?nica in Spain, Barcelona.

> are you sure that you have a PTP Link?

They are PTP because if I set them as PTMP they just don't work as I show now (I've restarted misnd-init and so):

------------------------------------
asterisk*CLI> console dial 941@pruebas
[Apr 3 15:02:07] WARNING[27877]: chan_oss.c:682 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
-- Executing [941@pruebas:1] Dial("OSS/dsp", "mISDN/1/675511308") in new stack
P[ 0] maxnum:2P[ 0] --> * NEW CHANNEL dad:675511308 oad:(null)
P[ 1] * Queuing chan 0x8233ae0
P[ 1] read_config: Getting Config
P[ 1] --> TON: Unknown
P[ 1] --> LTON: Unknown
P[ 1] --> CTON: Unknown
P[ 1] * CALL: 1/675511308
P[ 1] --> * dad:675511308 tech:mISDN/0-u1 ctx:entrantes-analogicas
P[ 1] --> * adding2newbc ext 675511308
P[ 1] --> * adding2newbc callerid
P[ 1] --> pres: -1 screen: -1
P[ 1] --> pres: 0
P[ 1] --> PRES: Allowed (0x0)
P[ 1] --> SCREEN: Unscreened (0x0)
P[ 1] NO OPTS GIVEN
P[ 1] I SEND:SETUP oad: dad:675511308 pid:3
P[ 1] --> bc_state:BCHAN_CLEANED
P[ 1] --> channel:0 mode:TE cause:16 ocause:27 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:0 l3id:90001 b_stid:0 layer_id:0
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] --> new_l3id 90002
P[ 1] NO USERUESRINFO ENCODED
P[ 1] --> * SEND: State Dialing pid:3
-- Called 1/675511308
P[ 1] Sending msg, prim:30580 addr:41000104 dinfo:90002
P[ 1] handle_frm: frm->addr:42000103 frm->prim:3f182
P[ 1] --> lib: RELEASE_CR Ind with l3id:90002
P[ 1] --> lib: CLEANING UP l3id: 90002
P[ 1] empty_chan_in_stack: cannot empty channel 255
P[ 1] $$$ CLEANUP CALLED pid:3
P[ 1] --> queue_hangup
[Apr 3 15:02:13] DEBUG[27903]: chan_misdn.c:2301 misdn_hangup: misdn_hangup(mISDN/0-u1)
P[ 1] * RELEASING CHANNEL pid:3 ctx:entrantes-analogicas dad:675511308 oad:941 state: CALLING
P[ 1] * IND : HANGUP pid:3 ctx:entrantes-analogicas dad:675511308 oad:941 State:CALLING
P[ 1] --> l3id:90002
P[ 1] P[ 1] --> cause:27
--> * State Down
P[ 1] --> out_cause:27
P[ 1] --> Setting AST State to down
P[ 1] --> state:CALLING
P[ 1] --> Channel: mISDN/0-u1 hanguped new state:CLEANING
== Everyone is busy/congested at this time (1:0/0/1)
== Auto fallthrough, channel 'OSS/dsp' status is 'CHANUNAVAIL'
------------------------------------

> your conclusion is correct, that is how the group dial mechanism works.

Sorry, I can't understant what you mean. I repeat that mISDN group dial doesn't work at all (for outgoing calls) if there are not L2Links already UP.

For example:
- I start Asterisk, there are no calls now.
- After a seconds all the L2 are released by my provider.
- Now I dial using a mISDN group and because all the L2 are DOWN Asterisk can't call.
- But I still can dial if I use a direct port instead of a group.

Are you really telling that this is the expected behaviour in group dial? or didn't I explain properly?

Please, ask me for more info if you need. Regards.
By: crich (crich) 2007-04-03 08:40:54

Yes this is the expected behaviour. A PTP Link should have a constant L2 which keeps UP all the time.

So in my eyes your provider has a wrong setting in his switch configuration.

When you explicitely dial out with a port you tell chan_misdn to try and get the L1 and L2 UP before making an outbound call, this might cost some time and it might even fail, that's why chan_misdn doesn't do that in a group dial, because the group dial should definitely work (fast).

have you already asked your provider why he is shutting down the L2 ?

could you please do also the following:

set the debug variable in /etc/misdn-init.conf to 0x42 and restart Asterisk and just wait until the L2 goes down, then post the output of "dmesg" here.

Thx.
By: Iñaki Baz Castillo (ibc) 2007-04-03 09:08:46

It's very strange. I restart Asterisk and my provider doesn't release L2 in any port. I can wait for a long and they continue UP.

I need to do a call by ISDN and after that the used port L2 is released:

--------------------------------
## I restart Asterisk:

asterisk*CLI> misdn show stacks
BEGIN STACK_LIST:
* Port 1 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:4
* Port 2 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:4
* Port 3 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:4

## I do a call:

asterisk*CLI> core dial 941@pruebas
[Apr 3 15:53:18] WARNING[29215]: chan_oss.c:682 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
-- Executing [941@pruebas:1] Dial("OSS/dsp", "mISDN/1/675511308") in new stack
P[ 0] maxnum:2P[ 0] --> * NEW CHANNEL dad:675511308 oad:(null)
P[ 1] * Queuing chan 0x822de00
P[ 1] read_config: Getting Config
P[ 1] --> TON: Unknown
P[ 1] --> LTON: Unknown
P[ 1] --> CTON: Unknown
P[ 1] * CALL: 1/675511308
P[ 1] --> * dad:675511308 tech:mISDN/0-u0 ctx:entrantes-analogicas
P[ 1] --> * adding2newbc ext 675511308
P[ 1] --> * adding2newbc callerid
P[ 1] --> pres: -1 screen: -1
P[ 1] --> pres: 0
P[ 1] --> PRES: Allowed (0x0)
P[ 1] --> SCREEN: Unscreened (0x0)
P[ 1] NO OPTS GIVEN
P[ 1] I SEND:SETUP oad: dad:675511308 pid:2
P[ 1] --> bc_state:BCHAN_CLEANED
P[ 1] --> channel:0 mode:TE cause:16 ocause:16 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:0 l3id:0 b_stid:0 layer_id:0
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] --> found chan: 1
P[ 1] I IND :NEW_CHANNEL oad: dad:675511308 pid:2 state:NOTHING
P[ 1] --> channel:1 mode:TE cause:16 ocause:16 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:0 l3id:0 b_stid:0 layer_id:0
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] --> bc_state:BCHAN_CLEANED
P[ 1] --> updating channel name to [mISDN/1-u1]
P[ 1] --> found channel: 1
P[ 1] set_chan_in_stack: 1
P[ 1] --> new_l3id 90001
P[ 1] NO USERUESRINFO ENCODED
P[ 1] --> * SEND: State Dialing pid:2
-- Called 1/675511308
P[ 1] Sending msg, prim:30580 addr:41000104 dinfo:90001
P[ 1] handle_frm: frm->addr:42000103 frm->prim:30282
P[ 1] set_channel: bc->channel:1 channel:1
P[ 1] I IND :NEW_CHANNEL oad: dad:675511308 pid:2 state:CALLING
P[ 1] --> channel:1 mode:TE cause:16 ocause:16 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:0 l3id:90001 b_stid:0 layer_id:0
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] --> bc_state:BCHAN_CLEANED
P[ 1] --> updating channel name to [mISDN/1-u2]
P[ 1] setup_bc: with dsp
P[ 1] --> Channel is 1
P[ 1] --> TRANSPARENT Mode
P[ 1] set_chan_in_stack: 1
P[ 1] channel already in use:1
P[ 1] I IND :PROCEEDING oad: dad:675511308 pid:2 state:CALLING
P[ 1] --> channel:1 mode:TE cause:16 ocause:16 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:50010102 l3id:90001 b_stid:10010100 layer_id:50010180
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] --> bc_state:BCHAN_ACTIVATED
P[ 1] --> updating channel name to [mISDN/1-u3]
P[ 1] -- mISDN/1-u3 is proceeding passing it to OSS/dsp
BCHAN: bchan ACT Confirm pid:2
[Apr 3 15:53:18] WARNING[29247]: chan_oss.c:978 oss_indicate: Don't know how to display condition 15 on OSS/dsp
[Apr 3 15:53:19] WARNING[29247]: chan_oss.c:682 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
[Apr 3 15:53:20] WARNING[29247]: chan_oss.c:682 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
[Apr 3 15:53:21] WARNING[29247]: chan_oss.c:682 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
[Apr 3 15:53:22] WARNING[29247]: chan_oss.c:682 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
[Apr 3 15:53:23] WARNING[29247]: chan_oss.c:682 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
P[ 1] handle_frm: frm->addr:42000103 frm->prim:30182
P[ 1] $$$ bc already upsetted stid :10010100 (state:BCHAN_ACTIVATED)
P[ 1] set_chan_in_stack: 1
P[ 1] channel already in use:1
P[ 1] I IND :ALERTING oad: dad:675511308 pid:2 state:PROCEEDING
P[ 1] --> channel:1 mode:TE cause:16 ocause:16 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:8 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:50010102 l3id:90001 b_stid:10010100 layer_id:50010180
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] --> bc_state:BCHAN_ACTIVATED
P[ 1] --> updating channel name to [mISDN/1-u4]
-- mISDN/1-u4 is ringing
P[ 1] Starting Tones, we have inband Data
asterisk*CLI> hangup
The 'hangup' command is deprecated and will be removed in a future release. Please use 'console hangup' instead.
[Apr 3 15:53:23] DEBUG[29247]: chan_misdn.c:2301 misdn_hangup: misdn_hangup(mISDN/1-u4)
P[ 1] * IND : HANGUP pid:2 ctx:entrantes-analogicas dad:675511308 oad:941 State:ALERTING
P[ 1] --> l3id:90001
P[ 1] --> cause:16
P[ 1] --> out_cause:16
P[ 1] --> state:ALERTING
P[ 1] I SEND:DISCONNECT oad: dad:675511308 pid:2
P[ 1] --> bc_state:BCHAN_ACTIVATED
P[ 1] --> channel:1 mode:TE cause:16 ocause:16 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:8 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:50010102 l3id:90001 b_stid:10010100 layer_id:50010180
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] --> Channel: mISDN/1-u4 hanguped new state:CLEANING
== Spawn extension (pruebas, 941, 1) exited non-zero on 'OSS/dsp'
P[ 1] Sending msg, prim:34580 addr:41000104 dinfo:90001
<< Hangup on console >>
P[ 1] handle_frm: frm->addr:42000103 frm->prim:34d82
P[ 1] empty_chan_in_stack: 1
P[ 1] $$$ CLEANUP CALLED pid:2
P[ 1] $$$ Cleaning up bc with stid :10010100 pid:2
P[ 1] --> ec_disable
P[ 1] Sending Control ECHOCAN_OFF
P[ 1] ph_control: c1:2319 c2:0
P[ 1] I IND :RELEASE oad: dad: pid:2 state:CLEANING
P[ 1] --> channel:0 mode:TE cause:16 ocause:16 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:50010102 l3id:90001 b_stid:0 layer_id:50010180
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] --> bc_state:BCHAN_CLEANED
P[ 1] ast_hangup already called, so we have no ast ptr anymore in event(RELEASE)
P[ 1] --> No need to queue hangup
P[ 1] Cannot hangup chan, no ast
P[ 1] I SEND:RELEASE_COMPLETE oad: dad: pid:2
P[ 1] --> bc_state:BCHAN_CLEANED
P[ 1] --> channel:0 mode:TE cause:16 ocause:16 rad: cad:
P[ 1] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1] --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1] --> screen:0 --> pres:0
P[ 1] --> addr:50010102 l3id:90001 b_stid:0 layer_id:50010180
P[ 1] --> facility:Fac_None out_facility:Fac_None
P[ 1] $$$ CLEANUP CALLED pid:2
P[ 1] Sending msg, prim:35a80 addr:41000104 dinfo:90001
P[ 1] handle_frm: frm->addr:42000103 frm->prim:3f182
P[ 1] --> lib: RELEASE_CR Ind with l3id:90001
P[ 1] --> lib: CLEANING UP l3id: 90001
P[ 1] $$$ CLEANUP CALLED pid:2
P[ 1] BCHAN: MGR_DELLAYER|CNF pid:2
P[ 1] MGMT: SSTATUS: L2_RELEASED

# Now the port 1 L2 is DOWN:

asterisk*CLI> misdn show stacks
BEGIN STACK_LIST:
* Port 1 Type TE Prot. PTP L2Link DOWN L1Link:UP Blocked:0 Debug:4
* Port 2 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:4
* Port 3 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:4
--------------------------------

I attach too the output of "dmesg" command.

> have you already asked your provider why he is shutting down the L2 ?

Shouldn't my provider shut down L2 if it provides me a PTP BRI? could be different with PTMP?
Is it normal that the L2 is released just AFTER a call?
I'm sorry for my ignorance in ISDN and BRI topics, I'd really like to ask my provider for the L2 release but I'd like to know a bit more about it.

Thanks a lot for all.
By: crich (crich) 2007-04-03 09:39:34

np.

as far as i know and as far as i have seen until now in PTP mode the provider should not Shutdown the L2 at all, also not after a call was made.
By: Iñaki Baz Castillo (ibc) 2007-04-03 11:46:52

Hi again, I've spoken with my ISDN provider. They will tell me details tomorrow but for now they say me that the L2 is configured to be always UP (anyway they will confirm it tomorrow to me), and there is PTP signaling.

So tomorrow I tell more here.

Regards and thanks for all.
By: Iñaki Baz Castillo (ibc) 2007-04-04 04:18:45

It's very strange: I've other BRI ISDN (just one TR) with same provider, but this one is configured as PTMP.

To do a test I have configured the 4th port of my card to speak PTMP with it.

The behaviour about L2 is similar, the Port4-L2 start UP:
--------------------------
* Port 1 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:0
* Port 2 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:0
* Port 3 Type TE Prot. PTP L2Link UP L1Link:UP Blocked:0 Debug:0
* Port 4 Type TE Prot. PMP L2Link UP L1Link:UP Blocked:0 Debug:0
--------------------------

And it becomes DOWN after a call, but it different of my problem with the PTP trunks:

I have configured a mISDN group just for ports 3 and 4:
--------------------------
[te4]
ports=3,4
context=entrantes-analogicas
msns=*
--------------------------

Now I defined those extensions:
--------------------------
exten => 950,1,Dial(mISDN/g:te4/675511308)
exten => 954,1,Dial(mISDN/4/675511308)
--------------------------

Of course I can dial 954 always, aven if L2 is DOWN, but the strange thing is that I can dial TOO always 950 (group dial) even if all L2 are DOWN so the call is made by port 4.

Is it normal? maybe because port 4 is PTMP and group dial checks L2 link in PTMP but not in PTP?
By: Iñaki Baz Castillo (ibc) 2007-04-16 06:11:30

I'm still waiting for my ISDN provider to call me to do a line test, so if it's possible I'd like this issue to be still open.

Thanks.
By: crich (crich) 2007-05-17 17:47:04

in the meantime i've added the application "misdn_check_l2l1" which can be used like:

exten => _X.,1,misdn_check_l2l1(mISDN/g:out|2)
exten => _X.,n,dial(mISDN/g:out/${EXTEN})

this app, checks wether the l2 & l1 are up on the ports in the group "out" if so, it just goes on in the dialplan. If not it pulls them up and waits for 2 seconds.
By: Iñaki Baz Castillo (ibc) 2007-05-18 03:18:50

Interesting, it could be very useful, thanks.
By: mimmo (mimmo) 2007-05-21 10:57:01

I'm interested too. Is this issue solved?
By: Joao Correia (joaocorreia) 2007-05-23 05:12:16

Hello,

Im having the same problem with a PTMP line !
Where can I get this app ? misdn_check_l2l1 ?
joao.correia@gmail.com

UPDATE: pmp_l1_check=no (putting this inside the Port configuration on misdn.conf seams to bring ports up and makes the call.)

Thanks
Joao Correia

By: Jasper Roel (jasperroel) 2007-06-22 04:59:11

We have recently moved, and now have a PTP connection with our telecom provider and are having the same problem.

We have upgraded to 1.4.5 and added "exten => _X.,1,misdn_check_l2l1(mISDN/g:outsidelines|2)" to our dialplan.

The console now shows:
-- Executing [**number**@default:1] Dial("SIP/57-081e6688", "mISDN/g:outsidelines/**number**") in new stack
P[ 0] --> Group Call group: outsidelines
P[ 1] Port Down L2:0 L1:1
[Jun 22 11:53:48] WARNING[28894]: chan_misdn.c:3150 misdn_request: Could not Dial out on group 'outsidelines'.
Either the L2 and L1 on all of these ports where DOWN (see 'show application misdn_check_l2l1')
Or there was no free channel on none of the ports

AND

-- Executing [**number**@default:1] misdn_check_l2l1("SIP/86-0820ed30", "mISDN/g:outsidelines|2") in new stack
[Jun 24 23:51:24] WARNING[14969]: chan_misdn.c:5065 misdn_check_l2l1: misdn_check_l2l1 makes only sense with chan_misdn channels!
== Spawn extension (default, **number**, 1) exited non-zero on 'SIP/86-0820ed30'

Any idea on how to 'trick' or tell misdn_check_l2l1 that we are really going to use mISDN, and not SIP (as it now thinks)?

By: Jasper Roel (jasperroel) 2007-06-29 03:08:27

After some playing, we found the 'problem' in channels/chan_misdn.c. Local revision: 68733 (Asterisk v1.4.5)

The function misdn_check_l2l1, line number 5062 contains a check to see if the line we are calling from is a mISDN channel. While this is a good thing, we are using the function to check if the line we are calling (which is a mISDN line) is up, not the line we are calling from (which is a SIP connection from our LAN).

The function would keep returning -1 because of this check. Because the *chan is not used anywhere else in this function, we disabled the check (line 5065 - 5068) and recompiled Asterisk.

And presto, it now works great!

We ended up with the following piece of code:

[macro-outbound]
exten => s,1,misdn_check_l2l1(g:outsidelines|1)
exten => s,n,Dial(mISDN/g:outsidelines/${ARG1})

Hope this helps!
By: Digium Subversion (svnbot) 2007-07-03 02:48:04

Repository: asterisk
Revision: 73004

------------------------------------------------------------------------
r73004 | crichter | 2007-07-03 02:48:02 -0500 (Tue, 03 Jul 2007) | 1 line

fixed issue, that misdn_l2l1_check could only be called from mISDN Source channels.. ASTERISK-9173
------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-07-03 03:00:32

Repository: asterisk
Revision: 73005

------------------------------------------------------------------------
r73005 | crichter | 2007-07-03 03:00:32 -0500 (Tue, 03 Jul 2007) | 9 lines

Merged revisions 73004 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r73004 | crichter | 2007-07-03 10:04:35 +0200 (Di, 03 Jul 2007) | 1 line

fixed issue, that misdn_l2l1_check could only be called from mISDN Source channels.. ASTERISK-9173
........

------------------------------------------------------------------------
By: crich (crich) 2007-07-03 03:04:35

jasperroel: you're quite right, this check is obviously wrong. I've removed it in 1.2,1.4 (r73005) and trunk.
By: Digium Subversion (svnbot) 2007-07-03 03:05:40

Repository: asterisk
Revision: 73006

------------------------------------------------------------------------
r73006 | crichter | 2007-07-03 03:05:39 -0500 (Tue, 03 Jul 2007) | 17 lines

Merged revisions 73005 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r73005 | crichter | 2007-07-03 10:17:06 +0200 (Di, 03 Jul 2007) | 9 lines

Merged revisions 73004 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r73004 | crichter | 2007-07-03 10:04:35 +0200 (Di, 03 Jul 2007) | 1 line

fixed issue, that misdn_l2l1_check could only be called from mISDN Source channels.. ASTERISK-9173
........

................

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-07-03 08:57:17

Repository: asterisk
Revision: 73099

------------------------------------------------------------------------
r73099 | phsultan | 2007-07-03 08:57:15 -0500 (Tue, 03 Jul 2007) | 77 lines

Merged revisions 72982,72986-72987,73003,73006,73054 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r72982 | russell | 2007-07-03 00:27:46 +0200 (Tue, 03 Jul 2007) | 7 lines

* Move LaTeX docs into a tex/ subdirectory of the doc/ dir
* Add a Makefile in doc/tex/ for generating PDF and HTML
* Add a README.txt file to doc/tex/ to document which tools are used and what
web sites to visit for getting them.
* Update build_tools/prep_tarball to put the proper Asterisk version string
in the automatically generated PDF for release tarballs

................
r72986 | russell | 2007-07-03 01:02:16 +0200 (Tue, 03 Jul 2007) | 6 lines

After some discussion on the asterisk-dev list, we determined that this approach
for extracting application, function, manager, and agi documentation is the wrong
one to take. The most severe problem is that the output depends on which modules
are loaded as well as compile time options, which both determine which parts are
available.

................
r72987 | qwell | 2007-07-03 04:51:08 +0200 (Tue, 03 Jul 2007) | 4 lines

Correct an issue where the wrong type was being used to start sasl.

Pointed out by and patch provided by mog.

................
r73003 | tilghman | 2007-07-03 07:21:02 +0200 (Tue, 03 Jul 2007) | 2 lines

Typo (closes issue 10105)

................
r73006 | crichter | 2007-07-03 10:22:13 +0200 (Tue, 03 Jul 2007) | 17 lines

Merged revisions 73005 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r73005 | crichter | 2007-07-03 10:17:06 +0200 (Di, 03 Jul 2007) | 9 lines

Merged revisions 73004 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r73004 | crichter | 2007-07-03 10:04:35 +0200 (Di, 03 Jul 2007) | 1 line

fixed issue, that misdn_l2l1_check could only be called from mISDN Source channels.. ASTERISK-9173
........

................

................
r73054 | tilghman | 2007-07-03 14:40:26 +0200 (Tue, 03 Jul 2007) | 18 lines

Merged revisions 73053 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r73053 | tilghman | 2007-07-03 07:38:53 -0500 (Tue, 03 Jul 2007) | 10 lines

Merged revisions 73052 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r73052 | tilghman | 2007-07-03 07:34:14 -0500 (Tue, 03 Jul 2007) | 2 lines

RetryDial should accept a 0 argument, but it does not, because atoi does not distinguish between 0 and error (closes issue ASTERISK-9796)

........

................

................

------------------------------------------------------------------------
By: Lukino (lukinovoip) 2007-11-14 07:59:02.000-0600

ASTERISK 1.4.13
Hi all,
I solve this issue by patching chan_misdn.c this way:

on line 3211 insert a comment

chan_misdn_log(4, port, "portup:%d\n", port_up);

/*Here if ( port_up>0 )*/ {
newbc = misdn_lib_get_free_bc(port, 0, 0, dec);

insert a comment in line 3167 too:

/*if (port_up <= 0)
continue;*/

Recompile asterisk.
This worked for me.
Hope this can help you
By: crich (crich) 2007-11-16 02:57:03.000-0600

This issue has been proved to be resolved by the introduction of the application:

misdn_check_l2l1

which should be used shortly before dialing on a mISDN group like:

[macro-outbound]
exten => s,1,misdn_check_l2l1(g:outsidelines|1)
exten => s,n,Dial(mISDN/g:outsidelines/${ARG1})

This is currently the recommended way of resolving this issue.