Re: [Devel] Patch with 3 improvements/fixes

[Paul Bagyenda]

Applied, thanks.Paul.On Feb 11, 2014, at 12:54, Jacek Raczkiewicz jacek.raczkiew...@gmail.com wrote:Hello,Here is another patch containing allow-adaptations setting for MMSC. It allows setup allow-adaptations=0/1 in the mmsbox.conf for each MMSC, this value is overwritten by the allow-adaptations passed in the sendmms request. By default (if nothing setup) it is set to true.
Regards,Jacek Raczkiewicz2014-01-23 18:27 GMT+01:00 Jacek Raczkiewicz jacek.raczkiew...@gmail.com:
I have extracted the patch agains not updated version of mbuni.Apparently point 3) is already in the code base.
Please find the updated patch with only point 1) and 2)
2014/1/23 Jacek Raczkiewicz jacek.raczkiew...@gmail.com

Hello,It this patch we have 3 improvement/fixes:1) when no-archive passed inside the DB connection string it is detected but NOT stripped from the connection string and bcz of that it is causing the database connection to fail. This issue has been fixed.


2) In order to make work SMIL with utf-8 data encoded in it (subject mostly) we need to parse it with different function and enforce the UTF-8 encoding on it. I also have added the UTF-8 encoding on the text files attached to MM7 SOAP request. Before it was empty and any UTF-8 chars in subject/MMS text were not displayed properly on the handset. For now it is hardcoded to UTF-8


3) When mbuni sends to MMSC and get 'not-success' status it will retry (if that is allowed) up to max-retrytimes. I have improve this feature by adding the ability to customize the 'retry statuses'. Some statuses from MMSC may be for permanent errors and retrying will not change anything, some may be temprorary. Now user can set which errors should be retried and the rest will not be retried.


Please review these changes and merge them into mbuni code base.Regards,Jacek Raczkiewicz


allow-adaptations.patch___Devel mailing listDevel@mbuni.orghttp://lists.mbuni.org/mailman/listinfo/devel
Paul BAGYENDALogos Solvo LtdTel:+230 465 9761Suite 6B, 6th FloorEbène Mews57 Ebène Cyber CityEbène,MauritiusWeb:http://www.logossolvo.comConfidentiality:This message and its attachments are confidential and are solely intended for the named above. Should you have received this message in error, you may not use or disclose any information contained; please reply to this message, inform the sender about the error and delete all copies of this message.Security Warning: Please be aware that email is not an absolute secure communication medium, as messages sent by email can be intercepted, corrupted, lost, destroyed or arrive late or incomplete without knowledge of the sender or the recipient. Please take this lack of integrity and confidentiality into account when exchanging messages via email with Logos Solvo Ltd.Viruses: Logos Solvo has taken reasonable steps to ensure this message and its attachments are free from viruses. We advise all recipients to follow good computing practices and ensure that messages received via email and any attachments are actually virus free prior to opening or forwarding.

___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel

Re: [Devel] MMSC Statistics support in mbuni

[Paul Bagyenda]

Khaled,

 Sounds interesting. I promise to review your changes when ready :)

Paul.

On Jan 08, 2012, at 12:20, Khaled Al-Hamwi wrote:

 Hi all,
 
 I did not find any information regarding the mmsc statistics such as:
 
 1. Total number of sent MMS messages via MM1 / MM3 / MM4 / MM7.
 2. Total number of successful MMS fetch.
 3. Total number of failed MMS fetch.
 4. Number of MMS messages in the server queue.
 5..
 
 I think it will be nice to support such type of statistics. I have already 
 done some work on this, but I need to know if you plan to include such a 
 feature.
 First, I started by creating a shared memory region to be used by MMSC to 
 update the statistics. The benefit of this is to separate the statistics 
 sampling from the mmsc core.
 Another process can attach this shared memory and collect these counters and 
 save them in a file in a given format.
 
 Then, I found it may be more appropriate to use some central caching service 
 like memcached. This has the clear advantage of sharing the statistics 
 remotely from another machine. So, the sampling process can collect 
 statistics from multiple active mmsc servers.
 
 When I am done with this, I can post the changes to be applied if approved :)
 
 What do you think? Am I doing it right?
 ___
 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] updated: mmsbox MT MMS sender now sends multiple recipients per transaction

[Paul Bagyenda]

I have just updated CVS so that mmsbox will (optionally) include  multiple 
recipients in a single MM7 transaction. For each mmsc you can now set 
'max-recipients' to a number that specifies how many 'To' addresses that MMSC 
will accept per transaction.

Bug reports welcome of course

Paul.
 ___
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel

Re: [Devel] [PATCH] Support UTF-8 characters in Subject field

[Paul Bagyenda]

Patches applied to CVS
On Nov 26, 2010, at 19:52, Piotr Isajew wrote:

 updated
 encodings.txt___
 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 to compile on FreeBSD 8.1-STABLE

[Paul Bagyenda]

applied.
On Sep 11, 2010, at 15:43, Piotr Isajew wrote:

 I needed this to compile on FreeBSD 8.1-STABLE and get mmsbox-mm1 to
 properly resolve dynamic symbols.
 mbuni_freebsd.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] [PATCH] -D_REENTRANT required for multithread on Solaris

[Paul Bagyenda]

All three patches applied. Many thanks.
On May 24, 2010, at 23:54, SATOH Fumiyasu wrote:

 Hi,
 
 Please apply the attached patch for Solaris multithread support.
 
 Regards,
 
 -- 
 -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp)
 -- Business Home: http://www.OSSTech.co.jp/
 -- Personal Home: http://www.SFO.jp/blog/
 mbuni-1.4.0.cvs20100125-solaris-reentrant.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

[Paul Bagyenda]

A little late, but applied. Do test and let me know. 
On Dec 09, 2009, at 06:16, Ian Donaldson wrote:

 Thanks.
 
  Would you kindly send a unified diff (preferably against CVS)?
 
 I've applied my patch with adjustments for differences in the CVS
 version, however I'm unable to test it; autoconf falls over
 with this:
 --
 configure.ac:27: error: possibly undefined macro: AM_INIT_AUTOMAKE
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
 configure.ac:29: error: possibly undefined macro: AM_MAINTAINER_MODE
 configure.ac:34: error: possibly undefined macro: AC_PROG_LIBTOOL
 configure.ac:324: error: possibly undefined macro: AM_CONDITIONAL
 --
 both on Fedora FC11 (autoconf-2.63.2) and on Solaris 9 (with autoconf-2.65)
 
 I've spent a bit of time trying to figure this out to no avail;
 I'm not an expert in any way with autoconf.
 
 Lots of similar complaints on google, with nothing obvious.
 
 I'm attaching the patch anyway; can somebody else see if its ok perhaps
 with an older autoconf.
 
 Ian D
 udiff.txt___
 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] Compile issues WAS Re: [Users] Re: Slow MMS MT delivery

[Paul Bagyenda]

Mbuni CVS now compiles against Kannel CVS only (see doc in CVS). You
are compiling against a different version of Kannel!

P.


