> >Martin wrote: >> An external request would be sent to the domain, e.g. [EMAIL PROTECTED] >> The internal mapping after passing through the SBC would >> route this to the sipXecs server, correct? In that sense >> individual phones are not accessible from the outside and >> therefore all requests would pass through the proposed auth >> plugin and get denied. >> >> Is there a use case where the external requester would have >> or could be given a set of credentials so that authentication >> can occur successfully? > >I only yesterday realized that you can put a remote SIP address into a >Speed Dial and actually BLF monitor the remote user. This actually works >because the remote sipXecs does not challenge the Dialog (and Registration) >Event SUBSCRIBEs sent by the local sipXrls. > >Implementing XECS-1606 the way I originally suggested would break this. > >> Would it make sense to make this configurable so that the >> admin at least could disable authentication? > >Yes, makes sense. > >I see next the logical next step you allude to above though. We might even >want to go straight to it instead. > >We could add a configuration table for sipXrls with fields Remote Domain, >User ID, and SIP Password. For local users to be able to BLF monitor users >on a remote system, the admin must add a single entry to this table for the >remote domain. The credentials can be for any user on the remote system, >not necessarily one of those that will be BLF monitored.
To make sure I understand this correctly: For every external domain that is allowed to monitor phones on my system, I would have to add that domain with one common set of credentials to the table. What needs to be configured on the other system then? Where would these credentials go on the sytem or phone of the external domain? I think as a first step this level of granularity would be acceptable. But wouldn't you think that at some point this needs to be broken down by user (i.e. you can monitor my phone but not the CEO's)? > >Then when the local sipXrls has its Dialog (and Registration) Event >SUBSCRIBEs challenged by the remote sipXecs system, it will look to this >new table and use the credentials corresponding to the remote domain >issuing the challenge. > >I think that would deliver a good solution. I also think that it would >eliminate the rationale for adding configuration that would disable >authentication entirely. We will need the sipXconfig team's input. There is a significant number of open issues on the sipXconfig side that need to go into this next release and adding new things is not going to help. Therefore, as a minimum we should be able to turn off aythentication so that we do not break current functionality. --martin > >Thoughts? > > >-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
