Re: [Devel] Couple of patches
Applied.
Thanks
On Dec 04, 2008, at 02:08, Benno Rice wrote:
The following patches make Mbuni compile and run properly on Solaris
9 (tested on x86). The problems were:
- mms_billing_shell.c needs to include sys/wait.h on Solaris to get
the WEXITSTATUS macro.
- In mms_queue.c, mms_queue_readenvelope opens the queue file
O_RDONLY, and then calls mm_lockfile on the fd. mm_lockfile (via
lockfile) attempts to lock the file using (under Solaris) fcntl and
F_WRLCK. This fails when the file is read only. The patch I've
included works around this by opening the file O_RDWR even though
we're only reading it. An alternative but possibly more correct
solution would be to give an argument to mm_lockfile (and lockfile)
to indicate that we want a read lock (F_RDLCK or LOCK_SH in flock
parlance) instead.
Thanks!
--
Benno Rice
[EMAIL PROTECTED]
Index: mmlib/mms_queue.c
===
RCS file: /cvsroot/mbuni/mbuni/mmlib/mms_queue.c,v
retrieving revision 1.40
diff -u -r1.40 mms_queue.c
--- mmlib/mms_queue.c 1 Dec 2008 05:14:55 - 1.40
+++ mmlib/mms_queue.c 3 Dec 2008 23:06:58 -
@@ -203,7 +203,7 @@
strncpy(xqf, octstr_get_cstr(fname), sizeof xqf);
- if ((fd = open(octstr_get_cstr(fname), O_RDONLY)) 0) {
+ if ((fd = open(octstr_get_cstr(fname), O_RDWR)) 0) {
octstr_destroy(fname);
return NULL;
} else if (mm_lockfile(fd, octstr_get_cstr(fname),
shouldblock) != 0) {
Index: mmsc/mms_billing_shell.c
===
RCS file: /cvsroot/mbuni/mbuni/mmsc/mms_billing_shell.c,v
retrieving revision 1.7
diff -u -r1.7 mms_billing_shell.c
--- mmsc/mms_billing_shell.c29 Aug 2007 13:33:09 - 1.7
+++ mmsc/mms_billing_shell.c3 Dec 2008 23:06:59 -
@@ -13,6 +13,10 @@
#include stdio.h
#include stdlib.h
+#ifdef SunOS
+#include sys/wait.h
+#endif
+
#include mms_billing.h
static Octstr *script = NULL;
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] vasp-id
A fair observation. Patch applied. Thanks On Oct 02, 2008, at 16:25, Christian Theil Have wrote: Hi I find it a bit impractical that the id of an mmsc is used as the vasp-id for soap mmscs. For instance, this could pose a problem with multiple mmscs using the same vasp-id. My suggestion is that we add an optional vasp-id to the mmsc configuration. A patch is attached. Any comments? Christian. vasp-id.patch___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] locking on SunOS
Thanks for the review.
If you would, kindly share a non-destructive patch for further
discussion.
P.
On Sep 18, 2008, at 17:05, Christian Theil Have wrote:
I've been testing the patch and it seems to work out allright :-)
A few notes;
#include sys/stat.h
must be outside #ifdef SunOS - other systems needs it too
in unlock_and_fclose(FILE *fp)
fclose is only called in #else, I suppose that should have been like
for unlock_and_close or we'll run out of filehandles ;-)
Best regards,
Christian
On Wed, Sep 10, 2008 at 10:05 PM, Jason Pollock [EMAIL PROTECTED]
wrote:
Christian Theil Have wrote:
Hi
I think it looks good :-) I was working on some similar code based
on a dict, which I was still testing out, but your patch is cleaner.
I look forward to trying it out, but I wont have the opportunity to
test it until Monday though.
About changing close and fclose everywhere in the codebase, you
could get around this without having to change the rest the of
codebase by using a few macros , eg.
#ifdef SunOS
#define close(fd) unlock_and_close(fd)
#endif
int unlock_and_close(fd) {
#ifdef close(fd)
#undef close(fd)
printf(unlock_and_close do the stuff..\n);
return close(fd);
#define close(fd) unlock_and_close(fd)
#endif
}
and similarly for fclose...
Christian.
That would work. I wasn't sure if the Mbuni team would want to go
that way, or the Kannel way:
#define close(x) you_should_not_call_close_directly(x)
I personally decided against the #define because I wanted to be able
to check that all instances of close/fclose had been modified in the
source I was working on. I did look at trying to figure out how to
wrap the libc call, but I thought that might be a bit too
destructive to my schedule. ;)
I'm still new to the gwlib code, I didn't realise it had a dict!
Too bad it uses octstr's as keys.
Let me know if you run into any problems. If I find any, I'll let
the list know.
Jason
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] locking on SunOS
Jason, Thanks. It would be nice to see a full patch against latest CVS for this. On Sep 19, 2008, at 02:16, Jason Pollock wrote: P. A. Bagyenda wrote: Thanks for the review. If you would, kindly share a non-destructive patch for further discussion. Here are the changes that I applied based on the comments. Index: mms_util.c === RCS file: /home/cvs/MBUNI/mmlib/mms_util.c,v retrieving revision 1.4 diff -a -u -r1.4 mms_util.c --- mms_util.c 10 Sep 2008 04:04:09 - 1.4 +++ mms_util.c 18 Sep 2008 23:15:09 - @@ -22,9 +22,9 @@ #include fcntl.h #include pthread.h #include sys/types.h -#include sys/stat.h #endif +#include sys/stat.h #include errno.h #include sys/types.h #include sys/stat.h @@ -929,9 +929,8 @@ key.dev = buf.st_dev; release_file_lock(fd, key); -#else -return fclose(fp); #endif +return fclose(fp); } /* Compare a file_lock(lhs) to the file_key(rhs) ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
[Devel] http-based mmsbox message relay
Has been added to CVS. The idea is that if you have two instances of mmsbox running on separate boxes, MMS received by one instance can be transparently routed to the other instance, which can then do some processing on it. Documentation has been updated. Please test and let us know. On another note, we have also completed the admin interface for Mbuni MMSC, so that you can dynamically stop/start VASP connections. Of course this works best if you also have dynamic loading of configuration settings, so that you can change the VASP parameters on the fly. Sadly these aspects are not all that well documented. Lets not whisper the word lazy, even though it might be accurate :) P. ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] locking on SunOS
Thank you Jason, Comments welcome from all interested parties, before we apply patch. Paul. On Sep 10, 2008, at 07:13, Jason Pollock wrote: PostgreSQL isn't really an option for me here at this point. I've modified the lock functions to (hopefully) allow linux's flock semantics. The code now maintains a list of inode/dev pairs. When a lock request arrives for an existing inode/dev, it is forced to wait on a pthread_cond_t. The change does require that close and fclose be changed to two functions in the library to maintain the list. Otherwise the list will get out of sync with the locks. This may not be viable for the main code base. I've attached my changes, I would appreciate any comments. Just a warning - I haven't tested it extensively, just enough to see that it stops the queue runner from starting a message a second time. P. A. Bagyenda wrote: We welcome a solution when one is found! The chickens among us would, if using Solaris, rather use the PostgreSQL-based queue storage module instead :) That brings a number of advantages: - Queue processing is faster for larger queues, since unlike the file-based storage which scans the entire queue directory tree on each run, this one only picks up messages due for processing - Message archival is built in. On Sep 04, 2008, at 00:02, Jason Pollock wrote: Jason Pollock wrote: I have noticed the same problem. With fcntl locks, the lock isn't associated with a file descriptor, it's associated with the file, so if someone opens the file, checks the lock and closes the file in the same process, the lock is released. Since it's a required lock, perhaps Solaris mandatory locking would be a better way to deal with the problem than a dict? http://sunsite.uakom.sk/sunworldonline/swol-04-1998/swol-04-insidesolaris.html Closer reading seems to indicate that that won't work either. Nuts. ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel code_changes.tgz___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] locking on SunOS
We welcome a solution when one is found! The chickens among us would, if using Solaris, rather use the PostgreSQL-based queue storage module instead :) That brings a number of advantages: - Queue processing is faster for larger queues, since unlike the file-based storage which scans the entire queue directory tree on each run, this one only picks up messages due for processing - Message archival is built in. On Sep 04, 2008, at 00:02, Jason Pollock wrote: Jason Pollock wrote: I have noticed the same problem. With fcntl locks, the lock isn't associated with a file descriptor, it's associated with the file, so if someone opens the file, checks the lock and closes the file in the same process, the lock is released. Since it's a required lock, perhaps Solaris mandatory locking would be a better way to deal with the problem than a dict? http://sunsite.uakom.sk/sunworldonline/swol-04-1998/swol-04-insidesolaris.html Closer reading seems to indicate that that won't work either. Nuts. ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
[Devel] Re: [Users] Help with Mbuni VASGW administration Interfaces
CVS now has the beginnings of the HTTP admin interface. No documentation updates yet, alas, but that should change over the coming hours. Briefly, you need to add the following config params to your mbuni conf group: mmsbox-admin-port = port_no admin-password = password admin-port-ssl = one_of_true_or_false You should then be able to access the HTTP admin port using http(s)://mbuni-host:port/?password=passwordcommand=cmdmmsc-id=mmsc In each case the HTTP response is XML formatted. The parameter 'cmd' is one of: - status: This spits out the status of the mmsc connection provided (if none is provided then status information for all active mmsc connections is provided) - start: This starts the mmsc connection whose ID (in the conf file) matches that provided (if none is provided then all are started) - stop: This stops the mmsc connection whose ID matches that provided (if none is provided then all are stopped) Feedback is welcomed of course. You will also notice additional updates in the Changelog, particularly with respect to dynamic configuration of Mbuni. (These are documented.) Regards, Paul. On Aug 30, 2008, at 11:27, Mohammad Abu Karim wrote: Hi Guys. Kannel Has HTTP administration to administer the kannel to check status, shutdown ..etc. Does mbuni has such administration HTTP or command interface to administer it? If yes tell me please how to access it, and how I can check mbuni vasgw status. I mean how I can check the vasgw queue, the served MMSes, the filed delivered MMses and so on. Regards. Mohammad Abu-Karim ___ Users mailing list [EMAIL PROTECTED] http://lists.mbuni.org/mailman/listinfo/users ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] [PATCH] include signal.h
applied. thanks On Sep 02, 2008, at 21:56, Martin Atukunda wrote: diff --git a/mmsc/mmsc.c b/mmsc/mmsc.c index 4e9fd99..7334d94 100644 --- a/mmsc/mmsc.c +++ b/mmsc/mmsc.c @@ -11,6 +11,7 @@ * the GNU General Public License, with a few exceptions granted (see LICENSE) */ +#include signal.h #include mmsc.h #include mms_uaprof.h -- 1.5.6.3 ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] [PATCH] Add a default mmsc to the send-mms-user field
applied with slight mods. Thanks On Aug 20, 2008, at 09:58, Martin Atukunda wrote: Hi, This patch adds an mmsc field to the send-mms-user section of the configuration file for mbuni. The idea is to have a default mmsc in case the CGI Variable is not set. for review, - Martin - 002_add_mmsc_to_send_mms_user .diff___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] [PATCH] fix content-id when a script is giving content
Applied -- thank you. Ditto Martin's patch.
Paul.
On Aug 18, 2008, at 17:01, Vincent CHAVANIS wrote:
Hi all,
This patch fixes the Content-ID header when a 'listed' web
programming language is used to get the content (to get an image/
sound/video into a DB from a php script for example).
This also fixes the content_type2file_ext() function when Content-type
is populated with more than one values.
(We take the first one expecting the content type)
(eg: Content-Type: text/plain; charset=utf-8; name=txt1.txt)
Vincent.
--
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Service Technique/Reseau - NOC
Direction du Developpement xMS+
http://www.telemaque.fr/
[EMAIL PROTECTED]
Tel : +33 4 92 90 99 84 (fax 9142)
diff -rbau /mbuni-cvs/mmlib/mms_util.c /mbuni/mmlib/mms_util.c
--- /mbuni-cvs/mmlib/mms_util.c 2008-08-07 16:09:25.0 +0200
+++ /mbuni/mmlib/mms_util.c 2008-08-18 15:53:58.0 +0200
@@ -1364,6 +1364,23 @@
{NULL, NULL}
};
+/* Some of Web languages used for generating content, but can't be
a content itself. */
+static struct {
+ char *language, *file_ext; }
+l_exts[] = {
+ {Perl, pl},
+ {Php, php},
+ {Python, py},
+ {Common Gateway Interface, cgi},
+ {Active Server Page, asp},
+ {Java Server Page, jsp},
+ {Ruby on Rails, rb},
+ {Tool Command Language, tcl},
+ {Shell Command Language, sh},
+ {Executables, exe},
+ {NULL, NULL}
+};
+
Octstr *filename2content_type(char *fname)
{
char *p = strrchr(fname, '.');
@@ -1379,7 +1396,12 @@
static char *content_type2file_ext(Octstr *ctype)
{
- int i;
+ int i,j;
+
+ /* Take the first value, expecting content-type! */
+ if ((j = octstr_search_char(ctype, ';', 0)) != -1)
+ octstr_delete(ctype, j, octstr_len(ctype));
+
for (i = 0; exts[i].file_ext; i++)
if (octstr_str_case_compare(ctype, exts[i].ctype) == 0)
return exts[i].file_ext;
@@ -1389,6 +1411,7 @@
char *make_file_ext(Octstr *url, Octstr *ctype, char fext[5])
{
+ int i;
fext[0] = 0;
if (url) {
HTTPURLParse *h = parse_url(url);
@@ -1402,6 +1425,11 @@
strncpy(fext, p+1, 4); /* max length of 4. */
http_urlparse_destroy(h);
+
+ for (i = 0; l_exts[i].file_ext; i++)
+ if (strcasecmp(fext, l_exts[i].file_ext) == 0)
+return content_type2file_ext(ctype);
+
if (fext[0]) return fext;
}
done:
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] [PATCH] Mime extension recognition problem for 3gpp
applied. thanks
On Aug 19, 2008, at 18:27, Vincent CHAVANIS wrote:
A very small fix,
3gpp should be recognize as 3gp and not 3gp2
Without this patch a 3gpp Content-type will be recognize with .3gp2
extention. And will result as an Non-playable MMS item on somes
phones.
Vincent.
diff -rbau /mbuni-cvs/mmlib/mms_util.c /mbuni/mmlib/mms_util.c
--- /mbuni-cvs/mmlib/mms_util.c 2008-08-19 10:44:42.0 +0200
+++ /mbuni/mmlib/mms_util.c 2008-08-19 17:13:27.0 +0200
@@ -1355,8 +1355,8 @@
{application/smil, smi},
{application/vnd.wap.mms-message, mms},
{application/java-archive, jar},
- {video/3gpp, 3gp2},
{video/3gpp, 3gp},
+ {video/3gpp, 3gp2},
{video/3gpp2, 3g2},
{audio/vnd.qcelp, qcp},
--
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Service Technique/Reseau - NOC
Direction du Developpement xMS+
http://www.telemaque.fr/
[EMAIL PROTECTED]
Tel : +33 4 92 90 99 84 (fax 9142)
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] Multiple values for single name in multipart/form-data for MMS service HTTP POST
We support unique names, we simply don't guarantee that they are unique, if the message contains multiple parts of the same type and/or the http-post-parameters is constructed in such a way as not to ensure they are unique. PHP is certainly not the ideal poster boy of Web languages I agree, but it is common and so we are stuck with it. To be sure we did not base this on what PHP does, rather we found that since a number of engines support this seamlessly (see Python, Perl, and so on), and your typical web clients (firefox, IE, etc) are perfectly happy sending multiple fields with the same name, then there is no reason for us to hard-code field generation in a way that might not be flexible for the end-user (programmer). And we think Python, PHP et al take the right view that it is better to be liberal in what you accept. The resulting code on the client side is also typically cleaner than what one might have dealing with many different names. In short, I am open to suggestions, but really in this case I am not convinced that Oreilly/Jakarta guys took the best position! P. On Apr 29, 2008, at 10:04, Giulio Harding wrote: Well, we're constrained to Java for our applications. The Java parsers we've tried including COS (com.oreilly.servlet) and Jakarta Commons fileupload do not support multiple identical names. Given that the RFC says that the names should be unique, I'd say that the PHP parser is not the best basis for mbuni's design/functionality. Why not support unique names as the RFC suggests, and thus allow the use of other (stricter) parsers? On 29/04/2008, at 3:12 PM, P. A. Bagyenda wrote: Giulio, Yes and no. Most CGI processors accept multiple parameters with the same name, and process them based on whatever rules they impose. For instance PHP converts the parameter into an array if the parameter name(s) are of the form name[]. Other languages do different things. Try the attached PHP file as a simple example. Mbuni for that reason also uses the same name for different parts as found. t.php On Apr 29, 2008, at 08:15, Giulio Harding wrote: From the mbuni documentation (http://www.mbuni.org/userguide.shtml#mms_service ): Note that the parameter name/value is repeated as many times in the POST data as there are matching parts in the message. That is, if there are three images in the MM and http-post-parameters is image=%i then the parameter image will be passed thrice, with different values. (The CGI script used must therefore be prepared to handle multiple parameters with the same name.) So; given multiple images, there would be multiple parameter/value pairs with 'name=image' in the mulitpart/form-data in the HTTP POST body. However, from RFC 2388 - Returning Values from Forms: multipart/ form-data (http://www.ietf.org/rfc/rfc2388.txt): 3. Definition of multipart/form-data The media-type multipart/form-data follows the rules of all multipart MIME data streams as outlined in [RFC 2046]. In forms, there are a series of fields to be supplied by the user who fills out the form. Each field has a name. Within a given form, the names are unique. ... multipart/form-data contains a series of parts. Each part is expected to contain a content-disposition header [RFC 2183] where the disposition type is form-data, and where the disposition contains an (additional) parameter of name, where the value of that parameter is the original field name in the form. So; it looks like mbuni's behaviour violates the RFC for multipart/ form-data, in that within it's given 'form', the names are NOT unique. Aside from RFC compliance (which could be debatable?), it turns out that pretty much every multipart/form-data parser we've come across does not support multiple values for a single name. We'd like to avoid hacking one of these parsers to support multiple values for a single name - wouldn't it be better for mbuni to enumerate the names somehow (to make them unique) when handling multiple pieces of the same type of content? -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman
Re: [Devel] Multiple values for single name in multipart/form-data for MMS service HTTP POST
Giulio, Yes and no. Most CGI processors accept multiple parameters with the same name, and process them based on whatever rules they impose. For instance PHP converts the parameter into an array if the parameter name(s) are of the form name[]. Other languages do different things. Try the attached PHP file as a simple example. Mbuni for that reason also uses the same name for different parts as found. body form method=POST enctype=multipart/form-data i: input name=x[] br j: input name=x[]br input type=submit ?php print_r($_POST['x']); ? /form /body On Apr 29, 2008, at 08:15, Giulio Harding wrote: From the mbuni documentation (http://www.mbuni.org/userguide.shtml#mms_service ): Note that the parameter name/value is repeated as many times in the POST data as there are matching parts in the message. That is, if there are three images in the MM and http-post-parameters is image= %i then the parameter image will be passed thrice, with different values. (The CGI script used must therefore be prepared to handle multiple parameters with the same name.) So; given multiple images, there would be multiple parameter/value pairs with 'name=image' in the mulitpart/form-data in the HTTP POST body. However, from RFC 2388 - Returning Values from Forms: multipart/form- data (http://www.ietf.org/rfc/rfc2388.txt): 3. Definition of multipart/form-data The media-type multipart/form-data follows the rules of all multipart MIME data streams as outlined in [RFC 2046]. In forms, there are a series of fields to be supplied by the user who fills out the form. Each field has a name. Within a given form, the names are unique. ... multipart/form-data contains a series of parts. Each part is expected to contain a content-disposition header [RFC 2183] where the disposition type is form-data, and where the disposition contains an (additional) parameter of name, where the value of that parameter is the original field name in the form. So; it looks like mbuni's behaviour violates the RFC for multipart/ form-data, in that within it's given 'form', the names are NOT unique. Aside from RFC compliance (which could be debatable?), it turns out that pretty much every multipart/form-data parser we've come across does not support multiple values for a single name. We'd like to avoid hacking one of these parsers to support multiple values for a single name - wouldn't it be better for mbuni to enumerate the names somehow (to make them unique) when handling multiple pieces of the same type of content? -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
[Devel] Additions to Mbuni
Hi All, There have been a number of additions/changes in mbuni CVS over the last few weeks that I thought I might hi-light here: - The Mbuni VAS GW can now be used to route messages from one MMSC to another without passing through an mms-service. There are two ways to do this: - using the 'reroute' and 'reroute-mmsc-id' parameters, or - using a loadable module or shell script that is called for each message received, and returns the ID of the MMSC through which to route the message (or the empty string to route to the matching 'mms-service' The module is also allowed to re-write the sender/receiver address! - To cater for MMSCs with picky MM7/SOAP parsers, we've added extra parameters you can use to control for exact coding of the MM7 XML you send. Refer to doc for details. - Support for custom MM7 implementations using the mmsc group config variable value 'type = custom' in Mbuni VAS GW. This makes it possible to (more easily) develop your own custom MM7 connectivity type and plug it in. As always, please refer to Changelog for details Paul. ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
[Devel] various changes in CVS
Hi All, A few additions and improvements on CVS, including: - A plug-in that makes it possible to store queued messages inside a PostgreSQL (v8.2) database rather than in files. In addition, messages can be stored permanently (delivered messages are moved to an archive table). - mmsbox can now be used to pure message routing using a new per- mmsc connection flag 'reroute'. - mmsbox will capture and pass on any UAProf data sent by the MMSC, if the MMSC is using MM7/SOAP v6.x.y More details in Changelog as always. Thanks Paul. ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] [PATCH] Manage SIGHUP
Applied to CVS. Thanks
P.
On Aug 29, 2007, at 11:24, [EMAIL PROTECTED] wrote:
Hi all,
usually SIGHUP is used in order to close and to reopen the log
files (with logrotate for example). Mbuni manage the SIGHUP as
SIGTERM and quit the application.
I attach my patch that manage the SIGHUP signal.
--- mmsbox/mmsbox.c 17 Jul 2007 08:26:36 - 1.35
+++ mmsbox/mmsbox.c 28 Aug 2007 13:29:57 -
@@ -40,6 +40,15 @@
http_close_port(mmc-incoming.port);
}
+//manage the SIGHUP signal
+static void relog_now(int notused)
+{
+ warning(0, SIGHUP received, catching and re-opening logs);
+ log_reopen();
+ alog_reopen();
+}
+
+
/* Finds text part, returns copy. */
static MIMEEntity *find_textpart(MIMEEntity *m)
{
@@ -555,7 +564,7 @@
mms_cfg_destroy(cfg);
- signal(SIGHUP, quit_now);
+ signal(SIGHUP, relog_now);
signal(SIGTERM, quit_now);
signal(SIGPIPE,SIG_IGN); /* Ignore pipe errors. They kill us
sometimes for nothing*/
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
[Devel] DLR handling improvement, UACapabilities tracking addition
Just posted to CVS, UACapabilities tracking on the mmsbox and mmsbox interfaces. This means that the VASP can receive info about the type of client requesting content. In addition, I have tried to clean up the DLR reporting and tracking in mmsbox. We now tag each service request transaction with an ID, which is reported (in addition to the message id, sender, receiver and User-Agent profile, if any) to the DLR URL. Details in the documentation. Questions, comments, corrections welcome. Paul. ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
[Devel] Mbuni 1.3.0 released
Hello, We have put out a new release of Mbuni, please find details on the website. Mostly this represents all the changes that have over the past eight months taken place (bug fixes, minor enhancements, etc). We will also shortly be announcing some commercial add-ons, in preparation of which you will see certain notes in Changelog file. Looking ahead, Mbuni really has matured in our view. In the main, what is required are the little bits of add-ons that can improve useability. Which is what changes since the last release have been mostly about. Also, one of the more requested features has been the ability to receive and send MMS using a GPRS/GSM modem on the VAS side. Generally we know how to do it, but have had a number of false starts caused by using the wrong hardware. It looks like we need a regular GPRS modem, not a phone that has a built-in modem (because this captures the MMS notification). The other missing component (concatenated MO SMS handling in Kannel) is now in place. Generally we consider this a low priority issue, but if somebody is interested in it, we can provide direction or they can provide the GPRS modem and we will get it working. Paul ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] From: header for MM4_delivery_report.REQ messages
I believe this issue should be resolved now. Kindly confirm. On May 25, 2007, at 14:34, Deon van der Merwe wrote: Hi All, I am tracing an issue with regard to MM4_delivery_report.REQ messages to other MMSC's. The From: field is set to [EMAIL PROTECTED]. The other MMSC is expecting this field to be the number for the handset to which the message was sent in the first place. Like MSISDN/[EMAIL PROTECTED]. The thing is this: I am unable to find the place where this message is created in order to set that From: field. Can anyone give me a pointer in the right direction, please? ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] Local delivery problem
What you need to do is use the resolver library plugin mechanism to implement your own script that decides which recipients are local or not. The script is invoked for each recipient. In your case it should simply return the current mmsc hostname and that should do the trick. (Look at config param resolver-library.) On Jun 10, 2007, at 01:02, James Caradoc-Davies wrote: I am attempting to use the Send MMS service to submit a message for local delivery. However I am unable to get the gateway to accept the message instead it says Don't know how to route! The config is shown: group=core ... group = mbuni name = blux hostname = mymmsc.com local-prefixes = 27 sendsms-url = http://192.168.1.10/sendsms sendsms-username = xxx sendsms-password = xxx sendmms-port = group = send-mms-user username = mms password = mms The idea is that Mbuni accepts the MMS via the HTTP-GET on port and stores the message, then originates a wap push to the sendsms-url to initiate the delivery sequence. The messages are NOT accepted for local delivery - I want ALL messages to be for local delivery. I have tried unified-prefix with no improvement. Still Don't know how to route! [I have noticed about 10 test messages came through but cannot isolate the config that worked - that was six hours ago] Thx -- caractacus ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] Content-type
Yes there is, but it aint all that pretty: Create an MMS message using one of those nokia tools, containing the image you want. Then point the service to this message. You want (of course) to ensure that the file extension (e.g. .mms) is mapped to the correct content type by your HTTP server. Really the 3GPP standards do not say anything about the message content type afaik, at least not in the strict sense, but most MMSC tend to choke on anything that is not straight-up multipart MIME On May 22, 2007, at 12:08, [EMAIL PROTECTED] wrote: List, I'm facing the following issue: I have defined a mms-service: group = mms-service name = fullmessage get-url = http://www.mbuni.org/images/logo.jpg accept-x-mbuni-headers = true catch-all = false keyword = thixs When i send the keyword thixs to the shortcode basically the mbuni will fetch the image defined in the get-url and build an MM. Problem that i'm facing is that the content-type of this image wil be set to image/jpeg which for me is ok. But the MMSC server doesn't like this. The MMSC server is expecting: multipart/related or multiparty/mixed (According to the MMSC vendor this is based on the 3GPP standard. Is there an easy way to fix this? Cheers, Edward ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
