I would be disappointed if not setting it resulted in any segs. Hopefully if so, someone would open jiras. On Aug 24, 2013 7:25 PM, "Stanislav Sinyagin" <ssinyagin@yahoo.com> wrote:
Anthony, thanks a lot for your explanations. I will try to put this together into a Wiki article.
I also searched through the C code, and indeed, many modules resort to the "domain" global variable if they don't find the domain in the command arguments.
switch_ivr_set_user() parses the user@domain string, finds the user, and sets two channel variables, "user_name" and "domain_name". Some modules use this when they create a channel (such as incoming INVITE in mod_sofia). But I could not find any C code which uses "domain_name" channel variable. I guess the intent is to use the variable in matching conditions in the dialplan.
Also, I saw both "domain" and "domain_name" event headers in event creation and processing, but didn't yet have time to figure out where they are used.
So, it looks like $${domain} global variable is required in vars.xml for general FreeSWITCH stability (it would probably coredump in some occasions if it's undefined). But $${domain_name} is obsolete and can be skipped if no other parts in the dialplan refer to it.
Then, the channel variable ${domain_name} is the right place to indicate the user's realm. It would be used to look up the user in the directory and for the realm part in SIP messages.
am I right in my considerations? If so, I will prepare a Wiki text for approval.
thanks stan
------------------------------ *From:* Anthony Minessale <anthony.minessale@gmail.com> *To:* FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Sent:* Saturday, August 24, 2013 3:03 AM *Subject:* Re: [Freeswitch-users] domain vs. domain_name variables
It took me like an hour to compose this explanation.....I hope it at least gives you an idea.
"domain" is a core variable its used as a fallback in certain situations when its defined and no other value is specified for domain. It's also used in the default configuration as a pre-processor substitution with the $${domain} notation which is substituted into the sofia profiles and conference etc.
"domain_name" is a variable that only exists in the scope of the demo dialplan. Its set initially as a global in vars.xml to whatever domain is set to as a base value.
From there its only set on a per-call basis to override and used in per call dialplan logic.
Its is not true that domain must be an IP. It defaults to the same value as local_ip_v4 to make sure the system works on any box without any configuration. If you have a working FQHN that points to your box, you should set that value in your domain var instead of the ip if you want things to reference the actual domain name.
I think once you learn that way the config files are setup in the default distribution are purely arbitrary the more sense it may begin to make.
The thing that made your head hurt is trying to explain that in SIP there is a separation from the host portion of a URI and the IP its sending the packet to. Because of PROXIES etc you can easily send a SIP packet to a specific address that contains a request URI or To: header with a different host name or ip.
think of domain as referring to the host portion of a user@host concept. The same notion of a REALM in radius. In SIP and in FS that can be an IP or a FQHN and it need not exist in the TLD dns on the internet or it can match one that exists and function on its own because it's not directly tied to dns. (For the sake of sanity do not use a real domain name that is not yours even if it works).
Basically the path of least resistance is to keep all these names aligned.. This is what the default config does for you because you set the domain variable once and its pre-processed into all the key places in the config that have domains so they are the same everywhere.
Say you set it to example.com
* The default directory will have a domain defined called example.comwith the default 1000-1019 extensions. * The internal sip profile will associate the internal profile with example.com and force any registrations etc to find that domain for auth. * The conferences will use example.com for presence etc.
Then it uses domain_name in the extensions etc as a clone of that example.com domain that you can change at runtime on a per call basis. Most likely in the default config with no changes this value will remain example.com the whole time and there is no difference.
Why?
Because people love multi-home stuff and they want to configure all of these things separately and once they start doing this, the config still is usable.
So:
FS never resolves domains to the IP and vice versa for you like it might in your unix environment or in a web browser. IP and FQHN have the same significance in sip packets as a unique realm string. It's only because you are binding the SIP UA to ${local_ip_v4} that your sip works on the IP.
The way SIP was designed to work, you would define a SRV record for the host name used in your sip uri and then that IP would be used in place of a default A record lookup. We can just as easily override that in a client by forcing the fields for the proxy address and domains.
Say you used example.com like I mentioned above and your valid IP was 200.8.8.8
You could change domain=example.com and restart FS and it would still come up.
Then you could go take a sip soft phone and play with the advanced settings and set the proxy addr to 200.8.8.8 and set the host or domain field to example.com and configure it to always send calls to the proxy addr.
Now you can use example.com in your phones all day long even though its not really your domain because its just saying that in the packets and you explicitly showed it what server to use.
Next, instead of example.com you could use 1.2.3.4 (or some real ip) as the domain even though it's obviously silly.
If you turn on the siptrace you'll see the packets hit your box and using those values like 1.2.3.4 and example.com in the host portion and talk to your client over the actual IP of the server.
On Fri, Aug 23, 2013 at 4:55 PM, Karl Schmidt <karl@xtronics.com> wrote:
On 08/23/2013 03:28 PM, Stanislav Sinyagin wrote:
What is the difference between ${domain} and ${domain_name} variables? Both are used in the source code, and example configs set them to the same value.
What is the design consideration behind?
Why not merging them into one variable?
This is an issue that has me a bit puzzled as well.
domain in vars.xml is supposed to be an IP address ( IMO Should have been called domain_ip ) domain_name is supposed to be a FQDN I think. grepping the configs tells me domain_name is never used in the default config so you can probably ignore it.
What is also not clear is the multiple uses of the term domain:
From the wiki -
https://wiki.freeswitch.org/wiki/Sofia.conf.xml#The_Relationship_Between_SIP...:
The domains inside the XML registry are completely different from the domains on the internet and again completely different from domains in sip packets. The profiles are again entirely different from any of the above. Its up to you to align them if you so choose.
OK that made my head hurt.
In some places in FS 'domain' = domain_IP_address
Here it says that SIP profile domain != IP-domain != SIP packet domain.
So I know what it isn't, but it might also help if I knew what it IS!
So, I think the domain definition in sofia MIGHT be a grouping of profiles? Then as you read on, it tells us that a domain is a domain.
" FreeSWITCH works off the concept of users and domains just like email."
The books nor the wiki nor googling the mailing list makes this clear.
Both the internal and external profiles set the name of the sofia-domain to all and $ sofia status gives the names as internal and external (after the directory? ).
-------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434
Reality isn't fair, but that it is where I live. -kps
--------------------------------------------------------------------------------
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org