I think he meant to create just 1 account on sipX for the gateway, not all the hundred users from the legacy PBX.
-MM On Thu, Apr 2, 2009 at 12:17 PM, milosz <[email protected]> wrote: > i wonder how easy it would be to > > (1) pull the list of extensions off your pbx and throw them in an > excel sheet (or something) > (2) use this list to generate a bunch of insert statements for the > users table in sipxconfig > (3) use same list & sip passwords to generate cli statements for patton > > the only lame thing about this is you would have to get an intern or > something to manually click on each user and hit "apply" so the > requisite config files get generated. > > On Thu, Apr 2, 2009 at 10:45 AM, Scott Lawrence > <[email protected]> wrote: >> On Thu, 2009-04-02 at 09:05 +0200, Massimo Vignone wrote: >>> milosz wrote: >>> > you can have the patton route the calls directly to the second gateway >>> > (instead of going through sipx). not sure if that's what you want. i >>> > believe there is an example of it in the smartware manual. >>> > >>> >>> Yes, this is what I've already done, but in a large organization, with >>> several traditional pbxs, doing this way could be a nightmare, because >>> you have t manage all direct connections between gateways. The goal is >>> to have the simplest configuration on the gateway, and use Sipx as a >>> glue between traditional pbxs and/or PSTN. This way I could cut down >>> costs, eliminating the need for directed connections between pbxs and >>> dedicated PRI interfaces to the PSTN. >>> >>> > the other thing you could do is create a user for the 200 extension in >>> > sipx and have the 4960 register it (like with an fxs user). then the >>> > call routing through sipx will work. i can send you an example if you >>> > tell me what release of the firmware you are running. >>> > >>> >>> thanks, but this is not the best way to do that: the gateway is >>> connected to pbxs with hundreds of extensions, so it is not confortable >>> to create users on the gateway for all of them... >>> >>> > again, this is stuff you can email [email protected] about, i have >>> > found them to be very helpful. >>> > >>> >>> I know, but I don't need examples in Smartware configuration: the point >>> is to understand why sipx need authentication when it routes call >>> between gateways, even if rules in the dial plan are set with no >>> particular permission, and if there is a way to bypass/disable >>> authentication. >> >> If there is no permission required by the dial plan _and_ the identity >> in the From header of the gateway-to-gateway request does _not_ match >> that of a sipXecs user, then sipXecs will not challenge the call for >> authentication. >> >> NOTE WELL: this leaves you open to hijacking - anyone who can get a SIP >> INVITE message onto your network can use your gateway to make any call >> they like. I tell you from experience that this can get expensive >> _very_ quickly. Setting up PSTN gateway dial rules with no permission >> is NOT RECOMMENDED, but it's the only way to do what you're asking >> without changing configuration of the gateways. >> >> If you can get the gateway between your legacy pbx and sipXecs to >> authenticate itself (that is, configure a user in sipXecs for the >> gateway and put those credentials in the gateway) it would be much >> better. Note that the user you configure does _not_ need to be the same >> as the identity in the From header for this to work. The From header >> can be the extension on the other pbx and the user the gateway >> authenticates as can be something else entirely - sipXecs doesn't care; >> all it wants is an identity that has the permission required by the dial >> plan. This is a _much_ better approach than removing the permission. >> >> >> >> > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