On Mon, Jul 28, 2008 at 12:26 PM, Leonard Cooper ::JimmyYakuza::
[EMAIL PROTECTED] wrote:
 FYI: getting:  ( I also got this on the AMD64, but commented out  if line
 74-98 in mms_util.c)

 if
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../mmlib -I../mmlib-I/usr/include -g
 -O2 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -O4 -Wall -fPIC -D_FILE_OFFSET_BITS=64
  -I/usr/include/openssl -I/usr/local/kannel/include/kannel -g -O2 
 -D_XOPEN_SOURCE=600
  -D_BSD_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/libxml2 
 -I/usr/include/openssl
  -I/usr/include/mysql -MT mms_util.o -MD -MP -MF .deps/mms_util.Tpo -c -o
 mms_util.o mms_util.c; \
 then mv -f .deps/mms_util.Tpo .deps/mms_util.Po; else rm -f
 .deps/mms_util.Tpo; exit 1; fi
 mms_util.c: In function âmms_load_core_settingsâ:
 mms_util.c:91: warning: passing argument 4 of âhttp_use_proxyâ from
 incompatible pointer type
 mms_util.c:91: error: too many arguments to function âhttp_use_proxyâ
 make[2]: *** [mms_util.o] Error 1
 make[2]: Leaving directory `/usr/local/src/mbuni/mmlib'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/usr/local/src/mbuni'
 make: *** [all] Error 2



 - Original Message -
 From: Paul Bagyenda [EMAIL PROTECTED]
 To: Leonard Cooper ::JimmyYakuza:: [EMAIL PROTECTED]
 Sent: Monday, July 28, 2008 3:49 AM
 Subject: Re: [Users] Re: Slow MMS MT delivery


 Works fine on other Linux and OSX boxes. Do you get the same error on
 a 32bit Linux system??

 On Sun, Jul 27, 2008 at 2:52 PM, Leonard Cooper ::JimmyYakuza::
 [EMAIL PROTECTED] wrote:
 I am attempting to use Postgres,
  but get the follow error on starting mmsbox.

 /usr/local/mbuni/bin/mmsbox: symbol lookup error:
 /usr/local/mbuni/lib/libmms_pgsql_queue.so: undefined symbol:
 gwlist_timed_consume

 HELP!



 - Original Message -
 From: Leonard Cooper ::JimmyYakuza:: [EMAIL PROTECTED]
 To: P. A. Bagyenda [EMAIL PROTECTED]
 Cc: Mbuni MMS Gateway Users List [EMAIL PROTECTED]
 Sent: Friday, July 25, 2008 4:15 PM
 Subject: Re: [Users] Re: Slow MMS MT delivery


 Hi,

 I have recomplied from cvs  (version: cvs-20080718).
 I have some issues with PIC being a AMD64 box. these were resolved by
 simply
 compiling kannel with -fPIC cflags.
 Mbuni compiles and runs, but STILL no concurrency!

 See below, one message delivered evey 8-11 seconds. this is no good for
 delivering thousands of messages. Even 25 message takes too long!
 I assumed it would run a process at least for each MMSC.
 I am using disk for queue and not postgres. Will using Postgres  make any
 significant difference?

 2008-07-25 15:51:06 Log begins
 2008-07-25 15:59:15 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27822260110/TYPE=PLMN]
 [msgid:REiJ3FkAAyvsAe/AqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 15:59:26 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27828203587/TYPE=PLMN]
 [msgid:REiJ3GUABCvsAP/AqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 15:59:37 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27824978456/TYPE=PLMN]
 [msgid:Q0iJ3G8ACivsAiDAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 15:59:48 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27825070507/TYPE=PLMN]
 [msgid:Q0iJ3HoAHyvsAK3AqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 15:59:58 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27828203587/TYPE=PLMN]
 [msgid:REiJ3IQABSvsAKXAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:00:06 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27822260110/TYPE=PLMN]
 [msgid:REiJ3IwABCvsAaPAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:00:13 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27825070507/TYPE=PLMN]
 [msgid:Q0iJ3JMAECvsAhXAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:00:21 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27824978456/TYPE=PLMN]
 [msgid:REiJ3JsACyvsAhXAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:00:28 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27822260110/TYPE=PLMN]
 [msgid:Q0iJ3KMAAyvsAVvAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:00:36 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27828203587/TYPE=PLMN]
 [msgid:REiJ3KoABivsAVvAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:00:44 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27824978456/TYPE=PLMN]
 [msgid:REiJ3LIABCvsAd3AqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:00:51 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27825070507/TYPE=PLMN]
 [msgid:Q0iJ3LoAACvsAaPAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:00:59 Sent MMS [INT:MMSBox] [ACT:] [MMSC:VODA]
 [from:2782980/TYPE=PLMN] [to:27828203587/TYPE=PLMN]
 [msgid:REiJ3MEABSvsAiDAqAJ1] [size=-1] [UA:] [MMBox:]
 2008-07-25 16:01

Re: [Devel] MMS extraction

[Paul Bagyenda]

On May 04, 2007, at 07:57, Kallon Weingarten wrote:


Hello, Devel@mbuni.org

I am developing an mms content fingerprinter.  And I have looked at  
the Mbuni source.
I would like to test using some of the functions like mms_frombinary 
() in mmlib/mms_msg.c


For Example, I have http transactions containing an mms message.  I  
would like to read in

the http file and do something like this:
1. extract and log certain http headers
2. assign mms into mmsMsg object
   2.1 extract and log specified mms headers (dirive the mms  
message type)
   2.2 extract and fingerprint (probably with CRC) mms content  
(will be multiple pieces of content)

   2.3 Write content to file

After getting a better feel for the mbuni processes, I would like  
to ask the following questions


- How can I include the mbuni libraries, namely libmms.a, to  
utilize such

functions as mms_frombinary(), octstr_read_file(),  ?




  You would have to modify the Makefile.am files to instal the  
headers and libs you need. At the moment they are not installed
- In my compilation, do I need to include Kannel libraries aswell,  
or are they part of the mbuni libraries?



Yes you would. They are not part of the Kannel libs
- is there a way to extract specified headers from a binary mms,  
for eg.; char* tranID = extract_header(MmsMsg msg,  
MMS_HEADER_MESSAGE_ID);



 in mms_msg.h:
Octstr  *mms_get_header_value(MmsMsg *msg, Octstr  *header);


-What c header files do I need to include?



mms_msg.h and mms_util.h should do it.

I appreciate any help.

Thank You,

Kallon.
___
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] Basic Authentication

[Paul Bagyenda]

Yes you are right up to a point: Mbuni currently only supports Basic  
authentication, which is why you are unable to connect. MD5 is not  
difficult to add, just a matter of putting in the time. Patch anyone?


P.

On Apr 05, 2007, at 13:36, Gert Horne wrote:


Hi List,

I am running Mbuni as a Vas gateway. I was connecting to a service
provider and sending messages. As far as I can see they are running
openwave on their gateway

They got this bright idea and disabled Basic authentication.

Now I get error:

HTTP/1.1 401 Unauthorized


They send me a logfile:

WWW-Authenticate: Digest realm=openwavemm7,
nonce=RhO8qw==66e30470390f4844c6aac9c6026165116f8166ac,
algorithm=MD5, qop=auth

They are running some digest authentication.

Q:
1. Am I correct in saying this is the problem?
2. Is there any support for other authentication in Mbuni
3. Any work around.


Regards
Gert Horne

___
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] Mbuni problem

[Paul Bagyenda]

Replied! See http://www.mail-archive.com/users@mbuni.org/msg01049.html


On Apr 04, 2007, at 13:40, Gert Horne wrote:


Hi List,

I have tried the users list but I think they all died of stress or  
some
complicated network error with the cellular network providers were  
some

idiot closed the firewall!!!

I have successfully install and configured mbuni. Gr8 product!

I have been able to connect as a vas to a gateway and successfully  
send

some mms messages.

Now I want to connect to a different gateway and now I receive an  
error

message:


INFO: XML sent is: soap-env:Envelope
xmlns:soap-env=http://schemas.xmlsoap.org/soap/envelope/;soap- 
env:HeaderTransactionID xmlns=http://www.3gpp.org/ftp/Specs/ 
archive/23_series/23.140/schema/REL-5-MM7-1-2 soap- 
env:mustUnderstand=1/TransactionID/soap-env:Headersoap- 
env:Bodysoap-env:Faultsoap-env:faultcodeServer.Service/soap- 
env:faultcodesoap-env:faultstringServer Error/soap- 
env:faultstringsoap-env:DetailStatus xmlns=http://www.3gpp.org/ 
ftp/Specs/archive/23_series/23.140/schema/REL-5- 
MM7-1-0StatusCode4004/StatusCodeStatusTextValidation Error/ 
StatusTextDetailsValidation violation: Probably namespace URI of  
tag TransactionID is wrong (correct one is http://www.3gpp.org/ 
ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0)/ 
Details/Status/soap-env:Detail/soap-env:Fault/soap- 
env:Body/soap-env:Envelope!


2007-04-03 14:52:49 [18772] [11] INFO: parse.soap, h=TransactionID,  
v=!

2007-04-03 14:52:49 [18772] [11] INFO: parse.soap, h=Fault, v=!
2007-04-03 14:52:49 [18772] [11] INFO: parse.soap, h=faultcode,
v=Server.Service!
2007-04-03 14:52:49 [18772] [11] INFO: parse.soap, h=faultstring,
v=Server Error!
2007-04-03 14:52:49 [18772] [11] INFO: parse.soap, h=Status, v=!
2007-04-03 14:52:49 [18772] [11] INFO: parse.soap, h=StatusCode,  
v=4004!

2007-04-03 14:52:49 [18772] [11] INFO: parse.soap, h=StatusText,
v=Validation Error!

2007-04-03 14:52:49 [18772] [11] INFO: parse.soap, h=Details,
v=Validation violation: Probably namespace URI of tag  
TransactionID is

wrong (correct one is
http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/ 
REL-5-MM7-1-0)!

2007-04-03 14:52:49 [18772] [11] INFO: Send to MMSC[mtn], failed,
code=[4004=Validation error], detail=Validation violation: Probably
namespace URI of tag TransactionID is wrong (correct one is
http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/ 
REL-5-MM7-1-0)

2007-04-03 14:52:49 [18772] [11] INFO: Sent to MMC[],
code=[4004=Validation error], msgid [(none)]
2007-04-03 14:52:49 [18772] [11] INFO: Retry later MMSBox Outgoing  
Queue

MMS Send: From number/TYPE=PLMN, to number/TYPE=PLMN, msgsize=104:
err=Failed to deliver to MMC[url=http://user:[EMAIL PROTECTED]/mm7/mm7Server,
id=mtn], status=[4004=Validation error]!

When I seak to the tech guy at the gateway provider is is talking  
about

some sort of Basic Authentication blah blah...

Could you please point me in the right direction.

Regards
Gert Horne



___
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] HTTP: Status line: HTTP/1.1 401 Unauthorized

[Paul Bagyenda]

Please send a more complete log. But from what we can see initially,  
obviously the other side is returning this error. In this case looks  
like you are sending the wrong username/password to the other side.

On Apr 04, 2007, at 22:42, Gert Horne wrote:


Hi list,

I have a new problem with my mbuni setup.
I have configured mbuni as a vas gateway to connect to gateway  
provider

from cvs but get same problem with stable release:

mbuni.conf:

group = core
log-file = /var/log/mbuni/mmsbox.log
access-log = /var/log/mbuni/mmsbox-access.log
log-level = 0

group = mbuni
storage-directory = /var/log/mbuni/spool
max-send-threads = 5
maximum-send-attempts = 2
default-message-expiry = 36
queue-run-interval = 5
send-attempt-back-off = 300
sendmms-port = 10001
name = smsonline

group = mmsc
id = local
mmsc-url = http://username:[EMAIL PROTECTED]:8082/mm7
incoming-username = mmslocal
incoming-password = 123456
incoming-port = 12345
type = soap

group = send-mms-user
username = user
password = 123456
#faked-sender = 2782982


The error in the log is:

HTTP: Status line: HTTP/1.1 401 Unauthorized
INFO: Retry later MMSBox Outgoing Queue MMS Send: From 2783/TYPE=PLMN,
to 2783/TYPE=PLMN, msgsize=87: err=Failed to contact
MMC[url=http://username:[EMAIL PROTECTED]:8082/mm7] = HTTP returned
status=[401]!



The gateway provider said it is my application for they don't give
status 401. I was able to send to them in the past.

Could someone give me some information as to what would generate this
error.


Kind regards
Gert Horne



___
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: [PATCH] MM7_SOAP_COMMAND_REJECTED error 3005

[Paul Bagyenda]

Thanks Vincent. My eyes have been known to play tricks on me  
(particularly Friday evenings!), so I had to be sure.


 I have also posted a whole range of changes to improve message  
parsing, MM4 handling and such. Changelog for details. Please test,  
those who can, and provide feedback.


Thanks

Paul.


On Mar 21, 2007, at 18:20, Vincent CHAVANIS wrote:


Sorry,

This was not the good file.
I see that you have made the changes Thansk !

Vincent.



- Original Message - From: Paul Bagyenda  
[EMAIL PROTECTED]

To: Mbuni MMS Gateway Developers devel@mbuni.org
Sent: Monday, March 19, 2007 11:26 AM
Subject: [Devel] Re: [PATCH] MM7_SOAP_COMMAND_REJECTED error 3005



Hi Vincent,
 Please clarify this patch:
1) The changes to mms_util.h are nowhere in mbuni CVS
2) The error you mention would not cause a re-queueing of the  
message  anyway.

P.
On Mar 14, 2007, at 02:20, Vincent CHAVANIS wrote:

Hi all,

Thi patch fixes the command rejected 3005 from the MMSC
A rejected command should not be requeued to be send later.

Vincent.



diff -rbau /mbuni-cvs/mmlib/mms_mm7soap.h /mbuni/mmlib/mms_mm7soap.h
--- /mbuni-cvs/mmlib/mms_mm7soap.h  2006-11-28   
13:00:20.0 +0100

+++ /mbuni/mmlib/mms_mm7soap.h  2007-03-12 17:52:54.0 +0100
@@ -16,6 +16,7 @@

#define MM7_SOAP_OK 1000
#define MM7_SOAP_FORMAT_CORRUPT 2007
+#define MM7_SOAP_COMMAND_REJECTED 3005
#define MM7_SOAP_UNSUPPORTED_OPERATION 4003
#define MM7_SOAP_STATUS_OK(e) ((e) / 1000 == 1)
#define  MM7_DEFAULT_VERSION 5.3.0


diff -rbau /mbuni-cvs/mmlib/mms_util.h /mbuni/mmlib/mms_util.h
--- /mbuni-cvs/mmlib/mms_util.h 2006-11-25 12:53:40.0 +0100
+++ /mbuni/mmlib/mms_util.h 2007-01-23 11:21:41.0 +0100
@@ -597,12 +609,12 @@
 } else
 tstatus = MM7_SOAP_FORMAT_CORRUPT;

- if (!MM7_SOAP_STATUS_OK(tstatus)) {
+ if (!MM7_SOAP_STATUS_OK(tstatus)  tstatus !=   
MM7_SOAP_COMMAND_REJECTED) {
 Octstr *detail =  mm7_soap_header_value(mresp,  
octstr_imm (Details));

 if (detail == NULL)
  mm7_soap_header_value(mresp, octstr_imm(faultcode));
 ret = NULL;



--
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Service Technique/Reseau - NOC
Developpement SMS/MMS/Kiosques
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

[Devel] Re: [PATCH] MM7_SOAP_COMMAND_REJECTED error 3005

[Paul Bagyenda]

Hi Vincent,

 Please clarify this patch:
1) The changes to mms_util.h are nowhere in mbuni CVS
2) The error you mention would not cause a re-queueing of the message  
anyway.


P.

On Mar 14, 2007, at 02:20, Vincent CHAVANIS wrote:


Hi all,

Thi patch fixes the command rejected 3005 from the MMSC
A rejected command should not be requeued to be send later.

Vincent.



diff -rbau /mbuni-cvs/mmlib/mms_mm7soap.h /mbuni/mmlib/mms_mm7soap.h
--- /mbuni-cvs/mmlib/mms_mm7soap.h  2006-11-28  
13:00:20.0 +0100

+++ /mbuni/mmlib/mms_mm7soap.h  2007-03-12 17:52:54.0 +0100
@@ -16,6 +16,7 @@

#define MM7_SOAP_OK 1000
#define MM7_SOAP_FORMAT_CORRUPT 2007
+#define MM7_SOAP_COMMAND_REJECTED 3005
#define MM7_SOAP_UNSUPPORTED_OPERATION 4003
#define MM7_SOAP_STATUS_OK(e) ((e) / 1000 == 1)
#define  MM7_DEFAULT_VERSION 5.3.0


diff -rbau /mbuni-cvs/mmlib/mms_util.h /mbuni/mmlib/mms_util.h
--- /mbuni-cvs/mmlib/mms_util.h 2006-11-25 12:53:40.0 +0100
+++ /mbuni/mmlib/mms_util.h 2007-01-23 11:21:41.0 +0100
@@ -597,12 +609,12 @@
 } else
 tstatus = MM7_SOAP_FORMAT_CORRUPT;

- if (!MM7_SOAP_STATUS_OK(tstatus)) {
+ if (!MM7_SOAP_STATUS_OK(tstatus)  tstatus !=  
MM7_SOAP_COMMAND_REJECTED) {
 Octstr *detail =  mm7_soap_header_value(mresp, octstr_imm 
(Details));

 if (detail == NULL)
  mm7_soap_header_value(mresp, octstr_imm(faultcode));
 ret = NULL;



--
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Service Technique/Reseau - NOC
Developpement SMS/MMS/Kiosques
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

Re: [Devel] [PATCH] MMS/SIP-patch for mbuni

[Paul Bagyenda]

I for one would love to look at the documentation.

  The project certainly sounds interesting. Does Nokia support  
sending MMS over SIP? Seems not for the current generation phones.  
Does any major vendor?
What advantages/applications can be envisaged? Why SIP over the  
current MM1-WAP scenario? Any comments from list members?

Paul.

On Oct 30, 2006, at 14:53, Ilkka Ollakka wrote:

 On ma 30. lokakuuta 2006 14:14:11, Paul Bagyenda wrote:
 This is certainly interesting. Can you tell us a bit more about your
 test setup? What h/w and so forth?

 Paul.

  Hi,

  Test platform was simple linux-server with mbuni installed, clients
  were one of our own sip-library/client and other 3rd party sip-client
  (can't recall it's name atm. but I'll look it up). Our client also  
 uses
  that same sip-library and has qt4 gui and has basic ability to demux
  mms-messages, also composing basic mms-messages works.

  Testing were done mostly by testing mms from email to sip-client via
  mbuni, and otherway around. Plan was to test also mbuni mm7-interface
  against nokia mmsc, but that still onhold due lack of time. We have
  access to nokia smsc/mmsc so we should be able to test those against
  real mms-messages also when time permits. H/W as ordinary x86-linux,
  client's were on linux/windows desktop pc. Also some test were done
  with nokia sip-phones iirc (with sip-connectivity, not actuall
  mms-sending/receiving yet).

  Also Jarkko Oikarinen and Teemu Husso (who were main workers of this
  project) found out this proposition about mms-messages
  ftp://ftp.tiaonline.org/TR-45/TR452/Incoming/MMS-06-25-conf-call/ 
 X34-20030625-007%20SIP-Based%20MMS_MM1%20%5BNortel%5D.doc
  and followed it's idea, thou we had came up pretty much the same when
  doing our own desining.

  All the documentations on that project is in finnish atm, but we can
  do fast translation from
  http://students.oamk.fi/~t5hute00/qt4/mbunidoc0830.pdf as soons as
  time permits.


 -- 
 Ilkka Ollakka
 I have the world's largest collection of seashells.  I keep it
 scattered around the beaches of the world ... Perhaps you've seen it.
   -- Steven Wright


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] [Users] CVS updated to use Kannel 1.4.1

[Paul Bagyenda]

True. Mbuni 'inherits' Kannel's compile flags.

On Oct 13, 2006, at 13:01, Vincent CHAVANIS wrote:

 In that way,

 Kannel should be compiled with -fPIC which is not the case by default.
 I've just recompiled kannel CVS tree, and recompiled mbuni  
 sucessfully.

 kannel : ./configure --with-cflags='-fPIC'  should work.

 Vincent.


 - Original Message -
 From: Vincent CHAVANIS [EMAIL PROTECTED]
 To: devel@mbuni.org
 Sent: Friday, October 13, 2006 11:27 AM
 Subject: Re: [Devel] [Users] CVS updated to use Kannel 1.4.1


 good news !!!

 But seems to have some incompatibilities with X86_64

 gcc -shared
 .libs/mms_billing_shell.o  -L/usr/lib64/mysql -L/usr/lib64 -L/usr/ 
 local/lib/kannel
 -lgw -lrt -lresolv -lxml2 -L/usr/lib64/openssl/lib -lmysqlclient_r  
 -lz -lcrypt
 -lnsl -lm -lssl -lcrypto -lwap -lgwlib -lpthread -ldl  -Wl,-soname  
 -Wl,libmmsc_billing_shell.so.0
 -o .libs/libmmsc_billing_shell.so.0.0.0
 /usr/bin/ld: /usr/local/lib/kannel/libgwlib.a(gwmem-native.o):  
 relocation
 R_X86_64_32 against `a local symbol' can not be used when making a  
 shared
 object; recompile with -fPIC
 /usr/local/lib/kannel/libgwlib.a: could not read symbols: Bad value
 collect2: ld returned 1 exit status
 make[2]: *** [libmmsc_billing_shell.la] Erreur 1

 Vincent.



 - Original Message -
 From: Paul Bagyenda [EMAIL PROTECTED]
 To: Mbuni MMS Gateway Developers devel@mbuni.org
 Cc: Mbuni MMS Gateway Users List users@mbuni.org
 Sent: Thursday, October 12, 2006 5:32 PM
 Subject: [Users] CVS updated to use Kannel 1.4.1


 Hi All,

  CVS has been updated to compile with Kannel 1.4.1. The most
 significant change is that the need to patch Kannel is gone
 (hopefully for good!)

 This is the first step towards realising the next release of Mbuni.
 Testing and bug reports would be most welcome.

 Thanks

 Paul


 ___
 Users mailing list
 Users@mbuni.org
 http://mbuni.org/mailman/listinfo/users_mbuni.org




 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org




 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

