[omerboyaci]

Hi,
I have problem with broadvoice. I got my sipura 2100 two days ago.
I do not have a public IP address and most probably behind a symmetric NAT. I tried every configuration option "NAT enabled " "stun server enabled"
but I can not register. Then i tried X-Lite, it works for FWD I can
get calls and initiate calls. I also try to configure the SAP 2100 and it also
works even without a stun server, because of the outbound proxy I guess.
In Xlite I open the diognisis window and figure out that when XLite
sends a REGISTER command to BV no 200 OK comes back,
actually nothing comes back. But for FWD everything is ok.
I suspect that FWD outbound proxy works like a HTTP server It responds
to the IPort of the source packet so it comes back. But BV most probably
respond to the IPort pair inside the header of the REGISTER, so it does not
work. Even STUN does not work because BV does not have a stun server,
and if I enter stun server of the FWD it is not working for symmetric NAT
because these two packets destinations are different (1. STUN discovery packet 2. Register packet).

Any suggestion or same situation?

Thanks

[rizsher]

BV works on Xlite?. Then you may want to assign a static IP to the SPA, ,put that IP in the DMZ of the router, and then see if the account registers.

For this, to preclude any other errors, you may want to use BV self provisioning to set things up. If the acocunt works with self provisionin, you can alwats disable autoprovision, and do the setup urself.

[omerboyaci]

Yes I tried but no response is coming for Register commands.

[jperry22]

Which proxy server are you trying to connect with on BV?

[omerboyaci]

proxy.dca.broadvoice.com

[mberlant]

Omer,

You are comparing apples and oranges here. FWD probably works for you because you are using FWD's Outbound Proxy. Outbound Proxy passes all traffic, both control and voice, through the server, which is why many service providers do not offer it as an option.

STUN servers, on the other hand, are simply glorified echo boxes. Your SIP client sends a query to the STUN server and the STUN server replies by informing you of your public IP address and SIP port number. Your client then includes this information in its SIP Register packet, so that your service provider can know where to deliver incoming calls. All STUN servers are perfectly interchangeable.

Unfortunately, your problem is in your router. Symmetric NAT routers are notoriously incompatible with SIP. The problem is that they tend to reassign public-side port numbers in the middle of a "session". In the case of SIP, this "session" is SIP registration and re-registration. In the worst case, which you seem to be experiencing, here's what happens:

Your SPA wants to Register with BV. It sends a STUN query packet to the STUN server of your choice, like stun.fwdnet.net:3478. You request Port 5060, but your router, in an effort to control security, assigns Port 5062 on the public side and sends the packet onward. The STUN server receives the query and responds by putting your public IP address and Port (5062) into the payload of the reply packet. Your SPA receives this information from the STUN server and uses it to send a Register packet to BV. In the Register packet it tells BV, "I am BV 3115552368, password xE5DD43c, public address 12.34.56.78, listening on Port 5062." Your router, however, has not maintained the relationship between your SPA and the public Port 5062, so the Register packet goes out on Port 5067. Needless to say, the registration does not succeed.

That, in a nutshell, is the problem with Symmetric NAT routers.

[omerboyaci]

mberlant Thanks for your detailed answer.
Actually I figure out that maybe the NAT is non-symmetric because the ICHs PCtoPhone app says non-symmetric
and also STUN client.exe report that

C:\>client.exe stun.fwdnet.net:3478
STUN client version 0.94
Primary: Full Cone Nat, random port, no hairpin
Return value is 0x9

So if it is non-symmetric why does not working?

Another question:
I am selecting use OB for BV why it doesn not work? If OB solves the question what is the problem with
OBs proxy server.

Another observation:
And although PCtoPhone connects to ICH X-Lite does not connect,
I ethereal the traffic and saw that PctoPhone uses a protocol different than SIP.

Thanks for your help

[Cyberian75]

Try port forwarding... http://www.broadvoice.com/support_faqs.html#firewall

[omerboyaci]

I do not have any access to the NAT device which is in front of the SPA. It is operated by management and they
do not forward any port.

[deavod]

Originally Posted by omerboyaci

...maybe the NAT is non-symmetric because the ICHs PCtoPhone app says non-symmetric
and also STUN client.exe report that

C:\>client.exe stun.fwdnet.net:3478
STUN client version 0.94
Primary: Full Cone Nat, random port, no hairpin
Return value is 0x9

So if it is non-symmetric why does not working?

Here's a really great little utility that FWD provides. It does a great job at telling you what kind of NAT you've got.

http://downloads.fwdnet.net/netcheck.exe

Try running this utility and see what it reports back.

Another question:
I am selecting use OB for BV why it doesn not work? If OB solves the question what is the problem with
OBs proxy server.

This gets a bit confusing. An outbound proxy will solve your problem because it changes how SIP works. Let me try to explain. Please let me know if this has helped...

Normally when you dial using your regular proxy the proxy acts something like a phone book, telling your device the IP and port of the remote device. This saves you the trouble of having to remember IP addresses and ports for every device you might want to contact. The proxy stays in touch with you to keep up with the progress of the call, etc. But the majority of the traffic will be point-to-point between your SIP device and the remote SIP device.

When you use an outbound proxy this changes everything. Instead of a point-to-point conversation your SIP device will use the outbound proxy to talk. You talk to the proxy and the proxy talks to the other device. This way is almost foolproof through a NAT but it has a very high overhead on the proxy!! That poor server will handle all the traffic for your call. If it was just one user that wouldn't be a big deal, but as you add hundreds of simultaneous calls the network requirements get huge.

So to recap:

• Using an outbound proxy you will have a conversation only with that one server and it will, in turn, talk to the other SIP device for you.
  
  Using the standard proxy you will talk to the remote SIP device directly.

Here's a link to the FWD FAQ that talks about this a little:

http://www.freeworlddialup.com/suppo...etworking#1510

Another observation:
And although PCtoPhone connects to ICH X-Lite does not connect,
I ethereal the traffic and saw that PctoPhone uses a protocol different than SIP.

Thanks for your help

Some of the other voice solutions, like Skype, use a different protocol than SIP. For example Skype uses a proprietary protocol based on a peer-to-peer file sharing protocol.