Re: [Devel] Usage of "mms-message-too-large-txt"
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. ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
Re: [Devel] Usage of "mms-message-too-large-txt"
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 don't see a problem adding the message ID. In future we will clean up these interfaces further. On Jul 21, 2006, at 23:06, Deon van der Merwe wrote: > Hi, > > (not sure if this should be on the users list???) > > Our MMSC is configured with: notify-unprovisioned = false. We do this > because we have a "mms-to-local-copy-handler" VASP configured that > receives a copy of all MMS. This handler will also do the "is > destination handset MMS enabled" check. If it is not enabled/capable > the local-copy-handler VASP will generate a reference and send a SMS > message to that subscriber. The subscriber then uses a web interface > (with the above reference) to view the MMS. > > This works great... but the flexibility is not preset for MMS that is > to big for the destiantion subscriber. There is the > "mms-message-too-large-txt" configuration. The issue here is, that > this only gives the subscriber a static link to go too. No dynamic > reference for the specific MMS message. > > So, what I am thinking of is this: the "prov-server-notify-script" > already passes the message_too_big status as well as the subscriber > information. If we can add the msgid as another parameter to this > script, then we can trigger a SMS to that subscriber with the > reference (that is generated by the local-copy-vasp). > > sjoe... at last I get to my point! > > How is other people using/solving the message_to_big problem? > Does the above sound like a fair/clean(ish) solution? > > ___ > 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] Usage of "mms-message-too-large-txt"
Hi, (not sure if this should be on the users list???) Our MMSC is configured with: notify-unprovisioned = false. We do this because we have a "mms-to-local-copy-handler" VASP configured that receives a copy of all MMS. This handler will also do the "is destination handset MMS enabled" check. If it is not enabled/capable the local-copy-handler VASP will generate a reference and send a SMS message to that subscriber. The subscriber then uses a web interface (with the above reference) to view the MMS. This works great... but the flexibility is not preset for MMS that is to big for the destiantion subscriber. There is the "mms-message-too-large-txt" configuration. The issue here is, that this only gives the subscriber a static link to go too. No dynamic reference for the specific MMS message. So, what I am thinking of is this: the "prov-server-notify-script" already passes the message_too_big status as well as the subscriber information. If we can add the msgid as another parameter to this script, then we can trigger a SMS to that subscriber with the reference (that is generated by the local-copy-vasp). sjoe... at last I get to my point! How is other people using/solving the message_to_big problem? Does the above sound like a fair/clean(ish) solution? ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org