[Devel] CVS updated to use Kannel 1.4.1

[Paul Bagyenda]

Hi All,

  CVS has been updated to compile with Kannel 1.4.1. The most  
significant change is that the need to patch Kannel is gone  
(hopefully for good!)

This is the first step towards realising the next release of Mbuni.  
Testing and bug reports would be most welcome.

Thanks

Paul


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Fwd: installing mbuni on cygwin

[Paul Bagyenda]

your errors are related to linking with a missing  libxml2, or the  
wrong version. See the detailed log you just sent.
On Oct 07, 2006, at 10:27, Abolfazl Rezvan wrote:

 Hi,
   config.log is very long. the part related to this error is what was
 in the previous message.

 Thanx,

 On 10/1/06, Paul Bagyenda [EMAIL PROTECTED] wrote:
 Hi,

   can you send the config.log file? It should show what happened
 On Oct 01, 2006, at 09:51, Abolfazl Rezvan wrote:

 Hi,

   I'm trying to install kannel+mbuni on cygwin. kannel was  
 patched and
 compiled and installed successfully but for mbuni in the middle of
 ./configure this error happens:

 checking for cfg_create in -lgwlib

 error: Kannel gwlib is required!


 I looked into config.log and here is the log (the part or this  
 error):


 configure:22316: gcc -o conftest.exe -g -O2 -I/usr/include/openssl
 -I/usr/local/include/kannel -g -O2 -I/usr/include/libxml2
 -I/usr/include/openssl   -L/usr/local/lib/kannel -lwap -lgwlib -lssl
 -lm  -lpthread -liconv -L/usr/lib -lxml2 -lz -liconv -lm -L/usr/lib
 -lcrypto -lssl conftest.c -lgwlib  -lssl -lpthread  -L/usr/lib
 -lcrypto -lssl 5
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function
 `charset_init':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:320:
 undefined reference to `_xmlAddEncodingAlias'
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function
 `charset_to_utf8':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:473:
 undefined reference to `_xmlFindCharEncodingHandler'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:478:
 undefined reference to `_xmlBufferCreate'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:479:
 undefined reference to `_xmlBufferCreate'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:480:
 undefined reference to `_xmlBufferAdd'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:482:
 undefined reference to `_xmlCharEncInFunc'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:487:
 undefined reference to `_xmlBufferFree'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:488:
 undefined reference to `_xmlBufferFree'
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function
 `charset_from_utf8':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:500:
 undefined reference to `_xmlFindCharEncodingHandler'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:505:
 undefined reference to `_xmlBufferCreate'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:506:
 undefined reference to `_xmlBufferCreate'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:507:
 undefined reference to `_xmlBufferAdd'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:509:
 undefined reference to `_xmlCharEncOutFunc'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:518:
 undefined reference to `_xmlBufferFree'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:519:
 undefined reference to `_xmlBufferFree'
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function
 `charset_convert':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:536:
 undefined reference to `_libiconv_open'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:550:
 undefined reference to `_libiconv'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:551:
 undefined reference to `_libiconv_close'
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function
 `charset_shutdown':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:327:
 undefined reference to `_xmlCleanupEncodingAliases'
 collect2: ld returned 1 exit status
 configure:22322: $? = 1
 configure: failed program was:
 | /* confdefs.h.  */
 |
 | #define PACKAGE_NAME mbuni
 | #define PACKAGE_TARNAME mbuni
 | #define PACKAGE_VERSION cvs
 | #define PACKAGE_STRING mbuni cvs
 | #define PACKAGE_BUGREPORT devel@mbuni.org
 | #define PACKAGE mbuni
 | #define VERSION 1.1.0
 | #define STDC_HEADERS 1
 | #define HAVE_SYS_TYPES_H 1
 | #define HAVE_SYS_STAT_H 1
 | #define HAVE_STDLIB_H 1
 | #define HAVE_STRING_H 1
 | #define HAVE_MEMORY_H 1
 | #define HAVE_STRINGS_H 1
 | #define HAVE_INTTYPES_H 1
 | #define HAVE_STDINT_H 1
 | #define HAVE_UNISTD_H 1
 | #define HAVE_DLFCN_H 1
 | #ifdef __cplusplus
 | extern C void std::exit (int) throw (); using std::exit;
 | #endif
 | #define HAVE_LIBPTHREAD 1
 | #define HAVE_DIRENT_H 1
 | #define STDC_HEADERS 1
 | #define HAVE_SYS_WAIT_H 1
 | #define HAVE_FLOAT_H 1
 | #define HAVE_MEMORY_H 1
 | #define HAVE_STDLIB_H 1
 | #define HAVE_STRING_H 1
 | #define HAVE_SYS_FILE_H 1
 | #define HAVE_UNISTD_H 1
 | #define HAVE_STDLIB_H 1
 | #define HAVE_MALLOC 1
 | #define RETSIGTYPE void
 | #define LSTAT_FOLLOWS_SLASHED_SYMLINK 1
 | #define HAVE_FLOOR 1
 | #define HAVE_LOCALTIME_R 1
 | #define HAVE_MEMSET 1
 | #define HAVE_SQRT 1
 | #define HAVE_STRERROR 1
 | #define HAVE_STRRCHR 1
 | #define

