 |
 | Vonage Forum Menu |
| | |
| Vonage Forums |
|
|
| | | |
| Vonage In The News |
| | |
| Vonage Customer Reviews |
| | |
| |
Vonage You may see a small decrease in bandwidth when the phone is not in use but when you
You may see a small decrease in bandwidth when the phone is not in use but when you are an an active call, your going to notice a loss in overall bandwidth to the point you may not be happy with.
A static IP on the Vonage adapter and placing that IP in the DMZ would be all that is required. After reading the specs on your model router, it does seem to be a true DMZ not like some of the other routers on the market. This should resolve your issue and the only way to test would be to make numerous phone calls.
You are 100% correct about your statement dealing with the common user and why Vonage does take a hit in the complaint department. Take the issues that are caused by the customer premise equipment and some of the deficiencies of the internet in general and your going to get one unhappy customer because they expect it to work out of the box. In most cases it does without any user intervention.
Without actually seeing a packet capture during an active call when the issue occurs, I cannot be sure but if I had to guess, I would say it comes down to a race condition.
The problem with SPI is that is modifies the headers in the SIP packets. Vonage has a built-in solution to deal with SIP and RTP through NAT. When the source IP of the IP packet header is 1 IP and the SDP / Contact headers are another IP, Vonage knows the user is NAT'd. When an SPI firewall rewrites Contact headers in SIP Registrations so that after the packet passes through the SPI enabled router, Vonage receives the SIP packet with the Contact header as being the Public IP which is the same as the IP header. Therefore user is seen as Not NAT'd. This is bad. Same goes for the SPI firewall rewriting the SDP in the SIP Invite or 200 OK.
On the SIP side, the 20 second quick Registration is meant to keep the pinhole through NAT open which is why port forwarding is not needed on a basic NAT router. When the user is treated as NAT'd, when an Invite on an outbound call or a 200 OK on an inbound call comes from the user, the Vonage media relay will not send any RTP packets until the first packet is received from the user so that the media relay knows what IP and port to send to.
If the SPI firewall rewrites the headers as mentioned and Vonage sees the user as Not NAT'd, the media relay will send RTP packets to the source IP of the SIP messaging and to the port in the SDP instantly. Normally the problem that may occur is that the DOS feature of the firewall will ban the media relay IP for the session since it sees a stream of packets coming from an unknown IP and will only allow the packets in once you start to send packets out. However, some routers are very flakey and can react differently depending upon hardware revisions and firmware.
It is possible that your router is allowing packets in which means you have to have sent at least 1 packet to the media relay on the correct IP and port but for some reason begins to restrict packets out. The issue may become intermittent depending upon whether out not your sent the first packet to the media relay or the media relay sent to you which is where the race condition comes in. And this is also why I am almost 100% sure your SPI is rewriting your SIP headers.
There is one other possibility that could cause an intermittent 1 way audio where no audio is being sent to far end. This would be in the case that there is a broken BGP route somewhere between your ISP and the IP handoff's they use to get to Vonage. Vonage has 4 outbound locations used for outbound calls and depending upon the number dialed, it may use a different location. Even dialing the same number many times may result in a different GW location used due to carrier failover. If this is the case, and your SPI firewall is rewriting the SIP headers, this could result in intermittent 1 way audio with no outbound RTP packet reaching Vonage. If your router is not rewriting SIP headers and this was the case, you would have no audio at all since Vonage would not send you any RTP until it received RTP from you.
Read The Full Thread: Port triggering vs forwarding
• Tech support suggested I disable my firewall to stop the frequent one-way calls
• About 90% of all audio issues related to VoIP is the customer's own firewall / NAT
• Well, that's far more straightforward than what I've been getting from TS. I'm
• I would agree with you on the bandwidth issue if the Vonage device is between the
• There is, perhaps, a fourth option to consider: Change routers.
I've had
• So it has no effect when the phone is not in use?
OK, I've defined a fixed
• I did change routers. I don't think it had any effect. Hard to tell, though, since
• There is, perhaps, a fourth option to consider: Change routers.
I've had
VonTechMgr posted "You may see a small decrease in bandwidth when the phone is not in use but when you" on 06/28/2009 |
|
|
| |
| Vonage Service Plans |
| | |
| Vonage VoIP Members |
|
 Members
 New behm27
 New Today 2
 Yesterday 3
 Total 64296
 Who Is On Site
 Visitors 145
 Members 0
 Total 145
Vonage VoIP Forum Members:
Login Here
Not a Member? You can Register Here
As a registered member you will have access to the VoIP Speed Test, Vonage Service Announcements and post comments in the
Vonage VoIP Forums | | | |
| Vonage Stock Price |
|
Value: 1.70
Change:  -0.03
Up to 15 Minute Delay | | | |
| Site Search |
| | |
|
|
Vonage VoIP Phone Service is redefining communications by offering consumers
& small business VoIP Internet phones, an affordable alternative to traditional phone service.
The Vonage VoIP Forum Generated This Page In: 0.33 Seconds and 193 Pages In The Last 60 Seconds
The Vonage VoIP Forum
|
