On Mon, 2009-09-21 at 11:49 -0400, Huijun Yang wrote:
> - Create unique identity for each peer system configured, which does
> not to be visible from the UI, could be something like ~~peer~{peer}
You would want to create a new group of special URIs, such as
"~~pr~{name}" or "~~pe~{name}". (The "name" part may be just an
internal sipXconfig identifier.) See
sipXregistry/doc/service-tokens.txt for a list of prefixes that are
already in use.
> But after thinking it a bit, I am not sure we need to extend
> site-to-site and sipTrunk to include peer system info. To me, a peer
> system will be just like a virtual user to the local system, and admin
> will grant whatever permissions to it to allow it to access dialplans
> on the local systems. For example, if LongDisance permission is
> granted to the peer, then PSTN calls from the peer system will be able
> to access dialplans that require LongDistance permission. In other
> words, peer system will be handled just as it is a user in the local
> system based on its permissions. If we allow to configure permission
> to a peer system, then the existing dialplan handling should be
> sufficient to handle it. There should not be a need to modify
> Site-to-Site or sipTrunk to specially handle the peer system to access
> dialplans
Yes -- the rule we have been following is that the permissions of the
caller do not affect what destination(s) a dialstring identifies, they
only affect whether the call is allowed to reach each destination. That
makes call routing much easier to understand and debug.
On Mon, 2009-09-21 at 12:18 -0400, Huijun Yang wrote:
> I am proposing to have a new
> page, that you can create a peer, which include peer name, certicate,
> permissions, etc. and underneath, system will create an itentity for the
> peer, and as you suggested, there is no need to expose the identity on
> the UI.
That sounds sensible to me.
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/