Re: [Devel] Fwd: installing mbuni on cygwin

[Paul Bagyenda]

Hi,

  can you send the config.log file? It should show what happened
On Oct 01, 2006, at 09:51, Abolfazl Rezvan wrote:

 Hi,

   I'm trying to install kannel+mbuni on cygwin. kannel was patched and
 compiled and installed successfully but for mbuni in the middle of
 ./configure this error happens:

 checking for cfg_create in -lgwlib

 error: Kannel gwlib is required!


 I looked into config.log and here is the log (the part or this error):


 configure:22316: gcc -o conftest.exe -g -O2 -I/usr/include/openssl
 -I/usr/local/include/kannel -g -O2 -I/usr/include/libxml2
 -I/usr/include/openssl   -L/usr/local/lib/kannel -lwap -lgwlib -lssl
 -lm  -lpthread -liconv -L/usr/lib -lxml2 -lz -liconv -lm -L/usr/lib
 -lcrypto -lssl conftest.c -lgwlib  -lssl -lpthread  -L/usr/lib
 -lcrypto -lssl 5
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function  
 `charset_init':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:320:
 undefined reference to `_xmlAddEncodingAlias'
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function  
 `charset_to_utf8':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:473:
 undefined reference to `_xmlFindCharEncodingHandler'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:478:
 undefined reference to `_xmlBufferCreate'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:479:
 undefined reference to `_xmlBufferCreate'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:480:
 undefined reference to `_xmlBufferAdd'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:482:
 undefined reference to `_xmlCharEncInFunc'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:487:
 undefined reference to `_xmlBufferFree'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:488:
 undefined reference to `_xmlBufferFree'
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function  
 `charset_from_utf8':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:500:
 undefined reference to `_xmlFindCharEncodingHandler'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:505:
 undefined reference to `_xmlBufferCreate'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:506:
 undefined reference to `_xmlBufferCreate'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:507:
 undefined reference to `_xmlBufferAdd'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:509:
 undefined reference to `_xmlCharEncOutFunc'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:518:
 undefined reference to `_xmlBufferFree'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:519:
 undefined reference to `_xmlBufferFree'
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function  
 `charset_convert':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:536:
 undefined reference to `_libiconv_open'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:550:
 undefined reference to `_libiconv'
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:551:
 undefined reference to `_libiconv_close'
 /usr/local/lib/kannel/libgwlib.a(charset.o): In function  
 `charset_shutdown':
 /cygdrive/e/Programs/MMS/TestTool/gateway-1.4.0/gwlib/charset.c:327:
 undefined reference to `_xmlCleanupEncodingAliases'
 collect2: ld returned 1 exit status
 configure:22322: $? = 1
 configure: failed program was:
 | /* confdefs.h.  */
 |
 | #define PACKAGE_NAME mbuni
 | #define PACKAGE_TARNAME mbuni
 | #define PACKAGE_VERSION cvs
 | #define PACKAGE_STRING mbuni cvs
 | #define PACKAGE_BUGREPORT devel@mbuni.org
 | #define PACKAGE mbuni
 | #define VERSION 1.1.0
 | #define STDC_HEADERS 1
 | #define HAVE_SYS_TYPES_H 1
 | #define HAVE_SYS_STAT_H 1
 | #define HAVE_STDLIB_H 1
 | #define HAVE_STRING_H 1
 | #define HAVE_MEMORY_H 1
 | #define HAVE_STRINGS_H 1
 | #define HAVE_INTTYPES_H 1
 | #define HAVE_STDINT_H 1
 | #define HAVE_UNISTD_H 1
 | #define HAVE_DLFCN_H 1
 | #ifdef __cplusplus
 | extern C void std::exit (int) throw (); using std::exit;
 | #endif
 | #define HAVE_LIBPTHREAD 1
 | #define HAVE_DIRENT_H 1
 | #define STDC_HEADERS 1
 | #define HAVE_SYS_WAIT_H 1
 | #define HAVE_FLOAT_H 1
 | #define HAVE_MEMORY_H 1
 | #define HAVE_STDLIB_H 1
 | #define HAVE_STRING_H 1
 | #define HAVE_SYS_FILE_H 1
 | #define HAVE_UNISTD_H 1
 | #define HAVE_STDLIB_H 1
 | #define HAVE_MALLOC 1
 | #define RETSIGTYPE void
 | #define LSTAT_FOLLOWS_SLASHED_SYMLINK 1
 | #define HAVE_FLOOR 1
 | #define HAVE_LOCALTIME_R 1
 | #define HAVE_MEMSET 1
 | #define HAVE_SQRT 1
 | #define HAVE_STRERROR 1
 | #define HAVE_STRRCHR 1
 | #define HAVE_STRTOL 1
 | #define HAVE_LIBSSL 1
 | #define HAVE_OPENSSL_X509_H 1
 | #define HAVE_OPENSSL_RSA_H 1
 | #define HAVE_OPENSSL_CRYPTO_H 1
 | #define HAVE_OPENSSL_PEM_H 1
 | #define HAVE_OPENSSL_SSL_H 1
 | #define HAVE_OPENSSL_ERR_H 1
 | #define HAVE_LIBSSL 1
 | /* end confdefs.h.  */
 |
 | /* Override any gcc2 internal prototype to 

Re: [Devel] MM1 PDU validity after submitting MM7 SubmitReq

[Paul Bagyenda]

Dziugas,

  We have used it without much trouble. That said, I would not be  
surprised if there were problems in this code! I will take a look and  
advise.

Paul.

On Sep 28, 2006, at 12:13, Dziugas Baltrunas wrote:

 Hi list,

 I noticed that MM7-MM1 conversion mbuni is doing most probably is  
 invalid.

 Attached you will find original MM7/SOAP request and mbuni spool files
 - one for queue and one for data.

 Notice the Content-ID\00mms\00 present in the data file which
 shouldn't really be here. What I'm also missing is the reference to
 the presentation (smil) Content ID (0x8A), thus no phone will show a
 presentation for the user. Going deeper, in the attached data file
 Length of Content Type in Content-Type PDU (0x84) is 0xa3 and specs
 (wap-230 spec, page 83) say that if the length is more than 0x1F,
 additional byte 0x1F shall be used for length indication.

 I'm wondering if anyone has succeeded sending MMS with mbuni via MM7
 with a SMIL presentation (I saw some posts that guys are successfully
 using Openwave SDK), thus maybe I'm doing something wrong here.

 My Nokia N80 will ignore (deffer) attached message, although older
 phones (like Nokia N70) will still accept it, but show no
 presentation.

 -- 
 Dziugas
 df3785.4.x417.21
 mm7req.txt
 qf3785.4.x417.21
 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Mbuni sources ARE on CVS

[Paul Bagyenda]

On Aug 10, 2006, at 12:02, Anton wrote:

 I'm was wrong :)
 Already available today. But CVS is very old? Can anyone
 suggest how to get development sources?


The sources are available and up to date. To download, follow  
instructions here:
http://www.mbuni.org/downloads.shtml

 Regards,
 Anton.

 On 10 August 2006 14:53, Anton wrote:
 Hello,

 Can anyone tell where MBUNI sources gone? For some time
 there is only things prior v1.0 both in downloads and CVS
 - looks like someone plans to release 1.1.0 as a
 commercial product...

 Rgards,
 Anton.

 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org

 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] [PATCH] Usage of mms-message-too-large-txt

[Paul Bagyenda]

applied, with slight modifications.

Thanks.

Paul.

On Jul 26, 2006, at 17:49, Deon van der Merwe wrote:

 Hi,

 This patch will add the current msgid to the notify script if it is  
 present.

 On 7/25/06, Deon van der Merwe [EMAIL PROTECTED] wrote:
 Hi Paul,

 On 7/25/06, Paul Bagyenda [EMAIL PROTECTED] wrote:
  Deon,
 
Not a bad idea at all. Would the additional parameter to the  
 notify-
  script then mean that the message-too-large field is not needed?  
 (Or
  we could just leave it as empty to signal nothing-to-send).
 

 I kept all the other parameters the same: just added the message  
 ID at
 the end.  Busy testing it now... will send the PATCH shortly.

 notify_prov_server_msgid.patch
 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] mime-version header patch

[Paul Bagyenda]

If fell through the cracks! Now applied and on CVS. Apologies.

On Jul 14, 2006, at 13:01, Deon van der Merwe wrote:

 Hi,

 I do not see this patch in the current CVS.  Is this the correct
 procedure for submitting patches?  Or maybe I missed a accept/reject
 for it?


 On 6/13/06, Deon van der Merwe [EMAIL PROTECTED] wrote:
 Hi,

 Small patch to add a MIME-Version header into outbound emails.   
 Some
 mailers do not display the content properly when this header is not
 present...




 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Please permit passing additional parameters to sendsms

[Paul Bagyenda]

Fixed in CVS. Code will check for the '?' and only add it if missing.

I wish all changes were this easy :)

There is a whole host of changes that we are working on, including:
- DB storage of queue data
- OMA MMS conformance in message header lengths
- Moving to up-coming Kannel 1.4.1
- WURFL db integration into content adaptation module

to name but a few.  (Just concluded World Cup has of course not  
helped speed up work!)

I have a list if anyone wants to help or support this.


Thanks

P.

On Jul 13, 2006, at 12:19, Loïc Minier wrote:

 Hi,

  We had problems delivering the notifications to some stricter SMS- 
 C due
  to invalid encoding of the SM.  The root cause was incorrect message
  class of the SM.
The Kannel source code seemed to show that the message class is
  always set to zero in the HTTP interface (sendsms) if not specified
  (other interfaces behave differently).  The coding / binary flag is
  also set to zero by this interface by default (meaning 7-bit /
  non-binary). [1]


  I now consider sendsms an interface where the defaults are not
  specified, so I think it would be best for Mbuni to pass coding and
  mclass parameters, but perhaps it's cleaner to offer them as
  configuration options?

  Anyway, I worked around this by removing ? in:
  octstr_format_append(m-sendsms_url,
   (from  octstr_len(from)  1) ?
   ?username=%Spassword=%Sfrom=%S :
   ?username=%Spassword=%S,
   user,
   pass,from);
  ... to be able to use:
 sendsms-url =
 http://XXX:13013/cgi-bin/sendsms?coding=1mclass=1;
  in mbuni.conf.


Bye,

  [1] I mentionned this to Kannel devel as it seems there's Kannel code
  to correctly guess the appropriate coding and perhaps mclass  
 depending
  on the presence of an udh.
 -- 
 Loïc Minier [EMAIL PROTECTED]

 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] To and CC field separation

[Paul Bagyenda]

On Jun 26, 2006, at 15:10, Deon van der Merwe wrote:

 Hi Paul,

 Had a look at our stats, and I now think the problem (USERS!) is
 actually very small.  Out of 2150 MMS there has only been 7 like this.
  So, now I am thinking: maybe the sulotion is rather the validation
 checks of the destinations.  In this case space is invalid in both
 numbers and email addresses.

 That then takes my little search to where/how/what validation does
 mbuni do on the destinations?



Indeed. There is *very* rudimentary address validation. Something  
better is  planned: A URL will be called prior to accepting a  
message, and passed all the addresses. Message will only be accepted  
if the URL returns something nice. Same URL will be called again  
before message is routed, and may do the necessary billing.



 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] user-agent and x-wap-profile integration

[Paul Bagyenda]

Correct on all counts. In addition, the mmsc should have the option  
to ignore the wap-profile url and rely only on wurfl if one so wishes  
it.

P.



On May 29, 2006, at 12:13, Deon van der Merwe wrote:

 Hi Paul,

 On 5/29/06, Paul Bagyenda [EMAIL PROTECTED] wrote:
 Firstly I apologise for the mailing list being down -- disk space
 issues!

   I think WURFL integration as a fallback is a good idea. It should
 also be fairly easy to implement, as all that's needed is a parser
 that converts the WURFL format to the internal UAProf structure used
 by Mbuni. Something to add onto the todo list.


 The internal memory lookup for the UAProf structure:
 - it can be done on the x-wap-profile header
 - if the above is not found, it also uses the user-agent header
 Is this correct?

 For the second case then: the actual URL of the x-wap-profile does
 not matter.  Correct?

 ___
 Devel mailing list
 Devel@mbuni.org
 http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

[Devel] [PATCH] Further changes to gwlib/mime.[ch] - resent

[Paul Bagyenda]

With subject change. Apologies


Hi,

 Attached is a new diff to update the mime libs somewhat, after my  
last updates. This one reduces the amount of copying that goes on  
as the interface passes objects back and forth


Cheers

Paul.



mime.diff
Description: Binary data


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] mms_start_profile_engine called twice

[Paul Bagyenda]

thanks, updated.
On Feb 21, 2006, at 18:07, Dziugas Baltrunas wrote:

 Hi,

 ok, the small patch attached tries to use a fallback strategy in case
 we're fetching uaprof for the first time. However, I think it would be
 still valuable to fetch and parse the uaprof on demand (or at least
 make a possibility to enable it in the config).

 On 2/20/06, Paul Bagyenda [EMAIL PROTECTED] wrote:
 I think you make a fair point, and certainly this is not something
 that at least I thought long and deep about. A fall back would be a
 nice idea, assuming the client always sends the relevant HTTP  
 headers.

  So yes, a patch that we can all discuss would be a good idea.

 P.

 On Feb 19, 2006, at 19:41, Dziugas Baltrunas wrote:

 Hi, Paul,

 thanks for the comments but IMHO this is not the behaviour most  
 users
 want. Imagine yourself working in some customer care and every  
 second
 user calls asking what does the message Mobile MMS Settings not
 found blaming him or her means. Is it really worth 1-2 seconds of
 blocking the uaprof fetching proxy?

 What is more, mbuni already has a fall-back capabilities negotiation
 strategy based on HTTP headers implemented, so why not to use it in
 case we don't have uaprof cached? Another solutions, such as using a
 central profiles repository databases like WURFL
 (http://wurfl.sourceforge.net/), which recently introduced C++ API,
 also exist.

 Basically I could try to implement a patch for this problem, before
 this I would like to hear opinions about the capabilities  
 negotiation
 strategy.

 Thanks.

 On 2/13/06, Paul Bagyenda [EMAIL PROTECTED] wrote:
 Dzuigas,

  This behaviour is intentional... I didn't think it wise for the
 proxy to block while it tries to retrieve the UA Profile from the
 Internet. Best to temporarily fail, so that client retries, by  
 which
 time  the profile will have been downloaded...

 P.

 On Feb 11, 2006, at 11:01, Dziugas Baltrunas wrote:

 Hi,

 I found out another bug related with uaprof. When starting mbuni
 with
 empty spool dir and sending an MMS, receiver gets a message with
 text
 Mobile MMS Settings not found. For the second time (when then
 uaprof
 is cached) this issue no longer occurs. Here is what debug log
 shows:

 2006-02-11 09:54:02 [6327] [7] DEBUG:  $$ fetch message [fail]
 replying with [type=m-retrieve-conf,content_len=125]:
 [...]
 2006-02-11 09:54:02 [6327] [7] DEBUG:data: 58 2d 4d 6d 73 2d
 52 65
 74 72 69 65 76 65 2d 53   X-Mms-Retrieve-S
 2006-02-11 09:54:02 [6327] [7] DEBUG:data: 74 61 74 75 73 3a
 20 45
 72 72 6f 72 2d 74 72 61   tatus: Error-tra
 2006-02-11 09:54:02 [6327] [7] DEBUG:data: 6e 73 69 65 6e 74
 2d 66
 61 69 6c 75 72 65 nsient-failure
 2006-02-11 09:54:02 [6327] [7] DEBUG:  Octet string dump ends.

 And it looks like only afterwards profile is being fetched:

 2006-02-11 09:54:02 [6327] [7] DEBUG: Dumping MMS message body  
 (not
 multipart) [0 parts] --
 2006-02-11 09:54:02 [6327] [7] DEBUG: HTTP: Destroying HTTPClient
 area
 0x8d93f80.
 2006-02-11 09:54:02 [6327] [7] DEBUG: HTTP: Destroying HTTPClient
 for
 `192.168.150.2'.
 2006-02-11 09:54:02 [6327] [7] DEBUG:  entered free_clientinfo 1,
 ip=148455712
 2006-02-11 09:54:02 [6327] [7] DEBUG:  left free_clientinfo
 2006-02-11 09:54:02 [6327] [7] DEBUG: Thread 7
 (mmsproxy.c:(gwthread_func_t *)fetchmms_proxy) terminates.
 2006-02-11 09:54:02 [6327] [6] DEBUG: HTTP: Opening connection to
 `nds1.nds.nokia.com:80' (fd=25).
 2006-02-11 09:54:02 [6327] [6] DEBUG: Socket connecting
 2006-02-11 09:54:02 [6327] [5] DEBUG: Get info about connecting
 socket
 2006-02-11 09:54:02 [6327] [5] DEBUG: HTTP: Sending request:
 2006-02-11 09:54:02 [6327] [5] DEBUG: Octet string at 0x8d8fa10:
 2006-02-11 09:54:02 [6327] [5] DEBUG:   len:  93
 2006-02-11 09:54:02 [6327] [5] DEBUG:   size: 1024
 2006-02-11 09:54:02 [6327] [5] DEBUG:   immutable: 0
 2006-02-11 09:54:02 [6327] [5] DEBUG:   data: 47 45 54 20 2f 75
 61 70
 72 6f 66 2f 4e 36 32 33   GET /uaprof/N623
 2006-02-11 09:54:02 [6327] [5] DEBUG:   data: 30 72 32 30 30 2e
 78 6d
 6c 20 48 54 54 50 2f 31   0r200.xml HTTP/1
 2006-02-11 09:54:02 [6327] [5] DEBUG:   data: 2e 31 0d 0a 48 6f
 73 74
 3a 20 6e 64 73 31 2e 6e   .1..Host: nds1.n
 2006-02-11 09:54:02 [6327] [5] DEBUG:   data: 64 73 2e 6e 6f 6b
 69 61
 2e 63 6f 6d 0d 0a 55 73   ds.nokia.com..Us
 2006-02-11 09:54:02 [6327] [5] DEBUG:   data: 65 72 2d 41 67 65
 6e 74
 3a 20 4d 62 75 6e 69 2f   er-Agent: Mbuni/
 2006-02-11 09:54:02 [6327] [5] DEBUG:   data: 31 2e 30 2e 30 2d
 63 76
 73 0d 0a 0d 0a1.0.0-cvs
 2006-02-11 09:54:02 [6327] [5] DEBUG: Octet string dump ends.

 Here is the relevant code in mmsc/mmsproxy.c:

  if (settings-content_adaptation) {
   MmsMsg *outmsg = NULL;
   int x = mms_transform_msg(m, h-prof, outmsg);

   if (x == -1) { /* Temporary failure, we need to fetch
 profile. */
