On Wed, May 4, 2011 at 11:49 PM, George Niculae <[email protected]> wrote:
> > On Wed, May 4, 2011 at 6:39 PM, Irena Dolovčak > <[email protected]>wrote: > >> Hi, >> >> we have a problem with an high-availability sipxecs installation. we are >> trying to create a sipxecs cluster containing two sipxecs (4.4.0) servers, >> each of them having their own sipxbridge. while we are successful in >> creating the cluster itself, we are unable to dedicate each of the two >> trunks to the appropriate sipxbridges. >> >> our goal is to have one sip trunk from one provider, and another one from >> another provider. if one server would fail, all of our phones would have >> another way to communicate with the world. first we created sip trunk for >> the first provider and assigned it to sipxbridge-1. then we enabled trunking >> server role on the redundant server, and created the second sip trunk, >> assigning it to the sipxbridge-2. although it gave us the choice of choosing >> between sipxbridge-1 and sipxbridge-2 when we were creating the second sip >> trunk, it didn't apply our configuration regarding on which sipxbridge >> should the trunk reside. >> >> we could see that second trunk wasn't applied to the sipxbridge-2 in three >> different ways: >> >> 1) when we would go to the >> DEVICES->GATWAYS->NAME_OF_THE_GATEWAY->CONFIGURATION, under 'Built-in >> SipTrunk SBC' there would still be 'sipxbridge-1', instead of 'sipxbridge-2' >> >> 2) Since our trunk should register with the ITSP, under 'SIP Trunk SBC >> Statistics' in DIAGNOSTICS it was clearly shown that our trunk has >> registered with the ITSP while it was on the first server, not the second >> one. >> >> 3) when we crashed the first server to see if second will make the calls, >> our phones couldn't call external (not sipxecs registered) numbers, while it >> could call all the extensions that were registered with either of the >> sipxecs servers. while going through the logs to see the problem, it was >> obvious that secondary sipxecs didn't know what to do with them, since he >> didn't have those numbers as registered, and since he didn't have a bridge >> to send those calls to. >> >> we tried to do the same configuration with 4.2.1 sipxecs cluster. all the >> configuration was the same, the only difference was that we've installed >> older version of sipxecs, and it worked. all three mentioned ways to check >> if the sip trunk was assigned to the right bridge were ok. also, when we >> tried making a call to the outside world while the first server was down, >> that call was successful. >> >> therefore, we think this is a bug in the new sipxecs version. >> >> Should we open a new jira for the problem? >> >> > Hi Irena, > > yes, please open up a Jira and provide logs on debug > > Looks like sipxbridge.xml generated on secondary is somehow messed up - sipconnect.sipgate.de itsp-account does not have user name / password, however it looks good on the primary, could you verify if copying itsp-account entry for sipconnect.sipgate.de from primary to secondary solves this issue? Check etc/sipxpbx/sipxbridge.xml <itsp-account> <itsp-proxy-domain>sipconnect.sipgate.de</itsp-proxy-domain> <sipxecs-lineids> <sipxecs-lineid>13</sipxecs-lineid> </sipxecs-lineids> <user-name>ELIDED</user-name> ... </itsp-account> Thanks, George
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
