24 thoughts on - Update Peer IP Address

• Hello Daniel,

  I’ll find myself in the same situation a few weeks from now 🙂

  I think the solution – for the inbound issue at least – could be to add more hosts as a peer. Have a looks at this forum post:

  http://www.ip-phone-forum.de/showthread.php?t=268787&p=1999371&viewfull=1#post1999371

  The user used a template and than he added peers, each with its own IP
  address. The provided list was last updated in 2014, though, so I assume the provider in the meantime has added to that list.

  It looks pretty tedious, though, I mean there could be dozens of IPs you’d have to add. But I guess this is the way to go with Asterisk 11
  and chan_sip.

  The future looks brighter 🙂 I read that with pjsip, which I understand is the replacement for chan_sip, you can have one peer entry and match an IP range instead of a single host. That should tidy up the dialplan.

  What I’m a little afraid of is the SIP provider using IPs out of a range that they also use for other services. Maybe out of the same range they hand out IPs to their customers. I guess we got to be careful 🙂

  Kind regards, Sebastian

  —

• Hello Sebastian,

  I had already seen this list of the hosts, but it is not active. All servers with which my Asterisk has been communicated are not listed.

  A port scan, to eventually update the list, found hundreds of servers provided in the address range 217.0.0.0/13 with open port 5060, some were even not found. I think there must be another solution.

  If I change insecure to insecure=port,invite – could that be a solution?

  Or should I try to change to res_pjsip (upgrade to Asterisk 13 is no problem)? Has there anyone experience with dynamic ip addresses of Asterisk?

  Daniel

• Maybe someone could elaborate on my first question again.

  If the ip address changes while a REGISTER period, the ip address of the peer isn’t been updated. How can asterisk update the ip address of the peer?

• You have two options for dealing with an IP change during the registration period:

  1) set the registration time to shorter period of time to minimize the downtime

  2) detect that the IP address has changed via whatever method available, and then issue a “sip reload” CLI command to asterisk, which will cause it to resend registrations immediately.

• Scott, thank you four your reply.

  I had already though about both options, but the problem is, that after an ip change AND a new registration the ip address of the peer is not updated automatically. INVITES are answered with 401.

  Only after a sip reload the peer works again.

  That can’t be normal…

  Daniel