mr = mms_retrieveconf(NULL, transid, Error-
 transient-failure

Re: [Devel] Time for another point release?

[Paul Bagyenda]

Your ideas sounds just about right. Let me know what we'd need to do  
on the mbuni side of things to (finally) get Kannel + Mbuni builds  
behaving right.

On Nov 30, 2005, at 15:32, Stipe Tolj wrote:


Paul Bagyenda wrote:


Sounds good.
 FYI: The only points in the mbuni patch that are not of general   
interest have to do with the config params. All else should really  
be  in Kannel.


yep, agree... I'm currently reviewing the patch and will commit  
changes to Kannel's CVS.


The issue about config directives that are used explicetly for  
Mbuni should go also into the direction of an add-on API config  
mechanism, in order to let add-on extentions configure and build  
without the explicite need on patching Kannel's source tree.


Something like:

  $ cd gateway
  $ ./configure  --with-add-on=../mbuni

then Mbuni's configure would be triggered after Kannel's configure  
runs and Kannel would proive a mechanism to incorporate the new  
config directives into it's gwlib/cfg.c module.


At least an approach, if you come up with a better one, please  
shout, we're open for ideas in this section.


Stipe

mailto:stolj_{at}_wapme-group.de
---
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org



___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Mbuni as VAS GW (documentation updated)

[Paul Bagyenda]

CVS has been updated as requested below. The key changes are:

 Each VASP (from the MMSC point of view) has two extra flags: mms-to- 
email-handler if set causes all mms2email to be routed via the VASP  
account (using MM7 SOAP or EAIF) instead of via SMTP. mms-to-local- 
copy-handler if set causes Mbuni to send a copy of each incoming  
local messages to the VASP, before sending out a notification to the  
user.


Carefully used, these changes should provide what you need.

cheers

P.

On Oct 19, 2005, at 19:00, Nicolas Zielinski wrote:

It looks to me like you have Mbuni MMSC and Mbuni VAS GW both  
running.




Indeed  ;)



 There is a problem, you are right, but a different kind of problem:
