Please see XTRN-1034 Counterpath : Deleting the contacts from the end user phonebook does not delete the contacts on SMC phone. It seems this is as design for SMC soft client: Response from CPath: OK, using WebDAV. Unfortunately no, that's not exactly how WebDAV storage works with the softphones. The intent of the server-based storage (WebDAV or XCAP) is for the softphones to be able to store and retrieve the contact list data from a remote source, so that e.g. two softphones running on different PCs can keep contacts in synch for the same user. The basic premise is that only the softphones make the edits to the lists stored remotely. We don't really support using 3rd party software to modify the content of the list.
The softphone keeps an e-Tag to indicate changes in the remotely held contact list, and if there is ever any conflict in which information to use, the local copy wins. In the case where you simply wipe out lists from the remote storage the local copy will definitely be used. If using 3rd party software or processes to modify the remotely held lists, it has to do exactly as a softphone would, otherwise the results are not predictable. I'd imagine it could work if the server was made to perform the operations and update the e-Tag in the same way that the softphones do but I don't know of anyone ever attempting this. -----Original Message----- From: Yang, Huijun (Huijun) [mailto:[email protected]] Sent: 19 March 2010 17:37 To: Bogdan Brezoi; [email protected] Subject: Re: [sipX-dev] Displaying contacts in SMC softphone question -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bogdan Brezoi Sent: Friday, March 19, 2010 11:46 AM To: [email protected] Subject: Re: [sipX-dev] Displaying contacts in SMC softphone question Yang, Huijun (Huijun) wrote: >> An interesting behaviour observed related to SMC phones. >> > > >> Here's a brief description of the problem: >> > - add from sipXconfig UI a SMC phone. > - create a new user in sipXconfig UI. > - go to user portal and import contacts from a gmail account. Let's assume > the gmail account has only 2 contacts that will be imported. > - go back to admin UI and assign the user as a line to the created SMC phone. > - send profiles to the SMC phone. > > >> Now, register the SMC with the above created line. We should see the 2 >> contacts appearing on the SMC interface. >> > > Next steps: > - from sipXconfig UI, remove and then recreate the earlier mentioned user. > - in user portal import contacts from another gmail account. Let's assume > this one has 4 contacts. > - in admin interface, re-assign the user as a line to the SMC phone. > - send profiles to the SMC phone > > >> After restarting the SMC phone, we should see now only 4 contacts in the SMC >> interface. But we actually see all 6 contacts (the new 4 ones AND the old 2 >> ones) although the <MAC>-directory.xml generated file, only contains the new >> 4 contacts. It seems that the SMC phone somehow keeps contacts data >> somewhere. >> > > >> Is this behaviour expected ? What do you think ? >> Should I open a JIRA for it ? >> > > > It is because SMC "cached" previous configuration data and "skipped" the new > data. There had been several issues related to this, and we managed to get > them fixed/workaround on sipXconfig side. (One example is, > http://track.sipfoundry.org/browse/XX-7406 ). But I think we need to > re-evaluate the way SMC handles the configuration changes. Please open a JIRA > to track this issue first, then we will see what is the proper way to fix > this, i.e. sipXconfig vs SMC. > > Thanks > Huijun > I know about the "caching" and the http://track.sipfoundry.org/browse/XX-7406 issue, it shouldn't be too hard to remember, as I worked on it and prepared the patch :D . I should > have mentioned this issue and its solution. But I don't know if the solution for that particular issue is suitable for this one. > There, we had a number of lines who appeared in the generated configuration > that were overlapping with the old configuration so it was easy to "disable" > the old lines. Let's say we had 5 lines at first and then we send 3 lines. > The first 3 lines were overwritten and the rest of the lines (up to the max. > number of allowed lines) were disabled in the generated configuration file > sent to the phone. > In the current case, I don't think this can be achieved this way, because > there is no limit (as far as I know) for the number of contacts supported by > the SMC phone. > So I think we should go for the SMC handling the configuration changes. It is good that you are the one who had worked and understand the nature of the related issues. I am not saying the same solution for XX-7406 can be used for this case. The reason I listed XX-7406 as an example, was because essentially they are all caused by the way SMC is handling configuration changes, and there is explanation on that in XX-7406 from SMC. That is why I was wondering if we should had fixed XX-7406 in the way we did, IMO, maybe the proper solution is to have it fixed on SMC side, so that we would not have run into this particular case you are running into... But I don't want to jump into the conclusion without really digging into it. So track it so that we will investigate it and find a proper solution. Huijun _______________________________________________ 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/
