Embarrassing Question: Local extension registering in the Public context on default configuration?
Hi All, I've used FS in the past to varying degrees but never as a PBX or a REGISTRAR and just to test basic config, I built and installed it and didn't change a damn thing. Had a softphone on the same internal network registered to it using the default password, but it seems to register itself in the public context when I'd have thought it'd register in default context so I can test all those pre-built extensions for an echo test, dumping channel variables etc. But they don't work as the call originated to say 5000 from extension 1000 goes into the public context which doesn't have 5000. What is going on? It's so embarrassing to ask such a simple question :( freeswitch@internal> sofia status profile internal 1000 ================================================================================================= Name internal Domain Name N/A Auto-NAT false DBName sofia_reg_internal Pres Hosts 192.168.3.101,192.168.3.101 Dialplan XML Context public Challenge Realm auto_from RTP-IP 192.168.3.101 SIP-IP 192.168.3.101 URL sip:mod_sofia@192.168.3.101:5060 BIND-URL sip:mod_sofia@192.168.3.101:5060 HOLD-MUSIC local_stream://moh OUTBOUND-PROXY N/A CODECS IN G7221@32000h,G7221@16000h,G722,BV32,PCMU,PCMA,GSM CODECS OUT G7221@32000h,G7221@16000h,G722,BV32,PCMU,PCMA,GSM TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false AGGRESSIVENAT false STUN-ENABLED true STUN-AUTO-DISABLE false CALLS-IN 0 FAILED-CALLS-IN 0 CALLS-OUT 0 FAILED-CALLS-OUT 0 Registrations: ================================================================================================= Call-ID: ZDVjOThlZmZhN2JhOGMyYjA1MTUxMzliYzAwMzNhYjU. User: 1000@192.168.3.101 Contact: "FreeSWITCH 1000" <sip:1000@192.168.3.121:49950 ;rinstance=15dfcfcc0353b7c7;fs_nat=yes;fs_path=sip%3A1000%40192.168.3.121%3A49950%3Brinstance%3D15dfcfcc0353b7c7> Agent: Bria Professional release 2.4.3 stamp 50906 Status: Registered(UDP-NAT)(unknown) EXP(2011-03-26 02:18:52) EXPSECS(1146) Host: Solaris11Ex IP: 192.168.3.121 Port: 49950 Auth-User: 1000 Auth-Realm: 192.168.3.101 MWI-Account: 1000@192.168.3.101
I'm no FS guru, but I believe that would happen based on the port that your softphone is using to register w/ the FS system. By default (at least in my experience), the internal / default profile is setup to listen on port 5060/5061 (ssl) and the external / public profile is setup to listen on port 5080/5081 (ssl). Check to make sure the softphone is set to register on port 5060, and it should re-register on the internal / default profile, unless there's a local firewall issue on the FS machine preventing it.. Randy On Mon, Mar 28, 2011 at 6:42 AM, A E [Gmail] <all.eforums@gmail.com> wrote:
Hi All,
I've used FS in the past to varying degrees but never as a PBX or a REGISTRAR and just to test basic config, I built and installed it and didn't change a damn thing. Had a softphone on the same internal network registered to it using the default password, but it seems to register itself in the public context when I'd have thought it'd register in default context so I can test all those pre-built extensions for an echo test, dumping channel variables etc. But they don't work as the call originated to say 5000 from extension 1000 goes into the public context which doesn't have 5000. What is going on? It's so embarrassing to ask such a simple question :(
freeswitch@internal> sofia status profile internal 1000
================================================================================================= Name internal Domain Name N/A Auto-NAT false DBName sofia_reg_internal Pres Hosts 192.168.3.101,192.168.3.101 Dialplan XML Context public Challenge Realm auto_from RTP-IP 192.168.3.101 SIP-IP 192.168.3.101 URL sip:mod_sofia@192.168.3.101:5060 BIND-URL sip:mod_sofia@192.168.3.101:5060 HOLD-MUSIC local_stream://moh OUTBOUND-PROXY N/A CODECS IN G7221@32000h,G7221@16000h,G722,BV32,PCMU,PCMA,GSM CODECS OUT G7221@32000h,G7221@16000h,G722,BV32,PCMU,PCMA,GSM TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false AGGRESSIVENAT false STUN-ENABLED true STUN-AUTO-DISABLE false CALLS-IN 0 FAILED-CALLS-IN 0 CALLS-OUT 0 FAILED-CALLS-OUT 0
Registrations:
================================================================================================= Call-ID: ZDVjOThlZmZhN2JhOGMyYjA1MTUxMzliYzAwMzNhYjU. User: 1000@192.168.3.101 Contact: "FreeSWITCH 1000" <sip:1000@192.168.3.121:49950 ;rinstance=15dfcfcc0353b7c7;fs_nat=yes;fs_path=sip%3A1000%40192.168.3.121%3A49950%3Brinstance%3D15dfcfcc0353b7c7> Agent: Bria Professional release 2.4.3 stamp 50906 Status: Registered(UDP-NAT)(unknown) EXP(2011-03-26 02:18:52) EXPSECS(1146) Host: Solaris11Ex IP: 192.168.3.121 Port: 49950 Auth-User: 1000 Auth-Realm: 192.168.3.101 MWI-Account: 1000@192.168.3.101
_______________________________________________ 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 Mon, Mar 28, 2011 at 8:28 AM, Randy Andrade <randy.andrade@gmail.com>wrote:
I'm no FS guru, but I believe that would happen based on the port that your softphone is using to register w/ the FS system. By default (at least in my experience), the internal / default profile is setup to listen on port 5060/5061 (ssl) and the external / public profile is setup to listen on port 5080/5081 (ssl). Check to make sure the softphone is set to register on port 5060, and it should re-register on the internal / default profile, unless there's a local firewall issue on the FS machine preventing it..
Randy
mmmm that isn't it. As is shown in the status of this endpoint it IS actually registered internally on 5060 and I'm not adding any port to the end of the domain/server name in Bria client.
Anymore ideas? With the gurus on the list, I'd have thought this would be answered in 10 mins of it being posted :)
On Mon, Mar 28, 2011 at 4:41 PM, Michael Collins <msc@freeswitch.org> wrote:
Anymore ideas? With the gurus on the list, I'd have thought this would be answered in 10 mins of it being posted :)
:)
Did you nail down the question about whether you have an ACL set? Also, did you pastebin a debug log of the call hitting the dialplan?
-MC
So, I did muck around a tad with the acl.conf.xml file although I was under the impression that it was auto-magically generated at install time? It looks like this. <list name="lan" default="allow"> <node type="deny" cidr="0.0.0.0/0"/> <node type="allow" cidr="192.168.3.0/24"/> </list> <list name="domains" default="deny"> <node type="allow" domain="$${domain}"/> <node type="allow" cidr="192.168.3.0/24"/> </list> and yes, I put the pastebin here: http://pastebin.freeswitch.org/15881 I also keep seeing this on the console in fs_cli: 2011-03-26 03:48:54.397538 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1000@192.168.3.101] from ip 192.168.3.121 Not sure why this is a "warning", and that might be an indication that FS thinks this UA is "foreign"? HTH?
return your acl.conf.xml to default and let the phones register to authenticate. You could do it with acls to but if you dont understand that yet try it simpler first:) -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Embarrassing-Question-Local-ex... Sent from the freeswitch-users mailing list archive at Nabble.com.
On Mon, Mar 28, 2011 at 5:45 PM, Jeff Lenk <jeff@jefflenk.com> wrote:
return your acl.conf.xml to default and let the phones register to authenticate. You could do it with acls to but if you dont understand that yet try it simpler first:)
Hey Jeff, I only started to mess around with the acl file after I had this problem with the default config :( So that can't be it. What else you got? :P
On Mon, Mar 28, 2011 at 2:50 PM, A E [Gmail] <all.eforums@gmail.com> wrote:
On Mon, Mar 28, 2011 at 5:45 PM, Jeff Lenk <jeff@jefflenk.com> wrote:
return your acl.conf.xml to default and let the phones register to authenticate. You could do it with acls to but if you dont understand that yet try it simpler first:)
Hey Jeff, I only started to mess around with the acl file after I had this problem with the default config :( So that can't be it. What else you got? :P Actually, it is that. See my other post. -MC
DING DING DING DING! We have a weener! :P Look at line 3 of your pastebin: 2011-03-26 02:00:54.058641 [DEBUG] sofia.c:6466 IP 192.168.3.121 Approved by acl "domains[]". Access Granted. Your "domains" ACL is letting the call in, but is not "authenticating" it so it's hitting the default context. If you absolutely want IP auth then you need to go into each directory entry for each user you want to have IP auth and add a tag like this: <user id="1000" cidr="192.168.3.10"> The better way to go, IMHO, is simply to use digest authentication. That way you don't have to worry about what IP address for what user, etc. Just make sure that you change the SIP password to something better than "1234" :) I answered this yesterday asking about the ACL. Granted it wasn't within 10 minutes but it was a Sunday for me... ;) -MC BTW, On Mon, Mar 28, 2011 at 2:01 PM, A E [Gmail] <all.eforums@gmail.com> wrote:
On Mon, Mar 28, 2011 at 4:41 PM, Michael Collins <msc@freeswitch.org> wrote:
Anymore ideas? With the gurus on the list, I'd have thought this would be answered in 10 mins of it being posted :)
:)
Did you nail down the question about whether you have an ACL set? Also, did you pastebin a debug log of the call hitting the dialplan?
-MC
So, I did muck around a tad with the acl.conf.xml file although I was under the impression that it was auto-magically generated at install time? It looks like this. <list name="lan" default="allow"> <node type="deny" cidr="0.0.0.0/0"/> <node type="allow" cidr="192.168.3.0/24"/> </list> <list name="domains" default="deny"> <node type="allow" domain="$${domain}"/> <node type="allow" cidr="192.168.3.0/24"/> </list> and yes, I put the pastebin here: http://pastebin.freeswitch.org/15881 I also keep seeing this on the console in fs_cli: 2011-03-26 03:48:54.397538 [WARNING] sofia_reg.c:1246 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1000@192.168.3.101] from ip 192.168.3.121 Not sure why this is a "warning", and that might be an indication that FS thinks this UA is "foreign"? HTH? _______________________________________________ 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 Mon, Mar 28, 2011 at 5:52 PM, Michael Collins <msc@freeswitch.org> wrote:
DING DING DING DING! We have a weener! :P Look at line 3 of your pastebin:
2011-03-26 02:00:54.058641 [DEBUG] sofia.c:6466 IP 192.168.3.121 Approved by acl "domains[]". Access Granted.
Believe it or not, I SWEAR I was going to highlight that and point it out that my $${domain} was coming up empty and it didn't have anyway to know who was local and who wasn't. So then I added the line <node type="allow" cidr="192.168.3.0/24"/> under <list name="domains"> to "teach" it! But that didn't work either.
Your "domains" ACL is letting the call in, but is not "authenticating" it so it's hitting the default context. If you absolutely want IP auth then you need to go into each directory entry for each user you want to have IP auth and add a tag like this:
<user id="1000" cidr="192.168.3.10">
The better way to go, IMHO, is simply to use digest authentication. That way you don't have to worry about what IP address for what user, etc. Just make sure that you change the SIP password to something better than "1234" :)
Sorry, how do I make it do that? Doesn't it do that by default?
I answered this yesterday asking about the ACL. Granted it wasn't within 10 minutes but it was a Sunday for me... ;)
Might have missed it :(
-MC
So bottom line, how do I fix this? like I kinda knew what the problem was, just wasn't sure and didn't know how to fix it :( If changing back to the original/default acl is the answer then why did this problem happen to begin with when I started out with a the basic default config that "make samples" spits out...hell I didn't even change the default pwd (don't worry this is running inside a VM and has no outside access) for registering the UAs. But when I had this issue, I started to much around.
On Mon, Mar 28, 2011 at 6:07 PM, A E [Gmail] <all.eforums@gmail.com> wrote:
On Mon, Mar 28, 2011 at 5:52 PM, Michael Collins <msc@freeswitch.org>wrote:
DING DING DING DING! We have a weener! :P Look at line 3 of your pastebin:
2011-03-26 02:00:54.058641 [DEBUG] sofia.c:6466 IP 192.168.3.121 Approved by acl "domains[]". Access Granted.
Believe it or not, I SWEAR I was going to highlight that and point it out that my $${domain} was coming up empty and it didn't have anyway to know who was local and who wasn't. So then I added the line
<node type="allow" cidr="192.168.3.0/24"/> under <list name="domains"> to "teach" it! But that didn't work either.
Your "domains" ACL is letting the call in, but is not "authenticating" it so it's hitting the default context. If you absolutely want IP auth then you need to go into each directory entry for each user you want to have IP auth and add a tag like this:
<user id="1000" cidr="192.168.3.10">
The better way to go, IMHO, is simply to use digest authentication. That way you don't have to worry about what IP address for what user, etc. Just make sure that you change the SIP password to something better than "1234" :)
Sorry, how do I make it do that? Doesn't it do that by default?
I answered this yesterday asking about the ACL. Granted it wasn't within 10 minutes but it was a Sunday for me... ;)
Might have missed it :(
-MC
So bottom line, how do I fix this? like I kinda knew what the problem was, just wasn't sure and didn't know how to fix it :( If changing back to the original/default acl is the answer then why did this problem happen to begin with when I started out with a the basic default config that "make samples" spits out...hell I didn't even change the default pwd (don't worry this is running inside a VM and has no outside access) for registering the UAs. But when I had this issue, I started to much around.
Bloody hell! I moved the modified acl file and did a "make samples" again and now it's going through the extensions in default context. Of course I get a "502" back but, with other bizarre issues going on...coz of all the hacky stuff I did to make it compile on Solaris 11, primarily coz it uses the "mod_hash" application that didn't compile so I commented it out but now it hangs up the call whenever that application is called in the dialplan. Wonder if anyone will answer my other email which has my Solaris woes! Thanks Michael and Jeff, I have no idea how, but you were right! I still don't get why the default config didn't work the first time!
participants (4)
-
A E [Gmail]
-
Jeff Lenk
-
Michael Collins
-
Randy Andrade