The MMSC currently sends all messages destined to email addresses
directly to the SMTP server. Should it have an option to re-direct
this to a VAS? It is easy to do, I just need to understand if we
should be doing it...



For instance, a MVNO which holds several mobile brands and who  
wants to use
one MMSC for all brands. Then, when a user sends a MMS2Email, it  
would be

cool to customize the e-mail in function of the sender (for example in
adding the brand logo in the message).

But maybe it doesn't exactly fit with the VASP concept...

BTW, I've found a little bug, mmsproxy doesn't close anymore when I  
use

start-stop-daemon, I have to use kill -9 pid instead.

NZ.


On Oct 19, 2005, at 16:08, Nicolas Zielinski wrote:



Mmsbox is running but I didn't test if it can receive messages...
The log doesn't say anything special, the MMS arrives to mbuni, and
then a
SMS or a mail is sent, but the mms-service is not called...

By the way I'm not clear with the expected message routing, could
you tell
me if I'm wrong :

MMS - Mbuni - MMS-Service - VASP - SendMMS - SMS/Mail ?

And currently I think it's doing this :

MMS - Mbuni - SMS/mail



-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la
part de
Paul Bagyenda
Envoye : mercredi 19 octobre 2005 12:26
A : Mbuni MMS Gateway Developers
Objet : Re: [Devel] Mbuni as VAS GW (documentation updated)

And mmsbox is running and receiving messages via MM7? What does the
log say?

  Keep in mind that mmsbox is not part of the MMSC. It is a separate
app even though it shares code.
P.

On Oct 19, 2005, at 12:29, Nicolas Zielinski wrote:




Hi Paul,





Not at the moment. But you could certainly implement your own VASP
URL that receives the MMS and does the necessary re-formatting
before
sending out to email. This is the beauty of the new additions.





I tried to do that, in using a mms-service with the catch-all
option, but it
seems that it's never called.

