Everything in the 1.0.6 book should work on 1.0.7 though... It'll only be missing some of the new features, but they're on the Wiki -Steve On 3 February 2011 11:46, Steven Ayre <steveayre@gmail.com> wrote:
No, and it never will be... 1.0.7 is the daily snapshot release candidate for the 1.0.8 release. The book might be updated for 1.0.8 once it comes out though.
-Steve
On 3 February 2011 11:24, Sam <u2nsam@gmail.com> wrote:
Is FS book 1.0.7 available ?
Regds
On Thu, Feb 3, 2011 at 4:37 PM, Sam <u2nsam@gmail.com> wrote:
Wow,
super explanation of the call flow, if such explanations are there in the FS book , I will take it.
Thanks again.
Regds Sam
On Thu, Feb 3, 2011 at 12:15 PM, Michael Collins <msc@freeswitch.org>wrote:
I think I'm going to write an article on this topic for the new folks since it seems to be a common point of confusion. Don't worry, you're not alone - this is a common challenge for new FS admins.
#1 - The first line of your pastebin is the key. You are letting the call in via an ACL. This is "okay" if it is what you want, but I doubt that it is. I recommend that you remove this phone's IP address from the "domains" section of acl.conf.xml. When using the default FS configs, if you let a phone call through using the "domains" ACL then it automatically goes to the public context. Why? Because the call is not explicitly associated with a local user on the system. It's like getting a free pass into Disneyland but you don't have a little badge that says, "Hi, my name is..."
Some get confused by the "Falling back to digest auth" message. It looks like an error but it's really just information. If the caller's SIP client properly authenticates (which is different than registration - see below) then FS knows exactly who is making the call and that it is a local user so it goes into the "default" context.
#2 - Make sure that you learn the difference between SIP *registration* and SIP *authentication*. Registration is where the SIP client tells FS: "Here's how you can reach me if you get a call for me." It is for calls TO the phone, not calls from the phone. On the other hand, call authentication is for calls FROM the phone to FS. When the phone calls FS, FS first checks to see if the phone's IP is in the "domains" ACL. If it is, then it just let's the call in to be handled by the public context. If not, then FS sends an "auth challenge" - basically saying, "What's the password?" If the SIP client properly responds then the call is "authenticated" - meaning that FS knows it is from a specific user and thus it goes to the default context.
I recommend that you get the FS book and look at chapter 4. We talk a lot about the user directory and it will help you understand how it all works. Hopefully this explanation will whet your appetite for more. :)
Keep hacking away at it - you'll get it soon enough!
-MC
On Wed, Feb 2, 2011 at 7:02 PM, Sam <u2nsam@gmail.com> wrote:
So you say that the extensions are not registered with FS and they are getting allowed by the acl, just like DIDs. How can i rectify this,any thing that needs to be checked ?
http://pastebin.freeswitch.org/15217
Regards Sam
On Wed, Feb 2, 2011 at 11:23 PM, Michael Collins <msc@freeswitch.org>wrote:
Turn on console debug level output (default in fs_cli) and make the test call. Pastebin the output. Most likely the call is not being authorized because you are letting it in via an ACL or something like that.
-MC
On Wed, Feb 2, 2011 at 1:55 AM, Sam <u2nsam@gmail.com> wrote:
> I have defined a user as : > > <user id="2099"> > <params> > <param name="password" value="1234"/> > <param name="dial-string" value="{presence_id=${dialed_user}@ > ${dialed_domain}}${sofia_contact(${dialed_user}@ > ${dialed_domain})}"/> > <param name="mwi-account" value="2099@voicemail"/> > <param name="vm-password" value="1234"/> > <param name="vm-email-all-messages" value="true"/> > <!--param name="vm-attach-file" value="true"/--> > <!--param name="vm-mailto" value=""/--> > </params> > <variables> > <variable name="user_context" value="inter"/> > <variable name="force_transfer_context" value="inter"/> > <variable name="accountcode" value="2099"/> > <variable name="internal_caller_id_name" value="2099"/> > <variable name="internal_caller_id_number" value="2099"/> > <variable name="callgroup" value="1"/> > <variable name="sip-force-contact" > value="NDLB-connectile-dysfunction"/> > </variables> > > > and in the dialplan i have > > <context name="inter"> > > <extension name="2099"> > <condition field="destination_number" expression="^(2099)"> > <action application="set" data="call_timeout=30"/> > <action application="set" data="dialed_extension=$1"/> > <action application="export" data="dialed_extension=$1"/> > <action application="set" > data="transfer_ringback=$${hold_music}"/> > <action application="set" > data="hangup_after_bridge=true"/> > <action application="set" data="continue_on_fail=true"/> > <action application="hash" > data="insert/${domain_name}-call_return/${dialed_extension}/${caller_id_number}"/> > <action application="hash" > data="insert/${domain_name}-last_dial_ext/${dialed_extension}/${uuid}"/> > <action application="hash" > data="insert/${domain_name}-last_dial_ext/${called_party_callgroup}/${uuid}"/> > <action application="hash" > data="insert/${domain_name}-last_dial_ext/global/${uuid}"/> > <action application="set" > data="called_party_callgroup=${user_data(${dialed_extension}@${domain_name} > var callgroup)}"/> > <action application="hash" > data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/> > <action application="bridge" > data="{sip_invite_domain=$${domain}}user/${dialed_extension}@ > ${domain_name}"/> > </condition> > </extension> > > </context> > > > Now extension 2075 is also made on above lines in the same context > for user and dialplan, here the call when initiated from 2075 to 2099 > searches for context public instead of context inter > > mod_dialplan_xml.c:331 Processing 2075 <2075>->2099 in context public > > any reason why ? > > Regards > Sam > > _______________________________________________ > 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 > >
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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