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 other messages (MM1, MM4), so we really can only perhaps use it for CDR and then throw it away. P. On Apr 07, 2006, at 20:06, Dziugas Baltrunas wrote: > Hi list, > > attached patch does the following: > > 1. In case VASP of type SOAP specifies a <SenderAddress>, it is uses > it instead of short code defined in config (which might be absent). > TODO: shall we introduce allow-sender-address-override parameter? > > 2. Now if resolver module returns empty string (e.g. we don't know how > to deliver message for some recipient), it gets converted to NULL, so > mmsglobalsender sees that. > > 3. Transaction IDs changed the format to [EMAIL PROTECTED] (was > [EMAIL PROTECTED](host-alias). Having the prefixed transaction id lets one > to distinguish between different MMSCs at the proxy, i.e. MMS PDU > starting with "\x8c\x83\x98mbuni@" would mean that this is > M-NotifyResp.ind and should go to mbuni. Message IDs and URL in > notifications remain the same. > > I also noticed that some thread of mmsrelay (obviously > mmsglobalsender) removes Vvasp-id line from queue file if one is > present, i.e. message was sent by VASP. After hour of debugging I > couldn't find the source for it :( However, it's easy to reproduce: > launch only mmsproxy, send MM from VASP, look at queue file, launch > mmsrelay and see the difference. > > -- > Dziugas > <misc.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
