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:
> (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 mailing list