[Devel] MM7 SOAP (and EAIF) test tools
Hello, Does anybody know of any good MM7 test tools out there (java or C would be best, stress-free setup on OSX/Unix-type). I am in the process of testing the MM7 parts of mbuni and could use additional bug beaters. Thank you. Paul. ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
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
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] "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
[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
[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
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] 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
[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
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. i: j: 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] CVS changes (memory leaks plugged)
Hi All, You will find a whole host of changes made recently in the CVS code. As the Changelog shows, we've had to plug a lot of memory leaks in Mbuni lately. Many thanks for Eric Monchanin (Skycore) and Vincent Chavanis (Telemaque) for raising the red flag(s). Please do test of course and let us know. Paul. ___ 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. 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.c
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] [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
[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=password&command=cmd&mmsc-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 #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] 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
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 ___ 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
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 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 #include #include -#include #endif +#include #include #include #include @@ -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
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. ___ 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] Missing header: X-NOKIA-MMSC-Message-Id
The X-NOKIA-MMSC-Message-Id header should only occur in two scenarios: - When the MMSC sends you (as VASP) a message. - In the response when you send a message to the MMSC. Any other scenarios are suspicious at best. For more documentation on EAIF you want to look out for a Nokia document titled "External Application Developers Guide" for the Nokia MMS Center. (For Nokia MMS Center v3.0 that doc has number MMSC30DOC3001.01). On Oct 16, 2008, at 12:49, Christian Theil Have wrote: With a particular nokia/eaif MMSC (it reports x-nokia-mmsc-version: 4.0) I get the following error when trying to submit a m-send-req: HTTP: Status line: Message-Id> With other eaif type mmsc's I usually get this back in a header _after_ the message is submitted, but apparently not with this mmsc :-( I tried adding a message id (taken from MmsMsg->msg-Id and padded with zeroes to the length 32) and settings this as X-Nokia-MMSC- Message-Id, but that resulted in an other error: HTTP: Status line: So, clearly it doesn't just expect some arbitrary message id. Bummer.. Has anybody experienced similar issues? I am wondering if the is an MMSC misconfiguration or it is just using slightly different version of the protocol? Btw. If anybody has a detailed document about the eaif protocol, please send me a copy. All I can find is: MMS Center Application Development Guide, Version 1.0, 04-03-2002 - which is sparse on technical details and maybe outdated? Best regards, Christian Theil Have ___ 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] 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 #include +#ifdef SunOS +#include +#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