another switch_ivr_set_user() can't find user
I'm interested in moving some VoIP phones I'm playing with to a different set of network numbers for various internal reasons. However, I'm not looking for multiple FreeSWITCH domains ... I just want one. Here's what I did: 1) On the FreeSWITCH box created a logical network interface and assigned it a number from the new set of network numbers. 2) Changed rtp-ip and sip-ip in internal.xml to use the number assigned to the logical network interface. 3) Per the FAQ set force-register-domain and force-register-db-domain in internal.xml to the value for domain in vars.xml (i.e. the main local ip v4 address of the FreeSWITCH machine). 4) Changed the VoIP phone to use a number from the new set. When I place a call from the VoIP phone FreeSWITCH complains: [WARNING] switch_ivr.c:1941 switch_ivr_set_user() can't find user [default@192.168.14.10] where 192.168.14.10 is the number assigned to the logical interface, however the call goes through / everything seems to work. I'm able to place a call to the VoIP phone from openzap without any complaints. Suggestions / pointers regarding the warning and how to make it happy? -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | -------------------------------------------------------------------------
On Mon, Dec 22, 2008 at 08:10:00PM -0500, John Wehle wrote:
I'm interested in moving some VoIP phones I'm playing with to a different set of network numbers for various internal reasons. However, I'm not looking for multiple FreeSWITCH domains ... I just want one. Here's what I did:
1) On the FreeSWITCH box created a logical network interface and assigned it a number from the new set of network numbers.
2) Changed rtp-ip and sip-ip in internal.xml to use the number assigned to the logical network interface.
3) Per the FAQ set force-register-domain and force-register-db-domain in internal.xml to the value for domain in vars.xml (i.e. the main local ip v4 address of the FreeSWITCH machine).
4) Changed the VoIP phone to use a number from the new set.
All fine so far.
When I place a call from the VoIP phone FreeSWITCH complains:
[WARNING] switch_ivr.c:1941 switch_ivr_set_user() can't find user [default@192.168.14.10]
where 192.168.14.10 is the number assigned to the logical interface, however the call goes through / everything seems to work.
Somewhere in your dial plan, the set_user application is being called with the above user and domain as parameter. http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_set_user The logs should show you which extensions are being executed in the dial plan so you can work out how it reached this point and why it's invoking set_user there. Basically, work through the logic of your dial plan to find out why this is happening. I'm sure others will have more specific advice, but, basically, it has to do with the details of how your dial plan is configured.
You don't have a default user in domain 192.168.14.10, in the default config I used this so that you can set some vars on every call with one call to set_user and it would set all the vars from the default user on the current session. Its best to rip it out the set_user call if you have modified things. /b On Dec 22, 2008, at 10:12 PM, Jason White wrote:
All fine so far.
When I place a call from the VoIP phone FreeSWITCH complains:
[WARNING] switch_ivr.c:1941 switch_ivr_set_user() can't find user [default@192.168.14.10]
where 192.168.14.10 is the number assigned to the logical interface, however the call goes through / everything seems to work.
Somewhere in your dial plan, the set_user application is being called with the above user and domain as parameter.
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_set_user
The logs should show you which extensions are being executed in the dial plan so you can work out how it reached this point and why it's invoking set_user there. Basically, work through the logic of your dial plan to find out why this is happening.
I'm sure others will have more specific advice, but, basically, it has to do with the details of how your dial plan is configured.
participants (3)
-
Brian West
-
Jason White
-
John Wehle