THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#286 - add_contact_alias doesn't translate address when sending NOTIFY
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Implemented
Additional comments about closing: set_contact_alias() solves the limitation of add_contact_alias()
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=286
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi!
I have been digging a bit in statistics vs counters
Kamailio stats is a wrapper round the sr counters.
They are interchangeable - all counters are listed as statistics and all statistics are listed as counters.
The counters have a bit more functions:
- COnfigurable prefixes
- Descriptions
If I list in-core module stats, some use counters and some use stats.
*** usrloc
location-contacts : 0 (kamailio statistic (no description))
location-expires : 0 (kamailio statistic (no description))
location-users : 0 (kamailio statistic (no description))
registered_users : 0 (kamailio statistic (no description))
USRLOC use kamailio stats without descriptions
The core TCP stats use counters:
*** tcp
con_reset : 0 (total number of TCP_RSTs received on established connections.)
con_timeout : 0 (total number of connections that did timeout (idle for too long).)
connect_failed : 0 (number of failed active connection attempts.)
The output is from kamcmd using a script I wrote.
I would like to convert as much as possible to counters with built-in descriptions.
Would that create problems? Is there any missing functionality if I do that?
At this point it's a bit confusing with two modules using the same core functions,
so at some point we could make sure that the counters module have the same
functions and RPCs as statistics and merge them.
/O
Another year getting slowly to the end, an excellent opportunity to
thank to all old and new friends of Kamailio project, from contributing
code to using it, helping on mailing lists and other places online, or
advertising it across the world!
Merry Christmas and Happy Winter Holidays!
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hi, All!
I had rewrote functions extract_avp and generate_avps of modules
auth_radius, misc_radius and peering, and generate_avps_rad of misc_radius.
Now this modules reading, parsing and creating AVPs for any retrieved from
RADIUS attributes.
modules parsing SIP-AVP (#int#int, str:str, str#int, #int:str) and not
SIP-AVP (#int#int, str:str, str#int, #int:str).
It`s not very well tested, but all my test are passed.
Please review and accept my pull request:
https://github.com/kamailio/kamailio/pull/14
Thanks to Ltd. "Skytel-Systems", Belarus, Minsk and klistrod! It well be
impossible without them! :)
--
With best regards
Dmitry Borisov
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]: Call from 'you(a)kamailio.org'
to 'you(a)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:00xxxxxxxxxx@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
;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.
Hi, I've added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state.
The feature is the same of probing_threshold but it counts the number of successful ping before moving back a destination from 'inactive' to 'active' state.
Hope it could be useful to someone else. I've also edited README file inserting the new parameter.
I've corrected somewhere in the code some misspelled words and changed some variables (I used the same counter for failure and successful requests, these features are mutually exclusive).
Please note: I've developed and tested this feature over release 4.1.6
You can merge this Pull Request by running:
git pull https://github.com/alezzandro/kamailio master
Or you can view, comment on it, or merge it online at:
https://github.com/kamailio/kamailio/pull/12
-- Commit Summary --
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state.
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x2
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x3
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x3
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x5
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x6
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x7
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x8
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x9
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x10
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x10
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x10
* Added support for custom number of successful probing requests before moving a destination from 'inactive' to 'active' state. x11
-- File Changes --
M modules/dispatcher/README (118)
M modules/dispatcher/config.c (7)
M modules/dispatcher/config.h (3)
M modules/dispatcher/dispatch.c (84)
M modules/dispatcher/dispatch.h (7)
M modules/dispatcher/dispatcher.c (17)
M modules/dispatcher/doc/dispatcher_admin.xml (26)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/12.patchhttps://github.com/kamailio/kamailio/pull/12.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/12
Hi,
i noticed a weird behavior in 4.2 branch with this kamailio.cfg (snippet)
#!substdef "!UDP_SIP!udp:MY_IP_ADDRESS:5060!g"
#!substdef "!TCP_SIP!tcp:MY_IP_ADDRESS:5060!g"
listen=UDP_SIP
listen=TCP_SIP
####### Routing Logic ########
route
{
# log the basic info regarding this call
xlog("L_INFO", "$ci|start|recieved $oP request $rm $ou");
.....
}
when clients using TCP send a SUBSCRIBE we get log info that it is a UDP operation.
when we send the first notify we get tcp errors.
for reference, i'm using Bria 4 in testing.
Dec 20 16:49:29 kamailio-05 kamailio[5085]: INFO: <script>: YzYwYWVlOTFiMGU0YmNjM2IyMDA1NmQ4NjdiMGEwZDY|start|recieved UDP request SUBSCRIBE sip:2135@sip.com
Dec 20 16:49:29 kamailio-05 kamailio[5072]: INFO: <script>: received dialog update for sip:2135@sip.com
Dec 20 16:49:29 kamailio-05 kamailio[5072]: INFO: presence [notify.c:1604]: send_notify_request(): NOTIFY sip:user_7z7b6s@sip.com via sip:user_7z7b6s@192.168.16.12:62285;transpop on behalf of sip:2134@sip.com for event dialog
Dec 20 16:49:29 kamailio-05 kamailio[5072]: CRITICAL: <core> [pass_fd.c:157]: send_all(): send on 0 failed: Socket operation on non-socket
Dec 20 16:49:29 kamailio-05 kamailio[5072]: ERROR: <core> [tcp_main.c:2303]: tcpconn_send_put(): failed to get fd(write):Socket operation on non-socket (88)
Dec 20 16:49:29 kamailio-05 kamailio[5072]: ERROR: tm [../../forward.h:227]: msg_send(): tcp_send failed
Dec 20 16:49:29 kamailio-05 kamailio[5072]: ERROR: tm [uac.c:598]: send_prepared_request_impl(): t_uac: Attempt to send to precreated request failed
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/11