Hi IMS'ers
I am generating CCR's happily from the ims_charging module (adapted to work standalone with standard userloc module) but have a couple of questions around AVP's supported.
a) I note that in the 3GPP TS 32.299 V12.7.0 specification that table 7.1.0.1, that it indicates Vendor-Id and Vendor-Specific-Application-Id aren't used. But later in section 7.1.16 it indicates that the Vendor-Id should be 10415 and set inside the Vendor-Specific-Application-Id AVP. Should I assume that the table is wrong ? b) The ims_charging_module doesn't seem to put an Auth-Application-Id into the CCR. This is mandatory according to 3GPP and RFC4006. I note that it does appear under the Vendor-Specific-Application-Id - but this doesn't seem right to me?
At this stage I am thinking to add the Auth-Application-Id AVP and also the 3GPP Called-Party-Address AVP. To I submit patches to the development list?
Kind regards Shane
Shane Harrison Senior Software Engineer
Imagination Technologies NZ Limited Level 2 1 Market Grove Lower Hutt, 5010 New Zealand
PO Box 30-449 Lower Hutt, 5040 New Zealand
Phone: +64 4 890-3681 ext 3361
Hello,
On 17/02/15 22:52, Shane Harrison wrote:
Hi IMS'ers
I am generating CCR's happily from the ims_charging module (adapted to work standalone with standard userloc module) but have a couple of questions around AVP's supported.
a) I note that in the 3GPP TS 32.299 V12.7.0 specification that table 7.1.0.1, that it indicates Vendor-Id and Vendor-Specific-Application-Id aren't used. But later in section 7.1.16 it indicates that the Vendor-Id should be 10415 and set inside the Vendor-Specific-Application-Id AVP. Should I assume that the table is wrong ? b) The ims_charging_module doesn't seem to put an Auth-Application-Id into the CCR. This is mandatory according to 3GPP and RFC4006. I note that it does appear under the Vendor-Specific-Application-Id - but this doesn't seem right to me?
At this stage I am thinking to add the Auth-Application-Id AVP and also the 3GPP Called-Party-Address AVP. To I submit patches to the development list?
I am not working with IMS that much, therefore I cannot comment on your remarks about the specks.
Just jumping in to say that the recommended way to submit a patch is a pull request via github project:
- https://github.com/kamailio/kamailio
It allows the other developers to review and make comments. Also, it doesn't get forgotten as it can happen with maling list patches, because sometime is higher traffic and some developers can be in vacation or traveling.
If github is not liked by you for what so ever reason, patching to mailing list is the alternative.
Cheers, Daniel
+1 Daniel.
Shane, you are welcome to submit patch as suggested by Daniel. I will have a look at the spec and what we have impl and get back to you as soon as I find a gap.
cheers jason
On Wed, Feb 18, 2015 at 1:16 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
On 17/02/15 22:52, Shane Harrison wrote:
Hi IMS'ers
I am generating CCR's happily from the ims_charging module (adapted to
work standalone with standard userloc module) but have a couple of questions around AVP's supported.
a) I note that in the 3GPP TS 32.299 V12.7.0 specification that table
7.1.0.1, that it indicates Vendor-Id and Vendor-Specific-Application-Id aren't used. But later in section 7.1.16 it indicates that the Vendor-Id should be 10415 and set inside the Vendor-Specific-Application-Id AVP. Should I assume that the table is wrong ?
b) The ims_charging_module doesn't seem to put an Auth-Application-Id
into the CCR. This is mandatory according to 3GPP and RFC4006. I note that it does appear under the Vendor-Specific-Application-Id - but this doesn't seem right to me?
At this stage I am thinking to add the Auth-Application-Id AVP and also
the 3GPP Called-Party-Address AVP. To I submit patches to the development list?
I am not working with IMS that much, therefore I cannot comment on your remarks about the specks.
Just jumping in to say that the recommended way to submit a patch is a pull request via github project:
It allows the other developers to review and make comments. Also, it doesn't get forgotten as it can happen with maling list patches, because sometime is higher traffic and some developers can be in vacation or traveling.
If github is not liked by you for what so ever reason, patching to mailing list is the alternative.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Jason Penton -
Shane Harrison