Hi, I work on a SIP PBX project that is using FreeSWITCH as a audio conference server which is working great. The audio conferencing is very well integrated in out web-based configuration server and allows the owner of the conference to control it (mute, unmute, isolate, ...) from a browser. One other neat thing a conference owner can do through the browser is to invite additional parties to the conference by typing in a SIP URI. This causes our SIP PBX to do 3rd party call control to refer the invited party to the proper conference. This works very well for conferences that do not require a PIN but breaks for conferences that do. In the latter case, when the invited party answers the call, he hears "please enter your conference access number" out of context. Given that this scenario is less that ideal I started looking for solutions what would allow someone to join a 'PIN-guarded' conference without being prompted for one. I looked at a variety of dialplan-based options without success and turned to another option which I successfully prototyped. The purpose of this post is to socialize the solution I came up with to get feedback and to ultimately learn what needs to be done to get this functionality committed in the code base. The high-level solution I came up with consists the following: 1- add the conference PIN to the INVITE that is sent to FreeSWITCH; 2- have conference dialplan set a well-known dialplan variable with the content of the PIN as extracted from the INVITE; 3- have mod_conference test the pin contained in the well-known dialplan variable before deciding to prompt the user to enter a PIN. The solution I prototyped supports two ways of adding the PIN to an INVITE. First, the pin can be included as a well-known URL parameter added to the INVITE, e.g. INVITE sip:myconf@myfreeswitch.local;X-ConfPin=1234 SIP/2.0. When the PIN is passed as a URL parameter, the conference dialplan needs to be of the following form to allow PIN-less entry: <extension name="700"> <condition field="destination_number" expression="^700$"> <action application="set" data="supplied_pin=${sip_req_params}"/> <action application="conference" data="myconf@700+1234"/> </condition> </extension> The other way of adding a PIN to an INVITE is to add a user-chosen proprietary header containing the PIN to the INVITE, e.g. X-My-Custom-Pin-Header: 1234. When the PIN is passed as a header, the conference dialplan needs to be of the following form to allow PIN-less entry: <extension name="700"> <condition field="destination_number" expression="^700$"> <action application="set" data="supplied_pin=${sip_h_X-My-Custom-Pin-Header}"/> <action application="conference" data="myconf@700+1234"/> </condition> </extension> Whichever method is taken, the end results are similar, i.e. the 'supplied-pin' dialplan variable is initialized with the conference PIN passed in the INVITE. All that is left to do is for the mod_conference to look-up the variable and extract the PIN out of it if non-empty and use it as though the user entered it from his keypad. If the PIN is not the correct one, the logic defaults to prompting the user. The mod_conference patch is attached to this post which essentially consists in adding 10 lines of code (if you ignore the lines changed because of indentation). Does this approach sound reasonable to you? If so, I'll open a tracker describing the problem and solution and attach my patch to it so that it can be committed. Thank you very much in advance, Robert
Can't you just omit telling mod_conference to not check a pin when you see your variable. On Thu, Sep 3, 2009 at 9:20 AM, Robert Joly <rjoly@nortel.com> wrote:
Hi, I work on a SIP PBX project that is using FreeSWITCH as a audio conference server which is working great. The audio conferencing is very well integrated in out web-based configuration server and allows the owner of the conference to control it (mute, unmute, isolate, ...) from a browser. One other neat thing a conference owner can do through the browser is to invite additional parties to the conference by typing in a SIP URI. This causes our SIP PBX to do 3rd party call control to refer the invited party to the proper conference. This works very well for conferences that do not require a PIN but breaks for conferences that do. In the latter case, when the invited party answers the call, he hears "please enter your conference access number" out of context. Given that this scenario is less that ideal I started looking for solutions what would allow someone to join a 'PIN-guarded' conference without being prompted for one. I looked at a variety of dialplan-based options without success and turned to another option which I successfully prototyped. The purpose of this post is to socialize the solution I came up with to get feedback and to ultimately learn what needs to be done to get this functionality committed in the code base.
The high-level solution I came up with consists the following: 1- add the conference PIN to the INVITE that is sent to FreeSWITCH; 2- have conference dialplan set a well-known dialplan variable with the content of the PIN as extracted from the INVITE; 3- have mod_conference test the pin contained in the well-known dialplan variable before deciding to prompt the user to enter a PIN.
The solution I prototyped supports two ways of adding the PIN to an INVITE. First, the pin can be included as a well-known URL parameter added to the INVITE, e.g. INVITE sip:myconf@myfreeswitch.local;X-ConfPin=1234 SIP/2.0. When the PIN is passed as a URL parameter, the conference dialplan needs to be of the following form to allow PIN-less entry:
<extension name="700"> <condition field="destination_number" expression="^700$"> <action application="set" data="supplied_pin=${sip_req_params}"/> <action application="conference" data="myconf@700+1234"/> </condition> </extension>
The other way of adding a PIN to an INVITE is to add a user-chosen proprietary header containing the PIN to the INVITE, e.g. X-My-Custom-Pin-Header: 1234. When the PIN is passed as a header, the conference dialplan needs to be of the following form to allow PIN-less entry:
<extension name="700"> <condition field="destination_number" expression="^700$"> <action application="set" data="supplied_pin=${sip_h_X-My-Custom-Pin-Header}"/> <action application="conference" data="myconf@700+1234"/> </condition> </extension>
Whichever method is taken, the end results are similar, i.e. the 'supplied-pin' dialplan variable is initialized with the conference PIN passed in the INVITE. All that is left to do is for the mod_conference to look-up the variable and extract the PIN out of it if non-empty and use it as though the user entered it from his keypad. If the PIN is not the correct one, the logic defaults to prompting the user. The mod_conference patch is attached to this post which essentially consists in adding 10 lines of code (if you ignore the lines changed because of indentation).
Does this approach sound reasonable to you? If so, I'll open a tracker describing the problem and solution and attach my patch to it so that it can be committed.
Thank you very much in advance, Robert
_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Anthony, I'm not sure that I fully understand your question/statement but here it goes. When a conference with a PIN is created, I never want mod_conference to not check for a PIN as this would go against the will of the conference creator. Instead, I want to add an additional way for the conference module to collect the PIN when a user enters a conference. With what I'm proposing, the PIN can be collected from the keypad (as it is today) or alternatively, it can be collected directly from the message via a dialplan variable. The latter approach allows a system to add ad hoc parties to an ongoing conference without requiring them to know the PIN. Does that help clarify what I did? Thank you in advance, bob
On Thursday, September 03, 2009 7:48 PM Anthony Minessale wrote:
Can't you just omit telling mod_conference to not check a pin when you see your variable.
On Thu, Sep 3, 2009 at 9:20 AM, Robert Joly <rjoly@nortel.com> wrote:
Hi, I work on a SIP PBX project that is using FreeSWITCH as a audio conference server which is working great. The audio conferencing is very well integrated in out web-based configuration server and allows the owner of the conference to control it (mute, unmute, isolate, ...) from a browser. One other neat thing a conference owner can do through the browser is to invite additional parties to the conference by typing in a SIP URI. This causes our SIP PBX to do 3rd party call control to refer the invited party to the proper conference. This works very well for conferences that do not require a PIN but breaks for conferences that do. In the latter case, when the invited party answers the call, he hears "please enter your conference access number" out of context. Given that this scenario is less that ideal I started looking for solutions what would allow someone to join a 'PIN-guarded' conference without being prompted for one. I looked at a variety of dialplan-based options without success and turned to another option which I successfully prototyped. The purpose of this post is to socialize the solution I came up with to get feedback and to ultimately learn what needs to be done to get this functionality committed in the code base.
The high-level solution I came up with consists the following: 1- add the conference PIN to the INVITE that is sent to FreeSWITCH; 2- have conference dialplan set a well-known dialplan variable with the content of the PIN as extracted from the INVITE; 3- have mod_conference test the pin contained in the well-known dialplan variable before deciding to prompt the user to enter a PIN.
The solution I prototyped supports two ways of adding the PIN to an INVITE. First, the pin can be included as a well-known URL parameter added to the INVITE, e.g. INVITE sip:myconf@myfreeswitch.local;X-ConfPin=1234 SIP/2.0. When the PIN is passed as a URL parameter, the conference dialplan needs to be of the following form to allow PIN-less entry:
<extension name="700"> <condition field="destination_number" expression="^700$"> <action application="set" data="supplied_pin=${sip_req_params}"/> <action application="conference" data="myconf@700+1234"/> </condition> </extension>
The other way of adding a PIN to an INVITE is to add a user-chosen proprietary header containing the PIN to the INVITE, e.g. X-My-Custom-Pin-Header: 1234. When the PIN is passed as a header, the conference dialplan needs to be of the following form to allow PIN-less entry:
<extension name="700"> <condition field="destination_number" expression="^700$"> <action application="set" data="supplied_pin=${sip_h_X-My-Custom-Pin-Header}"/> <action application="conference" data="myconf@700+1234"/> </condition> </extension>
Whichever method is taken, the end results are similar, i.e. the 'supplied-pin' dialplan variable is initialized with the conference PIN passed in the INVITE. All that is left to do is for the mod_conference to look-up the variable and extract the PIN out of it if non-empty and use it as though the user entered it from his keypad. If the PIN is not the correct one, the logic defaults to prompting the user. The mod_conference patch is attached to this post which essentially consists in adding 10 lines of code (if you ignore the lines changed because of indentation).
Does this approach sound reasonable to you? If so, I'll open a tracker describing the problem and solution and attach my patch to it so that it can be committed.
Thank you very much in advance, Robert
_______________________________________________ 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 <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
I haven't heard anything back on this topic. Is it ok for me to open a new tracker issue and attach my patch? Thanks in advance, bob
Anthony, I'm not sure that I fully understand your question/statement but here it goes.
When a conference with a PIN is created, I never want mod_conference to not check for a PIN as this would go against the will of the conference creator. Instead, I want to add an additional way for the conference module to collect the PIN when a user enters a conference. With what I'm proposing, the PIN can be collected from the keypad (as it is today) or alternatively, it can be collected directly from the message via a dialplan variable. The latter approach allows a system to add ad hoc parties to an ongoing conference without requiring them to know the PIN.
Does that help clarify what I did?
Thank you in advance, bob
On Thursday, September 03, 2009 7:48 PM Anthony Minessale wrote:
Can't you just omit telling mod_conference to not check a pin when you see your variable.
On Thu, Sep 3, 2009 at 9:20 AM, Robert Joly <rjoly@nortel.com> wrote:
Hi, I work on a SIP PBX project that is using FreeSWITCH as a audio conference server which is working great. The audio conferencing is very well integrated in out web-based configuration server and allows the owner of the conference to control it (mute, unmute, isolate, ...) from a browser. One other neat thing a conference owner can do through the browser is to invite additional parties to the conference by typing in a SIP URI. This causes our SIP PBX to do 3rd party call control to refer the invited party to the proper conference. This works very well for conferences that do not require a PIN but breaks for conferences that do. In the latter case, when the invited party answers the call, he hears "please enter your conference access number" out of context. Given that this scenario is less that ideal I started looking for solutions what would allow someone to join a 'PIN-guarded' conference without being prompted for one. I looked at a variety of dialplan-based options without success and turned to another option which I successfully prototyped. The purpose of this post is to socialize the solution I came up with to get feedback and to ultimately learn what needs to be done to get this functionality committed in the code base.
The high-level solution I came up with consists the following: 1- add the conference PIN to the INVITE that is sent to FreeSWITCH; 2- have conference dialplan set a well-known dialplan variable with the content of the PIN as extracted from the INVITE; 3- have mod_conference test the pin contained in the well-known dialplan variable before deciding to prompt the user to enter a PIN.
The solution I prototyped supports two ways of adding the PIN to an INVITE. First, the pin can be included as a well-known URL parameter added to the INVITE, e.g. INVITE sip:myconf@myfreeswitch.local;X-ConfPin=1234 SIP/2.0. When the PIN is passed as a URL parameter, the conference dialplan needs to be of the following form to allow PIN-less entry:
<extension name="700"> <condition field="destination_number" expression="^700$"> <action application="set" data="supplied_pin=${sip_req_params}"/> <action application="conference" data="myconf@700+1234"/> </condition> </extension>
The other way of adding a PIN to an INVITE is to add a user-chosen proprietary header containing the PIN to the INVITE, e.g. X-My-Custom-Pin-Header: 1234. When the PIN is passed as a header, the conference dialplan needs to be of the following form to allow PIN-less entry:
<extension name="700"> <condition field="destination_number" expression="^700$"> <action application="set" data="supplied_pin=${sip_h_X-My-Custom-Pin-Header}"/> <action application="conference" data="myconf@700+1234"/> </condition> </extension>
Whichever method is taken, the end results are similar, i.e. the 'supplied-pin' dialplan variable is initialized with the conference PIN passed in the INVITE. All that is left to do is for the mod_conference to look-up the variable and extract the PIN out of it if non-empty and use it as though the user entered it from his keypad. If the PIN is not the correct one, the logic defaults to prompting the user. The mod_conference patch is attached to this post which essentially consists in adding 10 lines of code (if you ignore the lines changed because of indentation).
Does this approach sound reasonable to you? If so, I'll open a tracker describing the problem and solution and attach my patch to it so that it can be committed.
Thank you very much in advance, Robert
_______________________________________________ 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
-- 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 <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
If you're wanting custom pin like this I would recommend doing it external of the conference module in lua or js. This way you can customize the way you want the pin handled. /b On Sep 11, 2009, at 7:52 AM, Robert Joly wrote:
I haven't heard anything back on this topic. Is it ok for me to open a new tracker issue and attach my patch?
Thanks in advance, bob
I thought it better to modify mod_confence over creating an external pin-entry mechanism for three main reasons: #1 - re-use: The conference module already has a perfectly fine 'prompt-the-user-for-pin' facility, so felt that it should be extended as opposed to be re-created somewhere else. #2 - extend FS: In my narrow view of the world, it seemed like providing a mechanism by which a conference PIN can be supplied as part of the signaling could be useful to other people. As such, adding the feature to mod_conference would make it available to everyone. #3 - simplicity: The entire functionality can be added in about 10 lines of code if done in mod_conference. bob
If you're wanting custom pin like this I would recommend doing it external of the conference module in lua or js. This way you can customize the way you want the pin handled.
/b
On Sep 11, 2009, at 7:52 AM, Robert Joly wrote:
I haven't heard anything back on this topic. Is it ok for me to open a new tracker issue and attach my patch?
Thanks in advance, bob
can you put the patch on jira and we can look at it? Does it require more sound files to be recorded? /b On Sep 11, 2009, at 8:38 AM, Robert Joly wrote:
I thought it better to modify mod_confence over creating an external pin-entry mechanism for three main reasons:
#1 - re-use: The conference module already has a perfectly fine 'prompt-the-user-for-pin' facility, so felt that it should be extended as opposed to be re-created somewhere else. #2 - extend FS: In my narrow view of the world, it seemed like providing a mechanism by which a conference PIN can be supplied as part of the signaling could be useful to other people. As such, adding the feature to mod_conference would make it available to everyone. #3 - simplicity: The entire functionality can be added in about 10 lines of code if done in mod_conference.
bob
Sure can: http://jira.freeswitch.org/browse/MODAPP-333. No new recordings are required to support this. Thanks, bob
On Friday, September 11, 2009 9:47 AM, Brian West wrote:
can you put the patch on jira and we can look at it? Does it require more sound files to be recorded?
/b
On Sep 11, 2009, at 8:38 AM, Robert Joly wrote:
I thought it better to modify mod_confence over creating an external pin-entry mechanism for three main reasons:
#1 - re-use: The conference module already has a perfectly fine 'prompt-the-user-for-pin' facility, so felt that it should be extended as opposed to be re-created somewhere else. #2 - extend FS: In my narrow view of the world, it seemed like providing a mechanism by which a conference PIN can be supplied as part of the signaling could be useful to other people. As such, adding the feature to mod_conference would make it available to everyone. #3 - simplicity: The entire functionality can be added in about 10 lines of code if done in mod_conference.
bob
participants (3)
-
Anthony Minessale
-
Brian West
-
Robert Joly