[Freeswitch-users] domain vs. domain_name variables

Anthony Minessale anthony.minessale at gmail.com
Sun Aug 25 06:11:56 MSD 2013 

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 at 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 at 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 at gmail.com>
> *To:* FreeSWITCH Users Help <freeswitch-users at 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 at 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 at 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_Profiles_and_Domains:
>
>  > 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 at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at 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 at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> googletalk:conf+888 at conference.freeswitch.org
> pstn:+19193869900
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130824/d63b4a16/attachment-0001.html

Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-users mailing list