Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

BTW, Frederico, you will see the AVP is marked as vendor-specific already... which is why wireshark will not decode... Trace some big vendor's diameter interfaces and you will see plenty of non-parseable avps in wireshark traces ;) --- You are receiving this because you commented. Reply to this

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Closed #659. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/659#event-703256058___ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

I've added a mod-param version for now and checked-in to master. When I find some time to dig through specs, I will add the std version. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/659#issuecomment

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Frederico, the problem is that the code is already in . there could be other ppl using it, so I think it would be unfair to just remove it. We have 2 solutions here: 1. move to a modparam. 2. move it to a vendor-specific AVP Finally, we will need to find someone who has time/priority to get t

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Sorry if i insist on the point...but really i do not see the point in leaving such AVP. To me is sufficient a feedback like "Our HSS is caring about this AVP, because we have a custom HSS thatetc...etc". I will close the PR or add a modparam and that's ok. This way we can for sure have a fal

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

If you introduce a nod parameters, then I can step in and merge. If someone needs old behaviour, nothing is lost. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/659#issuecomment-228319176_

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Still nothing? --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/659#issuecomment-228311665___ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-r

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Apologies Frederico, I've been swamped. Will take a look today --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/659#issuecomment-227392322___ sr-dev mailing lis

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Eventually, if really needed, i can try to find some time to modify the Pull Request in order to introduce a modparam. The point is that, as far as i understand, the AVP does not follow any (known to me at least) 3gpp or RFC specs...so is pointless to add it as it is, if not used against a "cust

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Any comment by @jaybeepee, @richardgood or @ngvoice? Eventually can be made optional with a modparam instead of complete remove if someone still finds it useful for some cases. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Any feedback regarding this ? --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/659#issuecomment-226109633___ sr-dev mailing list sr-dev@lists.sip-router.org htt

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

yup, checking On Tue, 7 Jun 2016 at 09:20 Daniel-Constantin Mierla < notificati...@github.com> wrote: > I guess @jaybeepee , @richardgood > or @ngvoice > want to check before merging. > > — > > > You are r

Re: [sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

I guess @jaybeepee, @richardgood or @ngvoice want to check before merging. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/659#issuecomment-224200204__

[sr-dev] [kamailio/kamailio] ims_registrar_scscf: Remove buggy AVP from SAR (#659)

Remove buggy function to add "Call-ID" AVP which actually doesn't exists on SAR Diameter Message According to TS129.229, it actually exists "Call-ID-Sip-Header" AVP witch code 643 which is grouped into "Subscription-Info" AVP. According to the same TS, this AVP is used for restoration procedure. Yo