After some discussion with Scott and Robert Joly, in which Scott clarified the problem, let me put into the record some of what we discussed:
One situation where permissions between federated systems could be useful is: sipXecs A --> (SIP) --> sipXecs B --> gateway --> PSTN In situations like this, the "obvious" solution is for the originating sipXecs, sipXecs A to be able to apply to the call an identity that will be recognized by sipXecs B. This allows the amount of information that is needed to be shared between the two systems to be kept to a minimum, because sipXecs B does not need to be aware of identities in sipXecs A. Note that this does not handle the (quite frequent) case where the originating PBX is a "legacy" PBX, one that can send calls via SIP to another PBX, but since it is not architected in SIP doesn't allow use much freedom to adjust the SIP requests that it sends. That case has to be dealt with separately. It seems to me that if we can adjust sipXecs A, we can get the desired behavior by doing a "coarse-grained" mapping of the users of sipXecs A to sipXecs B. That is, sipXecs A is provided with the credentials of a small number of artificial users of sipXecs B, which are used as aliases for the different *permission classes* of sipXecs A. That is, the mapping is: Identity @ A Permissions @ A Identity @ B Permissions @ B real user 1...@a --> LongDistance --> l...@b --> LongDistance real user 2...@a --> LongDistance --> l...@b --> LongDistance real user 3...@a --> LongDistance --> l...@b --> LongDistance outside cal...@a--> no permissions --> n...@b --> no permissions The first step, from Identity at A to Permissions at A, is done by the normal sipXecs mechanisms. The component that sends the SIP request from sipXecs A to sipXecs B adds a B identity to the request based on the *permissions* the request has in sipXecs A. sipXecs B translates the incoming B identity to permissions in sipXecs B in the normal manner. 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 sipXecs IP PBX -- http://www.sipfoundry.org/
