). We also patch the makefile
so that WAP libs (and headers) are installed/exposed. One interim
option might be to fold the patch into Kannel.
On Feb 08, 2005, at 05:49, Davy Chan wrote:
**>Date: Mon, 07 Feb 2005 21:19:04 +0100
**>From: Stipe Tolj <[EMAIL PROTECTED]>
**>To: Paul B
Hi,
We tended to think that the MSISDN should more properly be supplied by
the WAP gateway or HTTP proxy, in the case where the phone by-passes
the WAP stack. Note that the HTTP header name is configurable in mbuni,
so you can change it...
On Feb 08, 2005, at 14:05, Dziugas Baltrunas wrote:
Hi
Hi,
I will work on a fix for the quotes and advise.
On the content adaptation, for images we first tried with netpbm, but
it doesn't support that many graphics formats, so we dropped it. I
think that whatever you do, the content adaptation part is going to
require a lot of extra machinery. You
Dzuigas,
These are excellent thoughts. Comments below
On Feb 08, 2005, at 23:16, Dziugas Baltrunas wrote:
Hi again,
On the content adaptation, for images we first tried with netpbm, but
it doesn't support that many graphics formats, so we dropped it. I
think that whatever you do, the content adapt
Thanks Dzuigas,
I see the clamour for MM7 is rising. I guess this puts it near the top
of priority list? Last I looked at the protocols (SOAP and EAIF/nokia)
they struck me as simple. The issue will be getting the architecture
right.
On Feb 10, 2005, at 11:45, Dziugas Baltrunas wrote:
http://w
Hi,
You might be using an older gcc (less forgiving of non-standard C).
Please re-download and problem should go away. Let me know if not.
On Feb 11, 2005, at 09:19, Esin Seref wrote:
hello,
I am new to both kannel and mbuni. I wanted to install
and see how they work together, but no luck with m
Thanks Raphael, this is the correct and should work. I had already
updated the version on site as below.
On Feb 11, 2005, at 12:38, R. wrote:
Hello,
I am testing mbuni and this problem can be solved easily for "old" gcc
by modifying the file "mmsproxy.c"
lines 691 should be placed after the 2 f
With the current download you don't need to use gcc3 anymore. gcc2 will
work as well. It was a silly mistake on our part that caused no damage
but was more C++ than C (where declarations must, of course, all appear
at the beginning of a block!)
On Feb 11, 2005, at 23:39, Esin Seref wrote:
thank
Hi,
Sending to IP addresses is not supported at the moment, because we
couldn't find examples of such recipients. Could you tell me more about
these so we can see what to do?
Cheers.
Paul.
On Feb 14, 2005, at 15:53, Jayabharathi wrote:
Does Mbuni supports sending to ipv4 addresses. Since my M
Hi,
I hope to put out v0.9.7 over the weekend, and I could use some
testers of it. Attached is a patch to the current 0.9.6. Please see the
Changelog. For instance we now have access.log which provides a more
friendly way to keep tabs on what's going on inside mbuni
Please test this and let
CVS is coming shortly, and it is good that the interest is shown.
For indentention: K&R style. Or at least emacs's interpretation of it.
On Mar 02, 2005, at 18:57, Søren Hansen wrote:
Hi!
I'm very keen on doing some development on Mbuni, and I think it'd be
MUCH easier for everyone if you could se
Thanks Soren,
Somebody else on the list had mentioned this issue. I think your
approach is more generalised and therefore preferred. We would need, in
order to keep things easy, to have builti-in default behaviour that
ensures that if a plug-in is missing, delivery proceeds according to
prefix
No reason other than that I found the PPG interface a bit much, so
opted for direct encoding. A tested patch would definitely be welcome.
On Mar 03, 2005, at 11:43, Søren Hansen wrote:
Hi!
Is there any particular reason why we're encoding the MMS's ourselves
instead of using a PPG? If noone can g
Thanks Søren,
I have applied the patches to the next release, with a few exceptions:
- the move you suggested, of list_destroy(lto,NULL) in mmsfromemail.c
is potentially dodgy since that variable is reset in the meantime. So
in some circumstances, a leak could have resulted. I have made some
ch
On Mar 04, 2005, at 14:52, Søren Hansen wrote:
fre, 04 03 2005 kl. 13:23 +0300, skrev Paul Bagyenda:
- the move you suggested, of list_destroy(lto,NULL) in mmsfromemail.c
is potentially dodgy since that variable is reset in the meantime. So
in some circumstances, a leak could have resulted. I have
Hello all,
v0.9.7 is out and about (see website). Key changes:
- Bug fixes as reported
- Support for send/recieve to MMS clients who use IPv4/IPv6 addresses
instead of MSISDNs
- Generalised, plug-in based mechanism for identifying local MMS
recipients (rather than using prefixes, etc)
- Adde
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
Good idea as far as I can see. The key driver of the decision at the
time was to keep dependencies down to a minimum. And provisioning
suggests a database...
On Mar 06, 2005, at 21:23, Søren Hansen wrote:
I've been thinking.. Why is it that the provisioning things are
external
programs (probabl
It is on purpose. The thinking was: why should we check that the sender
is provisioned? If they can send, then we know they are. Note that the
GW calls the prov_notify script anyway so that the provisioning server
can update its view of the senders state.
On Mar 10, 2005, at 19:53, Søren Hanse
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 ex
On Mar 11, 2005, at 10:35, Søren Hansen wrote:
fre, 11 03 2005 kl. 08:05 +0300, skrev Paul Bagyenda:
It is on purpose. The thinking was: why should we check that the
sender
is provisioned? If they can send, then we know they are.
The way I see it, if they can send, they've guessed the URL fo
-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
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&#
Hmmm,
I tried removing it but then when I run configure, it seems to demand
for aclocal/automake and cousins on the machine. My concern was: Does
everybody have these on their systems? If my understanding was
incorrect, please feel free to remove.
P.
On Mar 11, 2005, at 15:00, Søren Hansen wro
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
(
The MMS v1.2 spec adds a specification for an 'mmbox'. This is
persistent storage on the network side. The idea is that, like email,
users might want to keep copies of messages (received, sent, drafts)
somewhere. Since the phone has limited space, the server should provide
this functionality.
7;s still on the way) one book on Mobile messaging
and it covers MMS from 1.1 to 1.3. Of course I don't recomend anybody
to buy it, but however it might be useful to put it in mbuni.org
resources place:
http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470011432.html
On Wed, 23 Mar 2005 13:
For those using CVS, documentation has been brought up to par with
recent changes, and will be kept that way. For instance, a number of
config directives have been added (and one removed). Details can be
found in userguide.shtml in the doc/ directory.
Thanks
Paul.
__
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
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 implemen
Thank you.
I have not had a problem finding the kannel libs. Perhaps you could
send me your config.log so I can try and figure it out?
On Apr 14, 2005, at 17:42, Enver ALTIN wrote:
Hi,
I just tried to compile the hopefully-MM7-enabled mbuni from CVS, and
while trying to patch Kannel CVS head, I
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 accor
uld make a
possibility to authorize VASP's calling some external module (which
would query DB for example). I think it's important because operator
often has lots of duplicates of the same VASP (for each SMPP, MM MM7,
MM MM4, PPG etc. connection).
On 4/14/05, Paul Bagyenda <[EMAIL PR
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
thanks for the info...
On Apr 15, 2005, at 12:18, Steve Kennedy wrote:
On Fri, Apr 15, 2005 at 10:39:53AM +0300, Paul Bagyenda wrote:
[snip]
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
CVS has been updated with support for MMS VAS using Nokia's EAIF
protocol. The configuration for a VASP is unchanged except that you set
the 'type = eaif' and the rest will happen nicely.
Currenly Mbuni ignores some flags such as ReplyCharging and
allowadptation. For the latter on second thoug
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
Hi all,
I'd like some suggestions on reducing the number of config directives
in/for Mbuni. One area: We have about 5 directives for storage
directories (mm1 queue, global queue, etc): I'd like to fold them into
one that specifies a storage directory (Mbuni then creates any
sub-directories it
Hi all,
v0.9.8 is out and about. Please see website. It is based on the
current CVS, and is an important part of the path to a 1.0 release.
If you have been watching the CVS updates on the devel list, then you
have seen everything you can expect in this release. One addition is
binary installe
in HTTP applications. (There was a small problem with generation of
MIME boundaries.)
Cheers
Paul.
Edward C.A. Tromp Wrote:
>
> Hi,
>
> After some troubleshooting and with the help of both Paul Bagyenda
nad
> Paul
> Komkoff.
> together we found out what the problem
Hi,
Your question perhaps needs some clarification. WAP Push is already
implemented in Kannel and in Mbuni (for MMS notification).
On May 06, 2005, at 20:31, Monchanin Eric wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Are you planning to integrate a conversion to Wap format (with wap
pu
Dzuigas,
Will certainly take a look at these documents and share my views.
On your previous email, I hope more experienced users on the list
can enlighten us. What follows are my own views (prejudices?!) on
relating content adaptation to IMEI.
GSM networks always pick up IMEI for one reason
Thanks to Nicolas for tripping on this issue. CVS updated with fix.
The problem was that the reiserfs filesystem does not fully
(correctly) populate the structure returned by the readdir() system
call, hence it is not possible (without a further call to stat()) to
tell which files are direc
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.
Hi,
Mbuni can send delivery/read reports to the VASP via MM7 (SOAP or
EAIF) for previously submitted requests. I suggest that your
application send messages to mbuni via MM7, that being a much cleaner
and standardised interface. There is no clean way otherwise for you
to receive the repor
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
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/
Quote handling in Kannel has caused problems before. Perhaps you can
pass on a patch to kannel (the mbuni patched one!) so that I can
update what we have on the site...
Thanks again for the feedback. I confess I didn't have the patience
to setup the Nokia emulator. Too much Java mixed with
Dziugas,
Finally got around to reading the STI spec! Comments below.
On May 13, 2005, at 13:17, Dziugas Baltrunas wrote:
Hi Paul,
thanks for the comments.
GSM networks always pick up IMEI for one reason or another, and
relating that to IMSI/MSISDN should not be a problem. Going from IMEI
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 th
Hello All,
CVS has seen a number of updates recently, please do take a look
and let me have your feedback. It seems every releases provides lots
of opportunity to beat out more bugs and add more improvements. (A
good thing of course!)
Brief change log:
- Mbuni can now be configured
Thanks for the patch (applied to CVS).
On ideas, this is very much encouraged (we can't all be coders, but
we can all have ideas). This list is the right place for such ideas
to be put forward and discussed.
I should update CVS shortly with your second suggestion.
Cheers
Paul
On Jul
The content adaptation flag has been added (and doc updated), please
test and let me know. Thanks
On Jul 13, 2005, at 20:24, Matthias Hofmann wrote:
Hi,
After I installed mbuni and played with it I found that there is a
issue with some older phones like a Nokia 7650 (firmware 3.16) who
do
since libssl depends on libcrypto, it appears kannel is outputting
the -l directives in the wrong order. Kannel's make file needs to be
fixed methinks. (Unlike mbuni they don't appear to use automake to
keep these up-to-date.)
On Aug 11, 2005, at 12:57, Paul Keogh wrote:
Hi,
I've just bui
Yes, Mbuni is relying on Kannel doing the splitting (too much trouble
at this stage to split it ourselves).
What Mbuni doesn't do (and should do really) is pay close attention
to size limits as spelt out in the MMS spec. For instance, From,
Subject and To fields should not exceed certain l
can you check (if you haven't yet), that your kannel is configured to
permit message concatenation. This may be the problem. Large
notifications work fine for me.
P.
On Aug 31, 2005, at 21:09, Loïc Minier wrote:
On mer, aoû 31, 2005, Loïc Minier wrote:
Borken download (mbuni.mms.example
A couple of cents worth: Intuitively your suggestion makes sense.
There is a potential problem that the MMSC would have to remember
every single message it has handled and where it came from, so that
it can route the corresponding DLRs. That could put a lot of pressure
on the MMSC in terms
Am afraid I can't reproduce this one! It works fine for me (Mac and
Linux). GDB would be nice, if you can single-step.
On the issue of MM7 versions, from my (limited) reading it looks like
v6 adds just a few extra headers (DRM, AppID, etc), and of course
changes the MM7 NS URL. If you are n
thats good. For record purposes, this response links to: http://
www.mail-archive.com/users@mbuni.org/msg00371.html
On Sep 28, 2005, at 13:16, Ian Cass wrote:
Paul Bagyenda wrote:
A bug most certainly. I'll update CVS shortly with what I think is a
fix. Try it and let us know (devel
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
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,
[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, thes
t; 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
Hello Ian,
apologies for the delay in responding.
I haven't looked at the v6.8.0 spec so I don't know what it calls
for. I hope I can find sometime to do that, so that it can be added
onto the wishlist. Sounds like a good idea...
P.
On Oct 18, 2005, at 19:01, Ian Cass wrote:
Hi Paul,
; 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 200
You must patch kannel with the patch file in CVS...
On Nov 01, 2005, at 21:31, Alex Judd wrote:
Hi list
The example configuration file (doc/examples/mmsc.conf) contains
mm7-port as one of the configuration parameters for the CVS
version, but our CVS built engine here refuses to accept it as
Hi,
I would like to get a sense for the amount of beating CVS is taking
from users out there, and how it is performing. It looks like it may
be time for another release... I have been putting this off until a
few more features are in there, but already CVS is too far ahead of
1.0.0, and
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.
P.
On Nov 30, 2005, at 00:20, Stipe Tolj wrote:
Paul Bagyenda wrote:
Hi,
I would like to get a sense for the amount of
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 n
Committed. And another patch for that "mandatory headers" check would
be nice :)
On Jan 07, 2006, at 06:03, Stipe Tolj wrote:
Loïc Minier wrote:
Hey,
I crashed mbuni 1.0.0 today as follow:
2006-01-06 15:42:45 [21530] [371] WARNING: Unexpected field value
type 3 for header X-Mms-
There are a couple of unchecked errors and (perhaps) memory leaks in
there. If you can, please run under valgrind or Purify (since you
seem to have long running jobs) and lets see what comes out.
All good patches welcome!
On Jan 07, 2006, at 21:54, Stipe Tolj wrote:
Loïc Minier wrote:
Looks like a crash after a failed character set conversion. This
would happen in the content adaptation module. Will investigate.
Just saw your posts to mantis and will apply!
On Jan 10, 2006, at 16:41, Loïc Minier wrote:
Hi,
I've seen a new mmsproxy crash, very different to the on
It still should not crash all the same... Hmmm. Could you perhaps
send me (privately) a sample MM that kills it thus?
P.
On Jan 11, 2006, at 17:06, Loïc Minier wrote:
On Wed, Jan 11, 2006, Paul Bagyenda wrote:
Looks like a crash after a failed character set conversion. This
would happen in
Hi Sergio,
Welcome.
To try and answer your questions: There is no architecture guide
at the moment, I suppose largely because no one expressed a need. the
user documentation does however provider a brief overview of the
system's internal structure, and links to documents with more info
y
> capabilities (hope I'm not bringing up a sensitive issue). From the
> Kannel perspective it would involve adding a third Box, the MMSbox,
> working in parallel to the already existing SMSbox and WAPbox.
>
> Best regards,
>
> Sergio
>
> Paul Bagyenda wrote:
>
>
Thanks Dzuigas,
Fixed the typo in the doc. Colours: Some suggestions would help.
Colours not my forte! On the octstr_destroy issue, please send
through a patch that I can review and use/post.
Cheers.
Paul.
On Feb 09, 2006, at 16:21, Dziugas Baltrunas wrote:
> Hi,
>
> I've just checked
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, Dzi
Hi,
This is all normal behaviour: The queue files may or may not be in
sub-directories, and a deffered means the message may be fetched
later, so it should not be deleted.
P.
On Feb 11, 2006, at 11:09, Dziugas Baltrunas wrote:
> Hi list,
>
> I noticed that queue directory tree structure i
Hi, One of the things I'd like to see change is the need to patch + rebuild kannel in order to install mbuni. It looks very much that this will be possible with the next release of Kannel, provided some proposed diffs from our side (posted to the [EMAIL PROTECTED] list) are incorporated. To achie
he 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
applied. Thanks
On Feb 21, 2006, at 12:21, Dziugas Baltrunas wrote:
> Hi list,
>
> I see that after moving config handling to mbuni, cvs head fails to
> compile. A patch below should fix this:
>
> Index: mmlib/mms_cfg.c
> ===
> RCS f
Fixed I hope and updated to CVS.
On Feb 21, 2006, at 16:35, Dziugas Baltrunas wrote:
> Hi, list,
>
> what was the purpose for the code in mmsc/
> mms_billing_shell.c::mms_billmsg():
>
> for (i=0;i Octstr *s;
> s = octstr_format("%s '%s' '%s'", octstr_get_cstr(script),
>
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
>
Hi,
You are missing the 'Content' element which tells the SOAP
recipient what part of the HTTP body is the message body.
Nonetheless the mms_msg module should have done better checking for
NULLs. I've done some work in this regard and updated CVS.
Thanks again
P.
On Feb 23, 2006, at 20:
Done and updated. Please test.
You could also test, while you are at it, the effect of allowing
the uaprof engine to fetch directly any missing profiles, rather than
doing so in the background and failing on first try. If it causes no
significant delays from the user perspective, then we s
l to billing-library to check if there is sufficient balance to
>> send an MM for all the recipients.
>> 2. For each of the MM recipients there is a call to resolver-library
>> to check whether is local or foreign recipient or MM shall be sent to
>> VASP.
>> 3. prov-s
> are visible as well.
>
> On 2/24/06, Paul Bagyenda <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> You are missing the 'Content' element which tells the SOAP
>> recipient what part of the HTTP body is the message body.
>> Nonetheless the mms_msg modul
Hi, anonymous cvs for mbuni has been woefully out-of-date over the last week or so for some unknown reason. Sourceforge seem to have resolved this now. There have been some changes in the meantime, so do check out the change logs, update your copy and test. ThanksPaul. ---
Actually Mbuni has a so-called resolver module plug-in, which allows
you to plug in a script or module that determines if a number is
local or not. I expect somebody out there does have a script that
actually uses this functionality to implement what you are talking
about.
There have bee
Patches applied - thanks. Also added a note of caution to the CVS
documentation.
On the vaspid 'disappearance', not sure what you mean but it seems to
me that in MMC mode it should indeed disappear. Notice for instance
that vaspid not part of the
deliver_req message, and not part of any oth
Hi,
short answer: No it isn't. We have avoided building against CVS
really. For the time being we will stick to release Kannel versions
On Apr 14, 2006, at 02:03, Vincent CHAVANIS wrote:
> Hi there,
>
> I'm pretty new subscriber to this ML, and i would like to know if
> mbuni CVS is "compat
Sourceforge have changed the CVS host names, which means you will now
need to access mbuni CVS from mbuni.cvs.sourceforge.net (instead of
cvs.sourceforge.net). Please note the changes. I have updated the web
site accordingly. Also note that CVS browsing is now at http://
mbuni.cvs.sourcefor
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. So
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:
>>
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
Deon,
Short answer is that it isn't. The spec says that if there are
multiple recipients, then the message will contain the To/Cc/Bcc
field as many times are there are recipients. This means that the
user should not, as in the case of email, put a space or whatever.
So the question is:
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 des
It would appear that your Kannel was not patched as should have
been done, prior to compilation. This requirement will disappear once
Kannel 1.4.1 is out.
P.
On Jun 28, 2006, at 03:24, Rene Kluwen wrote:
> So I downloaded mBuni from CVS.
>
> First I had to add CFLAGS=-L/path/to/gwlib to ./
Hi Rene,
The right place for this is mmsbox (VAS GW part of Mbuni). If you
look in there, there are two functions for talking to an MMSC. One
for MM7/SOAP the other for MM7/EAIF. mmsbox decides which to call
based on the 'type' of the MMSC (as specified in the config). Note
however that
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 i
1 - 100 of 146 matches
Mail list logo
