On Tue, 2010-04-20 at 12:05 -0400, Mossman, Paul (Paul) wrote: > George wrote: > > Checked the code and right now we are handling extensions as > > integers - (first, last and next extensions are defined as > > integers in extension_pool table). Since is too late to make > > such a change in this release I propose to keep extensions as > > integers and to track this change in a separate JIRA issue > > (unless we agree that this one is something critical and we > > really have to push it in the current release). > > I had a quick look at the patch. Unless I'm missing something, > First/Last pool extension are the only extension-related settings that > will be treated with the new int validation? > > Those seem OK to me, since I don't think we want the system suggesting > non-integer User IDs. > > > For the benefit of others, the JIRA we're discussing is > http://track.sipfoundry.org/browse/XX-7663 Integer validation in sipx: > Tapestry validator(for integer) accepting invalid input & not throwing > validation error.
I still don't understand why we're treating SIP user parts as integers... they are not integers. Would these fields accept negative numbers? Will they accept digit strings that have leading zeros and preserve them (perfectly good dial strings)? Will they accept numbers that don't fit into 32 bits? _______________________________________________ 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/
