MMS SCAP v1 support

MMS SCAP v1 support SearchSearch
Author Message
Farman
New member
Username: Forikfunk

Post Number: 1
Registered: 10-2013
Posted on Friday, October 25, 2013 - 01:14 pm:   

Dear NowSMS team.

is Ericsson SCAPv1 supported by Diameter interface? I mean send AccountingRequest (271) instead Credit-Control-Request (272)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4704
Registered: 08-2008
Posted on Friday, October 25, 2013 - 07:33 pm:   

Hi,

We don't have access to any documentation on SCAPv1.

But as long as it is DIAMETER based, it should be possible to support it ... but not without changes.

We use an XML template to define the format of the Diameter request, so you can define whatever AVPs are required by the charging system. However, the command code is currently hard coded as Credit-Control-Request (272).

The way I see it, we would need to make a simple change to our XML template to allow a Command-Code and Application-ID to be defined for the <diameter> element.

So we'd change our default template to start like this:

<diameter name="Credit-Control-Request" command-code="272" application-id="4">

In your case, you'd change the template to start with:

<diameter name="Accounting-Request" command-code="271" application-id="3">

That sounds like a rather simple change for us to make. We'll start with adding this support to the MM9 test program, which is used to validate before enabling the interface in the MMSC.

That will take about a week. In the meantime, do you have documentation on the packet formats, and more importantly, some traces of working examples?

--
Des
NowSMS Support
Farman
New member
Username: Forikfunk

Post Number: 2
Registered: 10-2013
Posted on Monday, October 28, 2013 - 09:10 am:   

Hi Des,
Thank you for info. I can send you example pcap file for AccountingRequest - Start and AcccountingRequest - Stop. Please provide email, because information on trace is confidential.

The only documentation for ScapV1 i found on here http://mobicents.googlecode.com/files/ChargingSDK-1_0_D31E.zip
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4706
Registered: 08-2008
Posted on Monday, October 28, 2013 - 05:12 pm:   

Hi,

Please send the PCAP to nowsms@nowsms.com ... include Attention: Des on the subject line.

We should have an update to the test program soon. I will post an update when it is ready.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4708
Registered: 08-2008
Posted on Monday, October 28, 2013 - 09:07 pm:   

Hi Farman,

We have received the trace ... thanks, that is very helpful.

We think that we can work with this protocol variation, however it will require several changes/enhancements to our logic, beyond adding support for setting the Diameter command code and application ID in the xml template.

Specifically, we need to do the following:

1.) Devise a mechanism for a single event to trigger two Diameter requests, those being the accounting start and stop events, both of which seem to be required. Our plan is to allow more than one <diameter> element in the XML template. (Question: Your trace shows this sequence, but the SCAPv1 programmer's doc suggests we could simply use Accounting-Record-Type = EVENT instead of generating a START and STOP. Do you know if this is the case?)

2.) Define a variable that can be used for AVP Origin-State-ID. It needs to increase between connections, so we'll probably just use the date/time of last restart as a replacement variable available in the XML template.

3.) Define a variable that can be used for AVP Accounting-Record-Number. It needs to increment with each request, so we plan to implement a Diameter transaction counter that is available as a replacement variable in the XML template.

Everything else looks relatively straight-forward. The only data element that we see an issue with is

AVP: Service-Parameter-Type(608) l=16 f=VM- vnd=Ericsson val=Originating Location Information (CCN) (8)

In your trace it has a value of GT=xxxxxxx ... and that value would need to be hard coded in the XML template, or if possible use the SGSN MCC-MNC value to detect a roaming location.

Let me know your feedback ... especially with regard to #1 ... if we can use accounting-record-type = EVENT instead of generating both START and STOP requests, that would greatly reduce the time required to implement.

--
Des
NowSMS Support
Farman
New member
Username: Forikfunk

Post Number: 3
Registered: 10-2013
Posted on Tuesday, October 29, 2013 - 07:24 am:   

Hello Des,

My Answers are below:

1) We can use Accounting-Record-Type = EVENT with SCAP-Requested-Action(615) - Direct-Debiting (0). It's ok for us. But if possible, please also implement Start/Stop request.

About Service-Parameter-Type(608) l=16 f=VM- vnd=Ericsson val=Originating Location Information (CCN) (8) . Its VLR address of Subscriber. For testing it's not mandatory. Can I request this value via http and include it to Diameter-Request?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4709
Registered: 08-2008
Posted on Tuesday, October 29, 2013 - 10:33 pm:   

Hi Farman,

It appears that two separate Diameter transactions (start and stop) will not be a problem.

We have created an XML template to generate Diameter requests in a format as close as possible to the trace format that you shared. We will soon be testing that template against an update to our MM9Test utility and correcting any differences.

I think the main issue will be the Originating Location Information. It can certainly be hard coded for testing.

