Even though your second record says that it is Sip-Method = Bye, it really is ACK. The provided sip_dictionary does not match what SER is sending.

Sip_dictionary says:

VALUE Sip-Method Other 0 VALUE Sip-Method Invite 1 VALUE Sip-Method Cancel 2 VALUE Sip-Method Ack 3 VALUE Sip-Method Bye 4

But SER is actually using (msg_parser.h):

enum request_method { METHOD_UNDEF=0, METHOD_INVITE=1, METHOD_CANCEL=2, METHOD_ACK=4, METHOD_BYE=8, METHOD_OTHER=16 };

Notice that 4 in the dictionary is Bye, but in msg_parser.h it is Ack. Also notice that you receive a 3rd RADIUS accounting message with Sip-Method = 8. That is the real BYE. So change sip_dictionary to:

VALUE Sip-Method Undefined 0 VALUE Sip-Method Invite 1 VALUE Sip-Method Cancel 2 VALUE Sip-Method Ack 4 VALUE Sip-Method Bye 8 VALUE Sip-Method Other 16

If you want to eliminate the ACK radius records add this to ser.cfg:

modparam("acc", "report_ack", 0)

I have yet to see a situation where the ACK record is different from than the INVITE, other than the Sip-method type. I'm puzzled as to why they send it.

Hope that helps.

- Robert Liao

----------------------------------------- Jan Janak writes:

Is Sip-Method set to ACK in one of the start records ?

Jan.

NO.

I have two consecutive starts with: Sip-Method = Invite and Sip-Method = Bye

and one stop with Sip-Method = 8

Razvan Radu

On 06-10 16:31, SER Users wrote:

...

hello,

I have ser configured with radius accounting and for each call I get two Start packets and one Stop packet.

Is this the correct behaviour or I have miss-configured something ? The only difference between the two Start Packets is the "Sip-Method" attribute which in one is "Invite" and in the other one is "Bye"

In my configuration I have:

... modparam("acc", "radius_flag", 2) modparam("acc", "radius_missed_flag", 3) ... setflag(2); if (!t_relay()) { sl_reply_error(); }; ...

thanks, Razvan Radu

---

Serusers mailing list Serusers at iptel.org http://lists.iptel.org/mailman/listinfo/serusers