> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Beeton, Carolyn AVAYA (CAR:9D60) > Sent: Friday, February 12, 2010 8:17 AM > To: Lawrence, Scott AVAYA (BL60:9D30); George Niculae > Cc: [email protected] > Subject: Re: [sipX-dev] XX-7319 - TLS Peer UI proposal > > > -----Original Message----- > > From: Lawrence, Scott AVAYA (BL60:9D30) > > Sent: Thursday, February 11, 2010 4:49 PM > > To: George Niculae > > Cc: Beeton, Carolyn AVAYA (CAR:9D60); Worley, Dale AVAYA > (BL60:9D30); > > [email protected] > > Subject: Re: [sipX-dev] XX-7319 - TLS Peer UI proposal > > > > > > Might it be easier to have sipXbridge raise an alarm when > it rejects a > > connection because the server name does not match? > > If the alarm includes the actual name(s) from the > connection, a human > > being could check them and put the right one into the configuration. > > > > I think this is the best idea. I'll do this. >
The screen we are talking about here is configuring identity mappings for incoming calls. If we find an identity that we recognize in the certificate, we will add a header that tells other components which internal user's permissions to use. If we do not find an identity that matches, this does not necessarily indicate an error condition - just that the system is not configured to apply user permissions to incoming calls. I suppose an INFO level alarm would be appropriate here. In the other direction, an outgoing call over TLS, we may actually reject a connection if the identity found in the certificate does not match the destination we sent it to (I haven't worked out exactly how I will test this yet). In this case, a higher-priority alarm is warranted. Carolyn _______________________________________________ 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/