• ——=_NextPart_001_0026_01D06C68.4A62EC60
  Content-Type: text/plain;
  charset=”UTF-8″
  Content-Transfer-Encoding: quoted-printable

  If I correctly understand what the problem is, what I did was write a script that runs out of CRON every 15 minutes. It checks the outside IP address by querying http://checkip.dyndns.org and compares it to the IP address stored in the parameter “externip” in the [general] section of sip.conf. If the two values are the same, the script exits quietly. If they are different, the script updates “externip” with the new address, does a sip reload, and shoots me an email saying there was an update. It’s a fairly simple and straightforward process and does the job. I use this script for all PBX’s that are behind a NAT. I hope this helps.

  Regards;

  John

  From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] Hello

  I use Asterisk 11 with FreePBX 12. Our SIP Provider is Telekom Germany. We have sometimes problems with incoming and outgoing calls. I hope I can explain it understandable.

  Hello Daniel,

  I’ll find myself in the same situation a few weeks from now 🙂

  For example, Asterisk sends a REGISTER to 217.0.23.68 (tel.t-online.de
  <http://tel.t-online.de/>), the message is answered with OK and the peer is registered.

  Usually INVITES comes now from this ip address. All works fine. But sometimes INVITES comes from an other IP address, for example
  217.0.23.100. This request Asterisk responds with 401 Unauthorized.

  In the next register procedure REGISTER are sent to the new ip address and answered also with OK. But qualify OPTIONS are continue be sent to the old ip address. Incoming and outgoing calls are canceled. Outgoing calls are answered with Forbidden.

  Even if the REGISTER procedure works with the new ip address, the peers are connected with the old address.

  Waiting doesn’t help, only a „sip reload“ update the ip address of the peer.

  What is the solution for this problem? How can asterisk update the peer?

  I think the solution – for the inbound issue at least – could be to add more hosts as a peer. Have a looks at this forum post:

  http://www.ip-phone-forum.de/showthread.php?t=268787 <http://www.ip-phone-forum.de/showthread.php?t=268787&p=1999371&viewfull=1#post1999371> &p=1999371&viewfull=1#post1999371

  The user used a template and than he added peers, each with its own IP
  address. The provided list was last updated in 2014, though, so I assume the provider in the meantime has added to that list.

  It looks pretty tedious, though, I mean there could be dozens of IPs you’d have to add. But I guess this is the way to go with Asterisk 11
  and chan_sip.

  The future looks brighter 🙂 I read that with pjsip, which I understand is the replacement for chan_sip, you can have one peer entry and match an IP range instead of a single host. That should tidy up the dialplan.

  What I’m a little afraid of is the SIP provider using IPs out of a range that they also use for other services. Maybe out of the same range they hand out IPs to their customers. I guess we got to be careful 🙂

  Kind regards, Sebastian

  The Asterisk is local behind a NAT with a firewall, following settings are used:

  externhost with DynDNS stun with stun.t-online.de
  <http://stun.t-online.de/> nat=yes srvlookup=yes allowguest=no trustrpid=no insecure=invite qualify=yes

  Thank you! Daniel

• John,

  thank you four your answer. I think you have misunderstood the problem. It’s about a ip address change of the sip trunk, not of my asterisk server.

  Kind regards, Daniel

• You would probably benefit by enabling the DNS Manager to allow for dynamic IP changes:

  # cat dnsmgr.conf
  [general]
  enable=yes ; enable creation of managed DNS lookups
  ; default is ‘no’
  refreshinterval=180 ; refresh managed DNS lookups every seconds
  ; default is 300 (5 minutes)

• Hello Daniel,

  I’ve asked myself that, too. But I don’t have access to the connection, yet, so I can’t test it right away.

  Kind regards, Sebastian

• Hello Andres,

  I read that same suggestion elsewhere in connection with Deutsche Telekom, so it seems there’s some benefit in it.

  Daniel, did you try it out already?

  Kind regards, Sebastian

  —

• Ok, I have tested dnsmgr. This is not a solution, the situation has not changed. With dnsmgr I can not place outbound calls. I do not know why and what dnsmgr really do. My current solution is as follows:

  Say allowguest=yes, configure the default context that there can not be placed outbound calls. Use iptables to DROP all at your SIP port and allow only your local phones and the sip trunk ip range. I think srvlookup must be set to yes to place outbound calls if there is an ip address change.

  I think with the restriction of the firewall that should be a secure solution.

  —

• ​I’d be curious if setting

  insecure=invite,port

  makes any difference either (without alllowguest on).
  ​

• Scott, I have changed the configuration as said it and will test it. I’m curious.

  Can you briefly explain what insecure=invite,port does?

  ;insecure=port ; Allow matching of peer by IP address without
  ; matching port number
  ;insecure=invite ; Do not require authentication of incoming INVITEs
  ;insecure=port,invite ; (both)

  Do I understand correctly that in this mode the IP address is not checked and no authentication is required?

• Not correct, the IP address is checked but not the port and if the ip address matches no password authentication is performed for the Invite.

• Actually, the IP address is still used to identify the incoming invite. With the insecure=port option set, Asterisk will presume the invite to still match the trunk account even if the NAT router has mangled (changed)
  the port number. My suspicion is that when the new register goes out, it’s creating a new state in the firewall, resulting in a new port number, which is why you would have to allow anonymous calls to then accept it without insecure=port. The other possibility is that you have a port forward in the router set, which is similarly mangling the port number. With a valid registration being held, and assuming the router does not drop UDP states faster than 30 minutes, and also assuming that the provider is sending you invites on the registered port rather than always on 5060, there should not be a need for an inbound port forward to Asterisk, and you should not need insecure=port.

  The invite option disables authentication – which means only that Asterisk will not force a check of the password on the other end. Where the IP
  address is well known and trusted, the extra overhead and delay of authenticating incoming INVITEs is not needed.

• Okay, Scott, I think we are on the wrong path. Maybe I’m wrong though.

  I will summarize again briefly the problems together:
  The peer ip address could be another than the ip address of incoming invites After an re-register the REGISTER is send to the new SIP server, answered with OK. But the peer ip address is still the old one (sip show peers). If now is a INVITE, the request is answered with 401 Unauthorized.

  That’s why I would say, the problem is not the port or a needed authentication. My Asterisk works behind a NAT without port forwarding and nat=no, I have qualify=yes that it does not come to a NAT timeout.

  Here is an example. The peer ip address was at this time 217.0.23.100, the INVITE came from 217.0.23.68 an was rejected with 401 Unauthorized:

  INVITE sip:06123456789@80.000.111.222:45061 SIP/2.0
  Max-Forwards: 58
  Via: SIP/2.0/UDP 217.0.23.68:5060;branch=z9hG4bKg3Zqkv7ib7h2smv8whryjnos88srot1i7
  To:
  From: ;tag=h7g4Esbg_44c62525
  Call-ID: af71bbfbf269b895@62.155.0.75
  CSeq: 3950540 INVITE
  Contact:
  Record-Route:
  Min-Se: 900
  P-Asserted-Identity:
  Session-Expires: 3600
  Supported: histinfo Supported: timer Supported: norefersub Content-Type: application/sdp Content-Disposition: session Content-Length: 204
  Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, REGISTER, UPDATE

  v=0
  o=- 0 0 IN IP4 217.0.23.68
  s=-
  c=IN IP4 217.0.4.134
  t=0 0
  m=audio 36480 RTP/AVP 9 8 102
  a=rtpmap:9 G722/8000
  a=rtpmap:8 PCMA/8000
  a=rtpmap:102 telephone-event/8000
  a=maxptime:20
  a=ptime:20

• That sounds like asterisk was working 100% correctly. If you receive an INVITE from an unknown IP address, then it should fail. Unless you want to allow anonymous, which is genearlly a very bad idea.

  If you are registering to IP X, but the provider may be transmitting invites from any number of other IP addresses, then you need a list of IP
  addresses, and have a trunk configuration set up for each one so that they are all recognized (with insecure=port,invite).

  If the provider is requiring you to accept invites from random IP
  addresses, get a new provider.

• I do not want set allowguest=yes. The problem is, there is no official list with ip addresses of Telekom Germany. But I think all ip addresses comes from the ip range 217.0.0.0/13.

  I have now the following addition to sip.conf. I think it is the only safe option. Or what would you say?

  [telekom](!)
  context=from-trunk type=peer defaultuser=
  authuser=
  remotesecret=
  fromdomain=tel.t-online.de qualify=no dtmfmode=rfc2833
  directmedia=no sendrpid=pai trustrpid=no insecure=port,invite disallow=all allow=g722
  allow=alaw allow=gsm deny=0.0.0.0/0
  permit=217.0.0.0/13

  [DTAG-IP_IN18_016](telekom)
  host=217.0.18.16

  [DTAG-IP_IN18_036](telekom)
  host=217.0.18.36

  etc.

• Hello Daniel,

  Judging by the lists I found I think it’s more like this subnet:
  217.0.16.0/255.255.248.0

  This configuration is now running here:

  [general]
  context=unauthenticated allowguest=no srvlookup=no udpbindaddr=0.0.0.0
  tcpenable=no localnet2.16.28.0/24
  alwaysauthreject=yes directmedia=no sdpsession=MyNewSessionString useragent=MyNewUserAgent language

• Hello Daniel,

  Thanks for the tip. I’ve enabled the DNS manager. Let’s see how it goes.

  Kind regards, Sebastian

• Hi again,

  I had poked a hole in my firewall for packets from above subnet to my port 5060. I had done the same for the RTP ports.

  A while back I realized that for RTP this was nonsense, as the RTP
  packets came from servers not even part of the subnet. Although there were no ports opened for those it just worked, because Telekom is doing symmetric RTP (and so is Asterisk by default).

  So I got rid of the firewall rule that opened the RTP ports. And then it dawned on me that I don’t even need to open the 5060 port. The REGISTER
  requests established a UDP connection that the kernel’s conntrack module was tracking anyway. The only issue was that the REGISTERs occurred only every 480s and the UDP connections were removed after 180s already.

  So at first I raised net.netfilter.nf_conntrack_udp_timeout_stream to
  500. That worked. But I didn’t really want to raise the default. So instead I added “qualify=yes” to the dtag_inbound peer. Now asterisk is sending an OPTIONS request to Telekom every 120s (I raised the frequency from 60 to 120 by setting “qualifyfreq0” under [general]), which keeps the connection open.

  Just wanted to add that.

  Kind regards, Sebastian

• As far as I understand, raising the UDP session timeout (or lowering the REGISTER timeout, if possible) is actually the better solution. Most Telcos I know don’t answer the OPTIONS request anyway and some might object to the traffic overhead.

• Sebastian,

  If I have understood you correctly, the SIP communication is now via NAT instead forwarded ports. For safety, it is much better.

  I think it is not because of a UDP timeout, but rather because of a NAT timeout. For this is “qualify” exactly the right thing to let the NAT port opened.

  Daniel

• Am 16. September 2015 18:48:16 MESZ, schrieb Daniel Heckl :
  Hi Daniel,

  Not quite. Asterisk is running on an Openwrt router. So Asterisk is listening on a public IP. No NAT involved, no port forwarding.

  Openwrt tracks the UDP connection for 180s (default). “qualify” keeps the connection alive (every 120s).

  Without “qualify” inbound calls wouldn’t work starting 180s after the registration, until after another 300s, when Asterisk registers again (provider requires a registration expiry >480s).

  Regards, Sebastian