Hi All, I noticed that in a pin protected conference scenario, if the user inputs more digits than the length of the correct one the remaining digits are accounted for next retry - e.g. if the conf pin is 1234 and user enter 12345 then 5 will be used as first digit in 2nd retry. Extension is configured as: <extension name="5678"> <condition field="destination_number" expression="^uuu$"> <action application="set" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="export" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="bridge" data="loopback/app=conference:uuu@5678 +1234"/> </condition> </extension> I attached a patch for mod_conference that checks pin buffer to be 0 before starting to collect digits again and reset it if > 0. I also modified the code to play "please enter the conference access number" prompt just first time and only "the passcode you entered is not correct, please try again" on subsequent retries. Please review the patch and let me know your comments. Thanks, George
Please post to jira.freeswitch.org /b On Jan 20, 2011, at 6:05 PM, George Niculae wrote:
Hi All,
I noticed that in a pin protected conference scenario, if the user inputs more digits than the length of the correct one the remaining digits are accounted for next retry - e.g. if the conf pin is 1234 and user enter 12345 then 5 will be used as first digit in 2nd retry. Extension is configured as:
<extension name="5678"> <condition field="destination_number" expression="^uuu$"> <action application="set" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="export" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="bridge" data="loopback/app=conference:uuu@5678+1234"/> </condition> </extension>
I attached a patch for mod_conference that checks pin buffer to be 0 before starting to collect digits again and reset it if > 0. I also modified the code to play "please enter the conference access number" prompt just first time and only "the passcode you entered is not correct, please try again" on subsequent retries.
Please review the patch and let me know your comments.
Thanks, George
<0001-Conference-pin.patch>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
yes it seems ok but be sure to post it to jira On Thu, Jan 20, 2011 at 6:11 PM, Brian West <brian@freeswitch.org> wrote:
Please post to jira.freeswitch.org
/b
On Jan 20, 2011, at 6:05 PM, George Niculae wrote:
Hi All,
I noticed that in a pin protected conference scenario, if the user inputs more digits than the length of the correct one the remaining digits are accounted for next retry - e.g. if the conf pin is 1234 and user enter 12345 then 5 will be used as first digit in 2nd retry. Extension is configured as:
<extension name="5678"> <condition field="destination_number" expression="^uuu$"> <action application="set" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="export" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="bridge" data="loopback/app=conference:uuu@5678+1234"/> </condition> </extension>
I attached a patch for mod_conference that checks pin buffer to be 0 before starting to collect digits again and reset it if > 0. I also modified the code to play "please enter the conference access number" prompt just first time and only "the passcode you entered is not correct, please try again" on subsequent retries.
Please review the patch and let me know your comments.
Thanks, George
<0001-Conference-pin.patch>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users 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
Nevertheless very cool patch :) Am 21.01.2011 um 01:11 schrieb Brian West:
Please post to jira.freeswitch.org
/b
On Jan 20, 2011, at 6:05 PM, George Niculae wrote:
Hi All,
I noticed that in a pin protected conference scenario, if the user inputs more digits than the length of the correct one the remaining digits are accounted for next retry - e.g. if the conf pin is 1234 and user enter 12345 then 5 will be used as first digit in 2nd retry. Extension is configured as:
<extension name="5678"> <condition field="destination_number" expression="^uuu$"> <action application="set" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="export" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="bridge" data="loopback/app=conference:uuu@5678+1234"/> </condition> </extension>
I attached a patch for mod_conference that checks pin buffer to be 0 before starting to collect digits again and reset it if > 0. I also modified the code to play "please enter the conference access number" prompt just first time and only "the passcode you entered is not correct, please try again" on subsequent retries.
Please review the patch and let me know your comments.
Thanks, George
<0001-Conference-pin.patch>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Michal Bielicki Geschäftsführer / CEO Seventh Signal Ltd. & Co. KG Weigandufer 45, Büro 115, D-12059 Berlin Voice: +49 30 60988730 Amtsgericht Charlottenburg HRA 44413 B Ust.-ID: DE266981999 Geschäftsführer: Michal Bielicki Persönlich Haftende Gesellschafterin: Seventh Signal Ltd, 69 Great Hampton St. Birmingham, B18 6EW, GB, Company Nr.: 06889439 WWW.: http://www.seventhsignal.de
Moved to JIRA, please see http://jira.freeswitch.org/browse/FS-3000 Thanks, George On Fri, Jan 21, 2011 at 2:23 AM, Brian West <brian@freeswitch.org> wrote:
Yep. /b On Jan 20, 2011, at 6:19 PM, Michal Bielicki wrote:
Nevertheless very cool patch :) Am 21.01.2011 um 01:11 schrieb Brian West:
Please post to jira.freeswitch.org
/b
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
This belongs to Jira, doesn't it? I am not skilled enough to review it, but the core devs really rather have this on Jira. Thank you for stepping up to solve a problem you've found. Regards, João Mesquita On Thu, Jan 20, 2011 at 9:05 PM, George Niculae <george.niculae79@gmail.com>wrote:
Hi All,
I noticed that in a pin protected conference scenario, if the user inputs more digits than the length of the correct one the remaining digits are accounted for next retry - e.g. if the conf pin is 1234 and user enter 12345 then 5 will be used as first digit in 2nd retry. Extension is configured as:
<extension name="5678"> <condition field="destination_number" expression="^uuu$"> <action application="set" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="export" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="bridge" data="loopback/app=conference:uuu@5678 +1234"/> </condition> </extension>
I attached a patch for mod_conference that checks pin buffer to be 0 before starting to collect digits again and reset it if > 0. I also modified the code to play "please enter the conference access number" prompt just first time and only "the passcode you entered is not correct, please try again" on subsequent retries.
Please review the patch and let me know your comments.
Thanks, George
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
George, Thanks for taking the time to look at the source code and creating a simple but useful patch. Your effort is definitely appreciated. Thank you also for putting this into Jira so that we can keep track of these sorts of things. -MC On Thu, Jan 20, 2011 at 4:05 PM, George Niculae <george.niculae79@gmail.com>wrote:
Hi All,
I noticed that in a pin protected conference scenario, if the user inputs more digits than the length of the correct one the remaining digits are accounted for next retry - e.g. if the conf pin is 1234 and user enter 12345 then 5 will be used as first digit in 2nd retry. Extension is configured as:
<extension name="5678"> <condition field="destination_number" expression="^uuu$"> <action application="set" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="export" data="supplied_pin=${sip_h_X-ConfPin}"/> <action application="bridge" data="loopback/app=conference:uuu@5678 +1234"/> </condition> </extension>
I attached a patch for mod_conference that checks pin buffer to be 0 before starting to collect digits again and reset it if > 0. I also modified the code to play "please enter the conference access number" prompt just first time and only "the passcode you entered is not correct, please try again" on subsequent retries.
Please review the patch and let me know your comments.
Thanks, George
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (7)
-
Anthony Minessale
-
Brian West
-
George Niculae
-
George Niculae
-
João Mesquita
-
Michael Collins
-
Michal Bielicki