I just added this to my conf file, maybe I forgot something :
--
group = send-mms-user
username = pass
password = pass

group = mmsc
id = vas_gw
mmsc-url = http://localhost:1981/
# mmsc-url = http://localhost:8080/vasp/servlet/messagerouter
incoming-username = pass
incoming-password = pass
incoming-port = 10002
type = soap

group = mms-service
name = main
catch-all = true
post-url = http://localhost/mms/vasp.php
http-post-parameters =
images[]=%itext[]=%tsmil[]=%sbinary[]=%bparts[]=%z
accept-x-mbuni-headers = true
keyword = all
assume-plain-text = true



-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la
part de
Paul Bagyenda
Envoye : mardi 18 octobre 2005 17:14
A : Mbuni MMS Gateway Developers
Objet : Re: [Devel] Mbuni as VAS GW (documentation updated)

Hi Nicolas, some answers below

On Oct 18, 2005, at 16:15, Nicolas Zielinski wrote:





Hey,  these changes seem to be great  :)






receive MMS and based on the text in the MMS
decide which URL to call, script to execute, or file to load to  
get

the content to send back.






Is it possible to use this function with the MMS2Email feature ?






  Not at the moment. But you could certainly implement your own VASP
URL that receives the MMS and does the necessary re-formatting  
before

sending out to email. This is the beauty of the new additions.





For instance, I would like to adapt the content of a MMS2Mail
before sending
it (depending on the recipient address for example). Is it possible
to do
this ?

Another question about MM7 : what is the structure of the SOAP
message that
a VASP should send to mbuni ?






  As documented, the VASP sends Mbuni either a SMIL file or some
content (e.g. image, audio). If you send Mbuni a SMIL, it examines
it, fetches all the referenced content (relative to the query URL if
need be) and packs the result together as an MM. If you send Mbuni
some other type of content, it packs it as-is into a message (this
means you can also send Mbuni a binary message).







Thanks.

Nicolas.

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la
part de
Paul Bagyenda
Envoye : lundi 17 octobre 2005 19:22
A : Mbuni MMS Gateway Developers
Objet : [Devel] Mbuni as VAS GW (documentation updated)

Hello All,

  If you've been watching CVS you've

Re: [Devel] Mbuni as VAS GW (documentation updated)

[Paul Bagyenda]

And mmsbox is running and receiving messages via MM7? What does the  
log say?


 Keep in mind that mmsbox is not part of the MMSC. It is a separate  
app even though it shares code.

P.

On Oct 19, 2005, at 12:29, Nicolas Zielinski wrote:


Hi Paul,



Not at the moment. But you could certainly implement your own VASP
URL that receives the MMS and does the necessary re-formatting before
sending out to email. This is the beauty of the new additions.



I tried to do that, in using a mms-service with the catch-all  
option, but it

seems that it's never called.

I just added this to my conf file, maybe I forgot something :
--
group = send-mms-user
username = pass
password = pass

group = mmsc
id = vas_gw
mmsc-url = http://localhost:1981/
# mmsc-url = http://localhost:8080/vasp/servlet/messagerouter
incoming-username = pass
incoming-password = pass
incoming-port = 10002
type = soap

group = mms-service
name = main
catch-all = true
post-url = http://localhost/mms/vasp.php
http-post-parameters =
images[]=%itext[]=%tsmil[]=%sbinary[]=%bparts[]=%z
accept-x-mbuni-headers = true
keyword = all
assume-plain-text = true



-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la  
part de

Paul Bagyenda
Envoye : mardi 18 octobre 2005 17:14
A : Mbuni MMS Gateway Developers
Objet : Re: [Devel] Mbuni as VAS GW (documentation updated)

Hi Nicolas, some answers below

On Oct 18, 2005, at 16:15, Nicolas Zielinski wrote:



Hey,  these changes seem to be great  :)




receive MMS and based on the text in the MMS
decide which URL to call, script to execute, or file to load to get
the content to send back.




Is it possible to use this function with the MMS2Email feature ?




  Not at the moment. But you could certainly implement your own VASP
URL that receives the MMS and does the necessary re-formatting before
sending out to email. This is the beauty of the new additions.



For instance, I would like to adapt the content of a MMS2Mail
before sending
it (depending on the recipient address for example). Is it possible
to do
this ?

Another question about MM7 : what is the structure of the SOAP
message that
a VASP should send to mbuni ?




  As documented, the VASP sends Mbuni either a SMIL file or some
content (e.g. image, audio). If you send Mbuni a SMIL, it examines
it, fetches all the referenced content (relative to the query URL if
need be) and packs the result together as an MM. If you send Mbuni
some other type of content, it packs it as-is into a message (this
means you can also send Mbuni a binary message).





Thanks.

Nicolas.

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la
part de
Paul Bagyenda
Envoye : lundi 17 octobre 2005 19:22
A : Mbuni MMS Gateway Developers
Objet : [Devel] Mbuni as VAS GW (documentation updated)

Hello All,

  If you've been watching CVS you've probably noticed a lot of
movement. I promised a while back to sync the documentation on CVS
with the changes that have been happening there. This I have now  
done.


  To summarise the changes: Mbuni can now behave as a VAS gateway in
the spirit of Kannel. This means that you can connect it to another
MMSC (even itself), receive MMS and based on the text in the MMS
decide which URL to call, script to execute, or file to load to get
the content to send back.

This has been achieved largely by adding a new tool: mmsbox. So if
you want MMSC behaviour, you run mmsrelay/mmsproxy. You want VAS GW
behaviour, run mmsbox. (You can run both on same machine of course
without a problem.)

I hope the model adopted is flexible, and I hope the bugs are few(!)
Please test and lets share.

P.

Ps. There has been an increase in people trying to unpack the binary
MMS stored in the queue directory, e.g. to extract the SMIL part. No
need for this any more! Just use the VAS GW to do that for you, and
hand you the part(s) you are interested in.

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org





___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org




___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

[Devel] Towards 0.9.9

[Paul Bagyenda]

Hi all,

 We think it's time to put out a 0.9.9 (last release before 1.0),  
taking into account all fixes since last release. CVS has been quiet  
for almost two weeks now, which suggests a level of stability. Do let  
me know of any issues we should be aware of before we do the RPM/Deb/ 
Fink thing.


Thank you

P.


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Patch

[Paul Bagyenda]

Very true! Fixed and updated to CVS. Keep the fixes coming.

Cheers

On May 26, 2005, at 05:53, J. Christopher Pereira wrote:


Hi:

There seems to be a bug in mmsglobalsender.c.
Here is the patch.

===
RCS file: /cvsroot/mbuni/mbuni/mmsc/mmsglobalsender.c,v
retrieving revision 1.8
diff -r1.8 mmsglobalsender.c
587c587
 http_header_add(rh, X-NOKIA-MMSC-Message-Id,  
octstr_get_cstr(from));

---

http_header_add(rh, X-NOKIA-MMSC-Message-Id,  
octstr_get_cstr(msgid));




Atentamente,

J. Christopher Pereira
Jefe de Proyecto
TRAZACHILE
www.trazabilidadchile.cl
(09) 475 0 341
(32) 852463

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org




___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

[Devel] WAP GW woes

[Paul Bagyenda]

Occasionally it appears that the WAP GW (Kannel in particular) eats  
part of the incoming MMS message. I imagine this has to do with WAP  
timeouts, etc. I had this problem at one time, and a user just  
reported a problem that at first looked like it was in Mbuni but  
turned out to be in the WAP GW.


 With current Mbuni you would see an error like:

2005-05-24 13:17:01 [23002] [5] WARNING: Parse error reading mime  
body [hlen=61, dlen=16764, left=13837]!


in the log file, which means that the message body sent was shorter  
than expected. This is detected while parsing the MIME entities.


Does anybody have any deeper insights into the cause of this? For now  
CVS has been updated to completely throw away such messages, so as  
not to propagate errors.


P.



___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Reports

[Paul Bagyenda]

Hi,
 Are you looking at this from the VASP side, i.e. do you need a  
program to receive and store DLRs for the VASP?

P.
On May 13, 2005, at 05:02, J. Christopher Pereira wrote:
Hi:
I need to write a stand-alone program (server) for recieving and  
storing delivery and read-reports for EAIF/MM7.
Which is the nearest implementation to recieve those MM7 messages?
Should I hack out the code from mmsproxy.c or can you suggest me  
any other starting point?

Thank you very much.
My best regards,
J. Christopher Pereira
Jefe de Proyecto
TRAZACHILE
www.trazabilidadchile.cl
(09) 475 0 341
(32) 852463
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

[Devel] Re: MM7 testing with NMSS Emulatior 1.5

[Paul Bagyenda]

Thanks, please keep the experiences flowing so that we can have a  
fairly clean new version to put out.

 On another note, those using the CVS version will have probably  
noticed another fairly benign change recently: The queue directory  
structure has changed slightly, to allow any given queue directory to  
hold a larger number of entries. The queue directory now contains a  
series of sub-directories (each of which can have sub-directories  
within).  In total, we can have about 40k sub-directories, which should  
 help prevent hitting limits on number of files per directory too   
quickly.

P.
On Apr 19, 2005, at 22:33, J. Christopher Pereira wrote:
Hi:
The problem is in the NMSS Emulator and not in MBUNDI.
I got MBUNDI send to NowMms (using mm7).
Besides I got the same error when sending from NowMMS to the NMSS  
Emulator, so it's the Emulator or it's configuration.

