[FS-2760] external-sip-ip with "hots:abc.com" being probed only once until
reload. Created: 05/Oct/10 Updated: 24/Feb/14 Resolved: 23/Nov/10
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Security Level:
Closed
FreeSWITCH
mod_sofia
1.0.6
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
New Feature
Peng Li
Not A Bug
None
Not Specified
CPU
Architecture:
Kernel:
Userland:
Compiler:
FreeSWITCH
GIT Revision:
GIT Master
Revision hash::
x86
None
public
Priority:
Assignee:
Votes:
Minor
Anthony Minessale II
0
Not Specified
Not Specified
Ubuntu 10.04 server, freeswitch 1.0.6
Linux
GNU/Linux
gcc
new
yes
Description
HI,
I have internet connecting through OpenWRT router (which has ez-ipupdate). ez-ipupdate will
faithfully update my new PPPoE ip to my dynamic host, say, abc.com.
Once I configured in vars.xml with ext-sip-ip=host:abc.com and ext-rtp-ip=host:abc.com, the
Freeswitch seems only probe once during it starts. In several times, I reloaded my router to get a
new PPPoE IP, my freeswitch still uses old IP to register to my Internet PHone provider, thus
causes people can not call in . In order to fix it, I have to restart Freeswitch each time after
router's ip change.
Is there a setting or timer that I can adjust to make Freeswitch constantly probe my dynamic
host to check updated IP? If there's new IP, different what Freeswitch currently, it should
update ext-sip-ip and ext-rtp-ip with the new one.
Please let me know
thanks in advance.
Peng
Comments
Comment by Peng Li [ 05/Oct/10 ]
one more note is that I tried to decrease sip-register timer to 10 or less minutes and activate the
"options" ping, in the hope that Register or Option message will check my Dynamic DNS host
name and update ext-sip-ip/ext-rtp-ip.
It seems doesn't help at all. I would think that a probe of Host DNS name for an updated IP is
needed prior to a register update or option update.
Not sure whether we have already implemented this or something needs to be working on.
thanks in advance.
Peng
Comment by Anthony Minessale II [ 06/Oct/10 ]
penalty for reporting a minor bug as major.....
Comment by Brian West [ 06/Oct/10 ]
Use stun: or autonat: with upnp/nat-pmp possibly.
/b
Comment by François [ 06/Oct/10 ]
You're lucky it even probes the first time, I cannot make "host:" work on my machine so far.
Use "autonat:" or "stun:" with a public server (stun.ekiga.net or similar) as suggested by Brian.
It seems to currently call some APR function in switch_stun that ends up calling getaddrinfo.
There is another function in switch_utils that does the same and works as far as i know, maybe
this one should be used (?). But none have DNS cache and it might endup being quite heavy.
If I understood correctly, Anthony is against having DNS things in mod_sofia (leaving every
SRV lookups and similar to be done by libsofia), so the "host:" support should be removed at
some point, better for you to do some external script that refreshes the IP in sofia.conf and does
a sofia "rescan" if you really can't use stun or autonat.
Anthony or Brian, could you confirm the above? I would love to try implementing a bit of DNS
in mod_sofia using sofia resolver (or udns) to improve that "host:" support and maybe even to
identify incoming calls from gateways defined by a domain name (in ACL?), but this was
strongly discouraged last time it was discussed.
François.
Comment by Anthony Minessale II [ 06/Oct/10 ]
everything you say is correct.
DNS resolver on every call leads to slowdowns and failures especially when the dns server is
dead.
Comment by Peng Li [ 06/Oct/10 ]
HI Brian, Anthony and Francois,
I had tried default stun server from Freeswitch in the default config, but it caused the following
problem. I can't remember clearly, but it is most like this.
It seems that Stun server from Freeswitch not only provides an ext-sip-ip, but also "guessed"
RTP ports; this caused the problem of one way voice and packet being redirected to a STUN
suggested port. It was in the log message and I was wondering who gave some PORT
instruction to RTP stream, definitely not the ports I defined. Then , further log revealed it's from
STUN server.
I am not sure whether this is a typical STUN server feature or just a feature implemented in stun
server from Freeswitch, to "guess" RTP port for me. I haven't tried other STUN server and just
rolled over to "Host:" option.
Please help clarify the above mentioned STUN behaviours.
If I use a stun that only provides ext-sip-ip , not recommending rtp-ports, I still have the
following questions. Maybe you can help.
Does STUN function inside Freeswitch use a timer to probe the STUN server? If so, it will
update new IP to Freeswitch to trigger a new "register" message to remote Telephone Provider's
server? or do I have to decrease SIP register timer, say to 3mins and at that time, FS will use
new IP found by STUN to send an Option or Register to remoter SERVER?
Again, my issue is that when WAN is changes, FS, doesn't know it.
Again, appreciate your input on this.
Peng
Comment by François [ 07/Oct/10 ]
Hi Peng Li,
AFAIK, it is STUN's job to learn how your NAT behaves, not only the public IP address but
also the port mapping (your router does not necessarily map your server's RTP port to the same
public one). I don't think it would work very well with only public IP detection in your case.
You might want to try asking in the IRC channel for some help to debug your one-way audio
problem.
If used in ext-rtp-ip, the STUN server should be probed before any SIP INVITE in order to find
out the current port mapping and place the correct IP and port in the session description (SDP)
part of the INVITE.
For the ext-sip-ip, it is probed every time the profile is started or rescanned, assuming the port
mapping will remain (use nat-ping options to keep the mapping in your router). If your IP
changes often, rescan your profile regularly.
Another way would be to have an external script that would detect your public IP from time to
time, rewrite sofia.conf and rescan.
Anthony, I respectfully disagree because what you say is also true for UPnP, STUN, and DNS
lookups done by libsofia when you define gateways with domain names (SRV lookups, ...).
Your router/STUN server/DNS/internet connection/SIP provider... could all die resulting in
slowdowns and failures.
I think it is the user's choice in using domain names and his fault if he can't configure DNS
properly, so he then should have the option of doing it. You can't have SIP without some SRV
and NAPTR lookups, the thing would be to do it properly with proper caching to reduce load
(which I think is already done in sofia resolver).
Comment by Anthony Minessale II [ 07/Oct/10 ]
The lookups can be done when resolving a host to connect to.
using it to resolve your own host every time is bad.
interchanging dns hostnames and ip in your configuration is also bad.
Even if you disagree you cannot change how FreeSWITCH behaves without our approval which
you have to earn.
At this point you are simply bashing holes in walls with sledge hammers because you don't
know where the doors are. If you are still here in 12-18 months maybe we can discuss it more.
Comment by François [ 08/Oct/10 ]
Agreed, I actually took the advice last time you told me and stopped trying to modify everything
while I learn to work with what is already there!
Peng Li, you should take the advice as well, I think this issue could be closed as it is not really a
bug. If we're both still here in 12-18 months maybe we can propose some alternative to
Anthony.
If you have "host:" working you can always do a rescan of your profile periodically to refresh it.
Otherwise you have plenty of alternatives, some described above such as "stun:", "autonat", or
configuring the ext-ips with an external script that could rescan your profile from time to time.
Check out xml-rpc as well, etc....
Comment by Peng Li [ 08/Oct/10 ]
HI Franc and Anthony,
Will STUN update SOFIA with a detected new ext-sip-ip and trigger an Registration refresh to
SIP server with new IP? If it doesn, then, it probably helps my situation so that I can save
$4/month for a static ip.
Thanks for your help.
peng
Comment by Anthony Minessale II [ 08/Oct/10 ]
no, stun is used for rtp, the stun in the SIP is a one time thing.
Comment by Peng Li [ 08/Oct/10 ]
Anthony,
Much appreciated!
Peng
Comment by Anthony Minessale II [ 08/Oct/10 ]
if you get a nat router with natpmp or pnp you can get all of this automatic from the default
configuration from HEAD
Comment by Peng Li [ 27/Oct/10 ]
HI Franc and Anthony,
sorry to ask a bit more on this,
1. If NATpmp or uPNP used between router and FS, it will update external-rtp-ip and externalsip-ip both, correct? Will it also trigger the a new registration update with new ip?
2. If it doesn't trigger a new sip registration with new IP, I can try to make my sip registration
timer smaller to this new ip updated in my sip provider, correct?
-----------------------3. If these are not option, I am thinking about to use script, as you suggested. Maybe, a crontab
job will do 1) Every 5min, grab my IP from my dyndns record of abc.com 2). Write this IP info
(whether it's new or same) to Memory when ext-sip-ip and ext-rtp-ip are stored. 3). make sip
register timer smaller, like 5 or 10 mins. Will this work? Can you help develop a sample crontab
for this?
This may take some of your valuable time, but I really appreciate it. Thanks in advance.
Always.
peng
Comment by Peng Li [ 27/Oct/10 ]
One more question for today,
I have just got Jingle working so that a call from remote computer----gmail---to my FS--sip
phone is working.
4, I have actually put in extra "external-rtp-ip=1.2.3.4" in client.xml to get this working. Please
confirm this is really needed.
5. It seems that I put "external-rtp-ip=host:ab.com" doesn't work. Please confirm whether it only
requires a numeric value here.
6. If "external-rtp-ip=host:abc.com" or "external-rtp-ip=&&{external-rtp-ip}" works, Can you
help incorporate this into above mentioned Crontab as well?
Again, many thanks
Peng
Comment by Brian West [ 23/Nov/10 ]
if you set the ext-sip-ip and ext-rtp-ip to auto-nat it will do the right thing for you. Also set the
local-network-acl to nat.auto
Generated at Sun Mar 06 00:12:30 EST 2016 using JIRA 6.4.10#64025sha1:5b8b74079161cd76a20ab66dda52747ee6701bd6.