Re: [Users] MMS User Provisioning
Hello Paul,
Thanks for highlighting the point we were missing all along. In fact, the
original reply had already stated that "The script should return the MSISDN on
"STANDARD OUTPUT" if the subscriber is allowed access", but we overlooked it.
Kindest regards,
Andrew & Deborah
-Original Message-
From: Paul Bagyenda [mailto:bagye...@dsmagic.com]
Sent: Tue 5/31/2011 7:27 AM
To: Andrew Caruana
Cc: users@mbuni.org
Subject: Re: [Users] MMS User Provisioning
Hi Andrew,
You want to return the msisdn as standard output, to wit:
#!/bin/bash
echo 0035612345678
On May 30, 2011, at 17:40, Andrew Caruana wrote:
Hello,
We have followed your kind feedback but mbuni is returning a returned
"msisdn = null" in the debug as follows:
2011-05-30 16:12:52 [4275] [0] INFO: mms_detokenize_shell.c:60
[mms_detokenizer] [n/a] Calling "/test_script xyz123
10.159.50.228"
2011-05-30 16:12:52 [4275] [0] INFO: mms_detokenize_shell.c:71
[mms_detokenizer] [n/a] Called "/test_script xyz123
10.159.50.228", returned msisdn = null
Thus, we would appreciate if you may highlight to us what may we be
doing wrong in our very simple script hereunder whereby our intention is to
return variable "$msisdn" with value 0035612345678 to Mbuni. The script runs
fine when executed by mbuni and the variables ("$1", "$2", "$msisdn") are
written to a log file. We are not sure if mbuni is expecting another variable
name other than "$msisdn":
#!/bin/bash
echo "$1" >> /tmp/detokenizer.log
echo "$2" >> /tmp/detokenizer.log
msisdn="0035612345678"
echo "$msisdn" >> /tmp/detokenizer.log
In this respect we have also included the following parameters in the
configuration file:
detokenizer-library = "builtin:shell"
detokenizer-module-parameters = "/usr/local/bin/mmsc_150/test_script"
Thanks and kind regards,
Andrew & Deborah
-Original Message-----
From: kitand...@gmail.com on behalf of Paul Bagyenda
Sent: Mon 5/30/2011 7:01 AM
To: Andrew Caruana
Cc: users@mbuni.org
Subject: Re: [Users] MMS User Provisioning
Hello Andrew,
answers inline:
On 27 May 2011 15:32, Andrew Caruana wrote:
Hi,
Thanks for feedback. It is now clear that subscriber control
may be achieved through the use of a script as defined by the variable
"prov-server-notify-script" as referred to in the Mbuni User Guide.
In this respect, and in view the user guide lacks such
information, we would appreciate that you share with information about:
(i) The name and syntax of the Mbuni output variables that the
script requires in order to be able to populate the subscriber database; and
You can use "detokenizer-library" for this. Set this to "builtin:shell"
Then set "detokenizer-module-parameters" to the (full path of the)
shell script.
This script will be called for each received request. The first
parameter is not used for shell scripts, the second is the request IP. The
script should return the MSISDN on standard output if the subscriber is allowed
access, otherwise it should fail (i.e. abort).
(ii) The name and syntax of the input variables that Mbuni
requires from the script following a query to the subscriber database in order
not to allow the processing of MMS requests originating from subscriber whose
MSISDNs do not exist in the subscriber database.
For this, use "prov-server-notify-script" which will be called with
parameters (in order):
- command type (notification type)
- event (sent,received, etc)
- msisdn
- msg ID
- user-agent
- UAProf
Thanks and regards,
Andrew & Deborah
-Original Message-
From: kitand...@gmail.com on behalf of Paul Bagyenda
Sent: Thu 5/26/2011 1:50 PM
To: Andrew Caruana
Cc: users@mbuni.org
Subject: Re: [Users] MMS User Provisioning
User provisioning is entirely outside of Mbuni. A
Re: [Users] MMS User Provisioning
Hi Andrew,
You want to return the msisdn as standard output, to wit:
#!/bin/bash
echo 0035612345678
On May 30, 2011, at 17:40, Andrew Caruana wrote:
> Hello,
>
> We have followed your kind feedback but mbuni is returning a returned "msisdn
> = null" in the debug as follows:
>
> 2011-05-30 16:12:52 [4275] [0] INFO: mms_detokenize_shell.c:60
> [mms_detokenizer] [n/a] Calling "/test_script xyz123
> 10.159.50.228"
> 2011-05-30 16:12:52 [4275] [0] INFO: mms_detokenize_shell.c:71
> [mms_detokenizer] [n/a] Called "/test_script xyz123
> 10.159.50.228", returned msisdn = null
>
>
> Thus, we would appreciate if you may highlight to us what may we be doing
> wrong in our very simple script hereunder whereby our intention is to return
> variable "$msisdn" with value 0035612345678 to Mbuni. The script runs fine
> when executed by mbuni and the variables ("$1", "$2", "$msisdn") are written
> to a log file. We are not sure if mbuni is expecting another variable name
> other than "$msisdn":
>
> #!/bin/bash
> echo "$1" >> /tmp/detokenizer.log
> echo "$2" >> /tmp/detokenizer.log
> msisdn="0035612345678"
> echo "$msisdn" >> /tmp/detokenizer.log
>
>
>
> In this respect we have also included the following parameters in the
> configuration file:
>
> detokenizer-library = "builtin:shell"
> detokenizer-module-parameters = "/usr/local/bin/mmsc_150/test_script"
>
>
> Thanks and kind regards,
>
>
> Andrew & Deborah
>
>
> -Original Message-
> From: kitand...@gmail.com on behalf of Paul Bagyenda
> Sent: Mon 5/30/2011 7:01 AM
> To: Andrew Caruana
> Cc: users@mbuni.org
> Subject: Re: [Users] MMS User Provisioning
>
> Hello Andrew,
>
> answers inline:
>
>
> On 27 May 2011 15:32, Andrew Caruana wrote:
>
>
> Hi,
>
> Thanks for feedback. It is now clear that subscriber control may be
> achieved through the use of a script as defined by the variable
> "prov-server-notify-script" as referred to in the Mbuni User Guide.
>
> In this respect, and in view the user guide lacks such information,
> we would appreciate that you share with information about:
> (i) The name and syntax of the Mbuni output variables that the script
> requires in order to be able to populate the subscriber database; and
>
>
>
> You can use "detokenizer-library" for this. Set this to "builtin:shell"
> Then set "detokenizer-module-parameters" to the (full path of the) shell
> script.
>
> This script will be called for each received request. The first parameter is
> not used for shell scripts, the second is the request IP. The script should
> return the MSISDN on standard output if the subscriber is allowed access,
> otherwise it should fail (i.e. abort).
>
>
>
> (ii) The name and syntax of the input variables that Mbuni requires
> from the script following a query to the subscriber database in order not to
> allow the processing of MMS requests originating from subscriber whose
> MSISDNs do not exist in the subscriber database.
>
>
>
>
>
> For this, use "prov-server-notify-script" which will be called with
> parameters (in order):
>
> - command type (notification type)
> - event (sent,received, etc)
> - msisdn
> - msg ID
> - user-agent
> - UAProf
>
>
>
>
> Thanks and regards,
>
>
> Andrew & Deborah
>
>
>
>
> -Original Message-
> From: kitand...@gmail.com on behalf of Paul Bagyenda
> Sent: Thu 5/26/2011 1:50 PM
> To: Andrew Caruana
> Cc: users@mbuni.org
> Subject: Re: [Users] MMS User Provisioning
>
> User provisioning is entirely outside of Mbuni. All that's required
> is that for each incoming MMS Mbuni can determine the sender. This is
> typically done using special HTTP headers added by your WAP GW. For billing,
> again we call a configured script, which can prevent delivery as needed based
> on user status (as determined by a separate database).
>
> P.
>
> On 26 May 2011 14:27, Andrew Caruana wrote:
>
>
> Hello,
>
>
>
> We would appreciate if someone may shed us some light on the
> topic of MMS user provisioning on Mbuni. Neither the use
Re: [Users] MMS User Provisioning
Hello,
We have followed your kind feedback but mbuni is returning a returned "msisdn =
null" in the debug as follows:
2011-05-30 16:12:52 [4275] [0] INFO: mms_detokenize_shell.c:60
[mms_detokenizer] [n/a] Calling "/test_script xyz123 10.159.50.228"
2011-05-30 16:12:52 [4275] [0] INFO: mms_detokenize_shell.c:71
[mms_detokenizer] [n/a] Called "/test_script xyz123 10.159.50.228", returned
msisdn = null
Thus, we would appreciate if you may highlight to us what may we be doing wrong
in our very simple script hereunder whereby our intention is to return variable
"$msisdn" with value 0035612345678 to Mbuni. The script runs fine when executed
by mbuni and the variables ("$1", "$2", "$msisdn") are written to a log file.
We are not sure if mbuni is expecting another variable name other than
"$msisdn":
#!/bin/bash
echo "$1" >> /tmp/detokenizer.log
echo "$2" >> /tmp/detokenizer.log
msisdn="0035612345678"
echo "$msisdn" >> /tmp/detokenizer.log
In this respect we have also included the following parameters in the
configuration file:
detokenizer-library = "builtin:shell"
detokenizer-module-parameters = "/usr/local/bin/mmsc_150/test_script"
Thanks and kind regards,
Andrew & Deborah
-Original Message-
From: kitand...@gmail.com on behalf of Paul Bagyenda
Sent: Mon 5/30/2011 7:01 AM
To: Andrew Caruana
Cc: users@mbuni.org
Subject: Re: [Users] MMS User Provisioning
Hello Andrew,
answers inline:
On 27 May 2011 15:32, Andrew Caruana wrote:
Hi,
Thanks for feedback. It is now clear that subscriber control may be
achieved through the use of a script as defined by the variable
"prov-server-notify-script" as referred to in the Mbuni User Guide.
In this respect, and in view the user guide lacks such information, we
would appreciate that you share with information about:
(i) The name and syntax of the Mbuni output variables that the script
requires in order to be able to populate the subscriber database; and
You can use "detokenizer-library" for this. Set this to "builtin:shell"
Then set "detokenizer-module-parameters" to the (full path of the) shell script.
This script will be called for each received request. The first parameter is
not used for shell scripts, the second is the request IP. The script should
return the MSISDN on standard output if the subscriber is allowed access,
otherwise it should fail (i.e. abort).
(ii) The name and syntax of the input variables that Mbuni requires
from the script following a query to the subscriber database in order not to
allow the processing of MMS requests originating from subscriber whose MSISDNs
do not exist in the subscriber database.
For this, use "prov-server-notify-script" which will be called with parameters
(in order):
- command type (notification type)
- event (sent,received, etc)
- msisdn
- msg ID
- user-agent
- UAProf
Thanks and regards,
Andrew & Deborah
-Original Message-
From: kitand...@gmail.com on behalf of Paul Bagyenda
Sent: Thu 5/26/2011 1:50 PM
To: Andrew Caruana
Cc: users@mbuni.org
Subject: Re: [Users] MMS User Provisioning
User provisioning is entirely outside of Mbuni. All that's required is
that for each incoming MMS Mbuni can determine the sender. This is typically
done using special HTTP headers added by your WAP GW. For billing, again we
call a configured script, which can prevent delivery as needed based on user
status (as determined by a separate database).
P.
On 26 May 2011 14:27, Andrew Caruana wrote:
Hello,
We would appreciate if someone may shed us some light on the
topic of MMS user provisioning on Mbuni. Neither the user guide nor the
archives cover this topic.
Thanks and regards,
Andrew & Deborah
This email and any files or content transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the
sender immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the
Re: [Users] MMS User Provisioning
Hello Andrew, answers inline: On 27 May 2011 15:32, Andrew Caruana wrote: > Hi, > > Thanks for feedback. It is now clear that subscriber control may be > achieved through the use of a script as defined by the variable > "prov-server-notify-script" as referred to in the Mbuni User Guide. > > In this respect, and in view the user guide lacks such information, we > would appreciate that you share with information about: > (i) The name and syntax of the Mbuni output variables that the script > requires in order to be able to populate the subscriber database; and > You can use "detokenizer-library" for this. Set this to "builtin:shell" Then set "detokenizer-module-parameters" to the (full path of the) shell script. This script will be called for each received request. The first parameter is not used for shell scripts, the second is the request IP. The script should return the MSISDN on standard output if the subscriber is allowed access, otherwise it should fail (i.e. abort). > (ii) The name and syntax of the input variables that Mbuni requires from > the script following a query to the subscriber database in order not to > allow the processing of MMS requests originating from subscriber whose > MSISDNs do not exist in the subscriber database. > > For this, use "prov-server-notify-script" which will be called with parameters (in order): - command type (notification type) - event (sent,received, etc) - msisdn - msg ID - user-agent - UAProf > Thanks and regards, > > > Andrew & Deborah > > > > -Original Message- > From: kitand...@gmail.com on behalf of Paul Bagyenda > Sent: Thu 5/26/2011 1:50 PM > To: Andrew Caruana > Cc: users@mbuni.org > Subject: Re: [Users] MMS User Provisioning > > User provisioning is entirely outside of Mbuni. All that's required is that > for each incoming MMS Mbuni can determine the sender. This is typically done > using special HTTP headers added by your WAP GW. For billing, again we call > a configured script, which can prevent delivery as needed based on user > status (as determined by a separate database). > > P. > > On 26 May 2011 14:27, Andrew Caruana wrote: > > > Hello, > > > > We would appreciate if someone may shed us some light on the topic > of MMS user provisioning on Mbuni. Neither the user guide nor the archives > cover this topic. > > > > > > Thanks and regards, > > > > > > Andrew & Deborah > > > > This email and any files or content transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. This message contains confidential information and > is intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this e-mail by > mistake and delete this e-mail from your system. If you are not the intended > recipient you are notified that disclosing, copying, distributing or taking > any action in reliance on the contents of this information is strictly > prohibited. The Company and the originator of this email accept no liability > for the content of this email, or for the consequences of any actions taken > on the basis of the information provided, unless that information is > subsequently confirmed in writing. If you are not the intended recipient you > are notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. > > > Warning: Although the Company and the originator have taken > reasonable precautions to ensure no viruses are present in this email, the > company cannot accept responsibility for any loss or damage arising from the > use of this email or attachments. > > > ___ > Users mailing list > Users@mbuni.org > http://lists.mbuni.org/mailman/listinfo/users > > > > > > > > > > ___ > Users mailing list > Users@mbuni.org > http://lists.mbuni.org/mailman/listinfo/users > > ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] MMS User Provisioning
Hi, Thanks for feedback. It is now clear that subscriber control may be achieved through the use of a script as defined by the variable "prov-server-notify-script" as referred to in the Mbuni User Guide. In this respect, and in view the user guide lacks such information, we would appreciate that you share with information about: (i) The name and syntax of the Mbuni output variables that the script requires in order to be able to populate the subscriber database; and (ii) The name and syntax of the input variables that Mbuni requires from the script following a query to the subscriber database in order not to allow the processing of MMS requests originating from subscriber whose MSISDNs do not exist in the subscriber database. Thanks and regards, Andrew & Deborah -Original Message- From: kitand...@gmail.com on behalf of Paul Bagyenda Sent: Thu 5/26/2011 1:50 PM To: Andrew Caruana Cc: users@mbuni.org Subject: Re: [Users] MMS User Provisioning User provisioning is entirely outside of Mbuni. All that's required is that for each incoming MMS Mbuni can determine the sender. This is typically done using special HTTP headers added by your WAP GW. For billing, again we call a configured script, which can prevent delivery as needed based on user status (as determined by a separate database). P. On 26 May 2011 14:27, Andrew Caruana wrote: Hello, We would appreciate if someone may shed us some light on the topic of MMS user provisioning on Mbuni. Neither the user guide nor the archives cover this topic. Thanks and regards, Andrew & Deborah This email and any files or content transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. The Company and the originator of this email accept no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Warning: Although the Company and the originator have taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] MMS User Provisioning
User provisioning is entirely outside of Mbuni. All that's required is that for each incoming MMS Mbuni can determine the sender. This is typically done using special HTTP headers added by your WAP GW. For billing, again we call a configured script, which can prevent delivery as needed based on user status (as determined by a separate database). P. On 26 May 2011 14:27, Andrew Caruana wrote: > Hello, > > > > We would appreciate if someone may shed us some light on the topic of MMS > user provisioning on Mbuni. Neither the user guide nor the archives cover > this topic. > > > > > > Thanks and regards, > > > > > > Andrew & Deborah > > > > This email and any files or content transmitted with it are confidential > and intended solely for the use of the individual or entity to whom they are > addressed. This message contains confidential information and is intended > only for the individual named. If you are not the named addressee you should > not disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. The > Company and the originator of this email accept no liability for the content > of this email, or for the consequences of any actions taken on the basis of > the information provided, unless that information is subsequently confirmed > in writing. If you are not the intended recipient you are notified that > disclosing, copying, distributing or taking any action in reliance on the > contents of this information is strictly prohibited. > > > Warning: Although the Company and the originator have taken reasonable > precautions to ensure no viruses are present in this email, the company > cannot accept responsibility for any loss or damage arising from the use of > this email or attachments. > > ___ > Users mailing list > Users@mbuni.org > http://lists.mbuni.org/mailman/listinfo/users > > ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
