Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Avaya SBCE+EMS 7.2.1
- Thread starter Vivek2005
- Start date
- Thread starter
- #3
G van Hamburg
IS-IT--Management
You need four IP adresses on the SBC for CM
A1 (internal) to SM for SIP and PPM (Not in B1 subnet)
M1 for management (Not in A1 or B1 subnet)
B1 for SIP and PPM from outside
B1 for relay http(s) from outside
Plan your work............Work your plan
![[afro]](/data/assets/smilies/afro.gif "[afro] [afro]")
A1 (internal) to SM for SIP and PPM (Not in B1 subnet)
M1 for management (Not in A1 or B1 subnet)
B1 for SIP and PPM from outside
B1 for relay http(s) from outside
Plan your work............Work your plan
- Thread starter
- #5
jimbojimbo
Vendor
Trick question. It depends.
EMS is relatively straight forward. You only need 1 IP Address
The SBC instances themselves would each have a management IP so there are 2 more (Assuming HA with EMS and 2 SBC). These are typically on the same management VLAN/Subnet as the EMS IP.
Now on to the fun part. First of all, A1/A2/B1/B2 are "shared addresses" you only have one address for the HA pair. It will also depend on what you are using for your remote clients and how many session managers are they going to connect with?
For remote workers using the Equinox Client and AADS with only one registration point you can cover just about everything with a single IP Address. PPM relay on 443, AADS relay on port 8443, SIP/TLS on 5061, and a range of UDP ports. You would then only need one DNS.
If you have IP Phones, SIP Trunks and/or redundant Session Managers in a single data center with a single HA SBC you may utilize multiple interfaces (I always separate Remote Worker and Trunk interfaces) and multiple IP Addresses.
With an IP Phone and a single interface you should have at least 2 IP Addresses since both the PPM and HTTP relay will be on port 443 so you put them on different IP Addresses.
Session Managers would be mapped one-to-one so with a primary and secondary session manager you need 2 IP addresses. Add the HTTP relay and you are now up to 3 External. Since I like simplicity and consistency I would map these to 3 internal IP Addresses making 6 total. Add this to the 2 SBC management and EMS management and you have 9 just for the remote worker component. Add an internal and external for SIP trunks on the second pair of interfaces and you are up to 11.
This may be as clear as mud but hopefully it gives you some things to think about.
EMS is relatively straight forward. You only need 1 IP Address
The SBC instances themselves would each have a management IP so there are 2 more (Assuming HA with EMS and 2 SBC). These are typically on the same management VLAN/Subnet as the EMS IP.
Now on to the fun part. First of all, A1/A2/B1/B2 are "shared addresses" you only have one address for the HA pair. It will also depend on what you are using for your remote clients and how many session managers are they going to connect with?
For remote workers using the Equinox Client and AADS with only one registration point you can cover just about everything with a single IP Address. PPM relay on 443, AADS relay on port 8443, SIP/TLS on 5061, and a range of UDP ports. You would then only need one DNS.
If you have IP Phones, SIP Trunks and/or redundant Session Managers in a single data center with a single HA SBC you may utilize multiple interfaces (I always separate Remote Worker and Trunk interfaces) and multiple IP Addresses.
With an IP Phone and a single interface you should have at least 2 IP Addresses since both the PPM and HTTP relay will be on port 443 so you put them on different IP Addresses.
Session Managers would be mapped one-to-one so with a primary and secondary session manager you need 2 IP addresses. Add the HTTP relay and you are now up to 3 External. Since I like simplicity and consistency I would map these to 3 internal IP Addresses making 6 total. Add this to the 2 SBC management and EMS management and you have 9 just for the remote worker component. Add an internal and external for SIP trunks on the second pair of interfaces and you are up to 11.
This may be as clear as mud but hopefully it gives you some things to think about.
- Thread starter
- #7
G van Hamburg
IS-IT--Management
If you translate your wishes into a design then the needed ip-adresses will be clear. I have done over 100 installs and they where all different.
Plan your work............Work your plan
Plan your work............Work your plan
- Thread starter
- #9
- Thread starter
- #10
G van Hamburg
IS-IT--Management
If you use TLS (you better) 5061 for SIP and a range of UDP ports for RTP. Define the same ports in SBC as in your Firewall. 35000 - 40000 is per default. 443 for https relay to the https server and PPM from Session Manager.
Plan your work............Work your plan
Plan your work............Work your plan
- Thread starter
- #12
- Thread starter
- #13
we have installed and configured SBC via TCP(5060)Equinox works on laptop and cellphone( however it stated VOIP services limited connectivity) on laptop / cellphone. how do I resolve this.
Next , we need to setup Equinox connectivity via TLS to do this. we have generated CSR file from SBC
Can I upload the SBC CSR file to SMGR and generate SIP trusted certificate, will it will delete old certificates in SMGR and impact the production.
I need to know the procedure to do that and will it impact the production
Thanks guys!!
Next , we need to setup Equinox connectivity via TLS to do this. we have generated CSR file from SBC
Can I upload the SBC CSR file to SMGR and generate SIP trusted certificate, will it will delete old certificates in SMGR and impact the production.
I need to know the procedure to do that and will it impact the production
Thanks guys!!
G van Hamburg
IS-IT--Management
Check you ‘internal’ trunk, private numbering, aar and routerpattern. All must match in order for PPM to work.
Plan your work............Work your plan
Plan your work............Work your plan
You can sign a cert with SMGR for anything - SBC included. That would make the SBC offer a SMGR-signed cert - much like when your phone connects internally via TLS to SM.
Look in the remote-worker config parts of the sbc documentation. You have to map A1/B1/SM100 in a couple of places.
Just like how the SBC handles the NAT on the media streams that SIP sets up, it needs to do the same with PPM.
That's to say the SBC is smart enough to take your media offer from the core towards the remote worker and change the SDP media description from internal on 172.whatever to the public IP on the SBC's outside interface when trying to get your remote phone in a call.
PPM works the same way - once you register via SIP, an Avaya phone will ask for PPM and SM will provide that back with a list of SIP registrars to use. If you don't have your mapping profiles and "remote access" part of "network configuration" in SM set up right, then you'll register via SIP, ask for and get PPM that says "register to 172.whatever" which will never work from the outside.
You can easily test that with a traceSBC and by proving a non-Avaya SIP client stays up
Look in the remote-worker config parts of the sbc documentation. You have to map A1/B1/SM100 in a couple of places.
Just like how the SBC handles the NAT on the media streams that SIP sets up, it needs to do the same with PPM.
That's to say the SBC is smart enough to take your media offer from the core towards the remote worker and change the SDP media description from internal on 172.whatever to the public IP on the SBC's outside interface when trying to get your remote phone in a call.
PPM works the same way - once you register via SIP, an Avaya phone will ask for PPM and SM will provide that back with a list of SIP registrars to use. If you don't have your mapping profiles and "remote access" part of "network configuration" in SM set up right, then you'll register via SIP, ask for and get PPM that says "register to 172.whatever" which will never work from the outside.
You can easily test that with a traceSBC and by proving a non-Avaya SIP client stays up
- Thread starter
- #16
Yeah. Read up on certificates. That's just having the SBC make a request and asking an authority to sign it. In your case, the authority is SMGR. The only thing that will change on SMGR is in it's CA logs, it'll show it signed a request and generated a certificate for something. It won't change anything about how SMGR functions.
When you import it in the SBC, you can assign it to a TLS profile which can then be applied to a signaling interface. If you're doing TLS before getting a cert signed, then you're default TLS profile in the SBC uses the out-of-the-box certificate.
So, if we had an SBC and wanted to SIP trunk to one another, we could have that SBC issue 2 CSRs for 2 TLS profiles - ViveksAura and KylesAura. Kyle's SMGR will sign one, Vivek's the other. The signaling interface from my SM towards that SBC would use the TLS profile with my SMGR signed cert, and you would use yours. Now, when the SBC connects to my SM, they'll exchange certs both issued by an authority they trust, and when it connects to yours, it'd use the certificate signed by Vivek's SMGR. The SBC would then act as a nice trusted box in between our networks and in both our DMZs. Make sense?
When you import it in the SBC, you can assign it to a TLS profile which can then be applied to a signaling interface. If you're doing TLS before getting a cert signed, then you're default TLS profile in the SBC uses the out-of-the-box certificate.
So, if we had an SBC and wanted to SIP trunk to one another, we could have that SBC issue 2 CSRs for 2 TLS profiles - ViveksAura and KylesAura. Kyle's SMGR will sign one, Vivek's the other. The signaling interface from my SM towards that SBC would use the TLS profile with my SMGR signed cert, and you would use yours. Now, when the SBC connects to my SM, they'll exchange certs both issued by an authority they trust, and when it connects to yours, it'd use the certificate signed by Vivek's SMGR. The SBC would then act as a nice trusted box in between our networks and in both our DMZs. Make sense?
- Thread starter
- #18
Oh, you will. SBC certificate documentation is pretty bad last I checked. In the SBC, the naming of things in most config elements is not relevant - like you can name a "server configuration" "potato" and name it's signaling interface "tomato" and it's fine. The TLS certificate enrollment stuff, it needs the same name for the csr as for the cert you upload. To say, if you make a CSR with name vivek.csr, you'd likely need to rename the file SMGR gives you to vivek.pem to make the SBC accept it. Something like that. It was brutal in 6.3, so hopefully it isn't as terrible now. Read up!
- Thread starter
- #20
I did test the SBC remote works on TLS , however from My Android phone I am able to place calls to the extension( IP Phones )
however, when I dial from IP phone call dont go through to Remote extension( SIP).
I see signaling group of SIP trunk is set to TCP while testing SBC over TCP , Do we need to change the Signalling group setting to TLS on CM.
however, when I dial from IP phone call dont go through to Remote extension( SIP).
I see signaling group of SIP trunk is set to TCP while testing SBC over TCP , Do we need to change the Signalling group setting to TLS on CM.
- Status
Similar threads
- Locked
- Question