Quote:
Originally Posted by emoci
A few things to try: ...
|
Thank you, Emoci! I understand that it may not be possible to make adjustments on the PSTN numbers, as different firms may operate different ones. And I believe the SIP call-transfer behavior from the service is valid, but was too bad that it exposed this NAT issue locally. Based on some further checking, it appears that DD-WRT (with its Netfilter NAT logic) does not yet support the RFC 4787 best practice of "Endpoint-Independent Mapping" (
http://www.rfc-archive.org/getrfc.php?rfc=4787).
I did not try the other PSTN numbers as their dialing arrangements weren't as direct, but for completeness did try the echo test (sip:*010*600@sipbroker.com) and EziDial. The echo call set up and my RTP stream went out, but no incoming on the LAN side; I didn't probe the WAN side, but suspect the far end did not set up as Symmetric RTP. The EziDial did not work (no incoming call at all), but I tried with a generalized SIP address as I do not have a Voxalot number. However, the sip:*850301@sipbroker.com and sip:1234@loligo.com echo tests work fine here.
Fortunately I'm now in business with the PSTN number. This Nokia E63 phone always sets up its RTP stream with a source port number of 49152, and since that matches the target port of SIP Broker's stream to me, I set up a UDP port forwarding range rule (49152-49155) direct to the phone, and am now up. When at a public hotspot, I may need to switch to the Fring application (RTP media proxying), and that's a fine compromise.
Thanks again and I hope this helps others as well.
ps: I just tried the *600 echo test again, this time on the Nokia (was on the computer) with its port forwarding rule. It ran fine.