Directory and ACL authentication
Hello, Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries. The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs. So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply. My SIP profile is: <profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile> Thanks! -Victor
You need this: <param name="apply-inbound-acl" value="domains"/> On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
Alright, thank you! Domains ACL works BUT requires "users" to be in "groups". If "users" are directly in the "domain" section, ACL remains empty. This is contradictory to the WiKi saying that: "Using groups is optional -- you can put your users straight into the domain section if you desire". Should I file Jira or should I edit WiKi instead? :) With regards to directory, I intend to keep it minimalistic: <user id="foo" cidr="1.2.3.4/32"> <variables> <variable name="accountcode" value="customer_1"/> </variables> </user> Will someone from a different CIDR be able to place calls as user "foo" bypassing any authentication? Note that I don't set any password in params. If so, how to secure this on the SIP profile level and keep user entries as concise as possible? Thanks again! -Victor On 14-05-05 12:24 PM, Steven Ayre wrote:
You need this: <param name="apply-inbound-acl" value="domains"/>
On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com <mailto:victor.chukalovskiy@gmail.com>> wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
I'd go with a Jira. Either it's an oversight, or there's a reason for it that can be tracked in Jira and then the wiki updated referencing the ticket. On 5 May 2014 21:38, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Alright, thank you! Domains ACL works BUT requires "users" to be in "groups". If "users" are directly in the "domain" section, ACL remains empty.
This is contradictory to the WiKi saying that: "Using groups is optional -- you can put your users straight into the domain section if you desire". Should I file Jira or should I edit WiKi instead? :)
With regards to directory, I intend to keep it minimalistic:
<user id="foo" cidr="1.2.3.4/32"> <variables> <variable name="accountcode" value="customer_1"/> </variables> </user>
Will someone from a different CIDR be able to place calls as user "foo" bypassing any authentication? Note that I don't set any password in params. If so, how to secure this on the SIP profile level and keep user entries as concise as possible?
Thanks again! -Victor
On 14-05-05 12:24 PM, Steven Ayre wrote:
You need this: <param name="apply-inbound-acl" value="domains"/>
On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
Ok, done: https://jira.freeswitch.org/browse/FS-6506 Also, added comment to the WiKi until this is fixed: https://wiki.freeswitch.org/wiki/XML_User_Directory_Guide#Groups On 14-05-06 12:32 PM, Steven Ayre wrote:
I'd go with a Jira. Either it's an oversight, or there's a reason for it that can be tracked in Jira and then the wiki updated referencing the ticket.
On 5 May 2014 21:38, Victor Chukalovskiy <victor.chukalovskiy@gmail.com <mailto:victor.chukalovskiy@gmail.com>> wrote:
Alright, thank you! Domains ACL works BUT requires "users" to be in "groups". If "users" are directly in the "domain" section, ACL remains empty.
This is contradictory to the WiKi saying that: "Using groups is optional -- you can put your users straight into the domain section if you desire". Should I file Jira or should I edit WiKi instead? :)
With regards to directory, I intend to keep it minimalistic:
<user id="foo" cidr="1.2.3.4/32 <http://1.2.3.4/32>"> <variables> <variable name="accountcode" value="customer_1"/> </variables> </user>
Will someone from a different CIDR be able to place calls as user "foo" bypassing any authentication? Note that I don't set any password in params. If so, how to secure this on the SIP profile level and keep user entries as concise as possible?
Thanks again! -Victor
On 14-05-05 12:24 PM, Steven Ayre wrote:
You need this: <param name="apply-inbound-acl" value="domains"/>
On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com <mailto:victor.chukalovskiy@gmail.com>> wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
Patch added to make it work either way but previously you don't need: <domain> <users> <user>...</user> <user>...</user> </users> </domain> Just: <domain> <user>...</user> <user>...</user> </domain> On Tue, May 6, 2014 at 1:47 PM, Victor Chukalovskiy < victor.chukalovskiy@gmail.com> wrote:
Ok, done: https://jira.freeswitch.org/browse/FS-6506
Also, added comment to the WiKi until this is fixed: https://wiki.freeswitch.org/wiki/XML_User_Directory_Guide#Groups
On 14-05-06 12:32 PM, Steven Ayre wrote:
I'd go with a Jira. Either it's an oversight, or there's a reason for it that can be tracked in Jira and then the wiki updated referencing the ticket.
On 5 May 2014 21:38, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Alright, thank you! Domains ACL works BUT requires "users" to be in "groups". If "users" are directly in the "domain" section, ACL remains empty.
This is contradictory to the WiKi saying that: "Using groups is optional -- you can put your users straight into the domain section if you desire". Should I file Jira or should I edit WiKi instead? :)
With regards to directory, I intend to keep it minimalistic:
<user id="foo" cidr="1.2.3.4/32"> <variables> <variable name="accountcode" value="customer_1"/> </variables> </user>
Will someone from a different CIDR be able to place calls as user "foo" bypassing any authentication? Note that I don't set any password in params. If so, how to secure this on the SIP profile level and keep user entries as concise as possible?
Thanks again! -Victor
On 14-05-05 12:24 PM, Steven Ayre wrote:
You need this: <param name="apply-inbound-acl" value="domains"/>
On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
Great, thank you Antony. I confirm it works either way now....it was a super quick one. On a similar topic, do I have to set this in the domain params? <param name="allow-empty-password" value="false"/> This is to keep things failproof, given I only set CIDR and no password for my users. On 14-05-06 03:07 PM, Anthony Minessale wrote:
Patch added to make it work either way but previously you don't need:
<domain> <users> <user>...</user> <user>...</user> </users> </domain>
Just:
<domain> <user>...</user> <user>...</user> </domain>
On Tue, May 6, 2014 at 1:47 PM, Victor Chukalovskiy <victor.chukalovskiy@gmail.com <mailto:victor.chukalovskiy@gmail.com>> wrote:
Ok, done: https://jira.freeswitch.org/browse/FS-6506
Also, added comment to the WiKi until this is fixed: https://wiki.freeswitch.org/wiki/XML_User_Directory_Guide#Groups
On 14-05-06 12:32 PM, Steven Ayre wrote:
I'd go with a Jira. Either it's an oversight, or there's a reason for it that can be tracked in Jira and then the wiki updated referencing the ticket.
On 5 May 2014 21:38, Victor Chukalovskiy <victor.chukalovskiy@gmail.com <mailto:victor.chukalovskiy@gmail.com>> wrote:
Alright, thank you! Domains ACL works BUT requires "users" to be in "groups". If "users" are directly in the "domain" section, ACL remains empty.
This is contradictory to the WiKi saying that: "Using groups is optional -- you can put your users straight into the domain section if you desire". Should I file Jira or should I edit WiKi instead? :)
With regards to directory, I intend to keep it minimalistic:
<user id="foo" cidr="1.2.3.4/32 <http://1.2.3.4/32>"> <variables> <variable name="accountcode" value="customer_1"/> </variables> </user>
Will someone from a different CIDR be able to place calls as user "foo" bypassing any authentication? Note that I don't set any password in params. If so, how to secure this on the SIP profile level and keep user entries as concise as possible?
Thanks again! -Victor
On 14-05-05 12:24 PM, Steven Ayre wrote:
You need this: <param name="apply-inbound-acl" value="domains"/>
On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com <mailto:victor.chukalovskiy@gmail.com>> wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto: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 ? @anthmfs ? @FreeSWITCH ?
? http://freeswitch.org/ ? http://cluecon.com/ ? http://twitter.com/FreeSWITCH ? irc.freenode.net <http://irc.freenode.net> #freeswitch ? _http://freeswitch.org/g+_
ClueCon Weekly Development Call ? sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> ? +19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
I would assume that's the default. On 6 May 2014 20:31, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Great, thank you Antony. I confirm it works either way now....it was a super quick one.
On a similar topic, do I have to set this in the domain params? <param name="allow-empty-password" value="false"/>
This is to keep things failproof, given I only set CIDR and no password for my users.
On 14-05-06 03:07 PM, Anthony Minessale wrote:
Patch added to make it work either way but previously you don't need:
<domain> <users> <user>...</user> <user>...</user> </users> </domain>
Just:
<domain> <user>...</user> <user>...</user> </domain>
On Tue, May 6, 2014 at 1:47 PM, Victor Chukalovskiy < victor.chukalovskiy@gmail.com> wrote:
Ok, done: https://jira.freeswitch.org/browse/FS-6506
Also, added comment to the WiKi until this is fixed: https://wiki.freeswitch.org/wiki/XML_User_Directory_Guide#Groups
On 14-05-06 12:32 PM, Steven Ayre wrote:
I'd go with a Jira. Either it's an oversight, or there's a reason for it that can be tracked in Jira and then the wiki updated referencing the ticket.
On 5 May 2014 21:38, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Alright, thank you! Domains ACL works BUT requires "users" to be in "groups". If "users" are directly in the "domain" section, ACL remains empty.
This is contradictory to the WiKi saying that: "Using groups is optional -- you can put your users straight into the domain section if you desire". Should I file Jira or should I edit WiKi instead? :)
With regards to directory, I intend to keep it minimalistic:
<user id="foo" cidr="1.2.3.4/32"> <variables> <variable name="accountcode" value="customer_1"/> </variables> </user>
Will someone from a different CIDR be able to place calls as user "foo" bypassing any authentication? Note that I don't set any password in params. If so, how to secure this on the SIP profile level and keep user entries as concise as possible?
Thanks again! -Victor
On 14-05-05 12:24 PM, Steven Ayre wrote:
You need this: <param name="apply-inbound-acl" value="domains"/>
On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>*
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
I retract that. Given that it's a security-related topic it made sense to check the code to verify. 'grep allow_empty_password src/mod/endpoints/mod_sofia/*' switch_bool_t allow_empty_password = SWITCH_TRUE; The default is in fact to allow them, so if you want to refuse them yes you *will* need that parameter. On 7 May 2014 11:15, Steven Ayre <steveayre@gmail.com> wrote:
I would assume that's the default.
On 6 May 2014 20:31, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Great, thank you Antony. I confirm it works either way now....it was a super quick one.
On a similar topic, do I have to set this in the domain params? <param name="allow-empty-password" value="false"/>
This is to keep things failproof, given I only set CIDR and no password for my users.
On 14-05-06 03:07 PM, Anthony Minessale wrote:
Patch added to make it work either way but previously you don't need:
<domain> <users> <user>...</user> <user>...</user> </users> </domain>
Just:
<domain> <user>...</user> <user>...</user> </domain>
On Tue, May 6, 2014 at 1:47 PM, Victor Chukalovskiy < victor.chukalovskiy@gmail.com> wrote:
Ok, done: https://jira.freeswitch.org/browse/FS-6506
Also, added comment to the WiKi until this is fixed: https://wiki.freeswitch.org/wiki/XML_User_Directory_Guide#Groups
On 14-05-06 12:32 PM, Steven Ayre wrote:
I'd go with a Jira. Either it's an oversight, or there's a reason for it that can be tracked in Jira and then the wiki updated referencing the ticket.
On 5 May 2014 21:38, Victor Chukalovskiy <victor.chukalovskiy@gmail.com
wrote:
Alright, thank you! Domains ACL works BUT requires "users" to be in "groups". If "users" are directly in the "domain" section, ACL remains empty.
This is contradictory to the WiKi saying that: "Using groups is optional -- you can put your users straight into the domain section if you desire". Should I file Jira or should I edit WiKi instead? :)
With regards to directory, I intend to keep it minimalistic:
<user id="foo" cidr="1.2.3.4/32"> <variables> <variable name="accountcode" value="customer_1"/> </variables> </user>
Will someone from a different CIDR be able to place calls as user "foo" bypassing any authentication? Note that I don't set any password in params. If so, how to secure this on the SIP profile level and keep user entries as concise as possible?
Thanks again! -Victor
On 14-05-05 12:24 PM, Steven Ayre wrote:
You need this: <param name="apply-inbound-acl" value="domains"/>
On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com
wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>*
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
However since you're actually asking about CIDR, that parameter is ignored for those users. The authentication by ACL occurs before checking the password given (if any), if the users match the CIDR then they'll never reach the allow-empty-passwords check. On 6 May 2014 20:31, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Great, thank you Antony. I confirm it works either way now....it was a super quick one.
On a similar topic, do I have to set this in the domain params? <param name="allow-empty-password" value="false"/>
This is to keep things failproof, given I only set CIDR and no password for my users.
On 14-05-06 03:07 PM, Anthony Minessale wrote:
Patch added to make it work either way but previously you don't need:
<domain> <users> <user>...</user> <user>...</user> </users> </domain>
Just:
<domain> <user>...</user> <user>...</user> </domain>
On Tue, May 6, 2014 at 1:47 PM, Victor Chukalovskiy < victor.chukalovskiy@gmail.com> wrote:
Ok, done: https://jira.freeswitch.org/browse/FS-6506
Also, added comment to the WiKi until this is fixed: https://wiki.freeswitch.org/wiki/XML_User_Directory_Guide#Groups
On 14-05-06 12:32 PM, Steven Ayre wrote:
I'd go with a Jira. Either it's an oversight, or there's a reason for it that can be tracked in Jira and then the wiki updated referencing the ticket.
On 5 May 2014 21:38, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Alright, thank you! Domains ACL works BUT requires "users" to be in "groups". If "users" are directly in the "domain" section, ACL remains empty.
This is contradictory to the WiKi saying that: "Using groups is optional -- you can put your users straight into the domain section if you desire". Should I file Jira or should I edit WiKi instead? :)
With regards to directory, I intend to keep it minimalistic:
<user id="foo" cidr="1.2.3.4/32"> <variables> <variable name="accountcode" value="customer_1"/> </variables> </user>
Will someone from a different CIDR be able to place calls as user "foo" bypassing any authentication? Note that I don't set any password in params. If so, how to secure this on the SIP profile level and keep user entries as concise as possible?
Thanks again! -Victor
On 14-05-05 12:24 PM, Steven Ayre wrote:
You need this: <param name="apply-inbound-acl" value="domains"/>
On 5 May 2014 17:13, Victor Chukalovskiy <victor.chukalovskiy@gmail.com>wrote:
Hello,
Coming from wholesale background, my FS's run without any registrations. So far everything was ACL-based using "apply-inbound-acl" and I did not use any directory entries.
The only problem with this is that once I have all IPs together in one big ALC, I can't identify which customer the call came from. E.g. need to set my_channel_variable=customer1 if a call came from particular IPs and my_channel_variable=customer2 if a call came from other IPs.
So I'm trying to move ACL logic into directory by means of defining a user with cidr attribute. So far, no matter what I do FS challenges INVITE with "407" even-though the INVITE comes from the IP that is included in CIDR attribute for a user. I suppose for whatever reason switch does not match INVITEs against CIDR's in the directory. Please help me with that. WiKi is written from a somewhat different logic / perspective, so it's hard to apply.
My SIP profile is:
<profile name="test"> <gateways> </gateways> <domains> </domains> <settings> <param name="parse-invite-tel-params" value="true"/> <param name="user-agent-string" value="test"/> <param name="debug" value="0"/> <param name="sip-trace" value="no"/> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="context" value="test"/> <param name="country" value="e164"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${default_codec_prefs}"/> <param name="caller-id-type" value="none"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="192.168.1.2"/> <param name="sip-ip" value="192.168.1.2"/> <param name="manage-presence" value="false"/> <param name="manage-shared-appearance" value="false"/> <param name="inbound-codec-negotiation" value="greedy"/> <param name="disable-transcoding" value="true"/> <param name="manual-redirect" value="false"/> <param name="disable-transfer" value="true"/> <param name="disable-register" value="false"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="pass-callee-id" value="false"/> </settings> </profile>
Thanks! -Victor
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>*
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
This used to work - only changed a few things to get fax detect to work reliably. Could it be that the two interact? If there isn't something obvious in the extension below: What steps to debug? Do I need SIP logging? <extension name="group_dial_sales"> <condition field="destination_number" expression="^30$"> <!--Export - Exports a channel variable from the A leg to the B leg--> <action application="export" data="dialed_extension=$1"/> <action application="answer"/> <action application="set" data="transfer_ringback=${us-ring}"/> <action application="set" data="ringback=${us-ring}"/> <action application="spandsp_start_fax_detect" data="transfer '33 XML features' 6"/> <!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> --> <action application="bind_meta_app" data="1 b s execute_extension::dx XML features"/> <action application="bind_meta_app" data="2 b s record_session::$${recordings_dir}/${strftime(%Y-%m-%d_%H-%M-%S)}.${caller_id_number}.wav"/> <action application="bind_meta_app" data="3 b s execute_extension::cf XML features"/> <action application="bind_meta_app" data="4 b s execute_extension::att_xfer XML features"/> <action application="bind_meta_app" data="5 b s execute_extension::echo XML default"/> <!-- ringback specifies audio to play to the A leg on =>unanswered<= aka (early media) call--> <!--transfer_ringack sets ring tone for =>answered<= calls. This is any bridged call. --> <!--call_timeout is the seconds to ring the B leg of a call when using the bridge application. The timeout is set on the A leg,--> <action application="set" data="call_timeout=20"/> <action application="set" data="zrtp_secure_media=false"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION"/> <action application="set" data="continue_on_fail=true"/> <!--Set hash values for call features--> <action application="hash" data="insert/${domain_name}-call_return/${dialed_extension}/${caller_id_number}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/${dialed_extension}/${uuid}"/> <action application="set" data="called_party_callgroup=${user_data(${dialed_extension}@${domain_name} var callgroup)}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/${called_party_callgroup}/${uuid}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/global/${uuid}"/>--> <action application="export" data="nolocal:sip_secure_media=${user_data(${dialed_extension}@${domain_name} var sip_secure_media)}"/> <action application="hash" data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/> <action application="bridge" data="${group_call(sales@${domain_name})}"/> <action application="sleep" data="1000"/> <action application="transfer" data="voicemail xml features"/> </condition> </extension> -------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Foreign aid is taking money from the poor people of a rich country and giving it to the rich people of a poor country. --------------------------------------------------------------------------------
Was t.38 involved? -- Brian West brian@freeswitch.org Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED) On May 6, 2014, at 6:15 PM, Karl Schmidt <karl@xtronics.com> wrote:
This used to work - only changed a few things to get fax detect to work reliably. Could it be that the two interact?
If there isn't something obvious in the extension below:
What steps to debug? Do I need SIP logging?
<extension name="group_dial_sales"> <condition field="destination_number" expression="^30$"> <!--Export - Exports a channel variable from the A leg to the B leg--> <action application="export" data="dialed_extension=$1"/> <action application="answer"/> <action application="set" data="transfer_ringback=${us-ring}"/> <action application="set" data="ringback=${us-ring}"/> <action application="spandsp_start_fax_detect" data="transfer '33 XML features' 6"/>
<!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> --> <action application="bind_meta_app" data="1 b s execute_extension::dx XML features"/> <action application="bind_meta_app" data="2 b s record_session::$${recordings_dir}/${strftime(%Y-%m-%d_%H-%M-%S)}.${caller_id_number}.wav"/> <action application="bind_meta_app" data="3 b s execute_extension::cf XML features"/> <action application="bind_meta_app" data="4 b s execute_extension::att_xfer XML features"/> <action application="bind_meta_app" data="5 b s execute_extension::echo XML default"/> <!-- ringback specifies audio to play to the A leg on =>unanswered<= aka (early media) call--> <!--transfer_ringack sets ring tone for =>answered<= calls. This is any bridged call. --> <!--call_timeout is the seconds to ring the B leg of a call when using the bridge application. The timeout is set on the A leg,--> <action application="set" data="call_timeout=20"/> <action application="set" data="zrtp_secure_media=false"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION"/> <action application="set" data="continue_on_fail=true"/> <!--Set hash values for call features--> <action application="hash" data="insert/${domain_name}-call_return/${dialed_extension}/${caller_id_number}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/${dialed_extension}/${uuid}"/> <action application="set" data="called_party_callgroup=${user_data(${dialed_extension}@${domain_name} var callgroup)}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/${called_party_callgroup}/${uuid}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/global/${uuid}"/>--> <action application="export" data="nolocal:sip_secure_media=${user_data(${dialed_extension}@${domain_name} var sip_secure_media)}"/> <action application="hash" data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/> <action application="bridge" data="${group_call(sales@${domain_name})}"/> <action application="sleep" data="1000"/> <action application="transfer" data="voicemail xml features"/> </condition> </extension>
-------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434
Foreign aid is taking money from the poor people of a rich country and giving it to the rich people of a poor country.
--------------------------------------------------------------------------------
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
On 05/08/2014 09:57 AM, Brian West wrote:
Was t.38 involved?
Could be - I've been having a few errors after changing the way I receive faxes.. After humbly rereading my subject - I see I wasn't as clear as I should be: - the "after FAX" meant that there is a fax detect line in the extension - before the bind_meta_app lines. Here is the faxrx extention: <extension name="faxrx"> <condition field="destination_number" expression="^33$"> <!-- The following sort of works--> <action application="set" data="file=/home/freeswitch/fax/${strftime(%Y-%m-%d_%H-%M-%S)}.tif"/> <action application="playback" data="silence_stream://2000"/> <action application="set" data="fax_enable_t38_request=false"/> <action application="set" data="fax_enable_t38=false"/> <action application="rxfax" data="${file}"/> <action application="system" data='echo "See attached FAX" | mutt -a ${file} -s "FAX" -- freeswitch@domain.tld' /> <action application="hangup" /> <action application="set_zombie_exec"/> </condition> </extension>
On May 6, 2014, at 6:15 PM, Karl Schmidt <karl@xtronics.com <mailto:karl@xtronics.com>> wrote:
This used to work - only changed a few things to get fax detect to work reliably. Could it be that the two interact?
If there isn't something obvious in the extension below:
What steps to debug? Do I need SIP logging?
<snip> -- -------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB http://xtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 History may not repeat itself, but it does rhyme a lot. -Mark Twain --------------------------------------------------------------------------------
participants (5)
-
Anthony Minessale
-
Brian West
-
Karl Schmidt
-
Steven Ayre
-
Victor Chukalovskiy