On 07/01/15 09:21, Muhammad Shahzad wrote:
> Finally i have found the problem and fixed it. I was creating new
> transaction for initial invite request too early (immediately after
> authentication and checking for re-transmits of initial requests), e.g.
>
> ...
> # request with no Username in RURI
> if ($rU==$null) {
> sl_send_reply("484","Address Incomplete");
> exit;
> } else {
> t_newtran();
> ...
>
> The interesting thing is that it was causing problem only for
> accounting events and everything else was working perfectly fine. A
> single line of code that wasted my full 2 weeks. :-(
>
Good that you sorted out.
If you create the transaction and set flags later, then you need to sync
back with transaction via:
-
http://kamailio.org/docs/modules/stable/modules/tmx.html#tmx.f.t_flush_flags
Cheers,
Daniel
>
>
>
> On Tue, Jan 6, 2015 at 7:00 AM, Muhammad Shahzad
> <shaherya...@gmail.com <mailto:shaherya...@gmail.com>> wrote:
>
> OK, finally back at office after holidays.
>
> I have done extensive testing of various kamailio revisions
> (backwards up to November) and it seems that problem is not
> related to any change in native code. It is somehow related to
> kamailio.cfg, which is very strange, since only changes in
> previous deployment and currently deployment of cfg file are
> related to dialog module (there are a lot of them, e.g. dialog
> timeout added, dialog profile setup, several dialog variables
> added and set, dialog start, end and failure event routes
> configured etc. etc.). However, there is no change related to acc
> setup and its configuration is still compatible with default
> kamailio.cfg. Does this make any sense to you?
>
> Looking at debug level 3 kamailio logs and mysql query logs, there
> is no attempt to insert data in acc table at all except for BYE
> message.
>
> Today i will try to compare working cfg file (back from
> mid-November, which inserts all ACC event records) with current
> cfg file (which only inserts BYE event records) and see if i can
> find that configuration changes that are causing this behavior.
>
> Thank you.
>
>
>
> On Tue, Dec 30, 2014 at 2:56 AM, Muhammad Shahzad
> <shaherya...@gmail.com <mailto:shaherya...@gmail.com>> wrote:
>
> OK, i will run some tests and get back to you.
>
> Thank you.
>
> On Sat, Dec 27, 2014 at 10:22 PM, Daniel-Constantin Mierla
> <mico...@gmail.com <mailto:mico...@gmail.com>> wrote:
>
> I did a basic test (acc with parameters as in default
> kamailio.cfg) and invite is accounted ok. I used master
> branch, but there is no difference with acc from 4.2.
>
> Can you run with debug=3 and see all the log messages,
> maybe you get a further hint from there.
>
> Also, you can try with clone_msg parameter set to 0 - it
> is one of latest additions to acc module, just be sure you
> don't have some corner case situation...
>
> Cheers,
> Daniel
>
>
> On 24/12/14 15:23, Muhammad Shahzad wrote:
>> After upgrade to version 4.2.1-a2aa22, result is same.
>>
>> Thank you.
>>
>>
>>
>> On Wed, Dec 24, 2014 at 1:32 PM, Muhammad Shahzad
>> <shaherya...@gmail.com <mailto:shaherya...@gmail.com>> wrote:
>>
>> Looking at log level 3 logs, i see when INVITE has
>> been authenticated ACC module creates the dialog,
>>
>> --
>> DEBUG: acc [acc_cdr.c:726]: cdr_on_create(): dialog
>> '0xa5936e70' created!
>> --
>>
>> But acc callback is only triggered AFTER 200 OK of
>> BYE request,
>>
>> --
>> DEBUG: acc [acc_logic.c:644]: tmcb_func(): acc
>> callback called for t(0xa591d840) event type 2, reply
>> code 200
>> --
>>
>> Between these two log lines there is no log from acc
>> module.
>>
>> Thank you.
>>
>>
>>
>> On Wed, Dec 24, 2014 at 11:04 AM, Muhammad Shahzad
>> <shaherya...@gmail.com
>> <mailto:shaherya...@gmail.com>> wrote:
>>
>> See attached SIP trace.
>>
>> Note, i have obfuscated source and destination
>> number and IPs etc. due to privacy reasons.
>>
>> Thank you.
>>
>>
>>
>> On Wed, Dec 24, 2014 at 10:36 AM, Muhammad
>> Shahzad <shaherya...@gmail.com
>> <mailto:shaherya...@gmail.com>> wrote:
>>
>> OK, i will upgrade my staging server and do
>> some testing.
>>
>> The acc module does not post records
>> anywhere, neither syslog nor db. The problem
>> is happening to all calls (not any specific
>> call).
>>
>> Regarding the FROM header, the only change
>> done is to add "+" to callerid (after
>> replacing 00 if present), this is extensively
>> tested feature in past 6 months.
>>
>> I have analyzed all the SIP packets in call
>> using ngrep, they all seem perfectly fine.
>> All packets (request + reply) are correctly
>> received and forwarded by kamailio.
>> Unfortunately i deleted them and need to get
>> new trace. I will send it to you in the
>> afternoon.
>>
>> Thank you.
>>
>>
>>
>> On Tue, Dec 23, 2014 at 10:10 PM,
>> Daniel-Constantin Mierla <mico...@gmail.com
>> <mailto:mico...@gmail.com>> wrote:
>>
>> Hello,
>>
>> you can try with latest git branch 4.2
>> and see the results.
>>
>> At a quick look between the version you
>> reported to work and the new version you
>> run, I couldn't spot a commit that could
>> be the reason.
>>
>> Do you get the acc record in syslog for
>> INVITE?
>>
>> How do you set the values for replacing
>> From header? If you load from database,
>> be sure the values are valid. I see the
>> uac module complains about restoring
>> operation. It might be the reason for the
>> issues -- config could be ok, but the
>> subscriber data wrong.
>>
>> You should save the traffic for a while
>> and check the packets for missing records
>> -- you can use tools such as tcpdump,
>> sipgrep, ngrep to store the traffic in a
>> file for later analysis. When you find a
>> missing record, search in the file with
>> the sip traffic and see if something is
>> broken there.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 23/12/14 21:45, Muhammad Shahzad wrote:
>>> Hi,
>>>
>>> About 3 weeks ago i upgraded one of my
>>> production server with latest stable
>>> kamailio version 4.2.1-fad00a. Now i am
>>> getting a lot of complaints about
>>> missing CDR events in ACC table. I
>>> observe following problems,
>>>
>>> 1. There are only BYE records in acc
>>> table, no record for INVITE or ACK.
>>> 2. In kamailio logs when ACK is received
>>> against 200 OK response for INVITE, i
>>> see following errors,
>>>
>>> --
>>> ERROR: <core> [parser/parse_from.c:113]:
>>> parse_from_uri(): failed to parse From uri
>>> ERROR: pv [pv_core.c:434]:
>>> pv_get_xto_attr(): cannot parse From URI
>>> NOTICE: <script>:
>>> [udp:<null>@1.0.0.127:5060
>>> <http://1.0.0.127:5060>]: Call from
>>> 'y...@kamailio.org
>>> <mailto:y...@kamailio.org>' to
>>> 'y...@kamailio.org
>>> <mailto:y...@kamailio.org>' has been
>>> hanged up by '<null>' at '1419364717.255484'
>>> --
>>>
>>> Of course all these errors are bogus, I
>>> have checked all headers in ACK (not
>>> just FROM header), they all seem
>>> perfectly fine and valid.
>>>
>>> 3. Then the dialog times out,
>>>
>>> --
>>> WARNING: dialog [dlg_handlers.c:1440]:
>>> dlg_ontimeout(): timeout for dlg with
>>> CallID
>>> '6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9'
>>> and tags
>>> '1D3ECD34F5731AB845BA3064AC95BB2D'
>>>
>>> '7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4'
>>>
>>> --
>>>
>>> 4. Any further sequential requests
>>> complain about "unable to find dialog", e.g.
>>>
>>> --
>>> NOTICE: <script>: Sequencial 'BYE'
>>> request received from caller
>>> ERROR: uac [replace.c:591]:
>>> restore_uri(): new URI [] shorter than
>>> old URI [sip:00xxxxxxx...@sip.domain.com
>>> <mailto:sip%3a00xxxxxxx...@sip.domain.com>]
>>> WARNING: dialog [dlg_handlers.c:1174]:
>>> dlg_onroute(): unable to find dialog for
>>> BYE with route param '5ae1.d595'
>>> [7845:22877]
>>> --
>>>
>>> 5. However the acc record for BYE is
>>> written to db and log file,
>>>
>>> --
>>> NOTICE: acc [acc.c:318]:
>>> acc_log_request(): ACC: transaction
>>> answered:
>>>
>>> timestamp=1419364760;method=BYE;from_tag=7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4;to_tag=1D3ECD34F5731AB845BA3064AC95BB2D;call_id=6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9;code=200;reason=OK;src_user=00xxxxxxxxxx;src_domain=sip.domain.com
>>>
>>> <http://sip.domain.com>;src_ip=xx.xx.xx.xx;dst_ouser=+1xxxxxxxxxx;dst_user=1xxxxxxxxxx;dst_domain=yy.yy.yy.yy
>>> --
>>>
>>>
>>> The same config was working fine with
>>> older version 4.2.0-97cab8. The kamailio
>>> config i am using is pretty much standard,
>>>
>>> --
>>> #!define FLT_ACC 1
>>> #!define FLT_ACCMISSED 2
>>> #!define FLT_ACCFAILED 3
>>> #!define FLT_DLG 4
>>>
>>> ...
>>>
>>> modparam("acc", "early_media", 1)
>>> modparam("acc", "report_ack", 1)
>>> modparam("acc", "report_cancels", 1)
>>> modparam("acc", "detect_direction", 1)
>>> modparam("acc", "log_flag", FLT_ACC)
>>> modparam("acc", "log_missed_flag",
>>> FLT_ACCMISSED)
>>> modparam("acc",
>>> "failed_transaction_flag", FLT_ACCFAILED)
>>> # log to db
>>> modparam("acc", "db_flag", FLT_ACC)
>>> modparam("acc", "db_missed_flag",
>>> FLT_ACCMISSED)
>>> modparam("acc", "db_url", "DBURL")
>>>
>>> ...
>>>
>>> request_route {
>>> # per request initial checks
>>> route(REQINIT);
>>>
>>> # NAT detection
>>> route(NATDETECT);
>>>
>>> # handle requests within SIP dialogs
>>> route(WITHINDLG);
>>>
>>> # CANCEL processing
>>> if (is_method("CANCEL")) {
>>> if (t_check_trans()) {
>>> t_relay();
>>> };
>>> exit;
>>> };
>>>
>>> #### only initial requests (no To
>>> tag) ####
>>> t_check_trans();
>>>
>>> ....
>>>
>>> # account only INVITEs
>>> if (is_method("INVITE")) {
>>> setflag(FLT_DLG); # create dialog
>>> setflag(FLT_ACC); # do accounting
>>> setflag(FLT_ACCFAILED); # ...
>>> even if the transaction fails
>>>
>>> $avp(dlg_timeout) = 60;
>>> dlg_manage();
>>> ....
>>>
>>> }
>>>
>>> --
>>>
>>> Any ideas why its happening? Since it is
>>> 3 weeks old so may be problem has
>>> already been spotted and fixed by
>>> someone else. Otherwise let me know how
>>> can i provide more info to help fix this
>>> issue.
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-...@lists.sip-router.org
>>> <mailto:sr-...@lists.sip-router.org>
>>>
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>> --
>> Daniel-Constantin Mierla
>> http://twitter.com/#!/miconda
>> <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio
>> (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> <mailto:sr-users@lists.sip-router.org>
>>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>>
>>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
> http://www.linkedin.com/in/miconda
>
>
>
>
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
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
