openzap Failure opening channel error
Hi, Again I was struck in a problem, Here is the scenario. On incomming call, I just call an event outboud socket. But what happens is, for the first 15 call, it is working fine. But from the 16th call to 30th call, it says the below error. 2009-10-07 15:07:48.201846 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:17 (ignored) 2009-10-07 15:07:55.381861 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:18 (ignored) 2009-10-07 15:07:58.569774 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:19 (ignored) 2009-10-07 15:08:01.37824 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:20 (ignored) 2009-10-07 15:08:03.129846 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:21 (ignored) 2009-10-07 15:08:04.825851 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:22 (ignored) 2009-10-07 15:08:06.289977 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:23 (ignored) 2009-10-07 15:08:07.761961 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:24 (ignored) 2009-10-07 15:08:09.737944 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:25 (ignored) 2009-10-07 15:08:11.462018 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:26 (ignored) 2009-10-07 15:08:13.566024 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:27 (ignored) 2009-10-07 15:08:15.430163 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:28 (ignored) 2009-10-07 15:08:17.446103 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:29 (ignored) 2009-10-07 15:08:19.430118 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:30 (ignored) 2009-10-07 15:08:21.358121 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:31 (ignored) But for the next call, when it is opening channel 1:1, it is executing my dial plans. I don't know why it failed when it is choosing 1:17-1:31. Any one has any idea. Below are my configuration details: openzap.conf [span zt PRI_1] trunk_type => e1 b-channel => 1:1-15 d-channel=> 1:16 b-channel => 1:17-31 openzap.conf.xml <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="7"/> </settings> <libpri_spans> <span name="PRI_1"> <param name="node" value="cpe"/> <param name="switch" value="euroisdn"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </libpri_spans> </configuration> zaptel.conf span=1,1,0,ccs,hdb3 bchan=1-15,17-31 dchan=16 loadzone = us defaultzone = us oz list span: 1 (PRI_1) type: isdn chan_count: 47 dialplan: XML context: default dial_regex: fail_dial_regex: hold_music: analog_options none
lakshmanan ganapathy <lakindia89@gmail.com> said:
On incomming call, I just call an event outboud socket. But what happens is, for the first 15 call, it is working fine. But from the 16th call to 30th call, it says the below error.
What is displayed with ztcfg -vv What is displayed with cat /proc/zaptel/1 -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
[debian :~]# ztcfg -vvv Zaptel Version: 1.4.11 Echo Canceller: MG2 Configuration ====================== SPAN 1: CCS/HDB3 Build-out: 0 db (CSU)/0-133 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Slaves: 01) Channel 02: Clear channel (Default) (Slaves: 02) Channel 03: Clear channel (Default) (Slaves: 03) Channel 04: Clear channel (Default) (Slaves: 04) Channel 05: Clear channel (Default) (Slaves: 05) Channel 06: Clear channel (Default) (Slaves: 06) Channel 07: Clear channel (Default) (Slaves: 07) Channel 08: Clear channel (Default) (Slaves: 08) Channel 09: Clear channel (Default) (Slaves: 09) Channel 10: Clear channel (Default) (Slaves: 10) Channel 11: Clear channel (Default) (Slaves: 11) Channel 12: Clear channel (Default) (Slaves: 12) Channel 13: Clear channel (Default) (Slaves: 13) Channel 14: Clear channel (Default) (Slaves: 14) Channel 15: Clear channel (Default) (Slaves: 15) Channel 16: D-channel (Default) (Slaves: 16) Channel 17: Clear channel (Default) (Slaves: 17) Channel 18: Clear channel (Default) (Slaves: 18) Channel 19: Clear channel (Default) (Slaves: 19) Channel 20: Clear channel (Default) (Slaves: 20) Channel 21: Clear channel (Default) (Slaves: 21) Channel 22: Clear channel (Default) (Slaves: 22) Channel 23: Clear channel (Default) (Slaves: 23) Channel 24: Clear channel (Default) (Slaves: 24) Channel 25: Clear channel (Default) (Slaves: 25) Channel 26: Clear channel (Default) (Slaves: 26) Channel 27: Clear channel (Default) (Slaves: 27) Channel 28: Clear channel (Default) (Slaves: 28) Channel 29: Clear channel (Default) (Slaves: 29) Channel 30: Clear channel (Default) (Slaves: 30) Channel 31: Clear channel (Default) (Slaves: 31) 31 channels to configure. [debian :~]# cat /proc/zaptel/1 + cat /proc/zaptel/1 Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) HDB3/CCS ClockSource Timing slips: 1 1 TE2/0/1/1 Clear 2 TE2/0/1/2 Clear 3 TE2/0/1/3 Clear 4 TE2/0/1/4 Clear 5 TE2/0/1/5 Clear 6 TE2/0/1/6 Clear 7 TE2/0/1/7 Clear 8 TE2/0/1/8 Clear 9 TE2/0/1/9 Clear 10 TE2/0/1/10 Clear 11 TE2/0/1/11 Clear 12 TE2/0/1/12 Clear 13 TE2/0/1/13 Clear 14 TE2/0/1/14 Clear 15 TE2/0/1/15 Clear 16 TE2/0/1/16 HDLCFCS 17 TE2/0/1/17 Clear 18 TE2/0/1/18 Clear 19 TE2/0/1/19 Clear 20 TE2/0/1/20 Clear 21 TE2/0/1/21 Clear 22 TE2/0/1/22 Clear 23 TE2/0/1/23 Clear 24 TE2/0/1/24 Clear 25 TE2/0/1/25 Clear 26 TE2/0/1/26 Clear 27 TE2/0/1/27 Clear 28 TE2/0/1/28 Clear 29 TE2/0/1/29 Clear 30 TE2/0/1/30 Clear 31 TE2/0/1/31 Clear On Wed, Oct 7, 2009 at 5:29 PM, <Russell.Mosemann@cune.org> wrote:
lakshmanan ganapathy <lakindia89@gmail.com> said:
On incomming call, I just call an event outboud socket. But what happens is, for the first 15 call, it is working fine. But from the 16th call to 30th call, it says the below error.
What is displayed with
ztcfg -vv
What is displayed with
cat /proc/zaptel/1
-- Russell Mosemann
________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Wed, Oct 7, 2009 at 3:34 AM, lakshmanan ganapathy <lakindia89@gmail.com>wrote:
Hi, Again I was struck in a problem, Here is the scenario.
On incomming call, I just call an event outboud socket. But what happens is, for the first 15 call, it is working fine. But from the 16th call to 30th call, it says the below error.
2009-10-07 15:07:48.201846 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:17 (ignored) 2009-10-07 15:07:55.381861 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:18 (ignored) 2009-10-07 15:07:58.569774 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:19 (ignored) 2009-10-07 15:08:01.37824 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:20 (ignored) 2009-10-07 15:08:03.129846 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:21 (ignored) 2009-10-07 15:08:04.825851 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:22 (ignored) 2009-10-07 15:08:06.289977 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:23 (ignored) 2009-10-07 15:08:07.761961 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:24 (ignored) 2009-10-07 15:08:09.737944 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:25 (ignored) 2009-10-07 15:08:11.462018 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:26 (ignored) 2009-10-07 15:08:13.566024 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:27 (ignored) 2009-10-07 15:08:15.430163 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:28 (ignored) 2009-10-07 15:08:17.446103 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:29 (ignored) 2009-10-07 15:08:19.430118 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:30 (ignored) 2009-10-07 15:08:21.358121 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:31 (ignored)
But for the next call, when it is opening channel 1:1, it is executing my dial plans. I don't know why it failed when it is choosing 1:17-1:31. Any one has any idea.
Below are my configuration details:
openzap.conf [span zt PRI_1] trunk_type => e1 b-channel => 1:1-15 d-channel=> 1:16 b-channel => 1:17-31
Just a hunch, but could you try this in openzap.conf: b-channel => 1:1-15,17-31 d-channel => 1:16 I want to see what happens. I don't have an E1 setup to test with right now otherwise I'd do it myself. Please report back. Thanks, MC
openzap.conf.xml <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="7"/> </settings> <libpri_spans> <span name="PRI_1"> <param name="node" value="cpe"/> <param name="switch" value="euroisdn"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </libpri_spans> </configuration>
zaptel.conf
span=1,1,0,ccs,hdb3 bchan=1-15,17-31 dchan=16
loadzone = us defaultzone = us
oz list
span: 1 (PRI_1) type: isdn chan_count: 47 dialplan: XML context: default dial_regex: fail_dial_regex: hold_music: analog_options none
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi I tried with the following openzap.conf [span zt PRI_1] trunk_type => e1 b-channel => 1:1-15,17-31 d-channel => 1:16 openzap.conf.xml <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="7"/> </settings> <libpri_spans> <span name="PRI_1"> <param name="node" value="cpe"/> <param name="switch" value="euroisdn"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </libpri_spans> </configuration> But as soon as I start the freeswitch I got the following error 2009-10-08 15:08:35.496270 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:37.601135 [DEBUG] ozmod_libpri.c:817 EVENT [ONHOOK][1][1:1] STATE [DOWN] 2009-10-08 15:08:37.701176 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:39.802004 [DEBUG] ozmod_libpri.c:817 EVENT [DTMF][0][1:1] STATE [DOWN] 2009-10-08 15:08:39.902034 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:42.010983 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:44.115874 [DEBUG] ozmod_libpri.c:817 EVENT [ONHOOK][1][1:1] STATE [DOWN] 2009-10-08 15:08:44.215915 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:46.312748 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:48.417552 [DEBUG] ozmod_libpri.c:817 EVENT [DTMF][0][1:1] STATE [DOWN] 2009-10-08 15:08:48.517587 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:50.626485 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:52.735325 [DEBUG] ozmod_libpri.c:817 EVENT [ONHOOK][1][1:1] STATE [DOWN] 2009-10-08 15:08:52.835357 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:54.944190 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:57.049109 [DEBUG] ozmod_libpri.c:817 EVENT [DTMF][0][1:1] STATE [DOWN] 2009-10-08 15:08:57.149148 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 2009-10-08 15:08:59.253979 [DEBUG] ozmod_libpri.c:885 Event Failure! 1 I also got the below error in the middle 2009-10-08 15:09:48.992613 [CRIT] lpwrap_pri.c:154 span 1 D-WRITE FAIL! [] 2009-10-08 15:09:48.992613 [ERR] ozmod_libpri.c:88 Short write: -1/5 (Invalid or incomplete multibyte or wide character) Please help. On Wed, Oct 7, 2009 at 9:19 PM, Michael Collins <msc@freeswitch.org> wrote:
On Wed, Oct 7, 2009 at 3:34 AM, lakshmanan ganapathy <lakindia89@gmail.com
wrote:
Hi, Again I was struck in a problem, Here is the scenario.
On incomming call, I just call an event outboud socket. But what happens is, for the first 15 call, it is working fine. But from the 16th call to 30th call, it says the below error.
2009-10-07 15:07:48.201846 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:17 (ignored) 2009-10-07 15:07:55.381861 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:18 (ignored) 2009-10-07 15:07:58.569774 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:19 (ignored) 2009-10-07 15:08:01.37824 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:20 (ignored) 2009-10-07 15:08:03.129846 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:21 (ignored) 2009-10-07 15:08:04.825851 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:22 (ignored) 2009-10-07 15:08:06.289977 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:23 (ignored) 2009-10-07 15:08:07.761961 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:24 (ignored) 2009-10-07 15:08:09.737944 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:25 (ignored) 2009-10-07 15:08:11.462018 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:26 (ignored) 2009-10-07 15:08:13.566024 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:27 (ignored) 2009-10-07 15:08:15.430163 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:28 (ignored) 2009-10-07 15:08:17.446103 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:29 (ignored) 2009-10-07 15:08:19.430118 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:30 (ignored) 2009-10-07 15:08:21.358121 [WARNING] ozmod_libpri.c:761 --Failure opening channel 1:31 (ignored)
But for the next call, when it is opening channel 1:1, it is executing my dial plans. I don't know why it failed when it is choosing 1:17-1:31. Any one has any idea.
Below are my configuration details:
openzap.conf [span zt PRI_1] trunk_type => e1 b-channel => 1:1-15 d-channel=> 1:16 b-channel => 1:17-31
Just a hunch, but could you try this in openzap.conf: b-channel => 1:1-15,17-31 d-channel => 1:16
I want to see what happens. I don't have an E1 setup to test with right now otherwise I'd do it myself. Please report back. Thanks, MC
openzap.conf.xml <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="7"/> </settings> <libpri_spans> <span name="PRI_1"> <param name="node" value="cpe"/> <param name="switch" value="euroisdn"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </libpri_spans> </configuration>
zaptel.conf
span=1,1,0,ccs,hdb3 bchan=1-15,17-31 dchan=16
loadzone = us defaultzone = us
oz list
span: 1 (PRI_1) type: isdn chan_count: 47 dialplan: XML context: default dial_regex: fail_dial_regex: hold_music: analog_options none
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, Oct 8, 2009 at 5:41 AM, lakshmanan ganapathy <lakindia89@gmail.com>wrote:
Hi I tried with the following openzap.conf [span zt PRI_1] trunk_type => e1 b-channel => 1:1-15,17-31 d-channel => 1:16
This does not look like a healthy config to me. You are using <span>:<channels> notation in zaptel spans, zaptel channels increment across spans, read point number 5 of this web page http://wiki.freeswitch.org/wiki/OpenZAP_OpenR2 , this is for another type of signaling, but the span/channel numbering concepts are the same. -- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
On Thu, Oct 8, 2009 at 8:02 AM, Moises Silva <moises.silva@gmail.com> wrote:
On Thu, Oct 8, 2009 at 5:41 AM, lakshmanan ganapathy <lakindia89@gmail.com
wrote:
Hi I tried with the following openzap.conf [span zt PRI_1] trunk_type => e1 b-channel => 1:1-15,17-31 d-channel => 1:16
This does not look like a healthy config to me. You are using <span>:<channels> notation in zaptel spans, zaptel channels increment across spans, read point number 5 of this web page http://wiki.freeswitch.org/wiki/OpenZAP_OpenR2 , this is for another type of signaling, but the span/channel numbering concepts are the same.
Moy, As usual you are right on the money. I'm so used to doing Sangoma configs that I forget about the zaptel syntax. I recommend this config: [span zt PRI_1] trunk_type => e1 b-channel => 1-15 d-channel => 16 b-channel => 17-31 Give that a try and report back if you have issues. -MC
-- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks all u guys. It got worked when I replaced with the following configuration and the incoming has no problem with that. [span zt PRI_1] trunk_type => e1 b-channel => 1-15 d-channel => 16 b-channel => 17-31 But still I'm facing problem with the outgoing call. It says INVALID_IE_CONTENTS. What might be the issue? Even I tried the following dialplan to call by using bridge. <extension name="outgoing-fxo"> <condition field="destination_number" expression="^(\d{10})$"> <action application="answer"/> <action application="bridge" data="openzap/1/1/${dialed_ext}"/> </condition> </extension> But it prints the same error. What might be the issue? On Thu, Oct 8, 2009 at 10:24 PM, Michael Collins <msc@freeswitch.org> wrote:
On Thu, Oct 8, 2009 at 8:02 AM, Moises Silva <moises.silva@gmail.com>wrote:
On Thu, Oct 8, 2009 at 5:41 AM, lakshmanan ganapathy < lakindia89@gmail.com> wrote:
Hi I tried with the following openzap.conf [span zt PRI_1] trunk_type => e1 b-channel => 1:1-15,17-31 d-channel => 1:16
This does not look like a healthy config to me. You are using <span>:<channels> notation in zaptel spans, zaptel channels increment across spans, read point number 5 of this web page http://wiki.freeswitch.org/wiki/OpenZAP_OpenR2 , this is for another type of signaling, but the span/channel numbering concepts are the same.
Moy,
As usual you are right on the money. I'm so used to doing Sangoma configs that I forget about the zaptel syntax. I recommend this config:
[span zt PRI_1] trunk_type => e1 b-channel => 1-15 d-channel => 16 b-channel => 17-31
Give that a try and report back if you have issues. -MC
-- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
lakshmanan ganapathy <lakindia89@gmail.com> said:
But still I'm facing problem with the outgoing call. It says INVALID_IE_CONTENTS. What might be the issue? Even I tried the following dialplan to call by using bridge. <extension name="outgoing-fxo"> <condition field="destination_number" expression="^(\d{10})$"> <action application="answer"/> <action application="bridge" data="openzap/1/1/${dialed_ext}"/>
Does "answer" need to be called here? I haven't used an fxo. So, I don't know. What value does $dialed_ext have? If you want to use the number matched in the condition, then it should be openzap/1/1/$1 -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
Hi, I've tried with the following dialplan(After making the changes that are recommended). But still I got INVALID_IE_CONTENTS error. Another thing is, if I use prispan configuration, I'm able to make outgoing calls. But if I use the libpri span configuration I'm not able to make outgoing calls, which says INVALID_IE_CONTENTS. I've been struck with this problem for the past 1 week. Any solution to this??? On Fri, Oct 9, 2009 at 6:06 PM, <Russell.Mosemann@cune.org> wrote:
lakshmanan ganapathy <lakindia89@gmail.com> said:
But still I'm facing problem with the outgoing call. It says INVALID_IE_CONTENTS. What might be the issue? Even I tried the following dialplan to call by using bridge. <extension name="outgoing-fxo"> <condition field="destination_number" expression="^(\d{10})$"> <action application="answer"/> <action application="bridge" data="openzap/1/1/${dialed_ext}"/>
Does "answer" need to be called here? I haven't used an fxo. So, I don't know. What value does $dialed_ext have? If you want to use the number matched in the condition, then it should be
openzap/1/1/$1
-- Russell Mosemann
________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Okay, please go to pastebin.freeswitch.org and paste your openzap.conf.xml file. Also, paste the ENTIRE debug log from a call from start to finish. Telling us that you see INVALID_IE_CONTENTS doesn't help if we don't know what the information element contains. Finally, turn on PRI debugging and make another test call and pastebin that debug log as well. The debug will show details about the communications between your machine and the carrier. Instructions for turning on debugging for libpri are found in the OpenZAP wiki page in the same place where the libpri instructions are located. Put the pastebin number in this email thread and then we'll go have a look. Thanks, MC On Sat, Oct 10, 2009 at 6:47 AM, lakshmanan ganapathy <lakindia89@gmail.com>wrote:
Hi, I've tried with the following dialplan(After making the changes that are recommended). But still I got INVALID_IE_CONTENTS error.
Another thing is, if I use prispan configuration, I'm able to make outgoing calls. But if I use the libpri span configuration I'm not able to make outgoing calls, which says INVALID_IE_CONTENTS.
I've been struck with this problem for the past 1 week. Any solution to this???
On Fri, Oct 9, 2009 at 6:06 PM, <Russell.Mosemann@cune.org> wrote:
lakshmanan ganapathy <lakindia89@gmail.com> said:
But still I'm facing problem with the outgoing call. It says INVALID_IE_CONTENTS. What might be the issue? Even I tried the following dialplan to call by using bridge. <extension name="outgoing-fxo"> <condition field="destination_number" expression="^(\d{10})$"> <action application="answer"/> <action application="bridge" data="openzap/1/1/${dialed_ext}"/>
Does "answer" need to be called here? I haven't used an fxo. So, I don't know. What value does $dialed_ext have? If you want to use the number matched in the condition, then it should be
openzap/1/1/$1
-- Russell Mosemann
________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Ya ok. Here is the required stuff Configuration: (PRI span) <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="7"/> </settings> <pri_spans> <span id="1" name="PRI_1"> <param name="q921loglevel" value="alert"/> <param name="q931loglevel" value="alert"/> <param name="mode" value="user"/> <param name="dialect" value="q931"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </pri_spans> </configuration> Log while starting freeswitch: http://pastebin.freeswitch.org/10646 Log when making a call: http://pastebin.freeswitch.org/10647 Configuration: (LIBPRI SPAN) <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="7"/> </settings> <libpri_spans> <span name="PRI_1"> <param name="node" value="cpe"/> <param name="switch" value="euroisdn"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </libpri_spans> </configuration> Log while starting freeswitch: http://pastebin.freeswitch.org/10648 Log while making a call: http://pastebin.freeswitch.org/10649 On Sat, Oct 10, 2009 at 10:39 PM, Michael Collins <msc@freeswitch.org>wrote:
Okay, please go to pastebin.freeswitch.org and paste your openzap.conf.xml file. Also, paste the ENTIRE debug log from a call from start to finish. Telling us that you see INVALID_IE_CONTENTS doesn't help if we don't know what the information element contains. Finally, turn on PRI debugging and make another test call and pastebin that debug log as well. The debug will show details about the communications between your machine and the carrier. Instructions for turning on debugging for libpri are found in the OpenZAP wiki page in the same place where the libpri instructions are located.
Put the pastebin number in this email thread and then we'll go have a look.
Thanks, MC
On Sat, Oct 10, 2009 at 6:47 AM, lakshmanan ganapathy < lakindia89@gmail.com> wrote:
Hi, I've tried with the following dialplan(After making the changes that are recommended). But still I got INVALID_IE_CONTENTS error.
Another thing is, if I use prispan configuration, I'm able to make outgoing calls. But if I use the libpri span configuration I'm not able to make outgoing calls, which says INVALID_IE_CONTENTS.
I've been struck with this problem for the past 1 week. Any solution to this???
On Fri, Oct 9, 2009 at 6:06 PM, <Russell.Mosemann@cune.org> wrote:
lakshmanan ganapathy <lakindia89@gmail.com> said:
But still I'm facing problem with the outgoing call. It says INVALID_IE_CONTENTS. What might be the issue? Even I tried the following dialplan to call by using bridge. <extension name="outgoing-fxo"> <condition field="destination_number" expression="^(\d{10})$"> <action application="answer"/> <action application="bridge" data="openzap/1/1/${dialed_ext}"/>
Does "answer" need to be called here? I haven't used an fxo. So, I don't know. What value does $dialed_ext have? If you want to use the number matched in the condition, then it should be
openzap/1/1/$1
-- Russell Mosemann
________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Lak, Okay I will need a little bit of time to dig into the IE's and what they contain. In the meantime can you tell me who the carrier is? I'd like to find out if they have some specific requirements. The fact that it doesn't work with libpri surprises me because that would mean that Asterisk systems would probably not work with this carrier as well. BTW, thanks for the very complete pastebin entries. :) -MC
We are using Reliance as the Carrier. I think, with this same Reliance carrier, in my office, they are able to make outgoing calls through asterisk+libpri. On Tue, Oct 13, 2009 at 12:19 AM, Michael Collins <msc@freeswitch.org>wrote:
Lak,
Okay I will need a little bit of time to dig into the IE's and what they contain. In the meantime can you tell me who the carrier is? I'd like to find out if they have some specific requirements. The fact that it doesn't work with libpri surprises me because that would mean that Asterisk systems would probably not work with this carrier as well.
BTW, thanks for the very complete pastebin entries. :) -MC
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Oct 13, 2009, at 6:45 AM, lakshmanan ganapathy <lakindia89@gmail.com> wrote:
We are using Reliance as the Carrier. I think, with this same Reliance carrier, in my office, they are able to make outgoing calls through asterisk+libpri.
If that's the case I would be very interested in seeing a pri debug from a working call on an asterisk box. It might give us a clue as to what is not working. -MC
On Tue, Oct 13, 2009 at 12:19 AM, Michael Collins <msc@freeswitch.org> wrote: Lak,
Okay I will need a little bit of time to dig into the IE's and what they contain. In the meantime can you tell me who the carrier is? I'd like to find out if they have some specific requirements. The fact that it doesn't work with libpri surprises me because that would mean that Asterisk systems would probably not work with this carrier as well.
BTW, thanks for the very complete pastebin entries. :) -MC
But that setup is not there right now. It was an year back they used that. I'll try to make those setup and send you the log. I think it may take some 2 days time, and I'm not very familiar with asterisk. In the mean time, I request you to kindly go-through freeswitch debug log. You may still get some clue. On Tue, Oct 13, 2009 at 9:16 PM, Michael S Collins <msc@freeswitch.org>wrote:
On Oct 13, 2009, at 6:45 AM, lakshmanan ganapathy <lakindia89@gmail.com> wrote:
We are using Reliance as the Carrier. I think, with this same Reliance carrier, in my office, they are able to make outgoing calls through asterisk+libpri.
If that's the case I would be very interested in seeing a pri debug from a working call on an asterisk box. It might give us a clue as to what is not working. -MC
On Tue, Oct 13, 2009 at 12:19 AM, Michael Collins < <msc@freeswitch.org> msc@freeswitch.org> wrote:
Lak,
Okay I will need a little bit of time to dig into the IE's and what they contain. In the meantime can you tell me who the carrier is? I'd like to find out if they have some specific requirements. The fact that it doesn't work with libpri surprises me because that would mean that Asterisk systems would probably not work with this carrier as well.
BTW, thanks for the very complete pastebin entries. :) -MC
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi. I made the setup quickly with one of my colleague, and here is the debug log given by asterisk Steps done by me : + Call Made from 04443902743 to 04439114600 + When call lands to 04439114600, I just route it to 09176454982. *CLI> *CLI> *CLI> pri debug span 1 Enabled debugging on span 1 *CLI> *CLI> *CLI> *CLI> < Protocol Discriminator: Q.931 (8) len=41 < Call Ref: len= 2 (reference 21/0x15) (Originator) < Message type: SETUP (5) < [a1] < Sending Complete (len= 1) < [04 03 80 90 a3] < Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) < Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) < User information layer 1: A-Law (35) < [18 03 a1 83 9f] < Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Preferred Dchan: 0 < ChanSel: As indicated in following octets < Ext: 1 Coding: 0 Number Specified Channel Type: 3 < Ext: 1 Channel: 31 ] < [6c 0c 01 81 34 34 34 33 39 30 32 37 34 33] < Calling Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) < Presentation: Presentation permitted, user number passed network screening (1) '4443902743' ] < [70 09 c1 33 39 31 31 34 36 30 30] < Called Number (len=11) [ Ext: 1 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '39114600' ] -- Making new call for cr 21 -- Processing Q.931 Call Setup -- Processing IE 161 (cs0, Sending Complete) -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 108 (cs0, Calling Party Number) -- Processing IE 112 (cs0, Called Party Number) q931.c:3504 q931_receive: call 21 on channel 31 enters state 6 (Call Present) q931.c:2769 q931_call_proceeding: call 21 on channel 31 enters state 9 (Incoming Call Proceeding)
Protocol Discriminator: Q.931 (8) len=10 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 9f] Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0 ChanSel: As indicated in following octets Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 31 ]
-- Accepting call from '4443902743' to '39114600' on channel 0/31, span 1 -- Executing [39114600@incoming-from-pri:1] NoOp("Zap/31-1", "FMS Call Extn:39114600:| CID:: <cid::>| Channel:Zap/31-1:| ") in new stack -- Executing [39114600@incoming-from-pri:2] Dial("Zap/31-1", "Zap/g1/w09176454982||rj") in new stack -- Making new call for cr 32770 -- Requested transfer capability: 0x00 - SPEECH
Protocol Discriminator: Q.931 (8) len=43 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: SETUP (5) [04 03 80 90 a3] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) 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: As indicated in following octets Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 1 ] [6c 0c 00 81 34 34 34 33 39 30 32 37 34 33] Calling Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) Presentation: Presentation permitted, user number passed network screening (1) '4443902743' ] [70 0c 80 30 39 31 37 36 34 35 34 39 38 32] Called Number (len=14) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '09176454982' ]
q931.c:3087 q931_setup: call 32770 on channel 1 enters state 1 (Call Initiated) -- Called g1/w09176454982 q931.c:2797 q931_alerting: call 21 on channel 31 enters state 7 (Call Received)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: ALERTING (1) [1e 02 81 88] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ]
< Protocol Discriminator: Q.931 (8) len=10 < Call Ref: len= 2 (reference 2/0x2) (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: As indicated in following octets < Ext: 1 Coding: 0 Number Specified Channel Type: 3 < Ext: 1 Channel: 1 ] -- Processing IE 24 (cs0, Channel Identification) q931.c:3636 q931_receive: call 32770 on channel 1 enters state 3 (Outgoing call Proceeding) -- Zap/1-1 is proceeding passing it to Zap/31-1 < Protocol Discriminator: Q.931 (8) len=13 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: ALERTING (1) < [1e 02 84 88] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4) < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] < [1e 02 84 82] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4) < Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ] -- Processing IE 30 (cs0, Progress Indicator) -- Processing IE 30 (cs0, Progress Indicator) q931.c:3549 q931_receive: call 32770 on channel 1 enters state 4 (Call Delivered) -- Zap/1-1 is ringing < Protocol Discriminator: Q.931 (8) len=9 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: PROGRESS (3) < [1e 02 84 84] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4) < Ext: 1 Progress Description: Unknown (4) ] -- Processing IE 30 (cs0, Progress Indicator) -- Zap/1-1 is making progress passing it to Zap/31-1 < Protocol Discriminator: Q.931 (8) len=9 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: PROGRESS (3) < [1e 02 84 88] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4) < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] -- Processing IE 30 (cs0, Progress Indicator) -- Zap/1-1 is making progress passing it to Zap/31-1 < Protocol Discriminator: Q.931 (8) len=19 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: CONNECT (7) < [4c 0c 01 83 39 31 37 36 34 35 34 39 38 32] < Connected Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) < Ext: 1 Presentation: Presentation allowed of network provided number (3) '9176454982' ] -- Processing IE 76 (cs0, Connected Number) q931.c:3579 q931_receive: call 32770 on channel 1 enters state 10 (Active)
Protocol Discriminator: Q.931 (8) len=5 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: CONNECT ACKNOWLEDGE (15)
-- Zap/1-1 answered Zap/31-1 q931.c:2904 q931_connect: call 21 on channel 31 enters state 8 (Connect Request)
Protocol Discriminator: Q.931 (8) len=14 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: CONNECT (7) [18 03 a9 83 9f] Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0 ChanSel: As indicated in following octets Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 31 ] [1e 02 81 82] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ]
-- Native bridging Zap/31-1 and Zap/1-1 < Protocol Discriminator: Q.931 (8) len=5 < Call Ref: len= 2 (reference 21/0x15) (Originator) < Message type: CONNECT ACKNOWLEDGE (15) q931.c:3664 q931_receive: call 21 on channel 31 enters state 10 (Active) < Protocol Discriminator: Q.931 (8) len=9 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: DISCONNECT (69) < [08 02 80 90] < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0) < Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] -- Processing IE 8 (cs0, Cause) q931.c:3779 q931_receive: call 32770 on channel 1 enters state 12 (Disconnect Indication) -- Channel 0/1, span 1 got hangup request, cause 16 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request q931.c:2920 q931_release: call 32770 on channel 1 enters state 19 (Release Request)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: RELEASE (77) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Hungup 'Zap/1-1' == Spawn extension (incoming-from-pri, 39114600, 2) exited non-zero on 'Zap/31-1' -- Executing [h@incoming-from-pri:1] Hangup("Zap/31-1", "") in new stack == Spawn extension (incoming-from-pri, h, 1) exited non-zero on 'Zap/31-1' NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Active q931.c:2968 q931_disconnect: call 21 on channel 31 enters state 11 (Disconnect Request)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: DISCONNECT (69) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Hungup 'Zap/31-1' < Protocol Discriminator: Q.931 (8) len=5 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: RELEASE COMPLETE (90) q931.c:3719 q931_receive: call 32770 on channel 1 enters state 0 (Null) NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null < Protocol Discriminator: Q.931 (8) len=5 < Call Ref: len= 2 (reference 21/0x15) (Originator) < Message type: RELEASE (77) q931.c:3754 q931_receive: call 21 on channel 31 enters state 0 (Null) NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: RELEASE COMPLETE (90) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null On Tue, Oct 13, 2009 at 9:16 PM, Michael S Collins <msc@freeswitch.org>wrote:
On Oct 13, 2009, at 6:45 AM, lakshmanan ganapathy <lakindia89@gmail.com> wrote:
We are using Reliance as the Carrier. I think, with this same Reliance carrier, in my office, they are able to make outgoing calls through asterisk+libpri.
If that's the case I would be very interested in seeing a pri debug from a working call on an asterisk box. It might give us a clue as to what is not working. -MC
On Tue, Oct 13, 2009 at 12:19 AM, Michael Collins < <msc@freeswitch.org> msc@freeswitch.org> wrote:
Lak,
Okay I will need a little bit of time to dig into the IE's and what they contain. In the meantime can you tell me who the carrier is? I'd like to find out if they have some specific requirements. The fact that it doesn't work with libpri surprises me because that would mean that Asterisk systems would probably not work with this carrier as well.
BTW, thanks for the very complete pastebin entries. :) -MC
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Lak, Okay, it stood out right away: FS is trying u-law but Asterisk is trying A-law. I'm not sure where the codec for openzap gets selected but you can try modifying this line in vars.xml: <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMU,PCMA,GSM"/> Try putting PCMA first. Also, I've never tried this but perhaps in your dialplan you can set absolute_codec_string to PCMA. I'm very interesting in hearing about the results. Please try them as soon as you can and report back. Thanks, MC On Tue, Oct 13, 2009 at 10:34 PM, lakshmanan ganapathy <lakindia89@gmail.com
wrote:
Hi. I made the setup quickly with one of my colleague, and here is the debug log given by asterisk
Steps done by me : + Call Made from 04443902743 to 04439114600 + When call lands to 04439114600, I just route it to 09176454982.
*CLI> *CLI> *CLI> pri debug span 1 Enabled debugging on span 1 *CLI> *CLI> *CLI> *CLI> < Protocol Discriminator: Q.931 (8) len=41 < Call Ref: len= 2 (reference 21/0x15) (Originator)
< Message type: SETUP (5) < [a1] < Sending Complete (len= 1) < [04 03 80 90 a3] < Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) < Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
< User information layer 1: A-Law (35) < [18 03 a1 83 9f] < Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Preferred Dchan: 0 < ChanSel: As indicated in following octets
< Ext: 1 Coding: 0 Number Specified Channel Type: 3 < Ext: 1 Channel: 31 ] < [6c 0c 01 81 34 34 34 33 39 30 32 37 34 33] < Calling Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Presentation: Presentation permitted, user number passed network screening (1) '4443902743' ] < [70 09 c1 33 39 31 31 34 36 30 30] < Called Number (len=11) [ Ext: 1 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '39114600' ]
-- Making new call for cr 21 -- Processing Q.931 Call Setup -- Processing IE 161 (cs0, Sending Complete) -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number) q931.c:3504 q931_receive: call 21 on channel 31 enters state 6 (Call Present) q931.c:2769 q931_call_proceeding: call 21 on channel 31 enters state 9 (Incoming Call Proceeding)
Protocol Discriminator: Q.931 (8) len=10 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 9f] Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0 ChanSel: As indicated in following octets Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 31 ]
-- Accepting call from '4443902743' to '39114600' on channel 0/31, span 1 -- Executing [39114600@incoming-from-pri:1] NoOp("Zap/31-1", "FMS Call Extn:39114600:| CID::| Channel:Zap/31-1:| ") in new stack
-- Executing [39114600@incoming-from-pri:2] Dial("Zap/31-1", "Zap/g1/w09176454982||rj") in new stack -- Making new call for cr 32770 -- Requested transfer capability: 0x00 - SPEECH
Protocol Discriminator: Q.931 (8) len=43 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: SETUP (5) [04 03 80 90 a3] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) 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: As indicated in following octets Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 1 ] [6c 0c 00 81 34 34 34 33 39 30 32 37 34 33] Calling Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) Presentation: Presentation permitted, user number passed network screening (1) '4443902743' ] [70 0c 80 30 39 31 37 36 34 35 34 39 38 32] Called Number (len=14) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '09176454982' ]
q931.c:3087 q931_setup: call 32770 on channel 1 enters state 1 (Call Initiated)
-- Called g1/w09176454982 q931.c:2797 q931_alerting: call 21 on channel 31 enters state 7 (Call Received)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: ALERTING (1) [1e 02 81 88] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ]
< Protocol Discriminator: Q.931 (8) len=10 < Call Ref: len= 2 (reference 2/0x2) (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: As indicated in following octets < Ext: 1 Coding: 0 Number Specified Channel Type: 3 < Ext: 1 Channel: 1 ] -- Processing IE 24 (cs0, Channel Identification)
q931.c:3636 q931_receive: call 32770 on channel 1 enters state 3 (Outgoing call Proceeding) -- Zap/1-1 is proceeding passing it to Zap/31-1 < Protocol Discriminator: Q.931 (8) len=13 < Call Ref: len= 2 (reference 2/0x2) (Terminator)
< Message type: ALERTING (1) < [1e 02 84 88] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4) < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ]
< [1e 02 84 82] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4) < Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ]
-- Processing IE 30 (cs0, Progress Indicator) -- Processing IE 30 (cs0, Progress Indicator) q931.c:3549 q931_receive: call 32770 on channel 1 enters state 4 (Call Delivered) -- Zap/1-1 is ringing < Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: PROGRESS (3) < [1e 02 84 84] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4)
< Ext: 1 Progress Description: Unknown (4) ] -- Processing IE 30 (cs0, Progress Indicator) -- Zap/1-1 is making progress passing it to Zap/31-1 < Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: PROGRESS (3) < [1e 02 84 88] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4)
< Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] -- Processing IE 30 (cs0, Progress Indicator) -- Zap/1-1 is making progress passing it to Zap/31-1
< Protocol Discriminator: Q.931 (8) len=19 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: CONNECT (7) < [4c 0c 01 83 39 31 37 36 34 35 34 39 38 32] < Connected Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Ext: 1 Presentation: Presentation allowed of network provided number (3) '9176454982' ] -- Processing IE 76 (cs0, Connected Number) q931.c:3579 q931_receive: call 32770 on channel 1 enters state 10 (Active)
Protocol Discriminator: Q.931 (8) len=5 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: CONNECT ACKNOWLEDGE (15)
-- Zap/1-1 answered Zap/31-1 q931.c:2904 q931_connect: call 21 on channel 31 enters state 8 (Connect Request)
Protocol Discriminator: Q.931 (8) len=14 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: CONNECT (7) [18 03 a9 83 9f] Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0 ChanSel: As indicated in following octets Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 31 ] [1e 02 81 82] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ]
-- Native bridging Zap/31-1 and Zap/1-1 < Protocol Discriminator: Q.931 (8) len=5 < Call Ref: len= 2 (reference 21/0x15) (Originator) < Message type: CONNECT ACKNOWLEDGE (15)
q931.c:3664 q931_receive: call 21 on channel 31 enters state 10 (Active) < Protocol Discriminator: Q.931 (8) len=9 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: DISCONNECT (69) < [08 02 80 90]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0) < Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] -- Processing IE 8 (cs0, Cause) q931.c:3779 q931_receive: call 32770 on channel 1 enters state 12 (Disconnect Indication)
-- Channel 0/1, span 1 got hangup request, cause 16 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request q931.c:2920 q931_release: call 32770 on channel 1 enters state 19 (Release Request)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: RELEASE (77) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Hungup 'Zap/1-1' == Spawn extension (incoming-from-pri, 39114600, 2) exited non-zero on 'Zap/31-1'
-- Executing [h@incoming-from-pri:1] Hangup("Zap/31-1", "") in new stack == Spawn extension (incoming-from-pri, h, 1) exited non-zero on 'Zap/31-1' NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Active
q931.c:2968 q931_disconnect: call 21 on channel 31 enters state 11 (Disconnect Request)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: DISCONNECT (69) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Hungup 'Zap/31-1' < Protocol Discriminator: Q.931 (8) len=5
< Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: RELEASE COMPLETE (90) q931.c:3719 q931_receive: call 32770 on channel 1 enters state 0 (Null) NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null < Protocol Discriminator: Q.931 (8) len=5 < Call Ref: len= 2 (reference 21/0x15) (Originator) < Message type: RELEASE (77) q931.c:3754 q931_receive: call 21 on channel 31 enters state 0 (Null)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: RELEASE COMPLETE (90) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
On Tue, Oct 13, 2009 at 9:16 PM, Michael S Collins <msc@freeswitch.org>wrote:
On Oct 13, 2009, at 6:45 AM, lakshmanan ganapathy <lakindia89@gmail.com> wrote:
We are using Reliance as the Carrier. I think, with this same Reliance carrier, in my office, they are able to make outgoing calls through asterisk+libpri.
If that's the case I would be very interested in seeing a pri debug from a working call on an asterisk box. It might give us a clue as to what is not working. -MC
On Tue, Oct 13, 2009 at 12:19 AM, Michael Collins < <msc@freeswitch.org> msc@freeswitch.org> wrote:
Lak,
Okay I will need a little bit of time to dig into the IE's and what they contain. In the meantime can you tell me who the carrier is? I'd like to find out if they have some specific requirements. The fact that it doesn't work with libpri surprises me because that would mean that Asterisk systems would probably not work with this carrier as well.
BTW, thanks for the very complete pastebin entries. :) -MC
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi, Tried setting PCMA as first parameter in vars.xml, no use. Still I got the same error. Tried setting the absolute_codec_string to PCMA, but got the same error. But I tried with a another parameter in openzap.conf.xml, which I got from the following thread http://www.nabble.com/Problem-dialing-out-via-E1-to22479047.html#a22626383 <param name="l1" value="alaw"/> After that I was able to make outgoing call, with the dialplan that I've. But I don't know why setting PCMA has not worked. Have any guess??? I planned to document this in the wiki. I was struggling to originate a call from the CLI. originate openzap/1/1/9952248266 openzap/1/1/9952248266 says "No route. Aborting". Have to find a way for this. I sincerely thank you for your valuable time and effort on this matter. On Wed, Oct 14, 2009 at 11:33 AM, Michael Collins <msc@freeswitch.org>wrote:
Lak,
Okay, it stood out right away: FS is trying u-law but Asterisk is trying A-law. I'm not sure where the codec for openzap gets selected but you can try modifying this line in vars.xml:
<X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMU,PCMA,GSM"/>
Try putting PCMA first. Also, I've never tried this but perhaps in your dialplan you can set absolute_codec_string to PCMA. I'm very interesting in hearing about the results. Please try them as soon as you can and report back.
Thanks, MC
On Tue, Oct 13, 2009 at 10:34 PM, lakshmanan ganapathy < lakindia89@gmail.com> wrote:
Hi. I made the setup quickly with one of my colleague, and here is the debug log given by asterisk
Steps done by me : + Call Made from 04443902743 to 04439114600 + When call lands to 04439114600, I just route it to 09176454982.
*CLI> *CLI> *CLI> pri debug span 1 Enabled debugging on span 1 *CLI> *CLI> *CLI> *CLI> < Protocol Discriminator: Q.931 (8) len=41 < Call Ref: len= 2 (reference 21/0x15) (Originator)
< Message type: SETUP (5) < [a1] < Sending Complete (len= 1) < [04 03 80 90 a3] < Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) < Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
< User information layer 1: A-Law (35) < [18 03 a1 83 9f] < Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Preferred Dchan: 0 < ChanSel: As indicated in following octets
< Ext: 1 Coding: 0 Number Specified Channel Type: 3 < Ext: 1 Channel: 31 ] < [6c 0c 01 81 34 34 34 33 39 30 32 37 34 33] < Calling Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Presentation: Presentation permitted, user number passed network screening (1) '4443902743' ] < [70 09 c1 33 39 31 31 34 36 30 30] < Called Number (len=11) [ Ext: 1 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '39114600' ]
-- Making new call for cr 21 -- Processing Q.931 Call Setup -- Processing IE 161 (cs0, Sending Complete) -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number) q931.c:3504 q931_receive: call 21 on channel 31 enters state 6 (Call Present) q931.c:2769 q931_call_proceeding: call 21 on channel 31 enters state 9 (Incoming Call Proceeding)
Protocol Discriminator: Q.931 (8) len=10 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: CALL PROCEEDING (2)
[18 03 a9 83 9f] Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0 ChanSel: As indicated in following octets
Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 31 ]
-- Accepting call from '4443902743' to '39114600' on channel 0/31, span 1 -- Executing [39114600@incoming-from-pri:1] NoOp("Zap/31-1", "FMS Call Extn:39114600:| CID::| Channel:Zap/31-1:| ") in new stack
-- Executing [39114600@incoming-from-pri:2] Dial("Zap/31-1", "Zap/g1/w09176454982||rj") in new stack -- Making new call for cr 32770 -- Requested transfer capability: 0x00 - SPEECH
Protocol Discriminator: Q.931 (8) len=43 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: SETUP (5) [04 03 80 90 a3] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
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: As indicated in following octets Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 1 ] [6c 0c 00 81 34 34 34 33 39 30 32 37 34 33] Calling Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
Presentation: Presentation permitted, user number passed network screening (1) '4443902743' ] [70 0c 80 30 39 31 37 36 34 35 34 39 38 32] Called Number (len=14) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '09176454982' ]
q931.c:3087 q931_setup: call 32770 on channel 1 enters state 1 (Call Initiated)
-- Called g1/w09176454982 q931.c:2797 q931_alerting: call 21 on channel 31 enters state 7 (Call Received)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: ALERTING (1) [1e 02 81 88] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ]
< Protocol Discriminator: Q.931 (8) len=10 < Call Ref: len= 2 (reference 2/0x2) (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: As indicated in following octets < Ext: 1 Coding: 0 Number Specified Channel Type: 3 < Ext: 1 Channel: 1 ] -- Processing IE 24 (cs0, Channel Identification)
q931.c:3636 q931_receive: call 32770 on channel 1 enters state 3 (Outgoing call Proceeding) -- Zap/1-1 is proceeding passing it to Zap/31-1 < Protocol Discriminator: Q.931 (8) len=13 < Call Ref: len= 2 (reference 2/0x2) (Terminator)
< Message type: ALERTING (1) < [1e 02 84 88] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4) < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ]
< [1e 02 84 82] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4) < Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ]
-- Processing IE 30 (cs0, Progress Indicator) -- Processing IE 30 (cs0, Progress Indicator) q931.c:3549 q931_receive: call 32770 on channel 1 enters state 4 (Call Delivered) -- Zap/1-1 is ringing < Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: PROGRESS (3) < [1e 02 84 84] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4)
< Ext: 1 Progress Description: Unknown (4) ] -- Processing IE 30 (cs0, Progress Indicator) -- Zap/1-1 is making progress passing it to Zap/31-1 < Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: PROGRESS (3) < [1e 02 84 88] < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4)
< Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] -- Processing IE 30 (cs0, Progress Indicator) -- Zap/1-1 is making progress passing it to Zap/31-1
< Protocol Discriminator: Q.931 (8) len=19 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: CONNECT (7) < [4c 0c 01 83 39 31 37 36 34 35 34 39 38 32] < Connected Number (len=14) [ Ext: 0 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Ext: 1 Presentation: Presentation allowed of network provided number (3) '9176454982' ] -- Processing IE 76 (cs0, Connected Number) q931.c:3579 q931_receive: call 32770 on channel 1 enters state 10 (Active)
Protocol Discriminator: Q.931 (8) len=5 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: CONNECT ACKNOWLEDGE (15)
-- Zap/1-1 answered Zap/31-1 q931.c:2904 q931_connect: call 21 on channel 31 enters state 8 (Connect Request)
Protocol Discriminator: Q.931 (8) len=14
Call Ref: len= 2 (reference 21/0x15) (Terminator) Message type: CONNECT (7) [18 03 a9 83 9f] Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0 ChanSel: As indicated in following octets Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 31 ] [1e 02 81 82] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ]
-- Native bridging Zap/31-1 and Zap/1-1 < Protocol Discriminator: Q.931 (8) len=5 < Call Ref: len= 2 (reference 21/0x15) (Originator) < Message type: CONNECT ACKNOWLEDGE (15)
q931.c:3664 q931_receive: call 21 on channel 31 enters state 10 (Active) < Protocol Discriminator: Q.931 (8) len=9 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: DISCONNECT (69) < [08 02 80 90]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0) < Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] -- Processing IE 8 (cs0, Cause)
q931.c:3779 q931_receive: call 32770 on channel 1 enters state 12 (Disconnect Indication)
-- Channel 0/1, span 1 got hangup request, cause 16 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request q931.c:2920 q931_release: call 32770 on channel 1 enters state 19 (Release Request)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 2/0x2) (Originator) Message type: RELEASE (77) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Hungup 'Zap/1-1' == Spawn extension (incoming-from-pri, 39114600, 2) exited non-zero on 'Zap/31-1'
-- Executing [h@incoming-from-pri:1] Hangup("Zap/31-1", "") in new stack == Spawn extension (incoming-from-pri, h, 1) exited non-zero on 'Zap/31-1' NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Active
q931.c:2968 q931_disconnect: call 21 on channel 31 enters state 11 (Disconnect Request)
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator)
Message type: DISCONNECT (69) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Hungup 'Zap/31-1' < Protocol Discriminator: Q.931 (8) len=5
< Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: RELEASE COMPLETE (90) q931.c:3719 q931_receive: call 32770 on channel 1 enters state 0 (Null) NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null < Protocol Discriminator: Q.931 (8) len=5 < Call Ref: len= 2 (reference 21/0x15) (Originator) < Message type: RELEASE (77) q931.c:3754 q931_receive: call 21 on channel 31 enters state 0 (Null)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request
Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 21/0x15) (Terminator)
Message type: RELEASE COMPLETE (90) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
On Tue, Oct 13, 2009 at 9:16 PM, Michael S Collins <msc@freeswitch.org>wrote:
On Oct 13, 2009, at 6:45 AM, lakshmanan ganapathy <lakindia89@gmail.com> wrote:
We are using Reliance as the Carrier. I think, with this same Reliance carrier, in my office, they are able to make outgoing calls through asterisk+libpri.
If that's the case I would be very interested in seeing a pri debug from a working call on an asterisk box. It might give us a clue as to what is not working. -MC
On Tue, Oct 13, 2009 at 12:19 AM, Michael Collins < <msc@freeswitch.org> msc@freeswitch.org> wrote:
Lak,
Okay I will need a little bit of time to dig into the IE's and what they contain. In the meantime can you tell me who the carrier is? I'd like to find out if they have some specific requirements. The fact that it doesn't work with libpri surprises me because that would mean that Asterisk systems would probably not work with this carrier as well.
BTW, thanks for the very complete pastebin entries. :) -MC
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
lakshmanan ganapathy <lakindia89@gmail.com> said:
I was struggling to originate a call from the CLI. originate openzap/1/1/9952248266 openzap/1/1/9952248266 says "No route. Aborting".
The syntax is incorrect. originate openzap/1/1/9952248266 <extension> For example, openzap/1/1/9952248266 1234 See the wiki for details about originate. I think I included a link in a previous message. -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
participants (5)
-
lakshmanan ganapathy
-
Michael Collins
-
Michael S Collins
-
Moises Silva
-
Russell.Mosemann＠cune.org