fwd.pulver.com is the "proxy/registrar" where a User Agent (or "UA", in your case the SPA-2100) "registers", i.e. it basically tells it: "If someone calls the number I have with you, pass the call here at the IP address and UDP port number so-and-so". This information is contained in the "Register" message, but sometimes proxy registrars disregard it, and instead use the source IP address and port number of the UDP packet that transported the message. This is because they assume that the content might reflect the internal address of the UA (the one on the LAN behind the NAT). NAT and SIP are awkward bedfellows, and there is an entire bag of tricks developed in recent years to try and make them work together. And still, sometimes they don't :-(
fwdnat.pulver.com:5082 is the "outbound proxy", i.e. the one that your UA contacts when it wants to initiate a call to someone else.
Yes, it does. I forgot on which page it is, but on the SPA-3000 it's in the "SIP" screen in the field "STUN Server:". I set it to "stun.fwdnet.net:3478".
That's not entirely correct. The STUN server is only used by the UA to learn the external IP address of its NAT router, and the type of NAT (full cone, port restricted, symmetrical etc.); the SIP dialogue for the session initiation goes through the outbound proxy (if used, else through the proxy/registrar). The actual RTP streams that transport the voice packets may or may not go through the outbound proxy, depending on the settings of the proxy and the capabilities of the two endpoint UA's (ability to issue re-invites). Unfortunately it's very hard to have two UA's both behind NAT talk to each other directly, so most of the times the RTP traffic is channeled through the outbound proxy.
Yes. But that, at most, requires about 80 kbit/s per conversation (or less, if compressed codecs are used): and not everybody is off hook at the same time...
You are probably confusing "SIP proxy" with "RTP proxy". [Outbound] SIP proxy is where your SIP phone will send a SIP INVITE message. RTP proxy is where the RTP stream will go to (if SIP proxy will decide to engage the RTP proxy and not send the voice stream directly). STUN is not related to the call initiation, it is just a "consulting" service, which allows SIP phone to learn what type of NAT/firewall it is behind.
BTW, there is really good description of NAT traversal issues and possible solutions for ITSP in the "PortaSIP User Guide"