M. Ranganathan wrote: [...]
>>> 1. Accept calls only from configured ITSP accounts. >>> >>> Not a very good solution. The problem of course is you have no control >>> over the ITSPs that your callers will pick. You will effectively >>> restrict inbound calls to only those ITSPs you know about and have >>> accounts with. Unfortunately we cannot authenticate inbound requests >>> from foreign domains ( defeats the whole purpose of unrestricted inbound >>> calling). >> I don't understand why you think that's unreasonable. If I get my phone >> service from BT, I wouldn't expect that interface to get calls from >> NTT. > > > We can restrict it that way. However, the following call would not go through > : > > Currently, if I know your public IP address, I can simply send an > INVITE to num...@sipxbridge-public-ip-address and right now (i.e. in > sipxbridge today), that call will go through. You would not need to > have an account with any ITSP or even be calling from a phone to make > a call to sipxbridge. We will need to disallow this case as you state. > > > We are, however, missing some configuration soupport. We would need to > add some additional support in sipxconfig for cases that do not > require registration but which do send INVITE from an Inbound Proxy ( > not the same as the ITSP Registrar field that we have today). > > I have come across ITSPs that support redundancy where the IB proxy > can be one of a list of addresses (an example of such a setup would be > AT&T) which would require you to know all inbound proxy server > addresses so this would imply we need to support a list of such > addresses in the configuration field (AT&T does not support DNS SRV - > they directly use IP addresses for configuration). Is this really useful? How would administrator know what is the set of IP addresses that should be configured here? I suppose that misconfiguration here results in really erratic behaviour. If I do configure that - what do I really gain: after all in most cases it's much easier to reach my system directly ([email protected]) rather than through my sipXbridge (nu...@sipxbridge-public-ip-address) [...] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
