Scott wrote:
> On Sun, 2009-04-19 at 19:19 -0400, Andy Spitzer wrote:
> > Woof!
> > 
> > >> I [Damian] actually quite like "Site to Site". Federated 
> system is 
> > >> less graphic
> > > 
> > > +1 on Site to Site
> > 
> > I like site-to-site as well, but isn't it more correctly:
> > 
> > sipXecs to sipXecs
> 
> There's really nothing sipXecs specific about what's 
> happening with this rule type - it's just used for an all-SIP 
> call (which is presumably toll-free and therefor not worth 
> the problems associated with having a permission on it).

Looking at the XCF-3635 description, this will be nearly the same as the
"Custom" type, except that the "Required Permissions" section will be
disabled.  It doesn't need to be an all-SIP call, though typically it
would be.

How about calling this a "Branch" dial rule type?


In the specific case of an all-SIP branch call, is it true that you'll
need to pair this rule with an "Unmanaged gateway" type entry for the
site to be dialed?  (And not a "SIP trunk" type gateway, as that's for
an ITSP account.)

If so, then would this use case also benefit from a "Branch" gateway
type?  It could be a clone of the "Unmanaged gateway" type, with perhaps
condensed Address and Location help text.


Unless... maybe there is ambiguity about the term "branch"?  

To me a branch is simply a remote site, regardless of whether there is a
sipXecs server at that site (and whether said sipXecs server is part of
a HA sipXecs cluster.)

I expect a superadmin creating a dial rule and gateway would understand
that the target must be a distinct sipXecs deployment.  If that is a
reasonable expectation, then I'm sticking with my suggestion of "Branch"
for dial rule the names.


-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

Reply via email to