> While reviewing the work Hoa Nguyen has been doing on > XX-8646, I realized that there is a restriction on resource > lists that we hadn't taken proper account of: In a single > resource list, all the URIs have to be different. See RFC > 4662 section 4.6 for the official prohibition -- but the > restriction must be obeyed because in a "partial state" > update, the only way the subscriber can tell which resources > have been updated is by recognizing their URIs. > > I haven't checked, but I suspect that sipXconfig does not > enforce this restriction -- a user can enter one extension > multiple times in his BLF list. (Doing that wouldn't make > sense with a desk telephone with a handful of BLFs, but on a > receptionist's console with 60 BLFs, one might want to have a > single extension displayed more than once (e.g., appearing in > several different groups).) > > An alternative strategy would be to have sipXconfig detect > duplicate entries in a resource list and modify them so as to > make them unique, but functionally identical. Doing this > would allow users to enter one URI/extension into his BLF > list more than once. > > In order to make "different" versions of a URI, I think the > best (only?) way is to add a URI parameter whose only purpose > is to make the URIs different. E.g., under the rules of RFC > 3261 section 19.1.4, the following are different: > > sip:[email protected];unique=1 > sip:[email protected];unique=2 > sip:[email protected];unique=3 > > (Although they all compare "the same" with > sip:[email protected], so the latter can't be used in the set.) > > (Note re sipXrls: When mapping a ResourceReference to a > ResourceCached, remember to remove this special > URI-parameter, so all these URIs cache as one URI.) > > So we need to enhance how sipXconfig handles BLF lists. The > user-visible question is whether we allow duplicate URIs in a > BLF list. > > Comments?
Can you think of a use case where it would be required to allow someone to enter a BLF twice because I cannot come up with one? If nobody can find a reason why it makes sense to allow duplciated BLF then, knowing that it muddies the water for partial updates, it seems to me we should disallow it in config. _______________________________________________ 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/
