adding voip vlan to switch
I have a cisco switch in a remote site that users are connected to and thats connected to the local cisco firewall, that has a vpn site to site connection to corporate.
In corporate I have installed IP phones and everything is going fine. However, I installed a IP phone in the remote site and it connected to the voice system and downloaded its updated firmware etc but when dialed it rings but no voice and when they call corp my phone rings but no voice.
I noticed that on the IP phone in the remote site it's not getting an IP address from the Voice VLAN that I set up in corp. I figure I need to configure the switch in the remote site with the approriate vlans so it can communicate but how? Data between the 2 sites transfers fine.
Thanks.
In corporate I have installed IP phones and everything is going fine. However, I installed a IP phone in the remote site and it connected to the voice system and downloaded its updated firmware etc but when dialed it rings but no voice and when they call corp my phone rings but no voice.
I noticed that on the IP phone in the remote site it's not getting an IP address from the Voice VLAN that I set up in corp. I figure I need to configure the switch in the remote site with the approriate vlans so it can communicate but how? Data between the 2 sites transfers fine.
Thanks.
I have a feeling your RTP is being blocked by a firewall, the ringing is a setup message from the call manager server, the RTP stream is then setup between the two phones, if you don't have inspection on your firewall for the port change or even disallowing the subnet to subnet it won't work.
As for the voice vlan, how has it managed to talk to the call manager server and download its firmware without option 150 being delivered by a DHCP server, you would only have this setup on the Voice DHCP subnets. For future reference the following will deliver a voice vlan to the phone:
switchport voice vlan XXX
However I have a feeling this is not your problem as the phone gets its files and even receives setup messages, like I said, check inspection and try allowing all UDP ports between the two phone subnets.
As for the voice vlan, how has it managed to talk to the call manager server and download its firmware without option 150 being delivered by a DHCP server, you would only have this setup on the Voice DHCP subnets. For future reference the following will deliver a voice vlan to the phone:
switchport voice vlan XXX
However I have a feeling this is not your problem as the phone gets its files and even receives setup messages, like I said, check inspection and try allowing all UDP ports between the two phone subnets.
ASKER
the phone was able to download the firmware from the call manager because I manually put the IP addresss of the call server in the phone, so it was able to contact it.
there is a hardware vpn site to site connection between the remote site and corp. how do I enable RTP on my corp firewall between the 2 sites?
there is a hardware vpn site to site connection between the remote site and corp. how do I enable RTP on my corp firewall between the 2 sites?
ASKER
Did a capture with wireshark and 192.168.75.115 is the IP phone, 10.1.10.35 is the Avaya server. Any relative information we can get from this?
capture.JPG
capture.JPG
What firewall is it? Have you allowed the phone subnets over the VPN also?
ASKER
I got it working by unchecking the "Allow direct media path" in the Avaya system under the users extension. Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Although, it solved my problem, I'd like to solve it the proper way. Pleae do not close the ticket.
sb1mpo,
I just found out that what I did, although works, can cause problems down the road. Please let me know what I need to do on my firewall to allow this to communicate.
This is a comment I received from a Avaya technician:
By requiring the endpoints to fork through the IPO chassis you are also consuming your DSP resources.. which could leave you with insufficient resources for TDM to IP conversion.. You have a routing or blocking problem between the two networks. Signaling packets go directly between the IP Deskphone and the IP Office. Normally, voice packets go directly between the IP Deskphone and another IP Deskphone.
By unchecking the "Allow direct media path", you are forcing the voice packets to go from the IP Deskphone to the IP Office and then to the other IP Deskphone. This probably works around your packet routing issue and provides operation. On the downside, this will add delays into the connection so I would still encourage you to find and resolve the packet rouing issue.
sb1mpo,
I just found out that what I did, although works, can cause problems down the road. Please let me know what I need to do on my firewall to allow this to communicate.
This is a comment I received from a Avaya technician:
By requiring the endpoints to fork through the IPO chassis you are also consuming your DSP resources.. which could leave you with insufficient resources for TDM to IP conversion.. You have a routing or blocking problem between the two networks. Signaling packets go directly between the IP Deskphone and the IP Office. Normally, voice packets go directly between the IP Deskphone and another IP Deskphone.
By unchecking the "Allow direct media path", you are forcing the voice packets to go from the IP Deskphone to the IP Office and then to the other IP Deskphone. This probably works around your packet routing issue and provides operation. On the downside, this will add delays into the connection so I would still encourage you to find and resolve the packet rouing issue.
ASKER
Although, it solved my problem, I'd like to solve it the proper way. Pleae do not close the ticket.
sb1mpo,
I just found out that what I did, although works, can cause problems down the road. Please let me know what I need to do on my firewall to allow this to communicate.
This is a comment I received from a Avaya technician:
By requiring the endpoints to fork through the IPO chassis you are also consuming your DSP resources.. which could leave you with insufficient resources for TDM to IP conversion.. You have a routing or blocking problem between the two networks. Signaling packets go directly between the IP Deskphone and the IP Office. Normally, voice packets go directly between the IP Deskphone and another IP Deskphone.
By unchecking the "Allow direct media path", you are forcing the voice packets to go from the IP Deskphone to the IP Office and then to the other IP Deskphone. This probably works around your packet routing issue and provides operation. On the downside, this will add delays into the connection so I would still encourage you to find and resolve the packet rouing issue.
sb1mpo,
I just found out that what I did, although works, can cause problems down the road. Please let me know what I need to do on my firewall to allow this to communicate.
This is a comment I received from a Avaya technician:
By requiring the endpoints to fork through the IPO chassis you are also consuming your DSP resources.. which could leave you with insufficient resources for TDM to IP conversion.. You have a routing or blocking problem between the two networks. Signaling packets go directly between the IP Deskphone and the IP Office. Normally, voice packets go directly between the IP Deskphone and another IP Deskphone.
By unchecking the "Allow direct media path", you are forcing the voice packets to go from the IP Deskphone to the IP Office and then to the other IP Deskphone. This probably works around your packet routing issue and provides operation. On the downside, this will add delays into the connection so I would still encourage you to find and resolve the packet rouing issue.
ASKER
I got it working by unchecking the "Allow direct media path" in the Avaya system under the users extension.
Now, on top of that I don't think your issues is that. There is something else involved. I have a feeling the sip is being blocked by your firewall. I have a feeling it's just a minor routing issue and not a vlan.