The issue is that while it is common to have access to the VLR as an SMSC, for an MMSC the closest information we tend to get access to is SGSN MCC-MNC or SGSN IP Address. If you can insert information into the HTTP header before the request gets to the MMSC, then we can easily extract that information and include it in the Diameter request. If we need to issue an HTTP request to fetch the information that is more complicated ... not impossible, but requires considerably more thought to determine the best way to implement.

I have received your e-mail and will reply shortly with instructions for opening a direct e-mail channel for additional discussion.


--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4713
Registered: 08-2008
Posted on Thursday, October 31, 2013 - 07:00 pm:   

Hi Farman,

We have updated our Diameter test utility as previously outlined in this thread.

The <diameter> element in the XML template now supports command-code and application-id attributes, so it is no longer restricted to Credit-Control-Request, and can be configured for Accounting-Request instead.

The XML template used for charging can also be configured to send more than one Diameter request (e.g., start and stop) by including multiple <diameter> elements. Note that the second (or third or later) request is sent only if the previous request was successful (Diameter result code 2001).

Replacement variables have been added which are appropriate for use with Origin-State and Accounting-Record-Number AVPs.

We are in the process of adding support for these changes to a future version of the MMSC.

The updated Diameter test/validation utility is at http://www.nowsms.com/download/mm9test.zip

The XML template in that download is still set for Credit-Control-Request.

To generate Accounting-Request instead, it is necessary to manually edit the diameter-credit-control.xml file and replace the content of that file with this:

<diameter name="Accounting-Request" command-code="271" application-id="0">
<avp name="Session-Id" code="263" mandatory="true" type="UTF8String" value="@@Session-Id@@" />
<avp name="Vendor-Specific-Application-Id" code=260" mandatory="true" type="Grouped">
<avp name="Vendor-Id" code="266" mandatory="true" type="Unsigned32" value="193" />
<avp name="Acct-Application-Id" code="259" mandatory="true" type="Unsigned32" value="19302" />
</avp>
<avp name="Origin-Host" code="264" mandatory="true" type="UTF8String" value="@@Config-Origin-Host@@" />
<avp name="Origin-Realm" code="296" mandatory="true" type="UTF8String" value="@@Config-Origin-Realm@@" />
<avp name="Destination-Realm" code="283" mandatory="true" type="UTF8String" value="@@Config-Destination-Realm@@" />
<avp name="Accounting-Record-Number" code="485" mandatory="true" type="Unsigned32" value="@@RequestCounter@@" />
<avp name="Origin-State-Id" code="278" mandatory="true" type="Unsigned32" value="@@ServerStartTime@@" />
<avp name="Event-Timestamp" code="610" vendor="193" mandatory="true" type="Unsigned32" value="@@TimeStamp@@" />
<avp name="Subscription-Id" code="553" vendor="193" mandatory="true" type="Grouped">
<avp name="Subscription-Id-Type" code="555" vendor="193" mandatory="true" type="Unsigned32" value="0" />
<avp name="Subscription-Id-Data" code="554" vendor="193" mandatory="true" type="UTF8String" value="@@Sender@@" />
</avp>
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="16" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="@@Sender@@" />
</avp>
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="17" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="@@Recip@@" />
</avp>
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="0" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="@@Config-Service-Provider-Id@@" />
</avp>
<avp name="Service-Identifier" code="439" mandatory="true" type="Unsigned32" value="@@Config-Service-Identifier@@" omitifblank="true" />
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped" value="@@SGSNMCCMNC@@" omitifblank="true" extensionset="3GPPSGSN">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="8" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="@@SGSNMCCMNC@@" />
</avp>
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="14" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="20" />
</avp>
<avp name="Accounting-Record-Type" code="480" mandatory="true" type="Unsigned32" value="2" />
<avp name="Requested-Service-Unit" code="606" vendor="193" mandatory="true" type="Grouped" value="@@Config-CC-Service-Specific-Units@@" omitifblank="true" >
<avp name="Unit-Type" code="611" vendor="193" mandatory="true" type="Unsigned32" value="2" />
<avp name="Unit-Value" code="612" vendor="193" mandatory="true" type="grouped" >
<avp name="Value-Digits" code="617" vendor="193" mandatory="true" type="Unsigned64" value="@@Config-CC-Service-Specific-Units@@" multiplerecipmultiply="true" />
</avp>
</avp>
</diameter>

