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@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@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@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@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@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900