[Freeswitch-users] context

[Sam]

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/45ca02d2/attachment-0001.html