On Thu, Sep 3, 2009 at 9:41 AM, Martin Steinmann <[email protected]>wrote:
> > > > >In general each field can have an "override" attribute (i.e. xml > attribute ) that dictates whether the user is allowed to change it or not. > This can be generated by >sipxconfig. The openfire plugin now simply > overrides all fields with those that are generated by sipxconfig but there > is no reason why this must be true. If "override" is >set to true then I > can compare creation time for the field / fields in question and take the > latest one when populating the openfire database. Clearly, sipxconfig must > >decide carefully about what fields it wants to allow overrides to.. > > > >Martin : I assume you mean "an alias to the user". Why does this make > sense. I thought these were for phone call routing ( like aliases can be > used for DIDs). Why >would it make sense to use the IM ID as a user alias? > Are there any other uses for this? > > > > We would end up with one <name> that could be used to communicate (call or > chat). Damian pointed out that setting the IM ID as an alias would impose > the uniqueness requirements as well as the name space restrictions, but that > might be something we can live with. If you think this does not make sense, > that’s fine too. > > --martin > > > It is an interesting idea indeed but I think it would complicate things for our first cut. I think it would be better to have the caller have the ability to call in via SIP or XMPP and then use the personal attendant to decide which mode of communication is appropriate. For example, a caller may call in via sip but get an XMPP alert if the user is on the phone so the conversation can continue via XMPP and vice versa. For example, if you want to chat, the personal attendant can be set up to try to make a call if the chat initiator's phone call is known or can be provided. Regards Ranga -- M. Ranganathan
_______________________________________________ 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/
