For those IM's we do check, an alarm message requesting another name be selected would help avoid IM IDs equivalent to exising User name. In my opinion, there are enough name combinations out there that I don't think accommodating new user names equivalent to existing IM IDs is necessary.
-----Original Message----- From: Krzeminski, Damian (BL60:9D30) Sent: Friday, December 04, 2009 3:54 PM To: [email protected] Subject: Re: [sipX-dev] IM IDs as aliases George Niculae wrote: > --- On Fri, 12/4/09, Damian Krzeminski <[email protected]> wrote: > >> From: Damian Krzeminski <[email protected]> >> Subject: [sipX-dev] IM IDs as aliases >> To: [email protected] >> Date: Friday, December 4, 2009, 9:26 PM JIRA is a poor place to have >> a conversation, so I am bringing this here: >> >> Robert writes: >> http://track.sipfoundry.org/browse/XX-7170?focusedCommentId=45877 >> >> "I think that there is one sipXconfig issue that remains. >> Here is the scenario: >> >> If I create a SIP user called 'X' and assign it IM ID 'Y' >> and then I try to >> create a new SIP user called 'Y', sipXconfig will refuse that on the >> grounds that the default IM ID it would assign to SIP user 'Y' would >> collide with the IM ID of SIP user 'X'. >> >> In general, it should be possible to add a new SIP user in sipXconfig >> even if its SIP user ID happens to match the IM ID of another SIP >> user. >> SipXconfig could be smarter in its default IM ID generation to avoid >> such collision (e.g. append a '_2')." >> >> I don't think it's true. I think sipXconfig refuses to create 'Y' >> because of the SIP alias conflict. > > Actually I think Robert is right - it collides with IM ID uniqueness rule and therefore user creation fails. But that's only because the patch for XX-6447 is not in, right? Once we actually start generating aliases we will have to stop people from using IM IDs that collide with SIP IDs. I am trying not to take sides here: I just don't see how we can have both what Robers wants and what Martin wants. >> I still don't think we can have it both ways and - regardless of an >> 'alias issue' - I think that generating default IM IDs that would >> work around naming conflict is a *bad* idea. > > What can be done here is to use an empty IM ID for this case - afterwards enabling the IM Account will fail if a valid IM ID is not provided. > Wouldn't it make enabling IM very awkward? Both from user and from implementation point of view. I don't think that we recheck IM IDs for all group members when enabling IM accounts for the entire group, and cost of doing that is probably prohibitive. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
