> -----Original Message----- > From: Fowler, Peter AVAYA (CAR:9D10) > Sent: Friday, January 22, 2010 10:00 AM > To: Joly, Robert AVAYA (CAR:9D30); Alfred Campbell; > [email protected] > Subject: RE: [sipX-dev] PA Command Improvements > > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Joly, > > Robert AVAYA (CAR:9D30) > > Sent: Friday, January 22, 2010 9:44 AM > > To: Alfred Campbell; [email protected] > > Subject: Re: [sipX-dev] PA Command Improvements > > > > > So after having used PA for some time now I wanted to get some > > > opinions on the command syntax. > > > > > > The only command I find to be a pain is the call command. > > > Using this from a mobile phone (which I do often) it is a > > total pain > > > to have to type from cell for every call I want to make. > We need a > > > way to set your calling location and/or use some mechanism to > > > determine where you want the call. Right now I type: call > > number/name > > > from cell. Ideally I would like to make it just call number/name > > > > > > Is there a way for PA to remember where the last call was > > made from? > > > So for the 1st call do call number/name from cell and then for > > > subsequent calls I need only do call number/name > > > > > > Opinions... > > > > > > The idea would be to instrument the PA to make an educated > guess as to > > what to use as the 'from <device>' clause when it is not explicitly > > specified by the user. I can think of two ways to do this: > > > > First is for the personal agent to query the client > information of the > > command sender if the call command does not contain a 'from' clause. > > This query returns strings like "Pidgin x.x.x", "Digsby xxx". > > We would have to build a parser that can recognize prevalent > > smart-phone based IM clients and assume that the user meant 'from > > cell' when sending a 'call xyz' from a smart phone client. > > > > The second is to leverage the 'resource' information > element that is > > built into XMPP. When you configure your account > information in an IM > > client, one of the fields you need to populate is the 'resource'. > > That resource helps the system track you when you log into your > > account from multiple places. The resource text can be > chosen by the > > user and is usually representative of where the IM client > is running. > > Typical resource values include "home", "work", "lab", > "laptop". If > > we said as a rule that when a call command does not include > a 'from' > > clause then PA turns to the resource value to see if it > could be used > > as a valid 'from' > > clause then with properly configured resource values, the > user would > > never have to enter 'from' clauses for either cell, work or > home. Of > > course, the reliability of this feature hinges on the users > ability to > > configure things correctly. > > _______________________________________________ > > 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/ > > Does the XMPP server somehow ensure that resource names are > unique? Ie If two clients Login to the same account at the > same time with the same resource name, what will Openfire do?
Then there's a collision and it is up to the server to enforce the resource collision policy, e.g. kick out old, deny new, ... I'm guessing that what you have in mind is a scenario where I have 2 or more IM clients at work. These could not all be using the 'work' resource. We would have to further qualify them to make them unique (work1, work2 for example). > GoogleTalk doesn't provide an interface (that I can find) > that allows one to specify a Resource name. GT server assigns resources. I was thinking more about clients that can connect directly to sipXecs and not come in through serer-to-server fed. _______________________________________________ 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/
