On 2004-02-29, at 00.20, Jiri Kuthan 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. can I rewrite the request-uri of the incoming request using a database lookup? jakob

all users have addresses like user(a)example.com. the same user has an alias like 5551234(a)example.com (for UAs that cannot handle alphanumerical addresses). some UAs will send a REGISTER with a To: of user(a)example.com, some with a To: of 5551234(a)example.com. both REGISTERs needs update the location records of user(a)example.com. rewriting 5551234(a)example.com to user(a)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(a)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

On 29-02 16:02, Jakob Schlyter wrote: 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.