[Freeswitch-users] context
Sam
u2nsam at gmail.com
Thu Feb 3 14:24:44 MSK 2011
Is FS book 1.0.7 available ?
Regds
On Thu, Feb 3, 2011 at 4:37 PM, Sam <u2nsam at 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 at 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 at 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 at 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 at 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 at 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 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20110203/5fec45ca/attachment.html
More information about the FreeSWITCH-users
mailing list