Carolyn wrote: > I think this summary is correct. I'm not sure that it is > worth any work on our part to prevent an admin from doing > something pointless, or to warn them about it - this just > gives us more code to test, translate, ...
I think we should prevent the admin from creating TLS Peer configuration that does nothing. It's the same as not allowing Users with a blank User ID, or Phone Groups with a blank Name. +1 from me for this issue to stand as-is: http://track.sipfoundry.org/browse/XX-8534 TLS Peers must have at least one enabled Call Permission to be have any effect By the way, Carson is implementing a new Authorization Code configuration entity, which will be very similar to TLS Peer: http://track.sipfoundry.org/browse/XX-8533 Add Authorization Code configuration I put the identical 'at least one enabled' requirement on Authorization Codes too. So I think Carson will be able to also fix XX-8534 with minimal incremental overhead versus someone who fixes XX-8534 alone. -Paul [email protected] _______________________________________________ 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/
