hi,
I have a user agent which can only register using numerical usernames (i.e. something that looks like a phone number), but I want to handle the request as if it was send with user's "normal" username (which is alphanumerical). is this doable in ser? can make the REGISTER processing look up this "alias" in a database table?
jakob
You may use numbers as usernames and have nice alphabetical aliases. Registrar does not process aliases -- they only resolve request-uri of incoming requests.
-jiri
At 01:17 PM 2/28/2004, Jakob Schlyter wrote:
hi,
I have a user agent which can only register using numerical usernames (i.e. something that looks like a phone number), but I want to handle the request as if it was send with user's "normal" username (which is alphanumerical). is this doable in ser? can make the REGISTER processing look up this "alias" in a database table?
jakob
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
On 2004-02-29, at 00.20, Jiri Kuthan wrote:
You may use numbers as usernames and have nice alphabetical aliases. Registrar does not process aliases -- they only resolve request-uri of incoming requests.
what needs to be modified so that the users can register using either number or alphanumerical username? I want to be able to use either name or number for registration, and perhaps for authentication too.
can I rewrite the request-uri of the incoming request using a database lookup?
jakob
At 06:15 AM 2/29/2004, Jakob Schlyter wrote:
On 2004-02-29, at 00.20, Jiri Kuthan wrote:
You may use numbers as usernames and have nice alphabetical aliases. Registrar does not process aliases -- they only resolve request-uri of incoming requests.
what needs to be modified so that the users can register using either number or alphanumerical username? I want to be able to use either name or number for registration, and perhaps for authentication too.
I do not understand the use scenario.
can I rewrite the request-uri of the incoming request using a database lookup?
Yes, thats what aliases do. They for example translate 1234 to jacob.
-jiri
what needs to be modified so that the users can register using either number or alphanumerical username? I want to be able to use either name or number for registration, and perhaps for authentication too.
I do not understand the use scenario.
all users have addresses like user@example.com. the same user has an alias like 5551234@example.com (for UAs that cannot handle alphanumerical addresses).
some UAs will send a REGISTER with a To: of user@example.com, some with a To: of 5551234@example.com. both REGISTERs needs update the location records of user@example.com. rewriting 5551234@example.com to user@example.com for INVITE et al can be handled using enum and/or normal alias lookup.
the authentication user could always be required to be user@example.com, but I guess that should be handled separately.
I have a feeling this should be handled like a normal alias on REGISTER processing + allowed 3rd party register.
jakob
At 08:02 AM 2/29/2004, Jakob Schlyter wrote:
what needs to be modified so that the users can register using either number or alphanumerical username? I want to be able to use either name or number for registration, and perhaps for authentication too.
I do not understand the use scenario.
all users have addresses like user@example.com. the same user has an alias like 5551234@example.com (for UAs that cannot handle alphanumerical addresses).
some UAs will send a REGISTER with a To: of user@example.com, some with a To: of 5551234@example.com. both REGISTERs needs update the location records of user@example.com. rewriting 5551234@example.com to user@example.com for INVITE et al can be handled using enum and/or normal alias lookup.
the authentication user could always be required to be user@example.com, but I guess that should be handled separately.
I have a feeling this should be handled like a normal alias on REGISTER processing + allowed 3rd party register.
It seems to me the request to be able to register using different names linked to a primary account removes lot of transparency, which is not good for security and troubleshooting. If you have a mixed environment of fully-fledged and numbers-only terminals, you can use numbers by default and have "nice" aliases.
-jiri
On 29-02 16:02, Jakob Schlyter wrote:
all users have addresses like user@example.com. the same user has an alias like 5551234@example.com (for UAs that cannot handle alphanumerical addresses).
some UAs will send a REGISTER with a To: of user@example.com, some with a To: of 5551234@example.com. both REGISTERs needs update the location records of user@example.com. rewriting 5551234@example.com to user@example.com for INVITE et al can be handled using enum and/or normal alias lookup.
the authentication user could always be required to be user@example.com, but I guess that should be handled separately.
I have a feeling this should be handled like a normal alias on REGISTER processing + allowed 3rd party register.
It is currently not possible to rewrite To header field in REGISTER messages -- registrar will always use the original value (not rewritten).
If you really need it urgently than you can use the following nasty _HACK_: 1) Authenticate user 2) Rewrite To header field 3) Forward the request to the same proxy again (i.e. make a spiral).
The question is if the phone will accept 200 OK with rewritten To as a reply to the original request. The standard transaction matching rules apply here and modified To can make the matching impossible (depending on the implementation).
Another option would be simply register what comes in the message. Usernames in To and digest credentials do not have to match (ser does not care if they match or not unless you explicitely check it in the script).
In this case some phones will be registered with their number, some will be registered with usernames.
To overcome lookup problems (when somebody calls username but the phone is registered with its number) you can create additional lookup table (in addition to location and aliases) and perform the lookup in that table each time lookup("location") fails. The table will map number->username and vice versa. After that you can do another lookup("location") and if it fails again than the user is not registered.
Note that if a user has two phones, one registered with its number and another one registered with username, calls to that user will be not forked to both phones.
Jan.
-
Jakob Schlyter -
Jan Janak -
Jiri Kuthan