[Freeswitch-dev] Searching for a valid extension.

Fri Oct 29 05:47:39 PDT 2010

Thanks for help.

We solved the problem with a specific digit at the end of the dialed number.

On calls originated from an FXS branch, the Endpoint searches for a
valid extension (digits sent) after the DTMF '#' or after the timeout
(option fxs-digit-timeout). That search is done in the context defined
in section <fxs-options>, or if no context configured, the search is
done in context defined in context-fxs.

:)

On Thu, Oct 14, 2010 at 2:45 PM, Anthony Minessale
<anthony.minessale at gmail.com> wrote:
> You have to run the call into your own logic, either some XML REGEX or
> a script etc and you manually return  INVALID_NUMBER_FORMAT when you
> want to signal to your phone to collect more digits.
>
> again, the dialplan is dynamic, fluid and stackable you cannot
> statically map every extension but you don't need to.  Once you build
> the functionality that hanging up with INVALID_NUMBER_FORMAT means
> collect more digits and any other cause means you have dialed an
> invalid number, you can go develop a million ways to send this message
> back to your module and not make the module care about it.  So you are
> hijacking that one cause to not actually hangup the channel.
>
>
>
>
>
>
>
>
>
> On Thu, Oct 14, 2010 at 12:16 PM, Geovani Ricardo Wiedenhoft
> <grw.freeswitch at gmail.com> wrote:
>> Thanks for the sugestions.
>>
>> I checked carefully every step, however, I got some questions.
>>
>> We tested the originate with the loopback endpoint, because we need to pass
>> through the dialplan.
>>
>> My context:
>>
>> <context name="khomp-SIP">
>>   <extension name="SIP">
>>     <condition field="destination_number" expression="^10(\d)$">
>>       <action application="bridge" data="user/100$1"/>
>>     </condition>
>>   </extension>
>> </context>
>>
>>
>> Test:
>> freeswitch at geovani> originate loopback/10/khomp-SIP/XML 1002
>>
>>
>> -ERR NO_ROUTE_DESTINATION
>>
>>
>>
>> In this test, we send the digits 10 (simulating the reception of these
>> digits in the FXS) for khomp-SIP context in XML. I expected the
>> INVALID_NUMBER_FORMAT return (accept more digits and try again), but the
>> result was NO_ROUTE_DESTINATION. This happened with the switch_ivr_originate
>> function too.
>>
>> switch_ivr_originate(NULL, &session, &cause, dialstring.c_str(), timeout,
>> NULL, NULL, NULL, NULL, NULL, SOF_NONE, NULL);
>>
>> cause = 3 = NO_ROUTE_DESTINATION
>>
>>
>> In previous email I did not say, we can make calls with timeout between
>> digits, but my goal is to anticipate the call if possible checking of the
>> extension/context(exact match). Also, we need verify what context configured
>> by the user is used.
>>
>>
>> Thanks again Anthony Minessale and Mathieu Parent, but the others options
>> use timeout for connections, if we understand completely.
>>
>>
>>
>> On Mon, Oct 11, 2010 at 5:44 PM, Anthony Minessale
>> <anthony.minessale at gmail.com> wrote:
>>>
>>> We don't have a static monolithic dialplan like asterisk, there can be
>>> many dialplans or dynamic dialplans that reach out to external
>>> services.
>>>
>>> The proper way to implement overlap dialing on a per-protocol basis would
>>> be:
>>>
>>> 1) Separate your native channel from the FreeSWITCH channel so you can
>>> create a FreeSWITCH session and attach the native channel.
>>>
>>> 2) send the call to the configured dialplan and allow that dialplan
>>> module to work out it's own ambiguities and respond:
>>>
>>> SWITCH_CAUSE_INVALID_NUMBER_FORMAT or cause 28
>>>
>>> 3) when you see this cause accept more digits and try again until you
>>> get some other cause code.
>>>
>>>
>>> This is how it's done in sip by doing an entire new call each time you
>>> need to dial more digits.
>>>
>>>
>>>
>>> The other way which we do in FreeTDM is to define 2 regex, one for
>>> anything that is valid and one for anything that is invalid and
>>> consult this regex on each digit until you know one way or another.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 11, 2010 at 3:12 PM, Geovani Ricardo Wiedenhoft
>>> <grw.freeswitch at gmail.com> wrote:
>>> > Hello,
>>> >
>>> > We are completing development of the mod_khomp endpoint for Khomp
>>> > boards:
>>> > - FXS
>>> > - FXO
>>> > - E1
>>> > - GSM (boards and usb devices)
>>> > - Passive record
>>> > - kommuter
>>> >
>>> > However, we are constrained in our implementation. We needed to verify
>>> > that
>>> > a given set of digits has a valid extension or if can wait for more
>>> > digits
>>> > at some points of our code, without making the call.
>>> >
>>> > In our implementation for Asterisk (our Khomp channel), we use the
>>> > functions
>>> > provided by the Asterisk:
>>> >
>>> > ##############################
>>> > ###############################################
>>> > ASTERISK:
>>> >
>>> > /* \brief Looks for a valid matching extension */
>>> >  - ast_canmatch_extension
>>> >
>>> > /* \brief Looks to see if adding anything to this extension might match
>>> > something. (exists ^ canmatch) */
>>> >  - ast_matchmore_extension
>>> >
>>> > #############################################################################
>>> >
>>> > Searching for a solution, we implemented within mod_khomp the reading
>>> > and
>>> > checking functions of digits and expressions in XML, but our
>>> > implementation
>>> > limits us to XML dialplans, which it would not be compatible if the user
>>> > need the database or other constructions of the dialplan.
>>> >
>>> >
>>> > So, I would like to know what is the possibility of similar functions to
>>> > be
>>> > implemented in the core?
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Thanks
>>> > :)
>>> >
>>> >
>>> >
>>> >
>>> > Geovani Ricardo Wiedenhoft
>>> >
>>> > _______________________________________________
>>> > FreeSWITCH-dev mailing list
>>> > FreeSWITCH-dev at lists.freeswitch.org
>>> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>> > 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
>>>
>>> _______________________________________________
>>> FreeSWITCH-dev mailing list
>>> FreeSWITCH-dev at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>> http://www.freeswitch.org
>>
>>
>> _______________________________________________
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> 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
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>