On Wed, 2009-02-04 at 13:31 -0500, Robert Joly wrote: > > Cam anybody see a way for this multi-branch blind transfer > > scenario to work even when outbound proxy settings are used? > > If not, then I would be forced to conclude that we have only > > two possible options: > > > > 1- declare this multi-site transfer scenario as unsupported; > > 2- resolve the call pick-up/call park target vs. identity > > problem once and for all so that we can lift the requirement > > of configuring outbound proxies. > > > > Any comments?
What is interesting is the semantics of the failure. A phone within ott.example.com generates a request to sip:[email protected]. That URI is *valid* within the desired security of the system, but it can't be generated by a dial string within ott.example.com, that is, it cannot result from mapping a URI sip:[email protected]. So although we want to allow the call to go through, sipXconfig doesn't generate an authrules entry to allow it. This problem bites us in transfer and other scenarios, but the root cause is that the authrules we are generating doesn't match the security we want to apply -- namely, that *any* URI to bos.example.com is acceptable. We could restrict the URIs to bos.example.com to 1xxx and 2xxx, but since bos.example.com is accessible over the Internet, bos.example.com is applying security to all incoming requests anyway, and there is no need to apply security outgoing from ott.example.com. (And since the two domains share no identities, bos.example.com cannot treat ott.example.com extensions specially.) The difficulty, I think, is that we are looking at the mapping of the 1xxx strings as a gateway operation. In fact, 1xxx strings are mapped to a SIP URI, which is then routed as such. Currently, the only way to specify that in the dial plan is to list the host-part as a gateway, which then brings in the gateway-security logic as baggage, which causes problems. I think a better solution would be to have some sort of new dial plan rule which will rewrite the chosen dial strings into URIs at a specified host-port, but does not invoke any gateway security. That is fairly close to Robert's proposal, but it avoids having sipXconfig have to keep track of ott.example.com as an entity: > One > possible way to solve the problem would be to introduce a new type of > gateway called something like "remote sipXecs" which behaves like an > unmanaged gateway with the exception that it is not added to the > 'NoAccess' clause of the authrules.xml. With such an arrangement, a > remote branch would be configured as 'remote sipXecs' (which from a > usability POV, is better than unmanaged gateway) and would not be added > to the 'NoAccess' clause which would allow the transfer to succeed. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
