Connecting FS to Hicom 300
We have connected FS to a Siemens Hicomm 300. As you might guess, it's not working right. Here is what we are working with. Dell 1750 (dual socket, dual core Xeon 2.8GHz) Debian 5 FS (15029), OpenZAP (without libpri) TE110P T1 card (Zaptel driver) Handles 71xx extensions Siemens Hicom 300 TMDN64P T1 card Handles 74xx extensions We are pretty much using the stock FS configuration, yet, because we're trying to get this to work. I have configured OpenZAP and the associated files like the examples on the wiki (see below) to work with a PRI T1. There are 23 B channels and 1 D channel. The Zaptel side looks fine. OpenZAP is able to open the channels when FS boots. So far, so good. When a call is made from 74xx (Rolmphone 624) to 71xx (X-Lite 4.0 beta from CounterPath on an office PC), X-Lite rings. The call can be answered, and the conversation sounds fine. That means the routing, registration and authorization are working on the network between X-Lite and FS. It also means that FS is able to communicate with the Hicom over the T1. Great. When the caller presses the transfer button on the 74xx phone, the Hicom sends a message over the D channel, and the call is disconnected (watching with fs_cli). As best I can interpret the bytes in the message, the Hicom sends a disconnect message when 74xx presses the transfer key. In order to call 74xx, I created dialplan/default/02_hicom.xml. The contents are <include> <extension name="hicom"> <condition field="destination_number" expression="^(74\d{2})$"> <action application="bridge" data="openzap/1/a/$1"/> </condition> </extension> </include> If a call is made from 71xx to 74xx, the Hicom forwards the call to the switchboard with "7100->7445 connection not possible" (or whatever extensions) in the switchboard display. 1. Are these issues related to the way I have configured FS? The Hicom is maintained by the local phone company. I do not have access to view or configure the T1 card on the Hicom. According to the phone guy, there isn't anything else that needs to be configured on the Hicom. He believes that if 74xx can call 71xx, then 71xx should be able to call 74xx. I suspect that something more needs to be done on the Hicom in order to accept calls from FS and bridge/transfer them to a local extension on the Hicom. It's as if the Hicom doesn't know how or is not permitted to route incoming calls on the T1 to local extensions. I have no way to know, though. I'm hoping someone else has connected FS to a Hicom 300 and can provide configuration details. If I could tell the phone guy something like, "You need to look at <this>," that would help him out. 2. Should I receive CID/ANI from the Hicom? X-Lite displays "OpenZAP" as the call and "1" as Other when the call comes in, which is the information for the endpoint. Is there something I need to do in the FS configuration to capture CID/ANI information from the Hicom and make it available (or is it not being provided by the Hicom)? 3. When dialing from the Rolmphone is there a way for FS to send the called name back to the Hicom for it to appear in the display? When dialing 74xx to 74xx, of course, it shows the called number and name in the display. We also have a HiPath 4000 connected to the Hicom 300. When dialing an extension on the HiPath from the Hicom, the HiPath ships the called name back to the Hicom for display on the phone. It would be nice to do that from FS. Let me know if you need additional information. Thanks for any pointers or insight as to how things work. -- Russell Mosemann openzap.conf [span zt PRI_1] name => OpenZAP number => 1 trunk_type => t1 b-channel => 1-23 d-channel => 24 zt.conf [defaults] codec_ms => 20 wink_ms => 150 flash_ms => 750 echo_cancel_level => 64 rxgain => 0.0 txgain => 0.0 openzap.conf <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="0"/> <!--<param name="hold-music" value="$${moh_uri}"/>--> <!--<param name="enable-analog-option" value="call-swap"/>--> <!--<param name="enable-analog-option" value="3-way"/>--> </settings> <pri_spans> <span name="PRI_1"> <param name="q921loglevel" value="alert"/> <param name="q931loglevel" value="alert"/> <param name="mode" value="user"/> <param name="dialect" value="national"/> <param name="dialplan" value="XML"/> <param name="context" value="public"/> </span> </pri_spans> </configuration> zaptel.conf # Span 1: WCT1/0 "Digium Wildcard TE110P T1/E1 Card 0" (MASTER) span=1,1,0,esf,b8zs # termtype: te bchan=1-23 dchan=24 # Global data loadzone = us defaultzone = us ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
You might want to try the ozmod_pri instead of ozmod_isdn until the new revision of ozmod_isdn is published into the source tree. On Thu, Oct 1, 2009 at 9:37 AM, <Russell.Mosemann@cune.org> wrote:
We have connected FS to a Siemens Hicomm 300. As you might guess, it's not working right. Here is what we are working with.
Dell 1750 (dual socket, dual core Xeon 2.8GHz) Debian 5 FS (15029), OpenZAP (without libpri) TE110P T1 card (Zaptel driver) Handles 71xx extensions
Siemens Hicom 300 TMDN64P T1 card Handles 74xx extensions
We are pretty much using the stock FS configuration, yet, because we're trying to get this to work. I have configured OpenZAP and the associated files like the examples on the wiki (see below) to work with a PRI T1. There are 23 B channels and 1 D channel. The Zaptel side looks fine. OpenZAP is able to open the channels when FS boots. So far, so good.
When a call is made from 74xx (Rolmphone 624) to 71xx (X-Lite 4.0 beta from CounterPath on an office PC), X-Lite rings. The call can be answered, and the conversation sounds fine. That means the routing, registration and authorization are working on the network between X-Lite and FS. It also means that FS is able to communicate with the Hicom over the T1. Great.
When the caller presses the transfer button on the 74xx phone, the Hicom sends a message over the D channel, and the call is disconnected (watching with fs_cli). As best I can interpret the bytes in the message, the Hicom sends a disconnect message when 74xx presses the transfer key.
In order to call 74xx, I created dialplan/default/02_hicom.xml. The contents are
<include> <extension name="hicom"> <condition field="destination_number" expression="^(74\d{2})$"> <action application="bridge" data="openzap/1/a/$1"/> </condition> </extension> </include>
If a call is made from 71xx to 74xx, the Hicom forwards the call to the switchboard with "7100->7445 connection not possible" (or whatever extensions) in the switchboard display.
1. Are these issues related to the way I have configured FS?
The Hicom is maintained by the local phone company. I do not have access to view or configure the T1 card on the Hicom. According to the phone guy, there isn't anything else that needs to be configured on the Hicom. He believes that if 74xx can call 71xx, then 71xx should be able to call 74xx.
I suspect that something more needs to be done on the Hicom in order to accept calls from FS and bridge/transfer them to a local extension on the Hicom. It's as if the Hicom doesn't know how or is not permitted to route incoming calls on the T1 to local extensions. I have no way to know, though. I'm hoping someone else has connected FS to a Hicom 300 and can provide configuration details. If I could tell the phone guy something like, "You need to look at <this>," that would help him out.
2. Should I receive CID/ANI from the Hicom?
X-Lite displays "OpenZAP" as the call and "1" as Other when the call comes in, which is the information for the endpoint. Is there something I need to do in the FS configuration to capture CID/ANI information from the Hicom and make it available (or is it not being provided by the Hicom)?
3. When dialing from the Rolmphone is there a way for FS to send the called name back to the Hicom for it to appear in the display?
When dialing 74xx to 74xx, of course, it shows the called number and name in the display. We also have a HiPath 4000 connected to the Hicom 300. When dialing an extension on the HiPath from the Hicom, the HiPath ships the called name back to the Hicom for display on the phone. It would be nice to do that from FS.
Let me know if you need additional information. Thanks for any pointers or insight as to how things work.
-- Russell Mosemann
openzap.conf [span zt PRI_1] name => OpenZAP number => 1 trunk_type => t1 b-channel => 1-23 d-channel => 24
zt.conf [defaults] codec_ms => 20 wink_ms => 150 flash_ms => 750 echo_cancel_level => 64 rxgain => 0.0 txgain => 0.0
openzap.conf <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="0"/> <!--<param name="hold-music" value="$${moh_uri}"/>--> <!--<param name="enable-analog-option" value="call-swap"/>--> <!--<param name="enable-analog-option" value="3-way"/>--> </settings> <pri_spans> <span name="PRI_1"> <param name="q921loglevel" value="alert"/> <param name="q931loglevel" value="alert"/> <param name="mode" value="user"/> <param name="dialect" value="national"/> <param name="dialplan" value="XML"/> <param name="context" value="public"/> </span> </pri_spans> </configuration>
zaptel.conf # Span 1: WCT1/0 "Digium Wildcard TE110P T1/E1 Card 0" (MASTER) span=1,1,0,esf,b8zs # termtype: te bchan=1-23 dchan=24
# Global data loadzone = us defaultzone = us
________________________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Anthony Minessale <anthony.minessale@gmail.com> said:
You might want to try the ozmod_pri instead of ozmod_isdn until the new revision of ozmod_isdn is published into the source tree.
libpri took care of the problem with the transfer. Now, someone can call into FS from the Hicomm and then transfer the call to another extension on the Hicomm. A call from FS to the Hicomm still transfers to the switchboard. I'm not seeing any CID/ANI on the X-Lite. It shows up as "OpenZAP" and "1". Is there something like ngrep for the D channel of a PRI? It would be nice to see what data is being sent between FS and the Hicom. -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
there was a feature to generate a pcap from the debug logs but i forgot who posted it. On Thu, Oct 1, 2009 at 4:19 PM, <Russell.Mosemann@cune.org> wrote:
Anthony Minessale <anthony.minessale@gmail.com> said:
You might want to try the ozmod_pri instead of ozmod_isdn until the new revision of ozmod_isdn is published into the source tree.
libpri took care of the problem with the transfer. Now, someone can call into FS from the Hicomm and then transfer the call to another extension on the Hicomm.
A call from FS to the Hicomm still transfers to the switchboard. I'm not seeing any CID/ANI on the X-Lite. It shows up as "OpenZAP" and "1". Is there something like ngrep for the D channel of a PRI? It would be nice to see what data is being sent between FS and the Hicom.
-- 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On Thu, Oct 1, 2009 at 2:19 PM, <Russell.Mosemann@cune.org> wrote:
Anthony Minessale <anthony.minessale@gmail.com> said:
You might want to try the ozmod_pri instead of ozmod_isdn until the new revision of ozmod_isdn is published into the source tree.
libpri took care of the problem with the transfer. Now, someone can call into FS from the Hicomm and then transfer the call to another extension on the Hicomm.
A call from FS to the Hicomm still transfers to the switchboard. I'm not seeing any CID/ANI on the X-Lite. It shows up as "OpenZAP" and "1". Is there something like ngrep for the D channel of a PRI? It would be nice to see what data is being sent between FS and the Hicom.
I believe the "OpenZAP" and "1" are coming from your conf file: openzap.conf [span zt PRI_1] name => OpenZAP number => 1
As far as debugging with ozmod_libpri I believe the syntax is: oz libpri debug 1 all It will do a traditional libpri-style debug, just like "pri debug span 1" in Asterisk. -MC
Michael Collins <msc@freeswitch.org> said:
I believe the "OpenZAP" and "1" are coming from your conf file: openzap.conf [span zt PRI_1] name => OpenZAP number => 1
That is correct. If that information is removed, then X-Lite displays FreeSWITCH [Other: 0000000000] Are there any variables to set to get CID, or is OpenZap supposed to be filling that in?
As far as debugging with ozmod_libpri I believe the syntax is: oz libpri debug 1 all
That works. Now, I have to figure out what some of these abbreviations mean. -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
On Fri, Oct 2, 2009 at 4:48 AM, <Russell.Mosemann@cune.org> wrote:
Michael Collins <msc@freeswitch.org> said:
I believe the "OpenZAP" and "1" are coming from your conf file: openzap.conf [span zt PRI_1] name => OpenZAP number => 1
That is correct. If that information is removed, then X-Lite displays
FreeSWITCH [Other: 0000000000]
do something like: name => XYZ Corp number => 8005551212
Are there any variables to set to get CID, or is OpenZap supposed to be filling that in?
As far as debugging with ozmod_libpri I believe the syntax is: oz libpri debug 1 all
That works. Now, I have to figure out what some of these abbreviations mean.
Welcome to the wacky world of Q931. The wiki has info:
http://wiki.freeswitch.org/wiki/ISDN:_Integrated_Services_Digital_Network -MC
Michael Collins <msc@freeswitch.org> said:
do something like: name => XYZ Corp number => 8005551212
I was expecting that information to be filled with the caller name and number. It doesn't really help if someone calls from outside the business, and it looks like my business is calling me. Doesn't OpenZAP extract caller information from a PRI T1? -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
On Fri, Oct 2, 2009 at 10:24 AM, <Russell.Mosemann@cune.org> wrote:
Michael Collins <msc@freeswitch.org> said:
do something like: name => XYZ Corp number => 8005551212
I was expecting that information to be filled with the caller name and number. It doesn't really help if someone calls from outside the business, and it looks like my business is calling me. Doesn't OpenZAP extract caller information from a PRI T1?
Can you pastebin a dialplan snippet (or put it here) so I can see what you're doing? -MC
Can you pastebin a dialplan snippet (or put it here) so I can see what you're doing? -MC
It is the stock FS configuration with a small change. We're still testing things, getting them to work. This is from public.xml. It detects calls to internal 71xx extensions and transfers them. The transfer works. Do some additional variables need to be set here? <extension name="public_extensions"> <condition field="destination_number" expression="^(10[01][0-9]|71\d{2})$"> <action application="transfer" data="$1 XML default"/> </condition> </extension> -- Russell Mosemann
On Fri, Oct 2, 2009 at 11:53 AM, Russell Mosemann <Russell.Mosemann@cune.org
wrote:
Can you pastebin a dialplan snippet (or put it here) so I can see what you're doing? -MC
It is the stock FS configuration with a small change. We're still testing things, getting them to work. This is from public.xml. It detects calls to internal 71xx extensions and transfers them. The transfer works. Do some additional variables need to be set here?
<extension name="public_extensions"> <condition field="destination_number" expression="^(10[01][0-9]|71\d{2})$"> <action application="transfer" data="$1 XML default"/> </condition> </extension>
cool. can you pastebin a debug log on an incoming call? -MC
cool. can you pastebin a debug log on an incoming call? -MC
Here you go. http://pastebin.freeswitch.org/10570 One thing I notice is that in the second line, the caller number is missing. 2009-10-02 16:42:39.539736 [NOTICE] ozmod_libpri.c:772 -- Ring on channel 1:1 (from to 7100) If libpri doesn't know the number, then it's probably not being sent by the Hicomm. -- Russell Mosemann
On Fri, Oct 2, 2009 at 2:53 PM, Russell Mosemann <Russell.Mosemann@cune.org>wrote:
cool. can you pastebin a debug log on an incoming call? -MC
Here you go.
http://pastebin.freeswitch.org/10570
One thing I notice is that in the second line, the caller number is missing.
2009-10-02 16:42:39.539736 [NOTICE] ozmod_libpri.c:772 -- Ring on channel 1:1 (from to 7100)
If libpri doesn't know the number, then it's probably not being sent by the Hicomm.
Exactly. Turn on q931 debugging and try again:
oz libpri debug 1 all PB the results again and we'll check it out. -MC
Exactly. Turn on q931 debugging and try again:
oz libpri debug 1 all PB the results again and we'll check it out. -MC
Here's the next one. I'm not sure what to look for, but nothing pops out right away. http://pastebin.freeswitch.org/10571 -- Russell Mosemann
On Fri, Oct 2, 2009 at 5:54 PM, Russell Mosemann <Russell.Mosemann@cune.org>wrote:
Exactly. Turn on q931 debugging and try again:
oz libpri debug 1 all PB the results again and we'll check it out. -MC
Here's the next one. I'm not sure what to look for, but nothing pops out right away.
Confirmed: the Hicomm isn't sending anything at all in the SETUP message except the usual stuff: dialed number, channel number, etc. Does the Hicomm have any config parameters, like Caller ID presentation? -MC
Michael Collins <msc@freeswitch.org> said:
Confirmed: the Hicomm isn't sending anything at all in the SETUP message except the usual stuff: dialed number, channel number, etc. Does the Hicomm have any config parameters, like Caller ID presentation?
I believe it does, but I don't have access to the Hicom. I have to go through the phone guy. It's kind of a delicate situation. At least I have something to suggest for him to investigate. I appreciate the confirmation. -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
On Mon, Oct 5, 2009 at 10:50 AM, <Russell.Mosemann@cune.org> wrote:
Michael Collins <msc@freeswitch.org> said:
Confirmed: the Hicomm isn't sending anything at all in the SETUP message except the usual stuff: dialed number, channel number, etc. Does the Hicomm have any config parameters, like Caller ID presentation?
I believe it does, but I don't have access to the Hicom. I have to go through the phone guy. It's kind of a delicate situation. At least I have something to suggest for him to investigate. I appreciate the confirmation.
If you need proverbial ammo let me know. If he speaks Q931 then your pastebin is the ultimate proof for him that the hicom is not sending any caller ID info. In any case, I'm here if you need assistance. -MC
Michael Collins <msc@freeswitch.org> said:
If you need proverbial ammo let me know. If he speaks Q931 then your pastebin is the ultimate proof for him that the hicom is not sending any caller ID info. In any case, I'm here if you need assistance.
Heh, I have the exact opposite problem. I don't think he configured a PRI T1 before, and the debug output would be meaningless to him. He usually handles everyday "my phone doesn't work" kind of issues. I try to nudge in the right direction without being pushy. :-) -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
On Mon, Oct 5, 2009 at 12:15 PM, <Russell.Mosemann@cune.org> wrote:
Michael Collins <msc@freeswitch.org> said:
If you need proverbial ammo let me know. If he speaks Q931 then your pastebin is the ultimate proof for him that the hicom is not sending any caller ID info. In any case, I'm here if you need assistance.
Heh, I have the exact opposite problem. I don't think he configured a PRI T1 before, and the debug output would be meaningless to him. He usually handles everyday "my phone doesn't work" kind of issues. I try to nudge in the right direction without being pushy. :-)
Haha, good luck w/ that. :P -MC
participants (4)
-
Anthony Minessale
-
Michael Collins
-
Russell Mosemann
-
Russell.Mosemann＠cune.org