[Freeswitch-users] mod_conference: Any way to pass conference PIN in the URI?

[Joe Attardi]

Hi Kristian,

Kristian Kielhofner wrote:
> I'm still pretty new at this (and I'm sure there are better ways to do
> it) but I *think* this should ask for ping 1234 unless you are coming
> from SIP host 192.168.0.5 (at least according to the $sip_from_host,
> presumably parsing the host portion of the From: header).  Obviously
> replace sip_from_host with a relevant SIP variable and expression with
> whatever you want to match...

I tried something similar (here is the relevant snippet from my 
default_context.xml):

<context name="default">
   <extension name="4444">
     <condition field="destination_number" expression="^conf1$" 
break="on-true">
       <action application="conference" data="conf1 at 4444+12345"/>
     </condition>
     <condition field="destination_number" expression="^conf1-nopin$" 
break="on-true">
      <action application="conference" data="conf1 at 4444" />
     </condition>
   </extension>
</context>

The intent was to skip the PIN if the destination number was 
'conf1-nopin' and require it if it was 'conf1'. This works great for the 
first person to call the conference. After that, the setting "sticks".

i.e. if I call conf1-nopin, I get in without a PIN, but then others get 
in without a PIN even if they call conf1;
and if I call conf1; I am prompted for a PIN, but then others get 
prompted for a PIN even if they call conf1-nopin.

I looked through the mod_conference docs and found this as the explanation:
http://wiki.freeswitch.org/wiki/Mod_conference#Syntax
"The first time a conference name (confname) is used, it will be created 
on demand, and the pin will be set to what ever is specified at that 
time: the pin in the data string if specified, or if not, the "pin" 
setting in the conference profile, and if that is also unspecified, then 
there is no pin protection. Any later attempt to join the conference 
must specify the same pin number, if one existed when it was created. "

So, though your suggestion was good (and I got excited when it initially 
worked!), it looks like this won't work. Does anyone else have any other 
ideas?

Thanks...

-- Joe