IP Office with Avaya SBCE

[BResource]

Hi Chaps,

I am trying to get our IP Office to use an Avaya SBCE without much luck.
In the transport field I have added the address of the SBCE and followed a guide I found online for belgacom trunks but there doesn't seem to be much out there information wise for this.

Has anyone on here has successfully setup and IP Office with this SBCE?

 

[intrigrant]

In our language we name stupid assholes "chap", just to let you know...

I install a LOT IP Office's and never had one installed with a Avaya SBCE and to be honest, I think only a few are actually sold by Avaya for IP Office installs and Avaya isn't really cooperative to hel either.

My advise to you is to trun to the CM forum and try there, I think you get good responses as CM is on another level as IP Office and the SBCE is more a CM thing.
Programming the SBCE for IP Office or CM can't be that much different as a SIP trunk is a SIP trunk on both systems. The only difference as I know is that on CM the registrar and gatekeeper have a different ip address as the media gateway, on IP Office they all have the same ip address.

 

[BResource]

Cheers mate

I will take a peak at the CM forum.

 

[ThreeSTXMAC]

What exactly are you trying to accomplish? a connection to your provider or to the SBC itself? The SBC really is just acting as a SIP firewall (Proxy) for IPO.
Are all the interfaces setup on the SBC? Internal/External/Mgmt? and are they all on separate Vlans? We have been selling all of our IPO Solutions with an Avaya SBC if they are utilizing SIP as a trunking service. We have fought with many of the installs as every provider seems to want to hand off in a different fashion.
All I can say is that you should stress to the customer that a DevConnect provider will make life a lot happier for all people involved. Too many times now we have had SIP "Providers" try and make us re-invent the wheel on our side of the fence in order to signal correctly.
In your SIP line settings make sure that the ITSP domain name is set to the IP address that the provider is expecting you to signal to, and the transport address on the transport tab is the INTERNAL interface created on the SBC itself. What this will do is send traffic from IPO to the SBC internal interface at the transport address but the FROM in the invite packet will show the ITSP domain which typically is what the provider needs to see. You will want to make sure that the "In Service" box is checked in the SIP line config as well. Now if they want you to register the trunk or the calls, that is where things get messy. Since you have an SBC on the edge and not just applying a public IP to LAN2, I would stress heavily to the provider that you want a "trusted IP" connection. There is no reason they cannot do this as it is an SBC to SBC connection. The best way to verify that messages are being sent is to login to the CLI of the SBC itself and do a traceSBC. this will show you any and all traffic trying to hit the SBC, including the provider you are trying to signal to. Based on the packets being sent from the provider you should be able to nail down what it is they want to see. If you are getting 500 messages in your monitor traces, chances are they are actually coming from the far end and not the SBC itself. (This is typically a good sign until the provider is ready to turn-up).