I'm trying to get FS working with alphanumeric UserIDs. I'm running into a problem when user1 registers using mixed case (User1@example.com) and then user2 tries to reach user1 by dialing "user1" instead of "User1". FS fails to make the connection between the two extensions and reports: [ERR] switch_ivr_originate.c:2648 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED] The dial plan string for bridging my internal users is: <action application="bridge" data="user/${dialed_extension}@${domain_name}"/> Is there a way to use alphanumeric UserIDs and bridge calls between internal extensions when the dialing user doesn't know exactly how (upper, lower, mixed case) the destination user/extension registered with FS? -- Peter Hinman ParcelPool.com Office: 801-434-7400 Cell: 801-830-8292
What's the user_id of "User1@example.com"? Is it "User1" or "user1"? (BTW, this is a classic example of why alphanumeric usernames are a bad idea in a telephony environment.) I would recommend that you enforce some policy, like always use all lower case. (I've poked around in the source code and I don't see any easy way to make alpha usernames be case insensitive.) -MC On Fri, Oct 1, 2010 at 2:50 PM, Peter Hinman <Peter.Hinman@parcelpool.com>wrote:
I'm trying to get FS working with alphanumeric UserIDs. I'm running into a problem when user1 registers using mixed case (User1@example.com) and then user2 tries to reach user1 by dialing "user1" instead of "User1".
FS fails to make the connection between the two extensions and reports: [ERR] switch_ivr_originate.c:2648 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED]
The dial plan string for bridging my internal users is: <action application="bridge" data="user/${dialed_extension}@${domain_name}"/>
Is there a way to use alphanumeric UserIDs and bridge calls between internal extensions when the dialing user doesn't know exactly how (upper, lower, mixed case) the destination user/extension registered with FS?
-- Peter Hinman ParcelPool.com Office: 801-434-7400 Cell: 801-830-8292
_______________________________________________ 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
It can't be case insensitive. The A1-Hash calculations would not work for the auth/challenge. /b On Oct 1, 2010, at 5:35 PM, Michael Collins wrote:
What's the user_id of "User1@example.com"? Is it "User1" or "user1"? (BTW, this is a classic example of why alphanumeric usernames are a bad idea in a telephony environment.)
I would recommend that you enforce some policy, like always use all lower case. (I've poked around in the source code and I don't see any easy way to make alpha usernames be case insensitive.)
-MC
Hi Michael - thank you for taking a look at the code. The user_ID for User1@example.com is lower case "user1", but the user is able to successfully register as "User1". Policy is good, but it's always nice to be able to enforce policy in code. Is there a way to force all registrations to match the case of the User_ID? I haven't seen anything in the wiki or the book that seemed to do that. Here is an example of one of our user accounts from the directory - are we missing something there?: <user id="adam.smith" number-alias="1001" mailbox="1001"> <params> <param name="password" value = "NotARealPassword"/> <param name="vm-password" value = "****"/> <param name="vm-email-all-messages" value = "true"/> <param name="vm-attach-file" value = "true"/> <param name="vm-keep-local-after-email" value = "true"/> <param name="vm-mailto" value = "adam.smith@ParcelPool.com"/> </params> <variables> <variable name="toll_allow" value="domestic,international,local"/> <variable name="accountcode" value="1001"/> <variable name="user_context" value="default"/> </variables> </user> On 10/1/2010 4:35 PM, Michael Collins wrote:
What's the user_id of "User1@example.com <mailto:User1@example.com>"? Is it "User1" or "user1"? (BTW, this is a classic example of why alphanumeric usernames are a bad idea in a telephony environment.)
I would recommend that you enforce some policy, like always use all lower case. (I've poked around in the source code and I don't see any easy way to make alpha usernames be case insensitive.)
-MC
On Fri, Oct 1, 2010 at 2:50 PM, Peter Hinman <Peter.Hinman@parcelpool.com <mailto:Peter.Hinman@parcelpool.com>> wrote:
I'm trying to get FS working with alphanumeric UserIDs. I'm running into a problem when user1 registers using mixed case (User1@example.com <mailto:User1@example.com>) and then user2 tries to reach user1 by dialing "user1" instead of "User1".
FS fails to make the connection between the two extensions and reports: [ERR] switch_ivr_originate.c:2648 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED]
The dial plan string for bridging my internal users is: <action application="bridge" data="user/${dialed_extension}@${domain_name}"/>
Is there a way to use alphanumeric UserIDs and bridge calls between internal extensions when the dialing user doesn't know exactly how (upper, lower, mixed case) the destination user/extension registered with FS?
-- Peter Hinman ParcelPool.com Office: 801-434-7400 Cell: 801-830-8292
_______________________________________________ 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
_______________________________________________ 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
-- Peter Hinman ParcelPool.com Office: 801-434-7400 Cell: 801-830-8292
participants (3)
-
Brian West
-
Michael Collins
-
Peter Hinman