Hello Apologies if this is in the wrong place, I am a complete beginner at Freeswitch! Has anyone had much joy with using the above to route calls from ISDN to a SIP provider? I have setup the SMG which is a stripped down version of Freeswitch, but am struggling to work out what to configure to get this working. So far I have tried to set up an external gateway to my provider, but this hasn't appeared in the SMG Web-gui as a SIP profile. My provider doesn't required auth by the way, they have just given me an IP to connect to. Any help is greatly appreciated Kind regards Ben
Hi Ben I do it as follows. Go to File Editor -> dialplan -> default.xml Look for <extension name="to-sip"> At the very end of the extension there is a part that already shows you how to route to IP. <!-- uncomment this if you want to dial to a fixed IP addr --> <!-- <action application="bridge" data="sofia/internal/${destnumber}@192.168.1.1"/> --> So you could have something like this. <action application="set" data="sip_contact_user_replacement=${destnumber}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/${destnumber}@192.168.1.1"/> <action application="hangup" data="${originate_disposition}"/> If you need to setup a DID then you could do something like this. <extension name="to-switchboard" > <condition field="destination_number" expression="xxxxxxxx"> ( REPLACE xxxxxx with the number dialled on the PSTN) <action application="set" data="span=${sip_h_X-FreeTDM-SpanName}"/> <action application="log" data="INFO Incoming CALL for switchboard on span=${span}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/yyyyyyyyy@192.168.1.1"/> (REPLACE yyyyyy with the destination number of the SIP Phone this call needs to go to) <action application="hangup" data="${originate_disposition}"/> </condition> </extension> If your calls need to be routed through the WAN to branch locations etc and you don't want to use the default ulaw/alaw then you could force the codec on the B-Leg of the call to what ever codec you prefer. This will depend on what codecs is supported on the end devices as well as if your card supports transcoding. It could look something like this: <extension name="to-switchboard" > <condition field="destination_number" expression="xxxxxxxx"> <action application="set" data="span=${sip_h_X-FreeTDM-SpanName}"/> <action application="log" data="INFO Incoming CALL for switchboard on span=${span}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/yyyyyyyyy@192.168.1.1"/> <action application="hangup" data="{absolute_codec_string=GSM} ${originate_disposition}"/> <action application="hangup" data="${originate_disposition}"/> </condition> </extension> These are just simple examples you can use. Hope this is helpful. Regards Deon On Aug 17, 2011, at 5:32 PM, Ben Naylor wrote:
Hello
Apologies if this is in the wrong place, I am a complete beginner at Freeswitch!
Has anyone had much joy with using the above to route calls from ISDN to a SIP provider? I have setup the SMG which is a stripped down version of Freeswitch, but am struggling to work out what to configure to get this working. So far I have tried to set up an external gateway to my provider, but this hasn’t appeared in the SMG Web-gui as a SIP profile. My provider doesn’t required auth by the way, they have just given me an IP to connect to.
Any help is greatly appreciated
Kind regards
Ben
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 Deon This is great, just what I was looking for! I am in Germany implementing this over the next few days (or however long it takes), so will start to play around with it today. Many thanks for your help, very much appreciated! Regards Ben From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Deon Vermeulen Sent: 18 August 2011 07:48 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Sangoma Media Gateway Hi Ben I do it as follows. Go to File Editor -> dialplan -> default.xml Look for <extension name="to-sip"> At the very end of the extension there is a part that already shows you how to route to IP. <!-- uncomment this if you want to dial to a fixed IP addr --> <!-- <action application="bridge" data="sofia/internal/${destnumber}@192.168.1.1 <mailto:sofia/internal/$%7bdestnumber%7d@192.168.1.1> "/> --> So you could have something like this. <action application="set" data="sip_contact_user_replacement=${destnumber}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/${destnumber}@192.168.1.1 <mailto:sofia/internal/$%7bdestnumber%7d@192.168.1.1> "/> <action application="hangup" data="${originate_disposition}"/> If you need to setup a DID then you could do something like this. <extension name="to-switchboard" > <condition field="destination_number" expression="xxxxxxxx"> ( REPLACE xxxxxx with the number dialled on the PSTN) <action application="set" data="span=${sip_h_X-FreeTDM-SpanName}"/> <action application="log" data="INFO Incoming CALL for switchboard on span=${span}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/yyyyyyyyy@192.168.1.1"/> (REPLACE yyyyyy with the destination number of the SIP Phone this call needs to go to) <action application="hangup" data="${originate_disposition}"/> </condition> </extension> If your calls need to be routed through the WAN to branch locations etc and you don't want to use the default ulaw/alaw then you could force the codec on the B-Leg of the call to what ever codec you prefer. This will depend on what codecs is supported on the end devices as well as if your card supports transcoding. It could look something like this: <extension name="to-switchboard" > <condition field="destination_number" expression="xxxxxxxx"> <action application="set" data="span=${sip_h_X-FreeTDM-SpanName}"/> <action application="log" data="INFO Incoming CALL for switchboard on span=${span}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/yyyyyyyyy@192.168.1.1"/> <action application="hangup" data="{absolute_codec_string=GSM} ${originate_disposition}"/> <action application="hangup" data="${originate_disposition}"/> </condition> </extension> These are just simple examples you can use. Hope this is helpful. Regards Deon On Aug 17, 2011, at 5:32 PM, Ben Naylor wrote: Hello Apologies if this is in the wrong place, I am a complete beginner at Freeswitch! Has anyone had much joy with using the above to route calls from ISDN to a SIP provider? I have setup the SMG which is a stripped down version of Freeswitch, but am struggling to work out what to configure to get this working. So far I have tried to set up an external gateway to my provider, but this hasn't appeared in the SMG Web-gui as a SIP profile. My provider doesn't required auth by the way, they have just given me an IP to connect to. Any help is greatly appreciated Kind regards Ben 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 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3840 - Release Date: 08/17/11
Hi Ben Glad I could help. I was also very new to FS when I setup SMG and took me quite a while to figure out how SMG is put together, etc... Thanks to the excellent help and guidance from the Sangoma Support Team I could get my system up and running to my requirements. Regards Deon On Aug 18, 2011, at 8:37 AM, Ben Naylor wrote:
Hi Deon
This is great, just what I was looking for!
I am in Germany implementing this over the next few days (or however long it takes), so will start to play around with it today.
Many thanks for your help, very much appreciated!
Regards
Ben
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Deon Vermeulen Sent: 18 August 2011 07:48 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Sangoma Media Gateway
Hi Ben
I do it as follows.
Go to File Editor -> dialplan -> default.xml
Look for <extension name="to-sip">
At the very end of the extension there is a part that already shows you how to route to IP.
<!-- uncomment this if you want to dial to a fixed IP addr --> <!-- <action application="bridge" data="sofia/internal/${destnumber}@192.168.1.1"/> -->
So you could have something like this.
<action application="set" data="sip_contact_user_replacement=${destnumber}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/${destnumber}@192.168.1.1"/> <action application="hangup" data="${originate_disposition}"/>
If you need to setup a DID then you could do something like this.
<extension name="to-switchboard" > <condition field="destination_number" expression="xxxxxxxx"> ( REPLACE xxxxxx with the number dialled on the PSTN) <action application="set" data="span=${sip_h_X-FreeTDM-SpanName}"/> <action application="log" data="INFO Incoming CALL for switchboard on span=${span}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/yyyyyyyyy@192.168.1.1"/> (REPLACE yyyyyy with the destination number of the SIP Phone this call needs to go to) <action application="hangup" data="${originate_disposition}"/> </condition> </extension>
If your calls need to be routed through the WAN to branch locations etc and you don't want to use the default ulaw/alaw then you could force the codec on the B-Leg of the call to what ever codec you prefer. This will depend on what codecs is supported on the end devices as well as if your card supports transcoding.
It could look something like this:
<extension name="to-switchboard" > <condition field="destination_number" expression="xxxxxxxx"> <action application="set" data="span=${sip_h_X-FreeTDM-SpanName}"/> <action application="log" data="INFO Incoming CALL for switchboard on span=${span}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/yyyyyyyyy@192.168.1.1"/> <action application="hangup" data="{absolute_codec_string=GSM} ${originate_disposition}"/> <action application="hangup" data="${originate_disposition}"/> </condition> </extension>
These are just simple examples you can use.
Hope this is helpful.
Regards Deon
On Aug 17, 2011, at 5:32 PM, Ben Naylor wrote:
Hello
Apologies if this is in the wrong place, I am a complete beginner at Freeswitch!
Has anyone had much joy with using the above to route calls from ISDN to a SIP provider? I have setup the SMG which is a stripped down version of Freeswitch, but am struggling to work out what to configure to get this working. So far I have tried to set up an external gateway to my provider, but this hasn’t appeared in the SMG Web-gui as a SIP profile. My provider doesn’t required auth by the way, they have just given me an IP to connect to.
Any help is greatly appreciated
Kind regards
Ben
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
No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3840 - Release Date: 08/17/11
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 Deon Did you encounter any problems when editing the dialplan? I'm not 100% sure, but it would appear that whenever I try and edit default.xml dialplan, the SMG changes status to 'down' in the webgui. I then change it straight back again and it comes back up briefly. However, I've got to the point now where I can't seem to get the SMG to work again, the TDM drivers start fine, but the SMG just does not want to start. I have also check the sangomagw log file in /usr/local/smg/log/ but this seems to stop logging anything once the SMG goes down. Do you know of any other log files I could check? Also, if I were to re-install the SMG, would re-running the make/install commands just re-install over the top? As a newbie to linux I am still not sure if this is the case! J Thanks for your help. Regards Ben From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Deon Vermeulen Sent: 18 August 2011 07:48 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Sangoma Media Gateway Hi Ben I do it as follows. Go to File Editor -> dialplan -> default.xml Look for <extension name="to-sip"> At the very end of the extension there is a part that already shows you how to route to IP. <!-- uncomment this if you want to dial to a fixed IP addr --> <!-- <action application="bridge" data="sofia/internal/${destnumber}@192.168.1.1 <mailto:sofia/internal/$%7bdestnumber%7d@192.168.1.1> "/> --> So you could have something like this. <action application="set" data="sip_contact_user_replacement=${destnumber}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/${destnumber}@192.168.1.1 <mailto:sofia/internal/$%7bdestnumber%7d@192.168.1.1> "/> <action application="hangup" data="${originate_disposition}"/> If you need to setup a DID then you could do something like this. <extension name="to-switchboard" > <condition field="destination_number" expression="xxxxxxxx"> ( REPLACE xxxxxx with the number dialled on the PSTN) <action application="set" data="span=${sip_h_X-FreeTDM-SpanName}"/> <action application="log" data="INFO Incoming CALL for switchboard on span=${span}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/yyyyyyyyy@192.168.1.1"/> (REPLACE yyyyyy with the destination number of the SIP Phone this call needs to go to) <action application="hangup" data="${originate_disposition}"/> </condition> </extension> If your calls need to be routed through the WAN to branch locations etc and you don't want to use the default ulaw/alaw then you could force the codec on the B-Leg of the call to what ever codec you prefer. This will depend on what codecs is supported on the end devices as well as if your card supports transcoding. It could look something like this: <extension name="to-switchboard" > <condition field="destination_number" expression="xxxxxxxx"> <action application="set" data="span=${sip_h_X-FreeTDM-SpanName}"/> <action application="log" data="INFO Incoming CALL for switchboard on span=${span}"/> <action application="set" data="hangup_after_bridge=yes"/> <action application="bridge" data="sofia/internal/yyyyyyyyy@192.168.1.1"/> <action application="hangup" data="{absolute_codec_string=GSM} ${originate_disposition}"/> <action application="hangup" data="${originate_disposition}"/> </condition> </extension> These are just simple examples you can use. Hope this is helpful. Regards Deon On Aug 17, 2011, at 5:32 PM, Ben Naylor wrote: Hello Apologies if this is in the wrong place, I am a complete beginner at Freeswitch! Has anyone had much joy with using the above to route calls from ISDN to a SIP provider? I have setup the SMG which is a stripped down version of Freeswitch, but am struggling to work out what to configure to get this working. So far I have tried to set up an external gateway to my provider, but this hasn't appeared in the SMG Web-gui as a SIP profile. My provider doesn't required auth by the way, they have just given me an IP to connect to. Any help is greatly appreciated Kind regards Ben 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 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3840 - Release Date: 08/17/11
On Sat, Aug 20, 2011 at 6:59 PM, Ben Naylor <bnaylor@sirran.com> wrote:
I’m not 100% sure, but it would appear that whenever I try and edit default.xml dialplan, the SMG changes status to ‘down’ in the webgui. I then change it straight back again and it comes back up briefly.
The only reason I can think of for such behavior is that you have some syntax error in the XML and the gateway fails to start. See the logs /usr/local/smg/log/sangomagw.log to find out why the gateway fails to start.
However, I’ve got to the point now where I can’t seem to get the SMG to work again, the TDM drivers start fine, but the SMG just does not want to start.
I have also check the sangomagw log file in /usr/local/smg/log/ but this seems to stop logging anything once the SMG goes down.
Do you know of any other log files I could check?
Depending on the version of SMG (can't remember the details), you have /usr/local/smg/init.log or /usr/local/smg/log/init.log
Also, if I were to re-install the SMG, would re-running the make/install commands just re-install over the top? As a newbie to linux I am still not sure if this is the case! J
Latest version of smg will backup the auto-generated configuration (freetdm.conf, wanpipe etc), but will NOT backup your dialplan, that is up to you. In general I recommend you to backup your whole conf/ directory before upgrading. Moises Silva Senior Software Engineer, Software Development Manager Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R 9R6 Canada t. 1 905 474 1990 x128 | e. moy@sangoma.com
Thanks Moses It would appear that there was a slight syntax error in the dialplan that was causing the problem. This has now been rectified and the SMG is stable again. I have now got to the point where I can see the call being processed by the dialplan, but it stops at the following point - 2011-08-21 14:18:59.788464 [INFO] ftmod_sangoma_isdn_stack_rcv.c:75 [s1c17][1:18] Received SETUP (suId:1 suInstId:0 spInstId:1) 2011-08-21 14:18:59.788464 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:57 [s1c17][1:18] Processing SETUP (suId:1 suInstId:0 spInstId:1) 2011-08-21 14:18:59.788464 [INFO] ftmod_sangoma_isdn_stack_hndl.c:142 [s1c17][1:18] Incoming call: Called No:[xxxxxxx29999] Calling No:[xxxxxxxxx627] 2011-08-21 14:18:59.788464 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:194 [s1c17][1:18] Changed state from DOWN to RING 2011-08-21 14:18:59.788464 [DEBUG] ftdm_state.c:508 [s1c17][1:18] Executing state processor for RING 2011-08-21 14:18:59.788464 [DEBUG] ftmod_sangoma_isdn.c:614 [s1c17][1:18] Completed state change from DOWN to RING in 0ms 2011-08-21 14:18:59.788464 [DEBUG] ftmod_sangoma_isdn.c:625 [s1c17][1:18] processing state change to RING 2011-08-21 14:18:59.788464 [DEBUG] ftmod_sangoma_isdn.c:649 [s1c17][1:18] Sending incoming call from xxxxxxxxx627 to xxxxxxx29999 to FTDM core 2011-08-21 14:18:59.788464 [DEBUG] mod_freetdm.c:2138 got clear channel sig [START] 2011-08-21 14:18:59.788464 [DEBUG] ftdm_io.c:3077 [s1c17][1:18] Enabled software DTMF detector 2011-08-21 14:18:59.788464 [DEBUG] mod_freetdm.c:378 Set codec PCMA 20ms 2011-08-21 14:18:59.789378 [DEBUG] mod_freetdm.c:1545 Connect inbound channel FreeTDM/1:17/xxxxxxx29999 2011-08-21 14:18:59.789378 [NOTICE] switch_channel.c:811 New Channel FreeTDM/1:17/xxxxxxx29999 [79c560d7-ae19-470d-9d9a-a1ced5690c76] 2011-08-21 14:18:59.789378 [DEBUG] mod_freetdm.c:1596 Call Variable: freetdm_screening_ind=network-provided 2011-08-21 14:18:59.789378 [DEBUG] mod_freetdm.c:1596 Call Variable: freetdm_isdn.prog_ind.loc=public-net-remote-user 2011-08-21 14:18:59.789378 [DEBUG] mod_freetdm.c:1596 Call Variable: freetdm_isdn.prog_ind.descr=origination-is-non-isdn 2011-08-21 14:18:59.789378 [DEBUG] mod_freetdm.c:1596 Call Variable: freetdm_presentation_ind=presentation-allowed 2011-08-21 14:18:59.789378 [DEBUG] mod_freetdm.c:1601 (FreeTDM/1:17/xxxxxxx29999) State Change CS_NEW -> CS_INIT 2011-08-21 14:18:59.789378 [DEBUG] switch_core_session.c:1116 Send signal FreeTDM/1:17/xxxxxxx29999 [BREAK] 2011-08-21 14:18:59.789378 [DEBUG] switch_core_state_machine.c:320 (FreeTDM/1:17/xxxxxxx29999) Running State Change CS_INIT 2011-08-21 14:18:59.789378 [DEBUG] switch_core_state_machine.c:356 (FreeTDM/1:17/xxxxxxx29999) State INIT 2011-08-21 14:18:59.789378 [DEBUG] mod_freetdm.c:406 (FreeTDM/1:17/xxxxxxx29999) State Change CS_INIT -> CS_ROUTING 2011-08-21 14:18:59.789378 [DEBUG] switch_core_session.c:1116 Send signal FreeTDM/1:17/xxxxxxx29999 [BREAK] 2011-08-21 14:18:59.789378 [DEBUG] switch_core_state_machine.c:356 (FreeTDM/1:17/xxxxxxx29999) State INIT going to sleep 2011-08-21 14:18:59.789378 [DEBUG] switch_core_state_machine.c:320 (FreeTDM/1:17/xxxxxxx29999) Running State Change CS_ROUTING 2011-08-21 14:18:59.789378 [DEBUG] switch_channel.c:1660 (FreeTDM/1:17/xxxxxxx29999) Callstate Change DOWN -> RINGING 2011-08-21 14:18:59.791404 [DEBUG] switch_core_state_machine.c:359 (FreeTDM/1:17/xxxxxxx29999) State ROUTING 2011-08-21 14:18:59.791404 [DEBUG] mod_freetdm.c:431 FreeTDM/1:17/xxxxxxx29999 CHANNEL ROUTING 2011-08-21 14:18:59.791404 [DEBUG] mod_freetdm.c:434 [s1c17][1:18] Indicating PROCEED in state RING 2011-08-21 14:18:59.791404 [DEBUG] mod_freetdm.c:434 [s1c17][1:18] Changed state from RING to PROCEED 2011-08-21 14:18:59.791404 [DEBUG] ftdm_state.c:508 [s1c17][1:18] Executing state processor for PROCEED 2011-08-21 14:18:59.791404 [DEBUG] ftmod_sangoma_isdn.c:614 [s1c17][1:18] Completed state change from RING to PROCEED in 0ms 2011-08-21 14:18:59.791404 [DEBUG] ftmod_sangoma_isdn.c:625 [s1c17][1:18] processing state change to PROCEED 2011-08-21 14:18:59.791404 [INFO] ftmod_sangoma_isdn_stack_out.c:167 [s1c17][1:18] Sending PROCEED (suId:1 suInstId:1 spInstId:1 dchan:1 ces:0) 2011-08-21 14:18:59.791404 [DEBUG] switch_core_state_machine.c:77 FreeTDM/1:17/xxxxxxx29999 Standard ROUTING 2011-08-21 14:18:59.791404 [INFO] mod_dialplan_xml.c:331 Processing <xxxxxxxxx627>->xxxxxxx29999 in context from-pstn Dialplan: FreeTDM/1:17/xxxxxxx29999 parsing [from-pstn->to-sip] continue=false Dialplan: FreeTDM/1:17/xxxxxxx29999 Regex (PASS) [to-sip] destination_number(xxxxxxx29999) =~ /^(.{1,})$/ break=never Dialplan: FreeTDM/1:17/xxxxxxx29999 Action set(destnumber=xxxxxxx29999) Dialplan: FreeTDM/1:17/xxxxxxx29999 Regex (PASS) [to-sip] destination_number(xxxxxxx29999) =~ /^(.*)$/ break=on-false Dialplan: FreeTDM/1:17/xxxxxxx29999 Action set(sip_contact_user_replacement=${destnumber}) Dialplan: FreeTDM/1:17/xxxxxxx29999 Action set(hangup_after_bridge=yes) Dialplan: FreeTDM/1:17/xxxxxxx29999 Action bridge(sofia/internal/${destnumber}@x.x.x.134) Dialplan: FreeTDM/1:17/xxxxxxx29999 Action hangup(${originate_disposition}) 2011-08-21 14:18:59.793352 [DEBUG] switch_core_state_machine.c:119 (FreeTDM/1:17/xxxxxxx29999) State Change CS_ROUTING -> CS_EXECUTE 2011-08-21 14:18:59.793352 [DEBUG] switch_core_session.c:1116 Send signal FreeTDM/1:17/xxxxxxx29999 [BREAK] 2011-08-21 14:18:59.793352 [DEBUG] switch_core_state_machine.c:359 (FreeTDM/1:17/xxxxxxx29999) State ROUTING going to sleep 2011-08-21 14:18:59.793352 [DEBUG] switch_core_state_machine.c:320 (FreeTDM/1:17/xxxxxxx29999) Running State Change CS_EXECUTE 2011-08-21 14:18:59.793352 [DEBUG] switch_core_state_machine.c:366 (FreeTDM/1:17/xxxxxxx29999) State EXECUTE 2011-08-21 14:18:59.793352 [DEBUG] mod_freetdm.c:451 FreeTDM/1:17/xxxxxxx29999 CHANNEL EXECUTE 2011-08-21 14:18:59.793352 [DEBUG] switch_core_state_machine.c:157 FreeTDM/1:17/xxxxxxx29999 Standard EXECUTE EXECUTE FreeTDM/1:17/xxxxxxx29999 set(destnumber=xxxxxxx29999) 2011-08-21 14:18:59.793352 [DEBUG] mod_dptools.c:1059 FreeTDM/1:17/xxxxxxx29999 SET [destnumber]=[xxxxxxx29999] EXECUTE FreeTDM/1:17/xxxxxxx29999 set(sip_contact_user_replacement=xxxxxxx29999) 2011-08-21 14:18:59.794441 [DEBUG] mod_dptools.c:1059 FreeTDM/1:17/xxxxxxx29999 SET [sip_contact_user_replacement]=[xxxxxxx29999] EXECUTE FreeTDM/1:17/xxxxxxx29999 set(hangup_after_bridge=yes) 2011-08-21 14:18:59.794441 [DEBUG] mod_dptools.c:1059 FreeTDM/1:17/xxxxxxx29999 SET [hangup_after_bridge]=[yes] EXECUTE FreeTDM/1:17/xxxxxxx29999 bridge(sofia/internal/xxxxxxx29999@x.x.x.134) 2011-08-21 14:18:59.795371 [NOTICE] switch_channel.c:811 New Channel sofia/internal/xxxxxxx29999@x.x.x.134 [b0588ca1-6910-4d19-9747-99ad8c61634b] 2011-08-21 14:18:59.795371 [DEBUG] mod_sofia.c:4237 (sofia/internal/xxxxxxx29999@x.x.x.134) State Change CS_NEW -> CS_INIT 2011-08-21 14:18:59.795371 [DEBUG] switch_core_session.c:1116 Send signal sofia/internal/xxxxxxx29999@x.x.x.134 [BREAK] 2011-08-21 14:18:59.796356 [DEBUG] switch_core_state_machine.c:320 (sofia/internal/xxxxxxx29999@x.x.x.134) Running State Change CS_INIT 2011-08-21 14:18:59.796356 [DEBUG] switch_core_state_machine.c:356 (sofia/internal/xxxxxxx29999@x.x.x.134) State INIT 2011-08-21 14:18:59.796356 [DEBUG] mod_sofia.c:84 sofia/internal/xxxxxxx29999@x.x.x.134 SOFIA INIT 2011-08-21 14:18:59.796356 [DEBUG] mod_sofia.c:124 (sofia/internal/xxxxxxx29999@x.x.x.134) State Change CS_INIT -> CS_ROUTING 2011-08-21 14:18:59.796356 [DEBUG] switch_core_session.c:1116 Send signal sofia/internal/xxxxxxx29999@x.x.x.134 [BREAK] 2011-08-21 14:18:59.796356 [DEBUG] switch_core_state_machine.c:356 (sofia/internal/xxxxxxx29999@x.x.x.134) State INIT going to sleep 2011-08-21 14:18:59.796356 [DEBUG] switch_core_state_machine.c:320 (sofia/internal/xxxxxxx29999@x.x.x.134) Running State Change CS_ROUTING 2011-08-21 14:18:59.796356 [DEBUG] switch_channel.c:1660 (sofia/internal/xxxxxxx29999@x.x.x.134) Callstate Change DOWN -> RINGING 2011-08-21 14:18:59.797451 [DEBUG] switch_core_state_machine.c:359 (sofia/internal/xxxxxxx29999@x.x.x.134) State ROUTING 2011-08-21 14:18:59.797451 [DEBUG] mod_sofia.c:147 sofia/internal/xxxxxxx29999@x.x.x.134 SOFIA ROUTING 2011-08-21 14:18:59.797451 [DEBUG] switch_ivr_originate.c:66 (sofia/internal/xxxxxxx29999@x.x.x.134) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2011-08-21 14:18:59.797451 [DEBUG] switch_core_session.c:1116 Send signal sofia/internal/xxxxxxx29999@x.x.x.134 [BREAK] 2011-08-21 14:18:59.797451 [DEBUG] switch_core_state_machine.c:359 (sofia/internal/xxxxxxx29999@x.x.x.134) State ROUTING going to sleep 2011-08-21 14:18:59.797451 [DEBUG] switch_core_state_machine.c:320 (sofia/internal/xxxxxxx29999@x.x.x.134) Running State Change CS_CONSUME_MEDIA 2011-08-21 14:18:59.797451 [DEBUG] switch_core_state_machine.c:378 (sofia/internal/xxxxxxx29999@x.x.x.134) State CONSUME_MEDIA 2011-08-21 14:18:59.797451 [DEBUG] switch_core_state_machine.c:378 (sofia/internal/xxxxxxx29999@x.x.x.134) State CONSUME_MEDIA going to sleep 2011-08-21 14:18:59.797451 [DEBUG] sofia.c:4659 Channel sofia/internal/xxxxxxx29999@x.x.x.134 entering state [calling][0] It stays like this until I hang up the call, Freeswitch then tears down the call. To me it looks like my SIP provider is not accepting the call in that format? I have tried changing the way the number is presented to Freeswitch by altering the routing on the telco switch, but still no joy. Is there anything else that could be causing an issue looking at the log above? Thanks in advance for your help. Kind regards Ben -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Moises Silva Sent: 22 August 2011 00:04 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Sangoma Media Gateway On Sat, Aug 20, 2011 at 6:59 PM, Ben Naylor <bnaylor@sirran.com> wrote:
I’m not 100% sure, but it would appear that whenever I try and edit default.xml dialplan, the SMG changes status to ‘down’ in the webgui. I then change it straight back again and it comes back up briefly.
The only reason I can think of for such behavior is that you have some syntax error in the XML and the gateway fails to start. See the logs /usr/local/smg/log/sangomagw.log to find out why the gateway fails to start.
However, I’ve got to the point now where I can’t seem to get the SMG to work again, the TDM drivers start fine, but the SMG just does not want to start.
I have also check the sangomagw log file in /usr/local/smg/log/ but this seems to stop logging anything once the SMG goes down.
Do you know of any other log files I could check?
Depending on the version of SMG (can't remember the details), you have /usr/local/smg/init.log or /usr/local/smg/log/init.log
Also, if I were to re-install the SMG, would re-running the make/install commands just re-install over the top? As a newbie to linux I am still not sure if this is the case! J
Latest version of smg will backup the auto-generated configuration (freetdm.conf, wanpipe etc), but will NOT backup your dialplan, that is up to you. In general I recommend you to backup your whole conf/ directory before upgrading. Moises Silva Senior Software Engineer, Software Development Manager Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R 9R6 Canada t. 1 905 474 1990 x128 | 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 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3848 - Release Date: 08/21/11
On Mon, Aug 22, 2011 at 3:32 AM, Ben Naylor <bnaylor@sirran.com> wrote:
2011-08-21 14:18:59.797451 [DEBUG] switch_core_state_machine.c:320 (sofia/internal/xxxxxxx29999@x.x.x.134) Running State Change CS_CONSUME_MEDIA 2011-08-21 14:18:59.797451 [DEBUG] switch_core_state_machine.c:378 (sofia/internal/xxxxxxx29999@x.x.x.134) State CONSUME_MEDIA 2011-08-21 14:18:59.797451 [DEBUG] switch_core_state_machine.c:378 (sofia/internal/xxxxxxx29999@x.x.x.134) State CONSUME_MEDIA going to sleep 2011-08-21 14:18:59.797451 [DEBUG] sofia.c:4659 Channel sofia/internal/xxxxxxx29999@x.x.x.134 entering state [calling][0]
It stays like this until I hang up the call, Freeswitch then tears down the call. To me it looks like my SIP provider is not accepting the call in that format? I have tried changing the way the number is presented to Freeswitch by altering the routing on the telco switch, but still no joy. Is there anything else that could be causing an issue looking at the log above?
It seems to me you did not include the most important part of the log, which is the unexpected hangup. All the logging you posted points to a successful call (at least to the point where is trying to reach the SIP peer). Moises Silva Senior Software Engineer, Software Development Manager Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R 9R6 Canada t. 1 905 474 1990 x128 | e. moy@sangoma.com
participants (3)
-
Ben Naylor
-
Deon Vermeulen
-
Moises Silva