<diameter name="Accounting-Request" command-code="271" application-id="0">
<avp name="Session-Id" code="263" mandatory="true" type="UTF8String" value="@@Session-Id@@" />
<avp name="Vendor-Specific-Application-Id" code=260" mandatory="true" type="Grouped">
<avp name="Vendor-Id" code="266" mandatory="true" type="Unsigned32" value="193" />
<avp name="Acct-Application-Id" code="259" mandatory="true" type="Unsigned32" value="19302" />
</avp>
<avp name="Origin-Host" code="264" mandatory="true" type="UTF8String" value="@@Config-Origin-Host@@" />
<avp name="Origin-Realm" code="296" mandatory="true" type="UTF8String" value="@@Config-Origin-Realm@@" />
<avp name="Destination-Realm" code="283" mandatory="true" type="UTF8String" value="@@Config-Destination-Realm@@" />
<avp name="Accounting-Record-Number" code="485" mandatory="true" type="Unsigned32" value="@@RequestCounter@@" />
<avp name="Origin-State-Id" code="278" mandatory="true" type="Unsigned32" value="@@ServerStartTime@@" />
<avp name="Event-Timestamp" code="610" vendor="193" mandatory="true" type="Unsigned32" value="@@TimeStamp@@" />
<avp name="Subscription-Id" code="553" vendor="193" mandatory="true" type="Grouped">
<avp name="Subscription-Id-Type" code="555" vendor="193" mandatory="true" type="Unsigned32" value="0" />
<avp name="Subscription-Id-Data" code="554" vendor="193" mandatory="true" type="UTF8String" value="@@Sender@@" />
</avp>
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="16" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="@@Sender@@" />
</avp>
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="17" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="@@Recip@@" />
</avp>
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="0" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="@@Config-Service-Provider-Id@@" />
</avp>
<avp name="Service-Identifier" code="439" mandatory="true" type="Unsigned32" value="@@Config-Service-Identifier@@" omitifblank="true" />
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped" value="@@SGSNMCCMNC@@" omitifblank="true" extensionset="3GPPSGSN">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="8" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="@@SGSNMCCMNC@@" />
</avp>
<avp name="Service-Parameter-Info" code="607" vendor="193" mandatory="true" type="Grouped">
<avp name="Service-Parameter-Type" code="608" vendor="193" mandatory="true" type="Unsigned32" value="14" />
<avp name="Service-Parameter-Value" code="609" vendor="193" mandatory="true" type="UTF8String" value="20" />
</avp>
<avp name="Accounting-Record-Type" code="480" mandatory="true" type="Unsigned32" value="4" />
<avp name="Used-Service-Unit" code="613" vendor="193" mandatory="true" type="Grouped" value="@@Config-CC-Service-Specific-Units@@" omitifblank="true" >
<avp name="Unit-Type" code="611" vendor="193" mandatory="true" type="Unsigned32" value="2" />
<avp name="Unit-Value" code="612" vendor="193" mandatory="true" type="grouped" >
<avp name="Value-Digits" code="617" vendor="193" mandatory="true" type="Unsigned64" value="@@Config-CC-Service-Specific-Units@@" multiplerecipmultiply="true" />
</avp>
</avp>
</diameter>


This file is attached here:

text/xmlscap1-diameter-credit-control.xml
diameter-credit-control.xml (7.9 k)



Note that the test utility will prompt for parameters that are not used by this modified template.

Service-Context-Id is NOT used.

Service-Identifier and CC-Service-Specific-Units are mapped to equivalent SCAPv1 attributes.

CC-Money and CC-Currency-Code are NOT used

SGSN-MCC-MNC is mapped to Originating Location information ... or edit XML to hard code this value.

Enable the SCAP extension set for the utility to prompt for the Service-Provider-ID value. (SCAP has separate Service-Id and Service-Provider-Id values.)

The end result should be very similar to the trace that you sent me.

Let me know if you have any questions.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4718
Registered: 08-2008
Posted on Monday, November 04, 2013 - 05:09 pm:   

Hi Farman,

A follow-up ... we posted an updated version of NowSMS which supports these MMSC Diameter template enhancements at http://www.nowsms.com/download/nowsms20131031.zip


--
Des
NowSMS Support
timeless
New member
Username: Forikfunk

Post Number: 4
Registered: 10-2013
Posted on Tuesday, November 05, 2013 - 07:03 am:   

Dear Des,
thank you for update. I have another question. Is it possible to continue send MMS if OSC (Online Charging System) return code as Result-Code: DIAMETER_END_USER_NOT_FOUND (5241). In this case we assume that this is postpaid subscriber.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4723
Registered: 08-2008
Posted on Tuesday, November 05, 2013 - 04:22 pm:   

Hi Farman,

I think we can find a way to work with that.

We are looking at adding a result-code-ok attribute to the <diameter> element, so you could add result-code-ok="2001,5241" and either result code value would be considered a success.

What some of our other customers do in this scenario is have an accounting callback that checks if the sender is prepaid, and the callback only requests a Diameter charge if it determines the account is prepaid.

But I do think flexibility on the result code values accepted as success is a good idea, so we will add that.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4732
Registered: 08-2008
Posted on Friday, November 08, 2013 - 07:20 pm:   

Hi Farman,

We updated both the test program and the MMSC to support a result-code-ok attribute to the <diameter> element. By default the expected success result code is 2001. Add result-code-ok="2001,5241" to the <diameter> element and either result code value would be considered a success.

The updated build that includes these MMSC changes is at http://www.nowsms.com/download/nowsms20131107.zip.

--
Des
NowSMS Support

Add Your Message Here, or click here to start a new topic.
Post:
Bold text Italics Underline Create a hyperlink Insert a clipart image
Options: Automatically activate URLs in message
Action: