[Freeswitch-dev] Searching for a valid extension.

Thu Oct 14 10:48:31 PDT 2010

Your regex does not match what you dialed:
^10(\d)$ needs three digits but you only dialed two digits in your
originate:
loopback/10/khomp-SIP/XML

try something like:
loopback/101/khomp-SIP/XML

-MC

On Thu, Oct 14, 2010 at 10:16 AM, 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 <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101014/6d6125e6/attachment.html 