I am going to take the liberty of boiling your post down to a single sentence of value and I will discuss a couple of other interesting phrases of no real value afterwards.
I'd like you to tell me what you want me to do to prove to you that the DIR-655 is indeed causing the problem. What proof, specifically, do you want?
You are absolutely right to tell me to put up or shut up. Here is the issue, in a perfect world I would want the below.
Access to a device identacle to your VoIP device, I know you offered to loan us yours, but I don't think I can take you up on that offer. Which means I need the next best thing, which is the below list.
- A config file from your DIR.
- A packet capture of half a dozen normal phone calls taken without the router in place.
- A packet capture form the WAN side of the router showing half a dozen calls. This capture should cover from the power up of the router, through the power up of the device, and finally the calls.
- A packet capture from the VoIP device showing half a dozen calls. This capture should cover from the power up of the router, through the power up of the device, and finally the calls. These would ideally be the exact same calls as the above (router WAN) capture, and would come with an exact time difference listed so I can make use of the timestamps in both captures as representing the same time.
This would show pretty clearly if this router is dropping or mangling any traffic. The rub is that this kind of difficult to get all this information, you would need a hub or switch capable of doing port mirroring (2 if you are going for the preferred form on the 2nd and 3rd captures). It also requires a bit of experiance to set up this test environment.
Short of the above we are in dangerous waters, as we don't have any logged relevant dropped traffic and if I read correctly the call still goes through it just has a silent delay (which I might add is really weird). Those together tell me the problem is either not a dropped packet that would be logged (I know of nothing that wouldn't be logged, but this isn't my product), or it is one that is dropped because of an issue such as NAT incompatability (have you tried any other routers?). If NAT compatability is the issue you would not see a dropped packet because the dropped packet would be on your providers side. That said that isn't my first thought because the call eventually goes through, maybe it is some sort of NAT failover on your providers side, there is no way for me to tell.
My cop out for the day is the fact that SIP was never designed to work in a NAT environment.
So the question becomes, could you provide the above list of requisites, or any significant portion thereof?
It was directed to one specific member in this forum who has no idea what he is talking about but HAS to comment in every thread. I was hoping to nip it in the bud, without mentioning said user's name. My apologies if I offended you.
No worries, I am much harder to offend than that, I am also attempting to stand between users with beef. My biggest point was that opening with a salvo like that guarentees a response in kind.
omnipotent D-Link technical engineer
This however offends me, I am not omnipotent because I am a D-Link employee, I am just plain omnipotent! The other D-Linkers, varying degrees of less so.
If only I was omnipresent I could solve this issue for you, but as is descussed above I can't predict the issue and this leaves me rather omnimpotent in that department.
*** modified by Fatman because he can't leave well enough alone and wants to play with bbcode formatting.
Author
Topic: Linksys PAP2T and DIR-655 problem in EVERY firmware version... (Read 33926 times)