Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Clancy]

OK, last post here because I can't type or sit up in my chair from laughing so hard.

[Fatman]

I live to serve mi'lord!

[GVG]

I am running two PAP2T units with a DIR-655 and using ViaTalk and I have no such errors or problems like you are describing.

I dont use DMZ, port forwarding or any other special settings. The only thing I did was turn off the ALG for SIP and everything works perfectly.

I think you need to look beyond your router to your modem or maybe even your ISP.

[Clancy]

i think you need to look beyond you router to your modem or maybe even your ISP.

I'm giving you a Karma point before you go negative for your last remark. Perhaps you are unaware that these boards are only for berating D-Link products and the engineers who moderate. 

[Fatman]

I am glad you are having no issues, and with two of them no less.

That gives me a lot of hope we can get Tsumeone straightened out.  As it proves at least one person has a working STUN implementation from behind a DIR-655 and is getting SIP through just fine.

His problems appear to be based strongly on getting the RTP streams forwarded, and potentially with a secondary SIP issue.  It is very possible your SIP provider is running a more vanilla implementation of SIP that our router understands how to handle and that we may come to the conclusion that we are at an impasse between the router and the service.

That said, I am going to beat on my old drum, once we have captures we will know what the issue is.

So, Tsumeone, how go those captures?

P.S. Clancy that sig is only going to feed my ego, are you really sure you wanna go there?

[GVG]

There are some STUN settings in the PAP2 that can be changed to make SIP work better. VIATALK knows the settings, and I also use VIATALKS STUN server.

[Clancy]

P.S. Clancy that sig is only going to feed my ego, are you really sure you wanna go there?

Well, yes. You are like a big brother. The one you go run and hide behind when someone wants to beat you up. You can take a punch, can't you? I was so in awe of your omnipotent power when you revealed that you have the ability to both reward and punish, or obliterate, that I'd better suck up to you like a Sears Shop Vac. Wipe that ugly thought from your mind right now. I ain't that kind of Vac. Now, please help me steer this thread back onto the highway with the light from your Karmic 3rd eye.

[javamarc]

SIP ALG works perfect with firmware 1.11 and my PAP2T. The PAP2T employs his local (192.168.x.x) IP address as if it was part of global IP space. The DIR 655 ALG exchanges this address for the true external address (from my ISP) within all outgoing SIP/RTP packets. It works perfectly! You can disable all NAT traversal options in the PAP2T user interface.

This didn't work with any 1.2 firmware. I would love to upgrade to 1.3x, but as long as nobody can confirm that SIP ALG works in 1.3 it's not an option.

[GnetHome]

"There are some STUN settings in the PAP2 that can be changed to make SIP work better. VIATALK knows the settings, and I also use VIATALKS STUN server."

I'm having the same problems with the DIR-655 (firmware 1.21) and PAP2T.  I can't even get a connection and receive the same ICMP outgoing errors.  I've opened the 5060-5080 incoming to the local IP (192.168.0.198).  I've also turned off the SIP ALG.  Still no effect.  The last thing my VOIPo support said was "Your network is blocking our STUN connection, which is typical of some kind of built in routing firewall.  Sounds like you have some serious connection problems from the adapter."

I'll try a DMZ to the port to see if that helps.  I'd like to know what might be changed on the PAP2T that might help.  Can I or should I roll the firmware back to ver 1.11?

[Fatman]

I had forgotten about this thread it had been so long since we had a post here.

I don't believe you can do that downgrade.

So Tsumeone, any results?

[gerritv]

Hi
I just posted similar sounding problem on the  DIR-615 (http://forums.dlink.com/index.php?topic=5716.0). Same symptoms, no ring when dialing out. Rings when dialing in but when I pick up it keeps ringing.

DIR-615 can't roll back either...
Fatman: Is there a way to get syslogs out of the router to help you? The debug log from the PAP2 doesn't show much.

[Fatman]

Not really, what we need are captures as described in this thread.

[gerritv]

Fatman:
Is this format ok for the dump? I will do a trace for the dir615C (with 3.10NA) and for the dir524 (which works)
11:53:12.625824 IP sbproxy01.sip > yoyo345.sip: SIP, length: 436
11:53:12.626025 IP sbproxy01.sip > yoyo345.sip: SIP, length: 501
11:53:12.626201 IP yoyo345.sip > sbproxy01.sip: SIP, length: 602

BTW, this is not directly related to using a PAP2T, it also fails on calls to my PBX from outside (when using the 3.10NA on DIR615.
Since I am doing this with a DIR615 do you prefer that I post in that section or shall we assume (for now) it is relevant to DIR655 as well?

[gerritv]

FYI, I reverted back to 3.01 on the DIR615C. See thread http://forums.dlink.com/index.php?topic=5716.0 for details on how this is done, in spite of DLink saying that you can't downgrade the version.

Fatman: I have some traces of the style shown above. They are DIR524-call and idle with matching call and idle from DIR615C with 3.10NA. I am not likely to upgrade to 3.10NA again anytime soon as I need to get on with other things, like a new PBX and WHS.

[Fatman]

Thanks for your assistance, the key part of what we needed with the captures was a simultaneous capture from both sides of the NAT during a failed and non failed call (if such things exist) so we can see at the packet level if we have any deformation or drops.