The mm7 implementation is working. Congratulations!
J. Christopher Pereira
Jefe de Proyecto
TRAZACHILE
www.trazabilidadchile.cl
(09) 475 0 341
(32) 852463
- Original Message - From: J. Christopher Pereira  
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: devel@mbuni.org
Sent: Tuesday, April 19, 2005 1:11 PM
Subject: MM7 testing with NMSS Emulatior 1.5


Hi:
My name is J. Christopher, 26 old, Software Developer, from Chile.
I'm testing Paul's new MM7/EAIF implementation and will probably send  
some diff patches in the future.
To begin, I'm trying to send a MMS to the NMSS Emulator (a MMSC)  
using the latest version available on the CVS.
I'm sending different MMS (generated and found on the web) and I get  
an message type is not set error.
Any clue?

Here's the emulator output:
---
[19.04.2005 12:45:45]INFO: Message received: { Fields {
   To=null
   Cc=null
   Bcc=null
   Subject=null
   Received date=Tue Apr 19 12:45:45 VET 2005
   Sent date=Tue Apr 19 12:45:45 VET 2005
   Delivery date=null
   Expiry date=null
   DR=false
   RR=false
   Message type=null
   Message id=cdcdd2965d5dd293
 }
 Headers {
   X-HTTPHEADER-Host=192.168.0.3:,
   X-HTTPHEADER-Content-Length=35509,
   X-HTTPHEADER-Content-Type=multipart/related;  
start=s1113865285.114102640.G
j.msg;  
boundary==_MIME_boundary_629492862_1113865285_R_o_bd777197551,
 }
 Multipart MIME content {
 }

[19.04.2005 12:45:46]INFO: Received response {1000=Success} from  
Client syste
m id = 13E0ABA7A413555AD38A208 192.168.0.3:9910, id = 1, topics =  
(ServerTopic
systemID=1FF835926C8D447DB73CC,  
serverID=1FF835926C8D447DB73CC-SOCKET_SERVER_1)
mode = AUTO socket://192.168.0.3:9910
[19.04.2005 12:45:47]INFO: Got: 0() routes for MMS with criteria:  
(receiver, s
ender)
[19.04.2005 12:45:47]SEVERE: message type is not set
[19.04.2005 12:45:47]SEVERE: Error handling MM7 message [12]  
message type is not set
com.nokia.mobile.services.emulator.EmulatorException: [12] message  
type is not set
   at  
com.nokia.mobile.services.emulator.mms.server.messageutil.MessageBuild 
er.buildResponse(MessageBuilder.java:58)
   at  
com.nokia.mobile.services.emulator.mms.server.plugin.protocolhandler.
[...]

---
J. Christopher Pereira
Jefe de Proyecto
TRAZACHILE
www.trazabilidadchile.cl
(09) 475 0 341
(32) 852463


___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] MM7/SOAP implementation now on CVS

[Paul Bagyenda]

On Apr 15, 2005, at 09:42, Dziugas Baltrunas wrote:
Hi Paul,
 On MM4 authorisation, that had put that on a back burner. The reason
for this is that it wasn't clear how to implement it. Must the sender
use authenticated smtp? How does info get passed on to mbuni?
I know that MMS standards provide no clear definicions on that, but I
see two ways here. One way would be to use standard SMTP AUTH protocol
and another way would be to assign IP address (or list of them) to
each of the VASPS, so IP address of connecting party matches, HTTP
basic (in case of MM7) or SMTP AUTH (in case of MM4) authorization
could be skipped then.
IP limiting is definitely a good thing to add to the MM7 interface at 
least. The concern on the MM4 side is SMTP intergration. We had avoided 
a full-blown SMTP protocol implementation, but then integrating Mbuni 
into an existing SMTP server brings its own issues (how that SMTP 
server passes on the AUTH info or IP of originator reliably, etc). I 
guess the real question was: What's a clean, simple way to do this... 
Debate...
--
Dziugas
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] MM7/SOAP implementation now on CVS

[Paul Bagyenda]

Thanks Dziugas,
 As I understand it, sf.net anonymous cvs is a couple of hours behind 
the developer one. Give it sometime and the changes should be visble. 
Otherwise my cvs would be lying to me :)

On Apr 14, 2005, at 15:19, Dziugas Baltrunas wrote:
Hi Paul,
congratulations once again for such a useful feature implementation!
It seems that Sourceforge again has long delays or you forgot to
commit the changes, because MM7 changes are missing (at least
doc/userguide.shtml and some others).
On 4/14/05, Paul Bagyenda [EMAIL PROTECTED] wrote:
CVS has been updated with our first implementation of MMS VAS support
in Mbuni.
 The short story:
   Mbuni now supports sending and receiving MMS via the MM7/SOAP
protocol as specified in 3GPP 23.140. Get CVS and play.
The longer story:
  In the config file for mbuni (cvs version that is) you can define 
one
or more value added services providers (VASPs). The userguide (found 
in
the doc/ directory) explains how to do this. (A sample config file
sent.) Mbuni will then accept messages from VASPs and send them on, 
and
will also send messages to VASPs when received.

 Since this required yet more changes to Kannel, you must first patch
and install Kannel before compiling Mbuni. (Patch file is in directory
misc-patches/.) Specifically, we updated the Kannel config file format
to include the new directives, and also added a new function to
mime.[ch] (existing ones were somewhat broken).
For testing purposes, the Openwave MMS SDK (found at
http://developer.openwave.com/dvl/tools_and_sdk/openwave_mobile_sdk/
mms_sdk/) is useful. It also comes with the actual source code (very
useful, since the supplied lib -- vaspapi.jar -- has a bug or two). 
The
SonyEricsson lib seems a bit limited...

Next we plan to implement the EAIF interface, while we clean-up the
SOAP code. Very good feedback has been received on the mmbox code, and
a number of fixes have been done in the meantime. All on cvs.
Please send feedback. Lets hope no bugs were introduced :)
Cheers
Paul
PS: cvs browsing: http://cvs.sourceforge.net/viewcvs.py/mbuni/mbuni/
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

--
Dziugas
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

[Devel] More CVS changes, mmsglobalsender + mmsmobilesender = mmsrelay!

[Paul Bagyenda]

Gents, Ladies,
 I should have pointed out one more change that has (just) happened to 
Mbuni in CVS: mmsmobilsender and mmsglobalsender have been folded into 
one tool called mmsrelay that performs both functions. We tended to 
think this was a bit more sensible.

Documentation on CVS updated accordingly.
Thank you.
P.
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

[Devel] Mbuni licensing issues

[Paul Bagyenda]

Dear all,
 In response to a number of off-list comments, and our own evaluation  
of the directions of the mbuni project, we are proposing a change of  
open source licensing, from the current to a GPL-style license. This  
license would of course include an exception for linking against Kannel  
(see  
http://www.fsf.org/licensing/licenses/gpl- 
faq.html#GPLIncompatibleLibs), and would cover new Mbuni versions going  
forward.

 The key driver for this change is better protection of input by all  
parties going forward. And warmer feelings all round.

 I realise we are making a move to a more restrictive license, which  
always sends the wrong signals, but in this case it seems justified,  
and is in the interests of developers. I would be grateful for your  
views.

 On another note, eager beavers have been hard at work on some of the  
features mentioned earlier, I should be posting code for users to try  
and out provide feedback as we head towards first release. The goal is  
to have a 1.0 before June (yes, with MM7 support).

Cheers
Paul.
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Provisioning

[Paul Bagyenda]

-1 signals that message should be discarded (see mms_billing.h)...
On Mar 11, 2005, at 12:24, Søren Hansen wrote:
fre, 11 03 2005 kl. 12:21 +0300, skrev Paul Bagyenda:
The way I see it, if they can send, they've guessed the URL for our
MMSC. That doesn't necessarily mean that they should be allowed to 
use
the MMSC... Or how would you block that? Can the billing module 
return
an error somehow?
Correct. Billing module should/would catch that.
How? mms_billmsg returns a double? How do I return an error from there?
--
Søren Hansen [EMAIL PROTECTED]
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Provisioning

[Paul Bagyenda]

On Mar 11, 2005, at 12:58, Søren Hansen wrote:
fre, 11 03 2005 kl. 12:30 +0300, skrev Paul Bagyenda:
-1 signals that message should be discarded (see mms_billing.h)...
So it does! Hmm... I still think some sort of check should be applied
beforehand.
In my little world, the provisioning stuff isn't just about capabilites
(MMS enabled or not), but also about permission to use the service.. 
I'm
thinking about calling the status script in sendmms_proxy after the
message has been parsed so that I can return and Error-service-denied.
Comments?

Equally you could queue back a DLR on mmsglobalsender...
--
Søren Hansen [EMAIL PROTECTED]
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

[Devel] CVS access

[Paul Bagyenda]

Hello All,
 I am pleased to announce that the CVS repository is now ready for 
prime time. Repository is /cvsroot/mbuni/ on cvs.sf.net and we will be 
using this for development. Please note however that 
http://mbuni.sf.net/ may be a couple of steps behind the main site.

 Do let me know if you experience any problems.
 Short primer:
 For anonymous access:
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/mbuni login
then followed by
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/mbuni co mbuni
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Re: [Devel] Fwd: Re: mbuni need for freebsd

[Paul Bagyenda]

hi,
 Could you send us patches against v0.9.7, explaining what they do, so  
that we can use those.

Thanks.
On Mar 04, 2005, at 14:58, Andrew Wingorodov wrote:

 I was build port for installation mbuni into FreeBSD (look at attach).
 But!
 To avoid the conflict, you should change the version of a file at its
 change. Also it is desirable to store all versions for different  
versions of
 ports. PLS!
( Look file distinfo for differences )

 Best regards!
---
mbuni_ports-0.9.6b.tgzmbuni_ports 
-0.9.6a.tgz___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org