SPA-2102 sending local IP instead of WAN IP in SIP packets

Home » Asterisk Users » SPA-2102 sending local IP instead of WAN IP in SIP packets
Asterisk Users 8 Comments

Hi Guys,

This is such an annoying issue whenever it comes up. The sender and receive
always receive the source public IP no matter what in the IP packets but
then SIP packets go out with something like 192.168.0.20.

In this instance, a Bell Canada DSL modem is installed and I saw the
SPA-2102 register properly but only to fail later on due to sending it’s LAN
IP to the Asterisk server.

So, I put NAT=yes and NAT_ALIVE=yes but that didn’t help at all. I also put
the device on DMZ in the Bell Canada DSL modem and still the same issue.

I am wondering when would manufacturers finally fully comply the SIP RFC?!

I don’t have the luxury to put SIP proxy, do a VPN, install a server or
anything on client site.

Diagram:

Asterisk Server <= Internet = Bell Canada Modem => SPA2102

Please send me your suggestions on how to fix this if you have this type of
experience with SPA-2102

Thanks for the input,
Bruce

8 thoughts on - SPA-2102 sending local IP instead of WAN IP in SIP packets

  • Kyle,

    Got an empty response from you. Were you intending to give your feedback?

    Regards,
    Bruce

  • href=”mailto:extension@192.168.0.10″>extension@192.168.0.10
    href=”mailto:extension@123.123.123.123″>extension@123.123.123.123

    If you set ‘nat=yes’ in the sip.conf peer entry for that device in
    Asterisk, Asterisk will reply to the IP address and port number the
    REGISTER request was received from, not the address in the Contact
    header provided in the request itself. It will also record this address
    and port number as the location of that peer for future INVITE messages
    to be sent to it.

  • And that is exactly what is done on the device: Nat=yes but Asterisk still
    sees the SIP packet coming in to register with a local IP an so it responds
    to a local IP which doesn’t even exist on the Asterisk network. This is what
    frustrates me that it’s not so straight forward to Asterisk to obtain the
    proper public IP of the device from the IP packet headers rather than the
    SIP packets.

    Thanks

    href=”mailto:extension@192.168.0.10″>extension@192.168.0.10
    href=”mailto:extension@123.123.123.123″>extension@123.123.123.123
    href=”mailto:kfleming@digium.com”>kfleming@digium.com

  • Am 09.10.2010 20:34, schrieb bruce bruce:
    when you do a sip debug do you see something like this:

    SIP read from 192.168.0.2 for example
    or do you see the internal ip only in the contact header?

    if its only in the contact header everything is ok. if not you maybe
    have a network problem like SIP ALG on your router.

    Asterisk can only work with the data which are received. turning NAT on
    or off only switch between the IP in the contact header or the source IP
    but if your device in between like a router does something wrong like
    faking packet source ips asterisk cant fix this.

    i dont know what kind of router you use, but have a look at SIP ALG and
    turn this off, if possible.

    best regards

    stefan

  • ‘nat=yes on the device’ doesn’t really make any sense; does that mean
    you set some sort of NAT setting on the *device* itself, or does it mean
    you set ‘nat=yes’ in the device’s peer entry in the Asterisk sip.conf file?

    If ‘nat=yes’ is set in the relevant sip.conf peer entry for that device,
    and Asterisk is properly selecting that entry when the device registers,
    then Asterisk *will* respond the device’s “apparent” IP address and port
    number, regardless of the address the device includes in the Contact
    header of the REGISTER request. Setting ‘nat=yes’ is exactly how you
    tell Asterisk to use the IP address from the IP header of the packet
    instead of the address in the SIP message.

    As I said before, there are likely hundreds of thousands (if not
    millions) of endpoints registering to Asterisk systems all over the
    world every day using this mechanism and it works just fine. If it’s not
    working for you, there is some sort of configuration problem.