Hi Bud, There isn’t currently a config option for this, I’m afraid. The code is all open-source if you’d like to have a go at adding something yourself, though – probably the simplest place to do so would be in Ralf, somewhere like https://github.com/Metaswitch/ralf/blob/dev/src/handlers.cpp#L211, where you can just return 200 OK without doing any further processing if Sprout sends an ‘event’ record type.
Best, Rob From: Bud Asterisk [mailto:[email protected]] Sent: 18 April 2016 21:53 To: Robert Day (projectclearwater.org) <[email protected]> Cc: [email protected] Subject: Re: [Project Clearwater] CTF Rf interface I should have asked earlier is it possible to disable this via config? It generates alot of traffic on the Rx interface when you start adding the the amount of subscribers registered. I am interested in ACR start and stop but simple registration events are not needed at this point. On Mon, Apr 18, 2016 at 10:54 AM, Robert Day (projectclearwater.org<http://projectclearwater.org>) <[email protected]<mailto:[email protected]>> wrote: Hi Bud, Thanks – I understand your question better now. The good news here is that incrementing that part of a Session-Id doesn’t indicate a retransmission – that’s just how we generate a new Session-Id to represent a new session. Your ACA was perfectly acceptable – there’s just a new event (e.g. another REGISTER) a minute later that’s creating a new, different ACR. You can see more information about the format of the Session-Id at https://tools.ietf.org/html/rfc6733#section-8.8 – basically, the recommended value is “<DiameterIdentity>;<high 32 bits of a monotonically increasing 64-bit value>;<low 32 bits of a monotonically increasing 64-bit value>”. So when you see 192.168.1.109;1460692734;1388 and then 192.168.1.109;1460692734;1389, that doesn’t mean it’s a retransmission – it just means we’re sending a new event that’s part of a new session (perhaps triggered by another REGISTER), so we’ve incremented our counter by 1 (so the lowest 32 bits were 1388, and are now 1389) and generated a new Session-Id based on that counter. Hope that helps, Rob From: Bud Asterisk [mailto:[email protected]<mailto:[email protected]>] Sent: 18 April 2016 15:32 To: Robert Day (projectclearwater.org<http://projectclearwater.org>) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [Project Clearwater] CTF Rf interface Robert, Thanks! In the ACR you can see the session ID as 192.168.1.109;1460692734;1388 and then I send the ACA back with the same session ID. CW will in about a minute later send me another session ID this time ending in 1389, then 1390 etc. I believe the number after the ';' is indicating a retransmission of a prior ACR. This keeps on going for days with that number being incremented every minute. This telling me that CW is not liking my ACA. Once it gets an ACA back that makes it happy it will stop sending ACRs on that specific session. I can send you a longer PCAP if you want showing the dialogue but either there is a bug in CW in terms of processing my ACA or there is a bug in my ACA format which is causing CW to reject it and send me an incremented ACR. Bud, [https://ipmcdn.avast.com/images/2016/icons/icon-envelope-open-tick-round-orange-v1.png]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> On Mon, Apr 18, 2016 at 10:22 AM, Robert Day (projectclearwater.org<http://projectclearwater.org>) <[email protected]<mailto:[email protected]>> wrote: Hi Bud, I’ve taken a look at the PCAP trace you’ve sent, and this looks quite normal to me – Ralf sends an Accounting-Request containing billing information, and the CDF sends an Accounting-Answer to acknowledge it. The Accounting-Answer just acknowledges the request (so we don’t need to send a retransmission or fail over, for example) – Ralf doesn’t need to do any processing on the answer, or answer the answer, or otherwise signal acceptance in any way. Could you clarify what you’re expecting to see in this trace that you’re not seeing, or what you’re seeing that you don’t expect? Also, you mention that “CW just keeps sending the same session ID of a ACR but the instance is incremented” – I’m not quite sure what you mean by this, and your PCAP trace only shows one ACR and one ACA (nothing is being resent). Best, Rob From: Clearwater [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Bud Asterisk Sent: 15 April 2016 17:08 To: [email protected]<mailto:[email protected]> Subject: [Project Clearwater] CTF Rf interface Folks, One quick question. Attached is a trace from my CDF connected to my CW-AIO instance on a VM. ACRs are flowing and I am responding with ACA but for some reason CW does not like them. I am getting no error logs of substance from Ralf. Wireshark is not showing my ACA badly formatted. My CDF works with other vendors IMS components. But CW just keeps sending the same session ID of a ACR but the instance is incremented. I believe the CDF is responding correctly. Any insights as to why CW is not accepting it? my format or CW bug? [Image removed by sender.]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
