| Interfacing with charging system |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through May 02, 2013 ⬆ |
◄ ► |
| Author | Message | |||||
| marc bazimon New member Username: Marc_orange Post Number: 14 Registered: 01-2007 |
Hi I’d like to connect a No Wireless MMSC with an Ericsson charging system using SCAP v2 protocol, for prepaid subscribers charging purpose. Is this protocol supported by the MMSC ? Can you advise how to solve this issue in a efficient way ? Thanks a lot for your feedback | |||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3719 Registered: 08-2008 |
Hi Marc, I'm going to ask one of my colleagues to look into this in more detail. It will probably take a day or two before he can reply back. -- Des NowSMS Support | |||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3729 Registered: 08-2008 |
Hi Marc, Apologies for the delay in response. I should have initially replied with some more detail, but I wanted to have one of my colleagues take a closer look at SCAP first. I should have given you some details of how the NowSMS MMSC interfaces with charging systems while waiting for my colleague to investigate the Ericsson SCAP protocol. I see some discussion threads from a few years ago where you and Bryce discussed accounting callbacks. Do you currently use our accounting callbacks? If not, they are described here: http://www.nowsms.com/doc/advanced-configuration-settings/mms-accounting-callbac ks We do not have a direct interface to Ericsson's SCAP. I asked Bryce if he could take a look at SCAP. He did, but he indicated that he's not sure it makes sense for the MMSC to interact with SCAP directly. The problem is that SCAP is designed more for content providers to charge for content. So, for example, a customer submits an MMS message, and the MMSC could record a charge of 25 cents, or whatever the set price is. If MMS is always a pay-per-use event on your network, that would be ok. If, however, you want to offer different bundles with some number of included MMS, then this does not work. Now, that said, perhaps your back end SCAP server can handle that part of the logic? We would entertain the possibility of custom development to create an interface from our accounting callbacks to a SCAP server. Are you already using SCAP? How do your other services interface with it? What attributes do you see as being required in a SCAP message from the MMSC. -- Des NowSMS Support | |||||
| marc bazimon New member Username: Marc_orange Post Number: 15 Registered: 01-2007 |
Hi Thanks a lot for your quick answer, Indeed SCAP is already used by other platforms connected to our Ericsson charging system. Regarding the charging method : from my understanding, using SCAP v2 allows the MMSC to charge an MMS as a specifc type of event, instead of a specific price, if the appropriate parameters are specified in the SCAP request. In this case, the charging system becomes responsible to define the MMS price according to subscriber profile. If case SCAP can be implemented by NowSMS, can you roughly estimate the time that would be required ? BR Marc | |||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3733 Registered: 08-2008 |
Hi again Marc, I'm sorry, we were so intent on trying to understand SCAP that we missed the obvious. SCAP is an Ericsson protocol that is a set of extensions built on top of Diameter. For MMS charging, I expect that Ericsson's SCAP uses pure Diameter. There are Diameter specifications that document these callbacks. That's why we didn't see them in the SCAP specifications. I'm relieved to understand that, because we have been investigating the use of Diameter for MMS charging (accounting) callbacks. I need to discuss with our Product Manager, so we'll get back to you by the middle of next week with more information. -- Des NowSMS Support | |||||
| marc bazimon New member Username: Marc_orange Post Number: 16 Registered: 01-2007 |
Hi Thx , i have got the Ericsson specification for their scap v2 , I think , like all the product coming from big supplier , the norm is Ericsson one. but as it is supplier documentation , could you tell me an email adress where i can send you that if you need? ( my email are marc.bazimon@orange.com ) BR Marc | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8011 Registered: 10-2002 |
Hi Marc, We probably already have that spec, but just in case, send it to nowsms@nowsms.com with Attention: Bryce on the subject line. The way we'd like to proceed on this, if possible, is to send you a test program to try to make a single charge to that SCAP server. Basically, the test program will just require you to input some parameters such as: Origin host, port & realm. Destination host, port & realm. MMS sender and recipient addresses. If you can get this to register with your SCAP server, then this will tell us that we're understanding the protocol correctly. Is this possible in your environment? -bn | |||||
| Jay New member Username: Jaypatel79 Post Number: 1 Registered: 02-2012 |
Hi, i am following the above thread and would like to know can we connect MMSC directly with Ericsson IN using SCAPv2. Now a day MMS does require complex charging rules with packaging. Does MMS charging required DPI funcationality for charing ? | |||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3816 Registered: 08-2008 |
Hi,
We are still waiting for feedback from the customer in this thread. We have developed a test program that implements the MM10 (Diameter based protocol) as defined by the 3GPP. At present, we do not have confirmation that Ericsson SCAP v2 implements MM10. Ericsson's SCAP is a Diameter based protocol, but I have yet to see any documentation for it that makes any reference to MM10, or even to MMS for that matter. We believe that MM10 (3GPP TS 29.140) will be the standard way for an MMSC to interface with a charging server. However, we are hesitant to provide full MM10 support until we can successfully test against a charging server that implements this protocol. I am happy to send our test program (Windows binary) to any NowSMS customer who wants to try it against a charging server. It basically just prompts for information about the charging server (host name and relevant Diameter realms), and for a sender and recipient to send a charging record for a single MMS transaction. If we can get verification of proof of concept, we will be happy to add MM10 support for a charging interface, in addition to the existing HTTP accounting callbacks interface. Those HTTP accounting callbacks are the way to interface today, as they provide the flexibility to interface into other systems.
I disagree. Charging based upon size, perhaps, but that is hardly complex.
Why should it? From a charging perspective, are you going to charge someone more if DPI detects "sexting" images?  I can see a case for message size based charging (if data for MMS is not being otherwise charged for), but deep packet inspection seems like overkill. Of course, I assume by DPI you mean Deep Packet Inspection, and not something else.... -- Des NowSMS Support | |||||
| marc bazimon New member Username: Marc_orange Post Number: 17 Registered: 01-2007 |
Hi Jay Sorry for delay , i was in vacation and E/// is currently launching the CS5 integration but the data and MMS will be postpooned to later. is the type of mms ( txt , audio or video ) , size belong to DPI issue? For me as far as i can foreseen the project, we won't have the use for DPI because it should have been done by the GGSN ( who are connected to charging system ). BR Marc | |||||
| marc bazimon New member Username: Marc_orange Post Number: 18 Registered: 01-2007 |
Hi Des, sorry again for delay I did some test in order to check the compliance from MMSC regarding the CS5 Diameter protocol. The software used need three inputs : origin msisdn , destination msisdn and service key. I did also a tcpdump trace in order to see exchange between CS5 testbed and my laptop. The network connection is ok but the result of diameter exchange protocol is an error "diameter_invalid_AVP_value" the AVP in trouble are the AVP 268 but it seems that the soft don't send it , maybe a mandatory parameter for CS5 , I asked to Ericsson if the AVP 268 is mandatory but as i said previously they are booked by the integration. Regarding the service key , is it possible to have the same software but instead of the service key , make request directly with a cost? i will give you feedback asap , BR Marc
| |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8017 Registered: 10-2002 |
Hi Marc, AVP 268 is for "Result Code". It is the parameter in the response that contains the result code for the operation. Considering that this is happening during the initial "capabilities exchange", I'm not sure which parameter value it could be complaining about. Ah ... now I see. There is another parameter in the response, Failed-AVP. In this parameter it is indicating that it does not like the "origin host". Possibly it wants something more of a fully qualified host name, as opposed to just "mmsc". We're not opposed to implementing some other DIAMETER based charging, as long as we can define the rules such that they can be flexible. In other words, we'd want the logic to be such that we could read the protocol parameters from a configuration file. We'd obviously prefer to use the MM10 protocol as defined by 3GPP. But I do have doubts that it is widely implemented. The problem with the Ericsson SDK is that they assume that their libraries are being used. We will implement the DIAMETER protocol directly, not through Java based libraries. From reading through the SDK, its terminology is very similar to RFC 4006. I assume that the logic flow would be capabilities exchange (the step that is currently failing), followed by a Credit-Control-Request. Aside from hosts and realms, these seem to be the required parameters: Auth-Application-ID = 4 Service-Context-ID = UTF8 string name for service allocated by service provider? CC-Request-Type = EVENT_REQUEST CC-Request-Number = incremental value Requested-Action = DIRECT_DEBITING or CHECK_BALANCE for PreAuth Subscription-ID = END_USER_E164/sender# Event-Timestamp = current time Requested-Service-Unit = what to charge for/how to charge? Maybe other parameters would be needed, but I think that's it. It seems pretty straight-forward, I think the open question is charging. How to determine charging units, pricing. If the MMSC needs to calculate a different price for national vs. international recipients and/or based upon size. From a specification stand point we can supply any combination of the following subparameters for Requested-Service-Unit: CC-Money - Currency and value CC-Total-Octets - Size of message CC-Service-Specific-Units - Whatever we want, such as number of messages Actually maybe we should be using Used-Service-Unit for DIRECT_DEBITING and Requested-Service-Unit for CHECK_BALANCE. That requires more investigation, but would make sense. Our preference would be to stay out of the money calculation, but indicate 1 as the service specific unit, and also indicate the size of the message. This does not account for international recipients, however. I don't see any good way to handle them in this particular scenario. Aside from figuring out the charging bit, this actually might be a little easier to implement than MM10, as this logic is very similar to the logic of our existing callbacks. Provide some guidance on the charging, and we can put this into a test program. -bn | |||||
| shoeb New member Username: Shoeb Post Number: 1 Registered: 07-2012 |
@marc bazimon: What is the status of your SCAPv2 implementation? | |||||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4280 Registered: 08-2008 |
Follow-up: 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 on the following new thread: http://support.nowsms.com/discus/messages/485/71497.html -- Des NowSMS Support | |||||
MM10 log
