Hello, How do I get a list of all users? Including users that are not registered yet? (note: I have already changed the domain to microcomaustralia.com.au) I have tried: freeswitch@voyage> user_exists brian@microcomaustralia.com.au false i believe this user should be defined in conf/directory/default/brian.xml, however it is like nothing in conf/directory/default.xml is being read. I want to prove if this is the case or not. When I try to register I get this error: 2010-02-21 13:09:02.568081 [WARNING] sofia_reg.c:1019 SIP auth failure (REGISTER) on sofia profile 'internal' for [brian@microcomaustralia.com.au] from ip 192.168.87.14 which I think might be because it can't find the matching user entry. Thanks -- Brian May <brian@microcomaustralia.com.au>
Brian May <brian@microcomaustralia.com.au> wrote:
(note: I have already changed the domain to microcomaustralia.com.au)
I have tried:
freeswitch@voyage> user_exists brian@microcomaustralia.com.au false
i believe this user should be defined in conf/directory/default/brian.xml, however it is like nothing in conf/directory/default.xml is being read. I want to prove if this is the case or not.
Have a look at /opt/freeswitch/log/freeswitch.xml.fsxml This is the compilation of all the XML files, and it's the file which is actually consulted to do the configuration lookup. If your user entry is in there, then you know that FreeSWITCH has it. Also, make sure the user-agent is configured to register to the domain, not to an IP address.
Try user_exists id <domain> Where <domain> is the output from the command 'eval ${domain}' On Sun, Feb 21, 2010 at 1:21 PM, Brian May <brian@microcomaustralia.com.au> wrote:
Hello,
How do I get a list of all users? Including users that are not registered yet?
(note: I have already changed the domain to microcomaustralia.com.au)
I have tried:
freeswitch@voyage> user_exists brian@microcomaustralia.com.au false
i believe this user should be defined in conf/directory/default/brian.xml, however it is like nothing in conf/directory/default.xml is being read. I want to prove if this is the case or not.
When I try to register I get this error:
2010-02-21 13:09:02.568081 [WARNING] sofia_reg.c:1019 SIP auth failure (REGISTER) on sofia profile 'internal' for [brian@microcomaustralia.com.au] from ip 192.168.87.14
which I think might be because it can't find the matching user entry.
Thanks -- Brian May <brian@microcomaustralia.com.au>
_______________________________________________ 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, I solved one problem. Yes, the user really was there, the problem was I followed the wiki documentation for generating a password hash: echo "username:domain:password" | openssl dgst -md5 This won't work because echo will append a new line; the correct version is: echo -n "username:domain:password" | openssl dgst -md5 I have updated the wiki. Now the client will register, and can make outgoing calls. Incoming calls don't work however, I get the messages: 2010-02-21 14:45:51.400081 [ERR] switch_ivr_originate.c:2387 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED] 2010-02-21 14:45:51.410081 [ERR] switch_ivr_originate.c:2387 Cannot create outgoing channel of type [user] cause: [USER_NOT_REGISTERED] As per one suggestion (as far as I can tell this shouldn't be required) I tried changing this (in dialplan/default.xml): <action application="bridge" data="user/${dialed_extension}@${domain_name}"/> with: <action application="bridge" data="sofia/internal/${dialed_extension}@${domain_name}"/> However that isn't using the registered IP address for the brian@microcomaustralia.com.au user; rather it does a DNS lookup for $(domain_name) and tries to contact that address instead, this is wrong; that DNS address resolves to my webserver, not the jabber client. On 21 February 2010 14:08, Mark Campbell-Smith <mcampbellsmith@gmail.com> wrote:
Try
user_exists id <domain>
Where <domain> is the output from the command 'eval ${domain}'
Curiously that still doesn't work, even though I registered: freeswitch@voyage> eval ${domain} microcomaustralia.com.au freeswitch@voyage> freeswitch@voyage> user_exists id brian@microcomaustralia.com.au false freeswitch@voyage> sofia status profile microcomaustralia.com.au ================================================================================================= Name microcomaustralia.com.au Domain Name N/A Alias Of internal Auto-NAT false DBName sofia_reg_internal Pres Hosts Dialplan XML Context public Challenge Realm auto_from RTP-IP 192.168.86.4 SIP-IP 192.168.86.4 URL sip:mod_sofia@192.168.86.4:5060 BIND-URL sip:mod_sofia@192.168.86.4:5060 HOLD-MUSIC local_stream://moh OUTBOUND-PROXY N/A CODECS IN G7221@32000h,G7221@16000h,G722,PCMU,PCMA,GSM CODECS OUT G7221@32000h,G7221@16000h,G722,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 4 FAILED-CALLS-OUT 4 Registrations: ================================================================================================= Call-ID: advktkbqoyvqmwm@andean.pri User: brian@microcomaustralia.com.au Contact: "Brian May" <sip:brian@192.168.87.14;fs_nat=yes;fs_path=sip%3Abrian%40192.168.87.14%3A5060> Agent: Twinkle/1.4.2 Status: Registered(UDP-NAT)(unknown) EXP(2010-02-21 16:07:39) Host: voyage IP: 192.168.87.14 Port: 5060 Auth-User: brian Auth-Realm: microcomaustralia.com.au MWI-Account: brian@microcomaustralia.com.au ================================================================================================= -- Brian May <brian@microcomaustralia.com.au>
Brian May <brian@microcomaustralia.com.au> wrote:
Incoming calls don't work however, I get the messages:
2010-02-21 14:45:51.400081 [ERR] switch_ivr_originate.c:2387 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED] 2010-02-21 14:45:51.410081 [ERR] switch_ivr_originate.c:2387 Cannot create outgoing channel of type [user] cause: [USER_NOT_REGISTERED]
what does sofia_contact username@microcomaustralia.com.au show? Maybe turning on debug logging at this point would help. /log debug
On 21 February 2010 15:15, Jason White <jason@jasonjgw.net> wrote:
what does sofia_contact username@microcomaustralia.com.au show?
freeswitch@voyage> sofia_contact brian@microcomaustralia.com.au sofia/internal/sip:brian@192.168.87.14;fs_nat=yes;fs_path=sip%3Abrian%40192.168.87.14%3A5060 looks good to me...
Maybe turning on debug logging at this point would help. /log debug
freeswitch@voyage> /log debug Unknown Command: /log debug Only debug I have found is: freeswitch@voyage> sofia loglevel all 9 Sofia log level for component [all] has been set to [9] however that doesn't display any extra information for this test case. -- Brian May <brian@microcomaustralia.com.au>
Brian May <brian@microcomaustralia.com.au> wrote:
freeswitch@voyage> sofia_contact brian@microcomaustralia.com.au
sofia/internal/sip:brian@192.168.87.14;fs_nat=yes;fs_path=sip%3Abrian%40192.168.87.14%3A5060
looks good to me...
It does.
Maybe turning on debug logging at this point would help. /log debug
freeswitch@voyage> /log debug Unknown Command: /log debug
I was assuming you were running fs_cli with FreeSWITCH in daemon mode, as is usual. At the console it's a different command to enable debugging, but I never run FreeSWITCH that way unless I'm trying to deal with a segfault or other startup issue.
On 21 February 2010 16:40, Jason White <jason@jasonjgw.net> wrote:
I was assuming you were running fs_cli with FreeSWITCH in daemon mode, as is usual. At the console it's a different command to enable debugging, but I never run FreeSWITCH that way unless I'm trying to deal with a segfault or other startup issue.
Yes, I should do that too. Seems to confirm what I already know, nothing new though :-( EXECUTE OpenZAP/1:1/1000 bridge(user/1000@microcomaustralia.com.au) 2010-02-21 16:59:56.790081 [DEBUG] switch_ivr_originate.c:1859 variable string 0 = [presence_id=1000@microcomaustralia.com.au] 2010-02-21 16:59:56.790081 [ERR] switch_ivr_originate.c:2387 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED] 2010-02-21 16:59:56.790081 [DEBUG] switch_ivr_originate.c:3185 Originate Resulted in Error Cause: 606 [USER_NOT_REGISTERED] 2010-02-21 16:59:56.800081 [ERR] switch_ivr_originate.c:2387 Cannot create outgoing channel of type [user] cause: [USER_NOT_REGISTERED] 2010-02-21 16:59:56.800081 [DEBUG] switch_ivr_originate.c:3185 Originate Resulted in Error Cause: 606 [USER_NOT_REGISTERED] 2010-02-21 16:59:56.800081 [INFO] mod_dptools.c:2353 Originate Failed. Cause: USER_NOT_REGISTERED -- Brian May <brian@microcomaustralia.com.au>
Ok, not sure what best practise is here... Previously, I had defined the user as such: <user id="brian" number-alias="1000"> This seems to work a lot better if I just register it as the number: <user id="1000"> -- Brian May <brian@microcomaustralia.com.au>
Brian May <brian@microcomaustralia.com.au> wrote:
EXECUTE OpenZAP/1:1/1000 bridge(user/1000@microcomaustralia.com.au) 2010-02-21 16:59:56.790081 [DEBUG] switch_ivr_originate.c:1859 variable string 0 = [presence_id=1000@microcomaustralia.com.au] 2010-02-21 16:59:56.790081 [ERR] switch_ivr_originate.c:2387 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED]
I think it's looking for 1000 rather than the user name, which of course isn't registered. In the extension for the user in your dial-plan, you could always write: <action application="bridge" data="$sofia_contact(brian@microcomaustralia.com.au)"/> or you could use a variable instead of writing the domain name explicitly, of course, which would be better practice.
Jason White <jason@jasonjgw.net> wrote:
In the extension for the user in your dial-plan, you could always write: <action application="bridge" data="$sofia_contact(brian@microcomaustralia.com.au)"/> or you could use a variable instead of writing the domain name explicitly, of course, which would be better practice.
Sorry - there should have been braces in the above: ${sofia_contact(user@domain)} it's the same function you called from the console in response to my earlier post, but this time executed from the dial-plan to perform the lookup.
On 21 February 2010 15:30, Brian May <brian@microcomaustralia.com.au> wrote:
freeswitch@voyage> sofia_contact brian@microcomaustralia.com.au
sofia/internal/sip:brian@192.168.87.14;fs_nat=yes;fs_path=sip%3Abrian%40192.168.87.14%3A5060
Just managed to disable NAT. Just in case. No NAT in use here. freeswitch@voyage> sofia_contact brian@microcomaustralia.com.au sofia/internal/sip:brian@192.168.87.14 I know it is locating my user record, because the voice message I get is "The person at the extension b-r-i-a-n is not available" when I dialled the extension of 1000. However, for some reason it doesn't seem to locate the registration record: === cut === freeswitch@voyage> sofia status profile internal reg brian Registrations: ================================================================================================= Call-ID: advktkbqoyvqmwm@andean.pri User: brian@microcomaustralia.com.au Contact: "Brian May" <sip:brian@192.168.87.14> Agent: Twinkle/1.4.2 Status: Registered(UDP)(unknown) EXP(2010-02-21 18:38:40) Host: voyage IP: 192.168.87.14 Port: 5060 Auth-User: brian Auth-Realm: microcomaustralia.com.au MWI-Account: brian@microcomaustralia.com.au ================================================================================================= freeswitch@voyage> sofia status profile internal reg brian@microcomaustralia.com.au Registrations: ================================================================================================= ================================================================================================= === cut === Ok then, afraid I can't explain this behaviour. Am sure 2nd command was working recently... -- Brian May <brian@microcomaustralia.com.au>
On 21 February 2010 15:00, Brian May <brian@microcomaustralia.com.au> wrote:
As per one suggestion (as far as I can tell this shouldn't be required) I tried changing this (in dialplan/default.xml):
<action application="bridge" data="user/${dialed_extension}@${domain_name}"/>
with:
<action application="bridge" data="sofia/internal/${dialed_extension}@${domain_name}"/>
Just noticed why this change didn't work. According to the example in http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_XML I needed to use <action application="bridge" data="sofia/internal/${dialed_extension}%${domain_name}"/> as "The % behind the username tells FS to lookup the user in it's local sip_registration database" and "If you don't want to bridge a call to a local registered user, but to a SIP URI, use the @ instead" disclaimer: not tested! However this matches exactly was was happening. -- Brian May <brian@microcomaustralia.com.au>
participants (3)
-
Brian May
-
Jason White
-
Mark Campbell-Smith