Default vs Public context
Hi All, Sorry for the rookie question, but am a bit confused here: 1. create an extension under conf/directory/default/ - I ensure that user_context is default 2. create a dialplan for this extension under conf/dialplan/default.xml - just a simple bridge to the extension 3. log in from XLite as this extension, from a PC which is in the same subnet as FS server - dial another similar extension FS processes this call in public context, and doesn't find the right dialplan Why does FS look for dialplan under public context, when the extension has been created in default?
Siri, it would be nice to have a log, to see exactly what u are doing. miha Dne 3/19/2013 6:19 AM, pis(e Siri MM:
Hi All, Sorry for the rookie question, but am a bit confused here: 1. create an extension under conf/directory/default/ - I ensure that user_context is default 2. create a dialplan for this extension under conf/dialplan/default.xml - just a simple bridge to the extension 3. log in from XLite as this extension, from a PC which is in the same subnet as FS server - dial another similar extension FS processes this call in public context, and doesn't find the right dialplan Why does FS look for dialplan under public context, when the extension has been created in default?
_________________________________________________________________________ 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
Is the call authenticating as the user you created? If not that might hit the public context. -Steve On 19 March 2013 05:19, Siri MM <sirimmfs@gmail.com> wrote:
Hi All,
Sorry for the rookie question, but am a bit confused here:
1. create an extension under conf/directory/default/ - I ensure that user_context is default 2. create a dialplan for this extension under conf/dialplan/default.xml - just a simple bridge to the extension 3. log in from XLite as this extension, from a PC which is in the same subnet as FS server - dial another similar extension
FS processes this call in public context, and doesn't find the right dialplan
Why does FS look for dialplan under public context, when the extension has been created in default?
_________________________________________________________________________ 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 Tue, 19 Mar 2013 16:19:08 +1100 Siri MM <sirimmfs@gmail.com> wrote:
1. create an extension under conf/directory/default/ - I ensure that user_context is default
You should probably include this entry. Sanitize the data of sensitive information. We will assume that you are not really handing out "XXXX" as a password.
2. create a dialplan for this extension under conf/dialplan/default.xml - just a simple bridge to the extension
Ditto.
3. log in from XLite as this extension, from a PC which is in the same subnet as FS server - dial another similar extension
I assume that this means that you are registering as this extension.
FS processes this call in public context, and doesn't find the right dialplan
This sounds like it is not actually registered. You can see if this is the case in the command line interface (fs_cli) with this command: sofia status profile internal reg -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:darcy@Vex.Net Voip: sip:darcy@Vex.Net
Which profile did you connect to with XLite - i.e. if you connected to the :5080 port, it will get you the public context, which is what you'd want for an unauthenticated external user, not an internal authenticated registration. The public vs default is essentially a firewall/gatekeeper to prevent a public/inward SIP call from being able to "dial" an extension such as "1###-###-####" and make a toll call. You also might have a setup where your extensions are not supposed to be publicly accessible. Make sure you're connecting XLite to :5060 or other port that is mapped to your default sip profile. -- Nathan On 03/19/2013 12:19 AM, Siri MM wrote:
Hi All, Sorry for the rookie question, but am a bit confused here: 1. create an extension under conf/directory/default/ - I ensure that user_context is default 2. create a dialplan for this extension under conf/dialplan/default.xml - just a simple bridge to the extension 3. log in from XLite as this extension, from a PC which is in the same subnet as FS server - dial another similar extension FS processes this call in public context, and doesn't find the right dialplan Why does FS look for dialplan under public context, when the extension has been created in default?
-- ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
Hello All, Thanks for the various replies. I have copied the user profile, dialplan, and logs to http://pastebin.freeswitch.org/20704 Answers to some of the questions are: XLite is Registered at port 5060:
sofia status profile internal reg Registrations: ================================================================================================= Call-ID: MmNlZDQxNWRiZDA2Y2VlMzQyNzY4MjlhYmE5NDgxZjc. User: 1005@xx.xx.xx.xx Contact: "1005" <sip:1005@yy.yy.yy.yy :5060;rinstance=c4a4c272fa0659c7> Agent: X-Lite release 5.0.0 stamp 67284 Status: Registered(UDP)(unknown) EXP(2013-03-20 17:26:20) EXPSECS(3634) Host: ubuntu IP: yy.yy.yy.yy Port: 5060 Auth-User: 1005 Auth-Realm: xx.xx.xx.xx MWI-Account: 1005@xx.xx.xx.xx Total items returned: 1 =================================================================================================
I am sure I am missing something simple!! On Tue, Mar 19, 2013 at 11:05 PM, Nathan Neulinger <nneul@mst.edu> wrote:
Which profile did you connect to with XLite - i.e. if you connected to the :5080 port, it will get you the public context, which is what you'd want for an unauthenticated external user, not an internal authenticated registration.
The public vs default is essentially a firewall/gatekeeper to prevent a public/inward SIP call from being able to "dial" an extension such as "1###-###-####" and make a toll call. You also might have a setup where your extensions are not supposed to be publicly accessible.
Make sure you're connecting XLite to :5060 or other port that is mapped to your default sip profile.
-- Nathan
On 03/19/2013 12:19 AM, Siri MM wrote:
Hi All, Sorry for the rookie question, but am a bit confused here: 1. create an extension under conf/directory/default/ - I ensure that user_context is default 2. create a dialplan for this extension under conf/dialplan/default.xml - just a simple bridge to the extension 3. log in from XLite as this extension, from a PC which is in the same subnet as FS server - dial another similar extension FS processes this call in public context, and doesn't find the right dialplan Why does FS look for dialplan under public context, when the extension has been created in default?
-- ------------------------------**------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
Cool. Found it -- this line is your problem: 2013-03-20 16:26:25.002596 [DEBUG] sofia.c:7697 IP yy.yy.yy.yy Approved by acl "domains[]". Access Granted. Since it's recognized under ACL, it doesn't *ask* for login credentials. If you remove this IP from acl.conf.xml, it should proceed as normal. Alternatively, if it is a fixed IP, you can add it as a CIDR for the user<http://wiki.freeswitch.org/wiki/Acl#Users> .. You might ask: "But it registered as 1005 -- it should be good: 2013-03-20 16:25:20.343565 [WARNING] sofia_reg.c:1520 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1005@xx.xx.xx.xx] from ip yy.yy.yy.yy" But registration is so FS knows where to send calls TO that account. When a call comes in, it still needs to auth. (iirc.) -Avi Marcus BestFone On Wed, Mar 20, 2013 at 7:43 AM, Siri MM <sirimmfs@gmail.com> wrote:
Hello All,
Thanks for the various replies. I have copied the user profile, dialplan, and logs to http://pastebin.freeswitch.org/20704
Answers to some of the questions are: XLite is Registered at port 5060:
sofia status profile internal reg Registrations:
================================================================================================= Call-ID: MmNlZDQxNWRiZDA2Y2VlMzQyNzY4MjlhYmE5NDgxZjc. User: 1005@xx.xx.xx.xx Contact: "1005" <sip:1005@yy.yy.yy.yy :5060;rinstance=c4a4c272fa0659c7> Agent: X-Lite release 5.0.0 stamp 67284 Status: Registered(UDP)(unknown) EXP(2013-03-20 17:26:20) EXPSECS(3634) Host: ubuntu IP: yy.yy.yy.yy Port: 5060 Auth-User: 1005 Auth-Realm: xx.xx.xx.xx MWI-Account: 1005@xx.xx.xx.xx Total items returned: 1
=================================================================================================
I am sure I am missing something simple!!
On Tue, Mar 19, 2013 at 11:05 PM, Nathan Neulinger <nneul@mst.edu> wrote:
Which profile did you connect to with XLite - i.e. if you connected to the :5080 port, it will get you the public context, which is what you'd want for an unauthenticated external user, not an internal authenticated registration.
The public vs default is essentially a firewall/gatekeeper to prevent a public/inward SIP call from being able to "dial" an extension such as "1###-###-####" and make a toll call. You also might have a setup where your extensions are not supposed to be publicly accessible.
Make sure you're connecting XLite to :5060 or other port that is mapped to your default sip profile.
-- Nathan
On 03/19/2013 12:19 AM, Siri MM wrote:
Hi All, Sorry for the rookie question, but am a bit confused here: 1. create an extension under conf/directory/default/ - I ensure that user_context is default 2. create a dialplan for this extension under conf/dialplan/default.xml - just a simple bridge to the extension 3. log in from XLite as this extension, from a PC which is in the same subnet as FS server - dial another similar extension FS processes this call in public context, and doesn't find the right dialplan Why does FS look for dialplan under public context, when the extension has been created in default?
-- ------------------------------**------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
_________________________________________________________________________ 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
Thanks for clarifying this Avi!! Would it be safe to say this? 1. If user context is default, and user has registered (may be because of an open acl), then on receiving a call, default context is searched 2. If user context is default, and user has not registered, then on receiving a call, public context is searched 3. If user context is public, then on receiving a call, public context is searched On Wed, Mar 20, 2013 at 7:20 PM, Avi Marcus <avi@avimarcus.net> wrote:
Cool. Found it -- this line is your problem:
2013-03-20 16:26:25.002596 [DEBUG] sofia.c:7697 IP yy.yy.yy.yy Approved by acl "domains[]". Access Granted.
Since it's recognized under ACL, it doesn't *ask* for login credentials. If you remove this IP from acl.conf.xml, it should proceed as normal.
Alternatively, if it is a fixed IP, you can add it as a CIDR for the user<http://wiki.freeswitch.org/wiki/Acl#Users> .
You might ask: "But it registered as 1005 -- it should be good: 2013-03-20 16:25:20.343565 [WARNING] sofia_reg.c:1520 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1005@xx.xx.xx.xx] from ip yy.yy.yy.yy"
But registration is so FS knows where to send calls TO that account. When a call comes in, it still needs to auth. (iirc.)
-Avi Marcus BestFone
On Wed, Mar 20, 2013 at 7:43 AM, Siri MM <sirimmfs@gmail.com> wrote:
Hello All,
Thanks for the various replies. I have copied the user profile, dialplan, and logs to http://pastebin.freeswitch.org/20704
Answers to some of the questions are: XLite is Registered at port 5060:
sofia status profile internal reg Registrations:
================================================================================================= Call-ID: MmNlZDQxNWRiZDA2Y2VlMzQyNzY4MjlhYmE5NDgxZjc. User: 1005@xx.xx.xx.xx Contact: "1005" <sip:1005@yy.yy.yy.yy :5060;rinstance=c4a4c272fa0659c7> Agent: X-Lite release 5.0.0 stamp 67284 Status: Registered(UDP)(unknown) EXP(2013-03-20 17:26:20) EXPSECS(3634) Host: ubuntu IP: yy.yy.yy.yy Port: 5060 Auth-User: 1005 Auth-Realm: xx.xx.xx.xx MWI-Account: 1005@xx.xx.xx.xx Total items returned: 1
=================================================================================================
I am sure I am missing something simple!!
On Tue, Mar 19, 2013 at 11:05 PM, Nathan Neulinger <nneul@mst.edu> wrote:
Which profile did you connect to with XLite - i.e. if you connected to the :5080 port, it will get you the public context, which is what you'd want for an unauthenticated external user, not an internal authenticated registration.
The public vs default is essentially a firewall/gatekeeper to prevent a public/inward SIP call from being able to "dial" an extension such as "1###-###-####" and make a toll call. You also might have a setup where your extensions are not supposed to be publicly accessible.
Make sure you're connecting XLite to :5060 or other port that is mapped to your default sip profile.
-- Nathan
On 03/19/2013 12:19 AM, Siri MM wrote:
Hi All, Sorry for the rookie question, but am a bit confused here: 1. create an extension under conf/directory/default/ - I ensure that user_context is default 2. create a dialplan for this extension under conf/dialplan/default.xml - just a simple bridge to the extension 3. log in from XLite as this extension, from a PC which is in the same subnet as FS server - dial another similar extension FS processes this call in public context, and doesn't find the right dialplan Why does FS look for dialplan under public context, when the extension has been created in default?
-- ------------------------------**------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
_________________________________________________________________________ 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.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
Here is how I understand it: - Each network/port on which FreeSwitch listens is a separate SIP (sofia) "profile". - Each SIP profile has a default context, set in the sip_profiles/<profile>.xml file, in the "context" param. This context is usually "public". - Each SIP profile has an optional domain, which specifies where to look for id/password pairs in the "directory". This is usually "N/A", which says to look in all domains. (?) - When authenticated with an id/password that matches in entry in the "directory" configuration, a "user_context" is usually set. This user context will override the default context set in the SIP profile. - When a user registers because of an open ACL, and thus does not match an id/password, a "default" record is used, probably the one that doesn't specify a "password" param. This "default" user typically does *not*set a user_context, leaving the registration with the default context (usually "public" as stated above). Based on that information, if your FS installation, for example, has 2 SIP profiles, and one is on an internal LAN, and thus secure, you could set the context of that SIP profile to be something other than "public". In this case, if an unknown phone were plugged into your LAN, it could register without a profile and then be able to dial calls. There is probably also a way to make registrations without a password on a particular SIP profile use a "default" directory entry that sets a user_context, but to prevent this "default" directory entry from being used on the "external" SIP profile, but I haven't had a need to figure out how to do that. -- Steve On Wed, Mar 20, 2013 at 10:58 PM, Siri MM <sirimmfs@gmail.com> wrote:
Thanks for clarifying this Avi!!
Would it be safe to say this? 1. If user context is default, and user has registered (may be because of an open acl), then on receiving a call, default context is searched 2. If user context is default, and user has not registered, then on receiving a call, public context is searched 3. If user context is public, then on receiving a call, public context is searched
participants (7)
-
Avi Marcus
-
D'Arcy J.M. Cain
-
Miha
-
Nathan Neulinger
-
Siri MM
-
Steven Ayre
-
Steven Schoch