| MMSC charging with DIAMETER Credit Control Application - MM10 or MM9 |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ |
◄ ► |
| Author | Message | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4279 Registered: 08-2008 |
Last year there was some discussion of adding DIAMETER Credit Control charging support to the NowSMS MMSC. (Reference: http://support.nowsms.com/discus/messages/485/70758.html) In that discussion, we were incorrect in assuming that MM10 was to be the preferred standard for MMS billing and charging using DIAMETER. The intent for MM10 is more oriented toward message routing control. By contrast, MM9 is also DIAMETER based, but MM9 uses the DIAMETER Credit Control Application to record charges. We are planning to implement direct MM9 charging support into the NowSMS MMSC. However, before we do this, we need to receive some customer feedback and perform some real world testing. We have a test command line program that prompts for DIAMETER connection information and source/recipient phone numbers to charge for sending a single MMS message. Pending successful tests, we plan to add built-in functionality to generate these MM9 DIAMETER charges directly from the MMSC. If you are interested in trying this test program, please reply to this post. -- Des NowSMS Support | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 19 Registered: 01-2007 |
Hi Des, i have still the executable and the network flow are still open, so i can easily trying but maybe it has new version because i have the test program MM10. By the way , we did implementation of scap v2 request from our SMSC to the Charging system from Ericsson supplier. I can forward you some pcap trace if you need it. wait for your feedback , BR Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4285 Registered: 08-2008 |
Hi Marc, I'll go ahead and upload the test executable. The current version is at http://www.nowsms.com/download/mm9test.zip It is very similar to the earlier MM10 test executable, but MM9 uses DIAMETER Credit Control Application (which is also the foundation upon which SCAPv2 is based). MM9 is defined in 3GPP TS 32.270 and more directly how it is implemented in DIAMETER is described by 3GPP TS 32.299. 3GPP TS 32.299 covers DIAMETER credit control message usage in 3GPP and LTE environments. Basically, 3GPP TS 32.299 defines additional AVPs for different types of charging events, with the base protocol based upon RFC4006 (DIAMETER Credit Control Application). When an MMS message is sent, a credit control message is generated for DIRECT_DEBITING and an MMS Information AVP contains details about the MMS message to be charged for. I believe this is very similar to SCAPv2, except that SCAPv2 expects a monetary charge instead of the MMS Information AVP. That said, we are not opposed to making our MM9 logic flexible enough to directly make monetary charges via DIAMETER CCA. In the case of SCAP v2 I'm not certain which DIAMETER AVPs are used for their charging model ... so a pcap trace would be helpful. Go ahead and send to nowsms@nowsms.com with Attention: Des in the subject line. Thanks! -- Des NowSMS Support | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4293 Registered: 08-2008 |
Hi Marc, I think we made some progress. An updated test program is at http://www.nowsms.com/download/mm9test.zip. And a more detailed description of the Diameter implementation is at http://www.nowsms.com/mmsc-diameter-mm9-implementation (I wanted to post the info here directly, but there are tables that are too difficult to format here.) The plan is to support both MMS Charging based on MM9 over Diameter (3GPP TS 32.299) and generic charging based upon Diameter Credit-Control-Application. By default, MM9 is used and the Diameter Credit-Control-Request contains information about the MMS message to be sent. Alternatively, you can specify either a service specific unit charge or a fixed monetary charge per message. We have yet to fully integrate this functionality into the MMSC pending additional feedback. -- Des NowSMS Support | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4294 Registered: 08-2008 |
More clarification ... Our current planned approach is that there are three possible ways to implement MMS charging over Diameter. 1.) MMS Charging based upon MM9 over Diameter as defined in 3GPP TS 32.299 (3GPP Diameter Charging Applications). 2.) Service specific unit charge per message using Diameter Credit-Control-Application (use Service-Identifier + CC-Service-Specific-Units). 3.) Fixed monetary charge per message using Diameter Credit-Control-Application (use Service-Identifier + CC-Money & Currency-Code) The test program currently supports all three approaches. | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8050 Registered: 10-2002 |
Some additional follow-up. We have been frequently updating this test program to address issues raised by feedback. So if anyone tried an earlier version without success, they may want to try again. I wanted to also provide some general feedback on questions that we have received via e-mail. 1.) The MMSC will support Device-WatchdogRequest and maintain a persistent session with the Diameter server. The MMSC will not generate Device-WatchdogRequest, but it will respond to these requests with an appropriate Device-WatchdogAnswer. 2.) Existing accounting callbacks will continue to be supported. Diameter charging will occur after the PreAuth callback, allowing that callback to take actions such as blocking a message, before a Diameter charge is recorded. 3.) For messages sent to multiple recipients, the MMSC will multiply the Requested-Service-Units and/or CC-Money values by the number of recipients when recording the charge. -- Another area of frequently asked questions pertains to roaming. Unfortunately there are no easy answers for this. From an MMSC perspective, if available in the network configuration, we will have the MCC-MNC value associated with the SGSN (see http://www.nowsms.com/operator-mmsc-accounting-detecting-roaming-subscribers). This is currently forwarded as a string value under the 3GPP-SGSN-MCC-MNC AVP. However, we are not aware of any billing system that will directly support this parameter. Ericsson's SCAPv2 defines a proprietary header named Subscription-Id-Location, which is intended to perform charging based upon the subscriber's location. We are not opposed to using this proprietary header when it has been detected that we are talking to an Ericsson server. The problem is that Ericsson wants an MSISDN format number ... CC+NDC+LSP...although the specification does state that only CC is required. We are thinking that perhaps we could use a table that converts from MCC to CC, but are unsure that a table for MCC+MNC to CC+NDC is available (and question the relevance of NDC). We need clarification (and experimentation) to determine what could be done here, and welcome feedback and suggestions. -bn | |||||||
| Davor Spasoski |
Hi all, I'm attaching the mm9.log (mm9.exe from 6th of March) and a couple of .cap files for analysis. A few words about my testing methodology. We already have an SMSC using SCAPv2 to charge on Ericsson CS5. The rating is on the server side. The E/// CCN node is configured for SMS charging only at the moment, so I had to use some values other than the recommended by Now to expect some success, i.e.: Service-identifier(439) val=100 CC-Service-Specific-Units(417) val=1 Nevertheless, the result was not good (error 3002) because some mandatory AVPs, specific for our case were missing: Group AVP 1075: Other-Party-ID AVP 1082: Traffic-case (20 for MO and 21 for MT case) AVP 1081: Service-Provider_ID (should be 101) AVP 1074 (Subscription-Id-Location) is not specific for us, but mm9.exe didn't send it. It's mandatory according to E////. The attached Diameter_Sibox.pcap is an example of successfully charged SMS. diametermm9.cap resulted in Diameter error 3002. SCAPv2_Event_DirectDebit.xls is what E/// expects as mandatory and optional. I hope this helps. I'm expecting Ericsson's recommendation for multiple recipients and 3GPP SGSN location AVPs. DS
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8051 Registered: 10-2002 |
Hi Davor, I think the 3002 error is related to the Destination-Host value. According to RFC 4006, that is an optional parameter, and it appears that there is no good reason for us to be implementing it. We have uploaded another update to the test program to remove this parameter (documentation has not been updated). http://www.nowsms.com/download/mm9test.zip This update also has an option to include the Ericsson SCAPv2 parameters. When enabled, Traffic-Case and Other-Party-ID are generated automatically. Values for Service-Provider-Id and Subscription-Id-Location are prompted for. We have the following concerns about using the Ericsson proprietary SCAPv2 parameters: 1.) How to handle multiple recipients with Other-Party-ID? Should the AVP be included multiple times? Or does a separate charge need to be registered for each recipient? The latter does cause a problem if credit runs out between recipient processing. 2.) How to specify an e-mail address as Other-Party-Id-Type or Other-Party-Id-Nature? The only supported values expect phone numbers. 3.) How to generate Subscription-Id-Location automatically as discussed previously. -bn | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 2 Registered: 04-2007 |
Hi Bryce, I did a couple of tests this morning and I got error 3009 (DIAMETER_INVALID_AVP_BITS. By comparing the .cap files I noticed a difference in AVP 1081. The length in the specs from CAPV2_Event_DirectDebit.xls is 13 for this AVP, but in the successful charging example .cap, the length is 15. Probably this is an error in the documentation and the source of error 3009.
Davor | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8053 Registered: 10-2002 |
Hi Davor, That is the SCAP Service-Provider-ID value, which is a string value. In your test case it is 2, while the SMSC is using a value of 101 (which is 2 bytes longer). That said, we think we understand the problem. It's a bit difficult to explain... We are in the process of converting the Diameter implementation to be driven by an XML based template which will make it easier to apply custom edits and attributes. We are also updating the test program to give it the ability to unset a previously set parameter. For example, it is possible that one of the SGSN related parameters is not understood and is causing the problem. The current test program remembers the previously entered parameter and won't let you remove it (other than editing the INI file). Once those updates are in place we should have sufficient flexibility to get this working without requiring code changes. -bn | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8054 Registered: 10-2002 |
Hi Davor, Apparently the 3009 error code is because we have a misunderstanding about the "mandatory" bit in the AVP flag. Our original interpretation was that this should be set only if we require that the other side of the connection understand and support the AVP. As you can understand, we want to be flexible and for the most part do not care ... merely considering most of the AVPs to be informational ... the other side is free to use or ignore however seen fit. However, there is a clause that says that for particular AVPs they must be flagged as mandatory if they are used. This is frustrating because it makes interoperability difficult. For example, the 3GPP-MS-TimeZone parameter is required by Ericsson. Yet it is not understood by some other Diameter servers. We would therefore like to flag it as optional ... use it if you like, ignore if you don't need it. As you can imagine, with different charging servers from different vendors, there will be different parameters expected. However, the parameter definition for most Diameter parameters (including most vendor specific ones) is that this mandatory flag must be set on the parameter. If it is not set, but the spec requires it, Ericsson CCN returns this error 3009 (DIAMETER_INVALID_AVP_BITS). The bottom line is that any Diameter implementations need to be extremely flexible about which parameters to include. We've decided to use XML template files to define which Diameter parameters are to be included with each request. We hope to accommodate common charging servers (like SCAPv2) without base template edits using a concept of required parameters, optional parameters, and extension sets. Optional parameters are included only if a value is specified for the parameter. Extension sets are groups of parameters that are enabled only if that extension set is enabled. These extension sets are intended to allow us to customise Diameter packet formats for different charging servers while still working from a common template. We're not going to document the XML format at this time. However, if you want to try adjusting some parameters, it should be somewhat self-explanatory. One other note. The MM9 Test Program saves previous responses, so these previous responses will be used as a default setting for the next test. (Previous versions did not save a few of the responses, this version saves all.) To delete a prior response for an optionally included parameter, so that it will not be sent, press the Space key, then Enter. -bn | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8055 Registered: 10-2002 |
P.S. - The update with these changes is at the same location as previous versions. http://www.nowsms.com/download/mm9test.zip | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 3 Registered: 04-2007 |
Hi Bryce, The latest version has finally produced the "2001" response (attached ,cap and MM9 log file), that is only if the 3GPP AVP 873 (Service information) is omitted. Without it, I could only get Diameter AVP unsupported (5001). That gives answer that if we want to use this AVP, Ericsson would have to work to support it. I'm anyway still expecting their say on charging MMS. My observations: 1. AVP 873 results in Error 5001 (cap file attached) 2. AVP 417, part of group AVP 437 (Service-subscription-units) works as charm when multiple units are specified 3. I used SCAP specific AVP 1074, (Subscription-ID-Location) to place the SGSN MCCMNC, instead of originating MSC. The CCR was accepted and the CCN applied roaming tariff, which leads to a conclusion that with a proper tariff, this field can work well for determining roaming status and location. 4. AVP 18 made no difference to E/// CCN. Open issues: 1. AVP 1075 - Other party id. What should it contain in case of e-mail and multiple recipients? With e-mail I got error 5012 2. MMS size was not touched. It makes sense when the MMS is sent from abroad. Then again, the MMSC could aonly charge the event and the GGSN the volume. -Davor
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8056 Registered: 10-2002 |
Hi Davor, Yes, I think this AVP 873 (Service-Information from 3GPP TS 32.299) is not widely supported. It does seem to have good potential, so maybe our including it as an option will encourage a charging vendor to support it. Disabling this extension set by default will be a good idea. I am encouraged that using the SGSN MCCMNC as Subscription-ID-Location may be a solution. We can include an option to facilitate this without requiring an edit of the XML template. In fact, right now in the test program, if you specify @@SGSNMCCMNC@@ as the Subscription-ID-Location value, it will apply the value entered for that parameter as the location. Our intent is that the MM9 test program builds an INI file that can be used to activate Diameter in the MMSC. (There are still a few format changes to be made before we reach that point.) Regarding the open issues ... 1.) I'm concerned about the limitations of the Other-Party-Id AVP. a.) First, let's discuss the issue of it containing an e-mail address. As a test, try removing Other-Party-Id-Type and change the value of Other-Party-Id-Nature to 0 (Unknown). According to the specification, the only valid value for Other-Party-Id-Type is 0 (END_USER_E164). There are other values defined (but not valid for SCAP), but none of them would seem to apply for an e-mail address. If we can't specify an e-mail address in this parameter, maybe the parameter needs to be skipped for e-mail recipients? b.) Let's look more closely at multiple recipient handling. Try editing the XML and repeat the Other-Party-Id group. If multiple recipients can't be supported, perhaps we need a configuration option to send multiple charge requests. I don't like that alternative because if we are only allowed to charge 1 out of 10 recipients, of course we can send the message only to that 1 recipient, but we can't really notify the sender of failure. (Of course if they're out of credit, I guess they'd find out soon enough.) 2.) Hmm...thinking in terms of generic Diameter Credit Control, you could charge based upon CC-Total-Octets instead of CC-Service-Specific-Units. Try changing the Requested-Service-Unit group in the XML with this: <avp name="Requested-Service-Unit" code="437" mandatory="true" type="Grouped" value="@@Config-CC-Service-Specific-Units@@@@Config-CC-Money@@@@MsgSize@@" omitifblank="true" > <avp name="CC-Total-Octets" code="421" mandatory="true" type="Unsigned64" value="@@MsgSize@@" /> <avp name="CC-Service-Specific-Units" code="417" mandatory="true" type="Unsigned64" value="@@Config-CC-Service-Specific-Units@@" multiplerecipmultiply="true" omitifblank="true" /> <avp name="CC-Money" code="413" mandatory="true" type="grouped" value="@@Config-CC-Money@@" omitifblank="true" > <avp name="Unit-Value" code="445" mandatory="true" type="grouped" value="@@Config-CC-Money@@" omitifblank="true" > <avp name="Value-Digits" code="447" mandatory="true" type="Unsigned64" value="@@Config-CC-Money-Value-Digits@@" multiplerecipmultiply="true" /> <avp name="Exponent" code="429" mandatory="true" type="Integer32" value="@@Config-CC-Money-Exponent@@" /> </avp> <avp name="Currency-Code" code="425" mandatory="true" type="Unsigned32" value="@@Config-Currency-Code@@" omitifblank="true" /> </avp> </avp> My reading of SCAP documentation suggests that you can only specify one of the service units ... so if trying size, do not include service specific units or money values. (Note that I added @@MsgSize@@ to the value of the grouped element in addition to adding the CC-Total-Octets AVP. The value associated with a grouped AVP element doesn't actually get encoded ... it is only present for evaluating the omitifblank attribute.) -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8057 Registered: 10-2002 |
Hi Davor, Some additional follow-up regarding open issue 1b. We have done some testing with the Ericsson Charging SDK and it clearly does not like multiple instances of the Other-Party-Id AVP. It returns Diameter error 5009, DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. We expect the actual CCN will have the same complaint. We have decided that our default behaviour for messages sent to multiple recipients will be to submit separate charging requests per recipient. Recipients where the charging request will be skipped. (The sender will only see an error if all recipients fail.) There will be a configuration option to enable multiple recipients in a single charging request when supported. There has been a minor update to the MM9 test program, but it should be insignificant as there are only internal changes related to integrating the logic into the MMSC, and building an INI file with settings that are compatible with the Diameter options to be implemented in the MMSC. -bn | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 4 Registered: 04-2007 |
Hi Bryce, - Omitting the other-party-type resulted in error 5004 - I'm confirming that the actual CCN returned error 5009 with multiple instances o Other-Party-ID - I was not lucky getting the mm9.exe prompt me for CC-Total-Octets. I edited the .xml as instructed... I guess that the multiple CCRs for multiple destinations is a good default. The proposal is to have NACK only if all recipients fail. I'm still hoping for a configuration for multi recipients, where the recipient field is either empty or has predefined value and number of units is > 1. After all, many operators don't care about the destination of the MMS/SMS. -Davor
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8058 Registered: 10-2002 |
Hi Davor, In the MMSC implementation there will be an additional configuration parameter for whether to submit one multiple recipient charge or one charge per recipient. For now, we are defaulting to one charge per recipient. (NACK only if all recipients fail.) As a temporary work-around for the SCAP Other-Party-Id parameter not allowing an e-mail address, we are adding a parameter to convert any e-mail address to a fixed number for the Diameter charging request. (Obviously not ideal, but seemingly the only practical solution for SCAP initially.) We are working on updating the documentation and completing internal testing so that we can make an interim release available for further Diameter testing in early April (about 2 weeks from now). One other note ... just to make sure that we are clear with regard to CC-Total-Octets. MM9Test will not prompt for this value. It is hardcoded to use a size of 32768. If you made the XML edit that I suggested, leave the service specific units and money parameters blank. In this event, only CC-Total-Octets would be sent. My understanding of the requested service unit element is that you can only specify one of total octets, service specific units, or money. In any event, if your Diameter server proposes another parameter in which the size can be included, the XML can easily be edited to add additional parameters. (If a vendor is looking to add support for MMS message size, I would first encourage them to support the 3GPP Service-Information/MMS-Information grouped parameter, as size is one of the included attributes.) -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 5 Registered: 04-2007 |
Hi Bryce, -Thanks for the instructions on CC-Total-Octets. I ran the test again on actual CCN and got back Error 5012 (DIAMETER_UNABLE_TO_COMPLY), which is kind of expected knowing that the CCN was configured for SMS charging. -e-mail to number translation is a good idea Davor
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8059 Registered: 10-2002 |
Hi Davor, Yes, I think CC-Total-Octets is more frequently used for data charging. Periodically a GGSN would report data usage in this manner. A similar approach could be used for MMS, but the charging server would need to be prepared to accept it. What would make the most sense would be to use a combination of service units, together with the size from the 3GPP MMS-Information structure. But if it is easier to use CC-Total-Octets, the XML templates provide this flexibility. We have updated the documentation to provide more explanation of how MM9TEST translates into Diameter configuration parameters for the MMSC at http://www.nowsms.com/mmsc-diameter-mm9-implementation We expect that as we gain more experience integrating into different environments, more configuration options will be needed. For now, the settings beyond those generated by MM9TEST are: Subscription-Id-Location – A string value required by the SCAP extension set. It is possible to use the 3GPP-SGSN-MCC-MNC value as the Subscription-Id-Location value by specifying a value of @@SGSNMCCMNC@@. EmailAddressNumber – Some charging environments may not be able to accept an e-mail address as a recipient. For those environments, specify a phone number to be substituted in Diameter charging requests for MMS messages to e-mail recipients. MultipleRecipCharge – By default, the MMSC issues a separate charging request for each recipient when an MMS message is sent to multiple recipients. When this parameter is set to Yes, the MMSC issues a single charging request for multiple recipients, multiplying CC-Service-Specific-Units or CC-Money by the number of recipients automatically. A preliminary MMSC release with the built-in functionality is now at http://www.nowsms.com/download/nowsms20130401.zip Obviously it would be best to try the Diameter integration on a test server first at this stage before implementing in a production environment. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 6 Registered: 04-2007 |
Hi Bryce, Thinking again about MMS to multiple destinations, it appears that unless there is an AVP to hold all destinations, there's a possibility for fraud. Service specific units is not enough if one of the destinations has a different price (a VAS short code). The think I didn't like about the multiple CCRs alternative is the fact that if there's not enough credit for all recipients NACK is sent. The message remains in outbox and on next recharge some of the recipients will receive the MMS twice or more. I propose a more graceful approach: In cases like this, the MMSC should ACK on MM1, but send back informative SMS for partial success and advice to resend to recipients (a, b, c, d...) upon recharge. An http callback could also be used. There are two other important things that came to my mind: 1. What is the trigger point for CCR? In our case (and I believe many other operators) the CCN is charging prepaid only subscribers so there must be a way to distinguish pre from post. In our case it is simple, we use IMSI ranges for that. Others might want to resource to something else. 2. Can more than one Diameter server be supported? I'll explain the reason for that in private e-mail, due to sensitive information. -Davor | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8060 Registered: 10-2002 |
Hi Davor, Yes, the prospect of different destinations with different charges is one of the reasons we defaulted to separate charge requests per recipient. (A single charging request is only practical if the charging server can process the 3GPP MMS-Information structure with full detailed recipient information, or if downgrading international MMS to SMS with web link.) I appreciate your point about the outbox. But it's not something we can address at this time. The good news is that while we haven't tested extensively with every possible device, the fact that a definitive error response is returned means that the message should not be stuck in an outbox that is automatically retried. Regarding your other questions, as postpaid users still need to be charged, I'd assumed that either the charging server would handle both, or a Diameter proxy would route the charge to the appropriate server. That said, we will investigate triggering Diameter based upon defined IMSI ranges, as it makes sense that accounts would be grouped by IMSI ranges. Whether or not different Diameter servers could be supported based upon different IMSI ranges will take some more investigation. It's a good idea, it is just going to take some analysis to determine how much effort will be required to implement, as this was not considered in the design. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 7 Registered: 04-2007 |
Hi Bryce, Thank you for the clarifications. Regarding postpaid customers, they are usually charged from CDRs. For that purpose we rely on the http callbacks, generate CDRs and log the events in DB. This has never failed to us, it's working very well for about 3 years. Davor | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8061 Registered: 10-2002 |
Hi Davor, I'm sorry ... my previous reply was not very well thought out. I have now had more time to think and discuss with colleagues. We have been looking at Diameter primarily from the perspective of a new installation. We love the flexibility of accounting callbacks, but we also have prospective customers who just can't grasp the concept and want to see a standard interface used. We have implemented Diameter to fill that purpose. However, you are correct, Diameter is far more widely used for prepaid as opposed to postpaid charging. While it makes sense to use Diameter for both, postpaid charging systems are frequently older and functioning well without real-time charging. We do need to rethink how accounting callbacks and Diameter can be better coordinated for combined usage. We've had some preliminary design discussions on this and would appreciate some feedback. Here are our thoughts for changes to better support accounting callback and Diameter coordination: MMS Accounting Pre-Auth needs an option to generate one callback per recipient. The Diameter configuration needs an option where it is only to be triggered by accounting callback. What I mean by this is that an option needs to be available where the MMS Accounting Pre-Auth decides whether or not a Diameter charge occurs. This would allow the Accounting callback to do its own postpaid processing without Diameter, but selectively trigger a Diameter charge for prepaid users (for example by returning a response of MM9Diameter=Yes). Those changes are relatively straight-forward, and we believe they could be implemented very quickly. Certainly it could be implemented more quickly than selective triggering based upon IMSI range. Supporting multiple Diameter servers (let's say one for prepaid and one for postpaid) is a more complicated prospect. While I can understand the potential for such a requirement, wouldn't this also be necessary for the SMSC and for data charging from the GGSN? It would seem that a Diameter proxy that was routing charges to the appropriate charging server, but doing so for all services, would be a more appropriate solution. We are investigating how we could do this (the accounting callback could potentially indicate which server to trigger, or it could be IMSI or MSISDN ranges). But I am wondering, is your SMSC supporting multiple Diameter servers? If so, is it standard functionality or custom integration? -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 8 Registered: 04-2007 |
Hi Bryce, My comments: "However, you are correct, Diameter is far more widely used for prepaid as opposed to postpaid charging. While it makes sense to use Diameter for both, postpaid charging systems are frequently older and functioning well without real-time charging." This is often a case with mature operators. Unless the benefits weigh over the costs and complexity, post processing of CDRs is the norm. It's usually a matter of licenses costs to online charge postpaids. "MMS Accounting Pre-Auth needs an option to generate one callback per recipient." I agree. This should be optional, though, in line with the option for single/multi CCR "The Diameter configuration needs an option where it is only to be triggered by accounting callback. What I mean by this is that an option needs to be available where the MMS Accounting Pre-Auth decides whether or not a Diameter charge occurs. This would allow the Accounting callback to do its own postpaid processing without Diameter, but selectively trigger a Diameter charge for prepaid users (for example by returning a response of MM9Diameter=Yes)." This looks perfectly good to me. It certainly solves our use cases. "While I can understand the potential for such a requirement, wouldn't this also be necessary for the SMSC and for data charging from the GGSN? It would seem that a Diameter proxy that was routing charges to the appropriate charging server, but doing so for all services, would be a more appropriate solution." All our network elements that support Diameter charging are triggered for prepaid customers only. IMSI, APN name or HLR profile are used as triggers, but CDRs are always produced. We are a small operator though, and we know that there are a number of more elegant ways to accomplish this, like the proxy you mention, DPI, convergent billing, etc. "We are investigating how we could do this (the accounting callback could potentially indicate which server to trigger, or it could be IMSI or MSISDN ranges). " In my opinion the callbacks seem as more obvious direction because of their nature to hand over the decision to an external system that in turn, we as customers tailor to our needs. I believe there are operators which don't rely on either IMSI or MSISDN to tell prepaid for postpaid, so a consultation of an external system is inevitable. IMSI/MSISDN could be an option for customers that adhere to that convention. Let's say an XML with IMSI ranges could decide if online charging is needed or not? Another one could provide the Diameter routing structure. On the other hand, many systems use an internal subscriber database. If you go this way, the handiness of auto-provisioning and easy start up is lost and a more robust provisioning and db structure is needed. At least, each subscriber should be flagged post/pre and probably have the Diameter server. I guess that the benefit of this would be a local control/decision without accounting callbacks If one needs to ditch the DIY concept of callbacks, then the MMSC should also provide other options for routing. (SS7 SRI, ENUM...). It gets more complicated from here. At the moment you probably don't want to add more complexity. The combination of callbacks and your current Diameter development is a sufficient basis that should be tested its standing in practice a while. "But I am wondering, is your SMSC supporting multiple Diameter servers? If so, is it standard functionality or custom integration? " Yes, it does. I think Now should also support it for one obvious reason and that is redundancy and/or capacity on server side. Our SMSC connects to two CCNs and it is configured to round-robin the requests. Although Diameter was custom integrated to the specifics of our CCN, this functionality is standard. It has an xml table to tell pre from post (parameters include IMSI, MSISDN and others), it has another one for routing based on regular expressions against parameters chosen. I hope that my comments will be of some help. If necessary, I could provide more details on e-mail/phone Davor | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 9 Registered: 04-2007 |
Hi Bryce, I discussed the Pre-Auth accounting callback with one of my colleagues and her opinion is that there is no added value in separating this callback to many in case of multiple destinations. The callback in the case of prepaid A-party should just give answer that indeed, this customer will need online charging (probable also the name of the responsible charging server) and there is no need to repeat the same answer many times. The separate ccr calls are made for the sake of Diameter limitation. Thinking about multi OCS servers, they might be organized in a similar fashion to MMSC routing section (VASP-OUTs). Davor | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8062 Registered: 10-2002 |
Hi Davor, I appreciate your sharing your perspective. It is very helpful. We are still processing some of the input. Your follow-up brought to the front of my mind one of our most important considerations. We need to be extremely careful about any changes that we make to the callback interface. We are going to add an option to generate one PreAuth callback per recipient as an alternative to the current approach of one per message. But it's just an option. Upon reflection, this option has no relationship to anything we've discussed here. It's just something that we get asked about with some regularity. The PreAuth callback, in either single or multiple recipient form, will support a response to indicate that a Diameter charge should occur. (If the PreAuth is for multiple recipients, and Diameter is configured for one charge per recipient, multiple Diameter requests will be generated.) We still have more testing to do, but preliminary tests look good. We are supporting a trigger of MM9Diameter=Yes in the PreAuth callback response as an indication that a Diameter charge should occur. Our current plan is to support a further extension to that response, where instead of "Yes", the value references a Diameter server in the configuration. This way the PreAuth callback would be able to direct the charge to a particular Diameter server. We may look at configuration settings to trigger server selection automatically based upon IMSI, MSISDN or other in the future, but for now will rely on callbacks. (We might implement some simple triggers as a starting point, but it will be basic in the short term.) I don't yet have an estimate for how long the multiple Diameter server support will take as we've been too focused on the integration between the PreAuth callback and Diameter triggering. But we should have a better idea in the next week or so. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 10 Registered: 04-2007 |
Hi Bryce, I'm glad I have been of some help. I believe you have a very good Diameter foundation at the moment to start with. Regarding my previous post for the client behavior in case of MM1 rejection, we did a few tests and certainly the message remains in outbox with no further retries. Now, regarding the information back, I found this thread is dealing with the Response-status and Response-text: http://support.nowsms.com/discus/messages/485/33235.html. There seems to be a potential in the Response-text, but from my tests, it's not presented on the handset. I will follow-up on that thread, but my point is that it's good to have a mapping between the Diameter error and the Response-text sent back. -Davor | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 12 Registered: 04-2007 |
Hi Bryce, A little follow-up from Ericsson on the SCAPv2 and the specifics we discussed: 1. Confirmation that 3GPP-SGSN-MCC-MNC is supported and should be used for SGSN. 2. On the MMS to E-mail: "For emails it is recommended to sent additional information with SPI (with type string) . ScapV2 supports 200 different SPI and it each of them can be used in tarfff." 3. On the multiple recipients case: "...Well: either MMS handles multiple recipients .. or send number of them within separate parameter. But in this case all or nothing. Or using the non'atomic charging means ..SDP will return how much of those are really charged. In this case MMS should have a additional logic to send only a part of the recipents list." 4. On the MMS message size: "...ScapV2 can have up to 600 additional parameters (SPI), based on which can be used in SDP tariff." Regarding 4, I asked if 3GPP Service-Information/MMS-Information grouped parameter is supported. I will follow-up with the proposed SPIs once I have them. BR, Davor | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8063 Registered: 10-2002 |
Hi Davor, Before I comment on those issues, a little update. We are adding a configuration parameter to the [MM9Diameter] settings, CallbackTriggerOnly=Yes means that the Diameter charge will only be triggered if the accounting callback returns MM9Diameter=Yes We will also support multiple Diameter servers. Initially the only way to trigger a charge on a non-primary server is via a PreAuth accounting callback response. Non-primary servers are defined by creating a section [MM9Diameter-xxxxxxxx] in the MMSC.INI, using the same format as the primary [MM9Diameter] section. xxxxxxxx is a name to be assigned to the server. The PreAuth accounting callback responds back with MM9Diameter=xxxxxxxx to indicate that which server the charge should be directed to. MM9Diameter=Yes goes to the primary server, while values other than Yes are interpreted as the name of a non-primary server. More testing is needed, but we are planning to make this available in the first part of May. Now to the comments... 1. That is good news. 2. That doesn't really address the issue. Other-Party-Id appears to be a required parameter, but an e-mail address is not supported as a value for the parameter. I don't see any option other than substituting a fixed number for the e-mail address in the Other-Party-ID field. Putting the actual e-mail address into another SPI is possible, but if Other-Party-ID is required, something must go there. 3. We're comfortable whatever way, as it will be a configuration setting. One charge to cover all recipients or one charge per recipient. We will default to one charge per recipient. 4. Depending on how the SPI is defined on the Diameter server side, it should be simple to add the parameter to the XML to include it in the charging request. @@MsgSize@@ in the XML will be replaced with the message size in the actual Diameter charge. At least it looks like some progress. BR, -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 13 Registered: 04-2007 |
Hi Bryce, I'm getting information (partial) slowly from E///, but I can confirm that they propose AVP 440 to be used for multiple recipients and MMS to e-mail. I still don't have an answer on what to put in 1075, though. I'm trying to squeeze that last missing piece. I'll follow-up as soon as I have the info. BR, Davor | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8067 Registered: 10-2002 |
Hi Davor, We have added an explanation of accounting callback triggered Diameter requests to the document at http://www.nowsms.com/mmsc-diameter-mm9-implementation. Basically it works like I described before, but here are more specifics: If CallbackTriggerOnly=Yes is set in the [MM9Diameter] section, then the Diameter charge will only occur if the PreAuth callback returns a response that includes the text MM9Diameter=Yes Additional Diameter servers can be defined by creating sections similar to [MM9Diameter], where a server name is included in the section header, such as [MM9Diameter-xxxxxxxx]. These extra servers can only be triggered by PreAuth callback responses. MM9Diameter=Yes triggers the primary Diameter server and MM9Diameter=xxxxxxxx triggers a server defined with the name xxxxxxxx. Regarding e-mail addresses as a recipient... Perhaps Other-Party-Id is not strictly required in SCAP, but is only required based upon the charging rules defined on your server. We are planning to more widely release this software version soon, so we are leaving room for customisation and flexibility. The following options are available: 1.) EMailAddressNumber=#### substitutes a fixed number value in place of a recipient that is an e-mail address. 2.) The XML templates have support for two additional variables that are not shown in the default templates. @@RecipNumber@@ contains the recipient address if it is a number, but is blank if it is an e-mail address. @@RecipEMail@@ contains the recipient address if it is an e-mail address, but is blank otherwise. This can work in a variety of ways. Other-Party-Id (SCAP AVP 1075) could continue to work as it is today, with e-mail recipients encoded as a fixed number. Or value="@@RecipNumber@@" omitifblank="true" could be added to the Other-Party-Id grouped attribute to cause it to be omitted for e-mail recipients. Similar logic could be used to include SCAP AVP 440 only if the recipient is an e-mail address. Hopefully that approach will offer sufficient flexibility. We will be uploading a preliminary update with this additional support early next week. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4483 Registered: 08-2008 |
Follow-up... An update which follows the logic described in Bryce's previous message (and described at http://www.nowsms.com/mmsc-diameter-mm9-implementation) has been posted at http://www.nowsms.com/download/nowsms20130515.zip. -- Des NowSMS Support | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 14 Registered: 04-2007 |
Thank you. We'll check the updated functionality. Davor | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 15 Registered: 04-2007 |
Hi Bryce, We are finally implementing Diaaeter charging with Ericsson's CCN. I'm introducing my colleague Tanja Poposka, she is working on the implementation and has already conducted some end to end tests. From the previous posts in this thread, we have decided to remove AVP 1075 (Other party ID) and replace it with propitiatory SPI's that have been added in the diameter-credit-control.xml However, when issuing CCRs, we can't see those AVP's in the tcpdump. The syntax of the .xml configuration is attached. Can you please help what could we be missing? --Davor
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8074 Registered: 10-2002 |
Hi Davor, That's a good question...I don't think we've explained this anywhere. The way we handle omitifblank="true" and grouped AVPs is a little odd. We require a dummy value to be associated with the grouped AVP. The value will not actually be encoded with the grouped AVP itself, it is evaluated only to determine whether or not to include the group. It is probably easiest to explain with examples based upon your XML config: <avp name="Destination-SPI-Group" code="440" vendor="193" mandatory="true" type="Grouped" omitifblank="true" > <avp name="Dest-Value-Type" code="441" vendor="193" mandatory="true" type="Unsigned32" value="201" /> <avp name="Dest-Value-Data" code="442" vendor="193" mandatory="true" type="UTF8String" value="@@Recip@@" /> </avp> In the above case, there is no value associated with the grouped AVP Destination-SPI-Group. A grouped AVP doesn't really have a value, it just contains other AVPs. But because omitifblank="true" is present, we test to see if there is a value associated with the grouped AVP. There is not, so the group is omitted from (not included in) the protocol output. If we add a value like this, the group will be included: <avp name="Destination-SPI-Group" code="440" vendor="193" mandatory="true" type="Grouped" omitifblank="true" value="@@Recip@@" > <avp name="Dest-Value-Type" code="441" vendor="193" mandatory="true" type="Unsigned32" value="201" /> <avp name="Dest-Value-Data" code="442" vendor="193" mandatory="true" type="UTF8String" value="@@Recip@@" /> </avp> The value in the grouped AVP Destination-SPI-Group is not actually encoded in the protocol output, it is just tested to see if there is a value. If a value is present, the grouped AVP is encoded. If no value, it is skipped. As it is a good assumption that @@Recip@@ will be present, you could also leave off omitifblank so that the grouped AVP is always encoded: <avp name="Destination-SPI-Group" code="440" vendor="193" mandatory="true" type="Grouped" > <avp name="Dest-Value-Type" code="441" vendor="193" mandatory="true" type="Unsigned32" value="201" /> <avp name="Dest-Value-Data" code="442" vendor="193" mandatory="true" type="UTF8String" value="@@Recip@@" /> </avp> -bn | |||||||
| Tanja Poposka New member Username: Tanjapp80 Post Number: 1 Registered: 12-2013 |
Hello Bryce, I've made the changes in the configuration file (diameter-credit-control.xml) as you advised and the newly defined AVP is now introduced in the CCR. Thanks for the explanation. Regards, Tanja | |||||||
| Tanja Poposka New member Username: Tanjapp80 Post Number: 2 Registered: 12-2013 |
Hello Bryce, I am happy to inform you that we have managed to configure and activate MMSC Diameter charging mechanism. MMSC is now connected to our prepaid platform and charging requests are exchanged and processed successfully. So you can record a successful Diameter integration with Ericsson SCAP_V2. We would like to thank you for your help and commitment. During the tests we came up with an idea for additional charging scenario. Our suggestion is introducing a possibility for MT MMS charging i.e. possibility to charge the subscriber for a terminating MMS message (e.g. application originated MMS). This could be useful functionality for subscription based services. We believe that implementation of MT MMS charging in Diameter interface would be pretty easy. We already have TrafficCase AVP (1082) in the CCR. Traffic Case value 20 indicates MO charging, whereas value 21 means MT charging event. Tell me what do you think about this? Regards, Tanja | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8075 Registered: 10-2002 |
Hi Tanja, That is good to hear. There is a similar MT MMS charging interface defined in the MMS specific protocols as well, and we envision that this could be integrated with our MMSRetrieve accounting callback. We wanted to make sure we had sufficient experience with the MO charging interface first. And that has been good. We have also been able to work with SCAPv1, which uses different Diameter messages, which has helped us better understand the flexibility required. Still, with current development plans, it may be several months before we can look at the MT case. I'm curious, however, whether or not what we envision would meet your use case. Our MMSRetrieve callback records when the MMS message content is retrieved. It does not offer the option to block the retrieval at this point. (If we did, it may be confusing for the end user, as they will have received an MMS notification message, and might see an odd error.) So, I'd be curious about your thoughts are on this. I am wondering if perhaps a different charging template might be desirable for a message received from a VASP or interconnect, treating that as a potential MT charge. -bn | |||||||
| Tanja Poposka New member Username: Tanjapp80 Post Number: 3 Registered: 12-2013 |
Hi Bryce, There is no need to complicate MMS MT charging by tying it with MMSRetrieve callback. Once the MMSC accepts the MMS message it will do its best to deliver the message to the subscriber. Eventually MMSC will sent legacy MMS giving an opportunity for a subscriber to view the MMS on a web page. We believe that MMSSend event should be used as a trigger for MT charging as well. It can be achieved either by defining different charging template or by adding information about charging direction (MO or MT) in the response returned by the accounting callback (e.g. MM9DiameterChargingDirection = MO). First option it is clear. In the second option there is no need for different charging template. But, MMSC should check charging direction parameter returned by accounting callback and populate Traffic-Case AVP accordingly (20 for MO charging and 21 for MT charging). Additionally, @@Sender@@ and @@Recip@@ variables in MT MMS charging should be populated differently than in MO MMS charging scenarios. @@Sender@@ variable should be obtained using the following logic: • MO MMS (P2P and P2A) = Source MSISDN • MT MMS (A2P) = Destination MSISDN I.e. in MO cases (P2P and P2A), the Source MSISDN will be used to identify the end user and in MT case (A2P), the Destination MSISDN will be used to identify the end user. Similarly, @@Recip@@ holds an identifier of the other party involved in a Credit-Control-Session. I.e. @@Recip@@ should be destination (number or e-mail) for MO MMS and source (number or e-mail) for MT MMS. I hope that the remarks given above will be helpful in Diameter MT charging mechanism dimensioning. Now back to what we already have. I’ve noticed that the information about SGSNMCCMNC (AVP 3GPP-SGSN-MCC-MNC) is not included in the CCR sent towards the Prepaid even tough instructed to do so. Here is the MM9Diemeter definition in our MMSC.INI. [MM9Diameter] CallbackTriggerOnly=Yes Destination-Host-Address=10.139.126.40 Destination-Host-Port-Number=3868 Destination-Realm=ccnmk.mobitel.si Host-IP-Address=212.158.178.58 Origin-Host=mmc.one.net.mk Origin-Realm=mmc.one.net.mk Service-Context-Id=SCAP_V.2.0@ericsson.com Service-Identifier=155 Service-Provider-Id=300 SupportedExtensionSets=SCAP,3GPPSGSN CC-Service-Specific-Units=1 I have also attached latest diameter-credit-control - 20131223.xml. On the other hand, I see that SGSNMCCMNC value is present in the accounting callback query string i.e. it is not empty (*QUERY_STRING: PreAuth=Yes&Type=MMSSend&From=%2B38976514008&To=%2B38975400687&MsgCount=1&Size=57&X-WAP-3GPP-IMSI=294020002034264&X-WAP-3GPP-SGSN-ADDRESS=89.31.155.244&X-WAP-3GPP-SGSN-MCC-MNC=29402) Any idea why is this happening? Thanks in advance, Tanja
| |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4779 Registered: 08-2008 |
Hi Tanja, I can't really address the MO/MT charging case until after the holidays. However, I do see what the issue is for the SGSNMCCMNC value. Add the following to the [MM9Diameter] section of MMSC.INI: SGSNMCCMNCHeader=X-WAP-3GPP-SGSN-MCC-MNC -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Tanja Poposka New member Username: Tanjapp80 Post Number: 4 Registered: 12-2013 |
Hi Bryce, MT MMS charging is not an urgent issue, take your time to think it through. Thanks for the tip regarding sgsnmccmnc. The problem has been solved. Happy holidays! Tanja | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 22 Registered: 01-2007 |
Hi Nowsms team , we want to implement the MMS charging using the scap v2 diameter request. As we don't want downtime implementing this , we wnat to test the AVP use , etc before the implentation, As far as i remember there was a simulator http://www.nowsms.com/download/mm9test.zip that could test the CCR and CCA in order to check that on charging system side all is well configured. is there any update for this tools? By the way , on our network , we charge the mms to the deposit , so how can i test this without being in production. meaning that we have a backup mmsc , in order to test it first but i won't have a MO traffic on it , only MT. Thx for your advice , br Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5231 Registered: 08-2008 |
Hi Marc, The MM9 test is still good. It was updated to support templates, if needed. The version at that link is the latest. Unfortunately, I can't think of a good way to test MO other than modifying the MMS settings on a handset to point to the backup server instead. -- Des NowSMS Support | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 23 Registered: 01-2007 |
Hi Nowsms team Thx for your feedback , I have one question regarding the way the mms will be charged. How the mmsc will charged multidestination mms. I see on the MM9 documentation on the SCAP extension set that the recipient address will be implemented on the AVP 1075, but what will be the behaviour on multidestination case. If the mms is sent to 4 destinations , it will have 4 requests ? or will it have several avp 1201 ? Br Marc | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8104 Registered: 10-2002 |
Hi Marc, By default, you are going to receive one callback per recipient, because that is what most charging systems are expecting. If you want to receive a single charge, add the following setting in the [MM9Diameter] section: MultipleRecipCharge=Yes By default, the MMSC issues a separate charging request for each recipient when an MMS message is sent to multiple recipients. When this parameter is set to Yes, the MMSC issues a single charging request for multiple recipients, multiplying CC-Service-Specific-Units or CC-Money by the number of recipients automatically. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 24 Registered: 01-2007 |
Hi , Thx a lot for your feedback , by the way , did you ever think the possibility to add a SS7 interface ? For MNP , we use the MMS routing call back , but as all the operator should have their database up to date , it is quite complicated sometimes. A SRI for SM on the HLR is the most safe way to know on which operator belong a sunscriber. We saw a lot of MMSC supplier that use this to discredit your product but don't worry we are not blind ^^. and we often talk about support ^^ they cannot fight on this. Br Marc | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 16 Registered: 04-2007 |
I second this Marc, support is superb and the product is quite comprehensive, stable and affordable. That's a rock solid foundation with no real competition. A Linux port would make it even better for operator use. SS7 interface would be very useful feature and now that Sigtran is a norm it won't require expensive signalling cards. There is even a nice openSS7 project http://www.openss7.org/ --Davor | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 25 Registered: 01-2007 |
Hi Davor thx for the link , it is interresting , i saw that the last update is from the Dec 7, 2013. project had been discarded ? anyway , i am interested on it i will have a look. We can use this as a mean to have the sri and the response through mms routing call back solution. Br Marc | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 17 Registered: 04-2007 |
I can see project's status page http://www.openss7.org/status.html is last updated on 13.10.2014 but despite my wish, time never allowed me to try this product. | |||||||
| Davor Spasoski New member Username: Dspasoski Post Number: 18 Registered: 04-2007 |
P.S. Another related projects I once had my eyes on was: http://gull.sourceforge.net/ --Davor | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8107 Registered: 10-2002 |
Hi Marc & Davor, We do not have direct access to an SS7 interconnect, so it is difficult to know where to start. Well, I guess we start with an HLR lookup, which I'm sure is easy, we just don't know how to configure all of the prerequisites...and don't have direct access to be able to test, experiment and verify. Ideally, I'd like to see an HLR query interface that was easy to deploy on top of something like OpenSS7, and we could concentrate on mapping locations to routes. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 26 Registered: 01-2007 |
Hi nowsms team, if you need to test , have access to ss7 network , or connect to an HLR , i can help you. We are skill center for COMVERSE smsc for Orange groups and as we are on reunion island (meaning a small network ) they are no constraint of a big operator ( lot of process , operational comitee, etc.. ). So i can have a point code and a GT for a laptop connected through sigtran and i can build association with our PTS as well. So if you need to test, experiment , and verify , it will be a pleasure to help you, but it will not be a full time help because of my work ^^ ideally , you only have to do a sri for sm in order to retrieve the IMSI from the HLR response. In case of temporarly error , you won't have the IMSI , so the best way is to send a SRI with the GSM priority to true ( SM RP PRI parameter ). in this way , the HLR will respond the last known MSC location and the IMSI even in case of temprarly error . I can send you a trace of a sri and his response if you need. Let me know if you are interessting or not. But again , i think it could be good for your product to include a SS7 interface to manage the MNP. Br Marc | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 30 Registered: 01-2007 |
Hi Nowsms team we are currently studying the imlplementation of MM9 interface , all the xml file are ready , as the MMSC.INI file. we will perform the scap V2 request for each subscriber meaning postpaid and prepaid. As we have got only one MMSC running ( the other is on backup ) , we have to pay attention when we will do the integration . To be safier is there any tips to do with accounting callback , to trigger the scap v2 request for only two or three msisdn ? Note that we don't use at this time the accounting callback. The best should be to have a txt file with the msisdn. do diameter rquest for the msisdn include in the list and else for other msisdn , don't perform diameter request. Thank you beforehand for your response Br Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5296 Registered: 08-2008 |
Hi Marc, Are you currently using any accounting callbacks? If yes, it should be relatively easy to modify the callback to only use Diameter for selected MSISDN. See the section titled "Enabling MM9 Diameter for Only Select Subscribers" under http://www.nowsms.com/mmsc-diameter-mm9-implementation The key point is to add CallbackTriggerOnly=Yes to the [MM9Diameter] section of MMSC.INI to indicate that the MMSC should only generate Diameter charges if directed to do so by the response to the MMSSend PreAuth callback. The callback response needs to include the text MM9Diameter=Yes to indicate that a Diameter charge is required for the transaction. -- Des NowSMS Support | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 31 Registered: 01-2007 |
Hi Des , thx for your feedback, at this point , we don't use accounting callback , it is why i asked this. At the beginning , i was thinking about putting a txt file with the msisdn on the mmsc web directory itself and activate the accoubting callbacl on the loopback , but what will happen for the rest of the msisdn that are not on the list ? access will be granted or not. It is why , i had ask this question , maybe , it exist a more simple way. Thank you beforehand for your advice, br Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5298 Registered: 08-2008 |
Hi Marc, A text file would be static, so it would affect all requests. You need something conditional. PHP is usually the easiest to work with. If you want to have NowSMS run the PHP scripts directly, follow these instructions: http://www.nowsms.com/now-sms-native-php-scripts After installing PHP, restart the SMS service. There's a sample PHP routing script here: http://www.nowsms.com/doc/mmsc-messaging-server/operator-mmsc-considerations/mobile-number-portability-mnp-considerations And here's the actual sample script: http://www.nowsms.com/download/mmsroute-php.txt Now, here's an edit of that script to filter on sender MSISDN and trigger select recipients to use DIAMETER.
Put this PHP file in the PHP directory of NowSMS or on another web server. Test the script from a web browser. http://localhost:8800/php/mmsroute.php?Type=MMSRouteCheck&From=%2B44777777777 should return MM9Diameter=Yes If you change the From= parameter, the response should change to just OK Adjust the logic to filter on your test subscribers. -- Des NowSMS Support | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 34 Registered: 01-2007 |
Hi Des Thx for your feedback, I need some help , i rtfm but i am lost ^^ here's the goal: in order to implement the MM9 on our MMSC and as the backup MMSC is unable to take traffic due to the architecture , we have to test the MM9 directly on the production server. So in order to do that , we wnated to use the accounting callback. Meaning that for the msisdn on the mmsroute, the mmsc produce a scap v2 request when ithe msisdn send a MO ( MMS ) and for other sender , keep like it is running currently ( without scap v2 ). If the test are commpliant with our need , we can implement it on the production system for all subscribers. I did install php , pear etc.. and i did test the php script with the full url and it is working properly. I did test also the mmsroute.php script using url. the php script is on C:\Program Files\NowSMS\php. For the accounting callback , i add MMSAccountingURL=http://127.0.0.1:8800/php/ on the mmsc.ini. But i didn't found how to activate in preauth callback for activating the test ? how to set the PreAuth=Yes etc.. on the 2-way menu? tell me if you want me to exchange directly by email using the nowsms.support adress or continue through the chat forum. Thx beforehand for your advices, br Marc
| |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5345 Registered: 08-2008 |
Hi Marc, Based on the above, the callback should be activated. I would expect that the MMSC is already using it. Unfortunately this is hard to confirm without enabling the debug logs to see what is happening. Enable the MMSCDEBUG.LOG, and you should see references to the callback, and the URLs being used. If you want me to look at an MMSCDEBUG.LOG, feel free to email to nowsms@nowsms.com with Attention: Des in the subject line. -- Des NowSMS Support | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 35 Registered: 01-2007 |
Hi Des Thx for your feedback , i was wondering me that because neither on mms.ini or smsgw.ini , i have notice that the script that has to be queryed is the mmsroute.php. do i have to coinfigure it on the 2-way brackets ? thx beforehand for your support Br Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5354 Registered: 08-2008 |
Hi Marc, I didn't notice this at first, but I see MMSAccountingURL=http://127.0.0.1:8800/php/ Don't you want that to be MMSAccountingURL=http://127.0.0.1:8800/php/mmsroute.php -- Des NowSMS Support | |||||||
| marc bazimon New member Username: Marc_orange Post Number: 37 Registered: 01-2007 |
Hi Des , Ok now it make sense, i will revise the configuration file now i have to test it directly on live system , croos the finger for me ^^ Thx for your advice Br Marc | |||||||
| Gonzalo Escuder New member Username: Gdescuder Post Number: 32 Registered: 06-2010 |
Hi Des, I'm testing a Diameter interface with mms9test to an Ericsson charging that seems to have problem with email destinations. I've configured EmailAddressNumber=8888 to overcome this issue but is not working. Do you have detailed instructions on how to configure a fixed number in substitution to an email destination? Thank you, very much. Regards, Gonzalo MM9TEST.INI [MM9Diameter] Destination-Host-Address=10.10.11.10 Destination-Host-Port-Number=8732 Destination-Realm=xxxxxxx Host-IP-Address=10.68.133.120 Origin-Host=xxxxxxx Origin-Realm=xxxxxxx Service-Context-Id=SCAP_V.2.0@ericsson.com Service-Identifier=600 SupportedExtensionSets=SCAP,3GPPTIMEZONE Service-Provider-Id=mms CC-Service-Specific-Units=1 MultipleRecipCharge=y EmailAddressNumber=8888 [MM9DiameterTest] SenderAddress=xxxxxxxx IncludeSCAPParameters=y Include3GPPMSTimeZone=y Include3GPPMMSInformation=n RecipAddress=gescuder@gmail.com }} | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5499 Registered: 08-2008 |
Hi Gonzalo, The MM9Test program does not understand the EmailAddressNumber setting, but the actual MMSC does. Test with a recipient of 8888, and that is what you would see for an email address on the live system with that setting. -- Des NowSMS Support | |||||||
| Gonzalo Escuder New member Username: Gdescuder Post Number: 33 Registered: 06-2010 |
Thank you, Des! I'll try with NowSMS then. Regards, Gonzalo | |||||||
| Amanpreet Singh New member Username: Ss7aman Post Number: 1 Registered: 04-2016 |
hi All, Section 5.3 MMS Online charging scenarios (RFC 32270) Defines charging on MM retrieve, basically it is required when subscriber is roaming. As per my understanding , on each retrieve, a charge request is sent. also mentioned " For IEC, if the retrieval process is not successful for any reason (e.g. MM1_retrieve_Ack is not received) and another MM1_retrieve_req is received for the same message (identified by the Message ID), it is OCS logic to determine whether the subsequent requests are charged." but nothing is mentioned for ECUR. Now custsomer is using Direct debit and refund mode. so refund can be sent as per 6.3.3 Immediate Event Charging (IEC) when "service charged previously through Direct Debiting Operation is finally proved to be unsuccessfully delivered." i.e. refund should be sent only when message is not retrieve (i.e no notification response or ACK ind received manual retrieve) and finally expired. solution 1: instruct OCS, to ignore all subsequent charge request sent for same message ID. So refund is only sent at message expiry. though result code should be success returned by CCA there is a problem , if OCS returns Refund information AVP, in this case, then which of charge request "Refund information " should be included in CCR(Refund) sent when retrieval failed. Solution 2: if OCS can't implement above logic to ignore charge request. then each CCR send on every retrieve will be charged. and MMSC can only send one Refund request as CCR at end , when retrieval is permanently failed. also if OCS inclues refund information AVP, then which one to send. Please advice, how refund can be implemented in MM retrieve question 2: In 32270 standard , below figure defined the ECUR mode charging. Figure 5.3.2.2b : MMS Online charging scenario for MM retrieval using ECUR is the same logic applied here. 1. for every retrieve, Reserve unit request is charged. but there is no note defined, that further units should not be reserved by OCS , like the note defined for IEC. so OCS will keep on reserving units, when end user has balance of 1 unit only, then second retrieval (if first retrieval time out) , reserve request will fail. 2. Also Confirmation request is only after retrive ACK is received. here retrieve ACK as per 23140 standard is interpreted as . so here mmsc will send confirmation of 1 unit i.e "When content/service delivery is completed (ack ind or notification resp), the network element sends CCR with CC-Request-Type AVP set to TERMINATION_REQUEST to terminate the active credit control session and report the used units. how to address problem in ecur mentioned in point 1 | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8144 Registered: 10-2002 |
Hi, I'm not sure if you questions are directly related to our MMSC product, or are more general technical discussion. From a product perspective, we do not currently generate a Diameter request on MMS message retrieval (MT), only on origination (MO). We do have an active customer request to add a configurable option for generating a Diameter charge on message retrieval. And I do expect that option to be added in the coming months. In most of the world, the SMS charging model has been "sender pays", so the charging focus is on origination. There are HTTP based accounting callbacks that report retrieval, we just haven't implemented it for Diameter yet, largely because it is not clear what an OCS should do with this information (except from a roaming perspective). From a more general perspective, I don't think there are any easy answers. I will say that your discussion seems to assume that all message traffic is local to the MMSC. You also need to consider MM4 inter operator connections where you will never see a retrieve or ack. And many of our customers have a significant number of MMS converted to SMS with web link, which creates another set of challenges. Considering these and other complications, my opinion is that your solution 2 is unworkable as a primary solution, as you will only see messages terminating at this MMSC. In some markets, subscribers are charged both for MO and MT, and I can see recording an MT charge in this way. But as a primary solution, no. Solution 1 is interesting, but you are saying that the MMSC must remember the refund information AVP returned by the OCS, and the MMSC must then present that information back in a refund request in the event of message expiry or other non-delivery. We would be happy to work with an OCS vendor to add refund on expiry/non-delivery functionality to the Diameter implementation in our MMSC. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 57 Registered: 01-2007 |
Hi Nowsms team, We are implementing the diameter for charge the MMS. I did configure the mmsaccounting in order to do diameter request only for one subscriber. CER are ok , but i have a issue on one of the AVP from CCR. we want to add the SGSN MCC MNC on the subscription ID to have the information if the subscriber is in roaming or not. please find the mmsc config file , the diameter CCR file and a pcap trace ( before mmsc is the field that we send from our wap gtw in the header http ( see packet 94) and the trace of ccr is the diameter request. As you can see the subscription location id is empty, could you check and tell me what is missing ? thanks beforehand for your help ,Br Marc .
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8246 Registered: 10-2002 |
Hi Marc, Try changing this: SGSNMCCMNCHeader=X-WAP-3GPP-SGSN-MCC-MNC to: SGSNMCCMNCHeader=SGSN-MCC-MNC -bn Bryce Norwood Now SMS/MMS Support | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 58 Registered: 01-2007 |
Hi Bryce Thanks it works , i add also SGSN IP address using sgsnaddressHeader= sgsn-IP let me ask you a question : on the diameter-credit-control.xml we want to add this <avp name="Subscription-Id-Location" code="1074" vendor="193" mandatory="true" type="UTF8String" value="@@SGSNMCCMNC@@" omitifblank="true" extensionset="SCAP" /> instead of having the information into the AVP 18 do i have to add command as Subscribtion-Location-idHeader=SGSN-MCC-MNC on the mmsc.ini ? i can send you the trace but on the ccr you can check that the avp 18 appears  thanks beforehand for your always useful advices | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8255 Registered: 10-2002 |
Hi Marc, Sorry, this required some investigation ... I believe the issue is that any "@@" variables (except those that start with "@@Config-") can only appear once in a template. So, the first occurrence is processed, but the second is not. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 59 Registered: 01-2007 |
Hi Bryce Thanks for your advice. I did a test , i remove the SGSNMCCMNCHeader=SGSN-MCC-MNC and add subscription-location-idHeader this into the mmsc.ini in order to have the AVP 1074. On the pcap trace you can see that the sgsn MCC MNC disappear but no subscription location id had been added on the CCR request. [MM9Diameter] CallbackTriggerOnly=Yes Destination-Host-Address=10.241.32.219 Destination-Host-Port-Number=3868 Destination-Realm=test.reunion.ftm.francetelecom.fr Host-IP-Address=10.163.7.135 Origin-Host=secondary.runmmsc01.orange.fr Origin-Realm=test.reunion.ftm.francetelecom.fr Service-Context-Id=SCAP_V.2.0@ericsson.com Service-Identifier=6 CC-Service-Specific-Units=1 SupportedExtensionSets=SCAP,3GPP,3GPPTIMEZONE,3GPPSGSN Service-Provider-Id=MMSC Subscribtion-Location-idHeader=SGSN-MCC-MNC SGSNADDRESSHeader=SGSN-IP is it the correct command to have the subscription location id ?
Br Marc
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8257 Registered: 10-2002 |
Hi Marc, I think I understand the confusion. Do not remove SGSNMCCMNCHeader=SGSN-MCC-MNC This tells the MMSC which HTTP request header has this information. What I am saying is that @@SGSNMCCMNC@@ can occur only once in the XML template for the Diameter request. So you cannot have both AVP 18 and this custom AVP. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 60 Registered: 01-2007 |
Hi Bryce , sorry for the misunderstanding , let me tell you better what is our need. On the diameter-credit-control.xml , the only row where @SGSNMNCMCC@@ is used is on the row 1074. But if you look on the pcap trace , you will see that there's AVP 18 that appears even if i didn't put it on the diameter-credit-control.xml. AVP 18 appears on the trace as soon as the SGSNMCCMNCHeader=SGSN-MCC-MNC is set on the mmsc.ini even if it is not implemented on the diameter-credit-control.xml file.. Our goal , is to have the same AVP than for the charging of our SMSC. we want to do that to make the implementation on our charging system more easier. so it is why we want to have the subscription-location-id filled by the SGSN-MCC-MNC. thanks beforehand for your feedback. Br Marc
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8260 Registered: 10-2002 |
Hi Marc, That's a mystery. There are no AVPs generated automatically...they are only generated if they appear in the diameter-credit-control.xml file. Our default diameter-credit-control.xml file does include this AVP, with an instruction to omit this AVP if the value is blank. I can only conclude that this default version is being used, instead of your edit...or perhaps an early version of your edit. Verify that DIAMETER\diameter-credit-control.xml is actually getting updated. The MMSC does keep the content of this file cached in memory, and automatically loads updates. Perhaps something is wrong with this reload, and the service needs to be restarted. -bn Bryce Norwood Now SMS/MMS Support | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8261 Registered: 10-2002 |
...I just had another 2 thoughts... Are your SMSGW.INI and MMSC.INI files in ProgramData, or in the same directory as the program files (executables)? The MMSC looks for DIAMETER\diameter-credit-control.xml relative to the directory that contains the executables. The other thought...Windows has some security quirks. If it doesn't think you have access to update a file, it saves your edit in a way that the update is only visible when logged in with your account. Other accounts (including the system account that the services run under) still see the original file. Knowing your thoroughness, I suspect this is the issue you are encountering. Scan your system for other copies of this diameter-credit-control.xml file. This shadow file/directory structure is generally created in \Users\useracount\AppData\Local\VirtualStore | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 61 Registered: 01-2007 |
HI Bryce , Thanks for your feedback and your advice , it allow to resolve the issue. i scan the server and found several diameter credit control xml file. ANd you will take me as a noob but my diameter conf file was not on the /diameter path. I change it , put the correct AVP and it is working properly now. Thanks see you and sorry for misunderstanding. Br Marc | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 63 Registered: 01-2007 |
Hi Bryce , Our IT team need severals field to be added into the AVP request. this i sthe case for user location info , rat type and APN. I already did the configuration into our Wap Gtw to send it to MMSC. AVP: l=9 t=Vendor-Specific(26) v=3GPP(10415) AVP Type: 26 AVP Length: 9 AVP Vendor ID: 3GPP (10415) VSA: l=3 t=3GPP-RAT-Type(21): EUTRAN(6) AVP: l=21 t=Vendor-Specific(26) v=3GPP(10415) AVP Type: 26 AVP Length: 21 AVP Vendor ID: 3GPP (10415) VSA: l=15 t=3GPP-User-Location-Info(22): 8246f700000246f70000001705 AVP: l=16 t=Called-Station-Id(30): orangerun.acte AVP Type: 30 AVP Length: 16 Called-Station-Id: orangerun.acte what is the parameter on header that have to be added on mmsc.ini in order to take into account this three AVP ? (like by example SGSNMCCMNCHeader=SGSN-MCC-MNC or SGSNADDRESSHeader=SGSN-IP) Thanks beforehand for your help Br Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5896 Registered: 08-2008 |
Hi Marc, Of the 3, only user 3GPP-User-Location-Info is currently supported. The DIAMETER XML template supports a @@UserLocationInfo@@ variable that is built from SGSN-MCCMNC. Typical encoding in the template is to use the OctetString format: <avp name="3GPP-User-Location-Info" code="22" vendor="10415" mandatory="true" type="OctetString" value="@@UserLocationInfo@@" omitifblank="true" extensionset="3GPPSGSN" /> I assume the other parameters can be extracted from the HTTP header? We are evaluating how to best add support for them. -- Des NowSMS Support | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 64 Registered: 01-2007 |
Hi Des Thanks for your feedback , yes it is feed by the http header. Nevertheless ,we found a B Plan , so no need for you to look for a workaround. Except that could be useful for other operator. Br Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5898 Registered: 08-2008 |
Hi Marc, Glad to hear that you found a work-around. We are adding support for up to 5 custom HTTP header values to be able to be encoded as DIAMETER AVPs. An interim release with this support should be ready in the next several days if you would like to try it. -- Des NowSMS Support | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 66 Registered: 01-2007 |
Hi Des Thanks , for sure we will try to try it. we can send it on the SPI ( service paramter info ) AVP that seems to be compliant with Ericsson scap V2 Br Marc | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 67 Registered: 01-2007 |
Hi Des Sorry but we have a small issue with the use rlocation info , i attach a doc file where you can find the header receive by the mmsc and the diameter request. The user location info is present on the header but it seems that mmsc decode only the mcc mnc and doesn't decode the location area code and the cell identity
i change the type octetstring into utf8string but it is not better maybe you have an idea as usual Thanks beforehand for your feedback , Br Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5900 Registered: 08-2008 |
Hi Marc, That is correct. We are not looking for a User-Location-Info HTTP header. The customer that needed this AVP only had the MCC MNC, and only really needed the MCC MNC for charging...but the charging platform expected to extract MCC and MNC from the user-location-info AVP. I think the solution is the update. Here's how it works: In the [MM9Diameter] section of MMSC.INI,, add: ExtraAVP1Header=User-Location-Info This defines the HTTP header that contains ExtraAVP1. In the Diameter XML template, use @@ExtraAVP1@@ At this time, up to 5 of these "extras" can be supported. The update is at https://www.nowsms.com/download/nowsms20180221.zip Make sure you have a NowSMS/MMS installer for the version that you are currently running. If there is an unexpected problem that forces you to rollback the version, use that installer. -- Des NowSMS Support | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 68 Registered: 01-2007 |
Hi Nowsms team i saw on this topics that severals servers may be configure. is it still configure to be used with the preauth accounting callback response or there's a mechanism that contact the second server in case of the watchdog failed? Another question is more a check before the migration : Now we are ready tomigrate to Diameter charging , i was using the accounting callback in order to do diameter requets only for my number so i add the following in the mmsc.ini [mmsc] MMSAccountingURL=http://10.163.7.134/mmsroute.php [MM9Diameter] CallbackTriggerOnly=Yes in order to migrate all our subscriber, i have only to remove the two lines before correct ? do i have to add MM9DIAMETER = yes ? thanks beforehand for your help, Br Marc | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8270 Registered: 10-2002 |
Hi Marc,
The typical multiple diameter server scenario is that an MMSC needs to connect to a different charging system for different subscribers. For example, prepay vs post pay, MVNO,, multiple countries, etc. Your scenario appears to just want a backup/alternate. To achieve this, create a DNS entry for the diameter server, resolving to multiple ip addresses. -bn | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8271 Registered: 10-2002 |
Correct
No | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 69 Registered: 01-2007 |
HI Nowsms team , Does it exist a log , or statistics regarding the Diameter request ? currently the only means for me to have such informations , is to take a pcap trace. Thanks beforehand for your advice, Br Marc | |||||||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 70 Registered: 01-2007 |
Hi Sorry for insist , did you have a look into the log of diameter on mmsc side ? Thanks beforehandd for your feedback , Br Marc | |||||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5959 Registered: 08-2008 |
Hi Marc, Sorry for the lack of response. The DIAMETER transactions themselves are not logged. But these DIAMETER transactions occur in response to an MMS transaction, and info about the MMS transactions are recorded in the MMSC-yyyymmdd.LOG files. -- Des NowSMS Support | |||||||
pcap from mm9.exe communication with SCAPv2
mmsroute.php
mmsc.ini
mmsc config file
