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
