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?

Dale
_______________________________________________
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/

Reply via email to