Hi, I agree with Paul that MM7 should be separated as much as possible. I see the following reasons for that:
- MM7 must run on separate port and probably host due to security reasons (VASP must have access to that interface). It would be great if we could follow the conception similar to Kannel's boxes. Expected result: MM7 listener (mosly mmsproxy clone with SOAP implementation and authorization) runs on a separate host accessible to the VASPs and has defined MMS global sender host in its configuration file. Such a separation of processes raises lots of questions, mainly authorization and the whole MMSC configuration issues. Since MM7 defines the replace.REQ/RESP, this process should also have an access to the queue. - There should be a possibility to put MM7/SOAP interface under SSL/TLS (could it apply to MM1 as well?) due to weakly defined authorization mechanisms for VASPS. - 3GPP TS 23140-680 says: MMS VAS Applications may be able to generate CDRs when receiving MMs from MMS Relay/Server and when submitting MMs to MMS Relay/Server. It also states, that billing might be done according to the passed ServiceCode and/or other parameters, indicating which party should be charged. It seems like billing will be the disaster number one (thinking about Reply-Charging here) :) > >> recipient is not local etc. Finally we would need config directives > >> for > >> VAS providers: name, user/pass (required for auth), short code (or > >> similar), flags, URL (which we use for sending incoming to them). It was already stated some weeks ago in the list that it's important to keep these credentials common between different protocols as the same VASP might use MM4 with the same credentials. What is more, MM7/SOAP operates VASID (Value Added Application ID) - shall this also be taken into account (i.e. one VASP has several VASIDs which MMSC differenciate according to the short codes)? I will look how this is implemented in commercial gateways. > It can be part of mmsproxy but it should be a separate function space. > So you would probably have a whole new lib file for EAIF and SOAP > decoding encoding, and a different URL handler. Then it means that *it* should also be the part of mmsmobilesender as we need to send the notifications for VASP as well. So the mixing problem arises again. It's also the question which procees should do the MM7_deliver.REQ? -- Dziugas _______________________________________________ Users mailing list Users@mbuni.org http://mbuni.org/mailman/listinfo/users_mbuni.org
