Thanks in advance for any assistance provided!
Here is my scenario:
I have a SIP circuit from Verizon, terminated into an Adtran 924e. I am currently using the FXS ports for dialtone into a small key system (Partner). I would like to switch the key system to an Avaya IP Office, but I am having trouble with the config on both the Adtran and the IP Office.
This is what I added to the Adtran config:
interface eth 0/2
ip address 10.101.10.1 255.255.255.248
no shutdown
!
voice trunk T03 type sip
description "IP Office"
sip-server primary 10.101.10.2 (One document I found said this should be IP Office address)
grammar from host local
transfer-mode network
!
voice grouped-trunk IPOFFICE
trunk T03
accept $ cost 0
Any help or insight would be great! Perhaps a sample config for the IP Office (if anyone on this forum even uses them)
Mike,
Thanks for posting! The IP address and voice trunk configuration you have looks correct, except I would add "media-gateway ip primary" to the ethernet interface. Also, my next concern would be if you need NAT configured since you have a private IP address on that interface. Since the Verizon network likely does not have routes to your 10.101.10.0/29 subnet, NAT to your public IP address will be required. Of course, save your current configuration before making any changes. Then, we have several guides which go over our firewall and NAT setup.
Configuring the Firewall (IPv4) in AOS
It is also worth noting that the IP Office should be using 10.101.10.1 as its SIP server. Once this is setup, you can begin to troubleshoot the SIP messaging using "debug sip stack message" to see the real-time SIP messages flowing through the unit. You can verify if the SIP messages are received by the Adtran unit, sent out to Verizon, and view the responses.
Lastly, you will likely need to work closely with Verizon on this change, since they will be the only party who is able to tell you specifically why a test call might be rejected.
Thanks!
David
Mike,
Thanks for posting! The IP address and voice trunk configuration you have looks correct, except I would add "media-gateway ip primary" to the ethernet interface. Also, my next concern would be if you need NAT configured since you have a private IP address on that interface. Since the Verizon network likely does not have routes to your 10.101.10.0/29 subnet, NAT to your public IP address will be required. Of course, save your current configuration before making any changes. Then, we have several guides which go over our firewall and NAT setup.
Configuring the Firewall (IPv4) in AOS
It is also worth noting that the IP Office should be using 10.101.10.1 as its SIP server. Once this is setup, you can begin to troubleshoot the SIP messaging using "debug sip stack message" to see the real-time SIP messages flowing through the unit. You can verify if the SIP messages are received by the Adtran unit, sent out to Verizon, and view the responses.
Lastly, you will likely need to work closely with Verizon on this change, since they will be the only party who is able to tell you specifically why a test call might be rejected.
Thanks!
David
Mike,
I went ahead and flagged this post as "Assumed Answered". If the response on this thread assisted you, please mark it as Correct or Helpful as the case may be with the applicable buttons. This will make it visible and help other members of the community find solutions more easily. If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.
Thanks!
David
So, if I use NAT on ETH0/2 thru PPP1, does it affect traffic on ETH0/1? Just want to make sure I don't affect the normal data.
Mike,
In order to turn on NAT on an interface, the firewall must be turned on. Since the firewall is a global command, it affects traffic on all interfaces. By default, traffic would just be "allowed" on an interface that has no policy class applied. However, traffic on those interfaces would be still be subject to idle timeouts and checked for firewall attacks. If you need traffic to just be allowed though an interface without any potential interference (as thought the firewall was not on), our recommendation would be to create a policy class that allows the traffic with the "stateless" key word applied. Below is a simplified example of allowing traffic through in a stateless manner.
ip firewall
!
interface eth 0/1
access-policy MyPolicy
!
ip access-list extended MatchAll
permit ip any any
!
ip policy-class MyPolicy
allow list MatchAll stateless
The default policy class for an interface has essentially the same internal configuration except it doesn't include the "stateless" keyword.
Thanks!
David
84Mike,
I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.
Thanks,
David