Re: [SR-Users] 408 callee hangup problem
What is the 408 in response to? A reinvite? Some other in-dialog request? You really need a complete SIP packet capture to figure that one out. kamai...@aaronlux.com wrote: Both callee and caller successfully establish 2-way audio however callee client disconnects with '408 NO_USER_RESPONSE ' after ~60 seconds. I'm totally stumped on this problem so any troubleshooting ideas would be appreciated. Regards, Aaron Debug Logs: http://pastebin.com/9Rw7zSQ0 ___ 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 -- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com___ 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
[SR-Users] dialog stats reported by app_perl
Hello, I am using kamailio 4.0. I am experimenting with module app_perl. Actually, I am not using it, I am just loading it because it solves this problem when loading snmpstats: /usr/lib/libnetsnmpagent.so.10: undefined symbol: boot_DynaLoader However, before using app_perl i was seeing this: # kamctl fifo get_statistics dialog active_dialogs dialog:active_dialogs = 1 But with app_perl loaded, I see this: # kamctl fifo get_statistics dialog active_dialogs app_perl:active_dialogs = 1 So, is app_perl intercepting stats requests that should be handled by module dialog? Is this expected? And, is there any performance penalty on having this handled by perl? Regards, Takeshi ___ 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
Re: [SR-Users] dialog stats reported by app_perl
Hello, probably this is because app_perl needs to make all symbols available, to be seen by the interpreter. Can you try to load dialog module before app_perl, or the other way around? I will look for a fix anyhow, just wanted to see if the order matters. Cheers, Daniel On 11/6/13 10:42 AM, mayamatakeshi wrote: Hello, I am using kamailio 4.0. I am experimenting with module app_perl. Actually, I am not using it, I am just loading it because it solves this problem when loading snmpstats: /usr/lib/libnetsnmpagent.so.10: undefined symbol: boot_DynaLoader However, before using app_perl i was seeing this: # kamctl fifo get_statistics dialog active_dialogs dialog:active_dialogs = 1 But with app_perl loaded, I see this: # kamctl fifo get_statistics dialog active_dialogs app_perl:active_dialogs = 1 So, is app_perl intercepting stats requests that should be handled by module dialog? Is this expected? And, is there any performance penalty on having this handled by perl? Regards, Takeshi ___ 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 -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - ___ 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
Re: [SR-Users] dispatcher: ds_options_callback, Setting the state failed
Hello, you message is not clear for me ... see some comments inline. On 11/5/13 2:22 PM, Seudin Kasumovic wrote: Hi, Test configuration uses OPTION for ping method. In log below host 198.51.100.68 probed first but reply come latter then 192.0.2.4. Seams that only last probed uri tried for setting state other hosts. Are you saying that only the state for the last probed uri is updated? Also, DEBUG log is broken. (kamailio version: kamailio 4.1.0-pre1 (i386/linux)). What is broken with it? More details will help seeing the issue, dry messages don't help that much. Cheers, Daniel Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: dispatcher [dispatch.c:2420]: ds_check_timer(): probing set #28, URI sip:198.51.100.68:5060 http://198.51.100.68:5060 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:243]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=sip:172.16.23.130 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:182]: dlg2hash(): DEBUG: dlg2hash: 33871 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:345]: t_uac_prepare(): executing event_route[tm:local-request] Nov 5 12:48:01 localhost kamailio[23729]: INFO: script: 1280:tm:local-request OPTIONS sip:198.51.100.68:5060 http://198.51.100.68:5060 --ID=77db7ea0-23729@172.16.23.5 mailto:77db7ea0-23729@172.16.23.5 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:410]: t_uac_prepare(): apply new updates to sip msg Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: dispatcher [dispatch.c:2420]: ds_check_timer(): probing set #0, URI sip:192.0.2.4:5090 http://192.0.2.4:5090 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:243]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=sip:172.16.23.130 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:182]: dlg2hash(): DEBUG: dlg2hash: 33872 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:345]: t_uac_prepare(): executing event_route[tm:local-request] Nov 5 12:48:01 localhost kamailio[23729]: INFO: script: 1280:tm:local-request OPTIONS sip:192.0.2.4:5090 http://192.0.2.4:5090 --ID=77db7ea1-23729@172.16.23.5 mailto:77db7ea1-23729@172.16.23.5 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=54 global id=53 T start=(nil) Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 33871 label 0 branch 0 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_lookup.c:1003]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0xb492a8a8)! Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=54 global id=54 T end=0xb492a8a8 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:2205]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0) Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:1309]: t_should_relay_response(): - T_code=0, new_code=200 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:2085]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:2122]: local_reply(): DEBUG: local transaction completed Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0xb492a8a8, callback type 1024, id 0 entered Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: dispatcher [dispatch.c:2359]: ds_options_callback(): OPTIONS-Request was finished with code 200 (to 192.0.2.4:5090 http://192.0.2.4:5090 Nov 5 12:48:01 localhost kamailio[23725]: ERROR: dispatcher [dispatch.c:2372]: ds_options_callback(): Setting the state failed (192.0.2.4:5090 http://192.0.2.4:5090 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:1667]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=50 global id=49 T start=(nil) Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 33872 label 0 branch 0 Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_lookup.c:1003]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0xb492c918)! Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=50 global id=50 T end=0xb492c918 Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_reply.c:2205]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0) Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_reply.c:1309]: t_should_relay_response(): - T_code=0, new_code=200 Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_reply.c:2085]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0 Nov 5 12:48:01 localhost kamailio[23726]:
Re: [SR-Users] dialog stats reported by app_perl
Daniel, thanks. Loading dialog (and usrloc which I just realized was also affected) before app_perl solved the issue. Regards, Takeshi On Wed, Nov 6, 2013 at 8:33 PM, Daniel-Constantin Mierla mico...@gmail.comwrote: Hello, probably this is because app_perl needs to make all symbols available, to be seen by the interpreter. Can you try to load dialog module before app_perl, or the other way around? I will look for a fix anyhow, just wanted to see if the order matters. Cheers, Daniel On 11/6/13 10:42 AM, mayamatakeshi wrote: Hello, I am using kamailio 4.0. I am experimenting with module app_perl. Actually, I am not using it, I am just loading it because it solves this problem when loading snmpstats: /usr/lib/libnetsnmpagent.so.10: undefined symbol: boot_DynaLoader However, before using app_perl i was seeing this: # kamctl fifo get_statistics dialog active_dialogs dialog:active_dialogs = 1 But with app_perl loaded, I see this: # kamctl fifo get_statistics dialog active_dialogs app_perl:active_dialogs = 1 So, is app_perl intercepting stats requests that should be handled by module dialog? Is this expected? And, is there any performance penalty on having this handled by perl? Regards, Takeshi ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - ___ 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 ___ 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
Re: [SR-Users] use append_hf() and remove_hf() on the same message
Hello, On 11/5/13 4:49 PM, Camille Oudot wrote: Le Tue, 5 Nov 2013 14:53:34 +0100, Daniel-Constantin Mierla mico...@gmail.com a écrit : Even if the header is not present, insert/append_hf() should not fail Ok I assumed wrong. The issue looks trickier: I've made tests that go OK or KO depending on a harmless looking cfg change. In the KO situation, a Path header is set depending on a !ifdef directive + if condition, while in the OK case, it's inserted without condition. After the Path hdr insertion, three other headers are appended. In the KO log, on line 3508, there are only three append_hf while in the OK log, there are four (line 3408). The network traces show that the Require header is not inserted as requested in the cfg. Update: adding a dummy xlog line on line 22 of kamailio.ko.cfg makes it work: the Require header is inserted but the log line is not printed. What defines you set for each of the cases? I see there is an else left open inside the #!ifdef, which ends up in getting an append_hf() if the define id is set. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - ___ 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
[SR-Users] Mitigation of unavailable rtpproxy
Hello, (Sorry for cross-posting to -users and -dev; not really sure where this post belongs most.) A few days ago, I ran into an issue with a Kamailio server being somewhat unresponsive, during moderate call volume, on account of a down rtpproxy--the only rtpproxy in the set. This is rtpproxy classic, not ngcp-mediaproxy-ng. Rtpproxy was not actually engaged on any of the initial INVITEs going through the server; the server is configured to invoke it conditionally based on a setting, and the setting was not set for any endpoints. rtpproxy_manage() was never called. However, I call unforce_rtp_proxy() unconditionally in my config when handling CANCELs, reasoning that it can't do any harm if rtpproxy_manage() was not called before[1]. Nevertheless, it seemed to be the case that this situation was clogging up SIP worker threads, because some SIP messages were definitely dropped. Periodic log messages about inability to reach the rtpproxy were echoed as well. This problem cleared up almost immediately when the rtpproxy instance was restored into service. This raised some questions in my mind about the relationship between rtpproxy management and SIP worker thread utilisation. I assume it was my indiscriminate unforce_rtp_proxy() calls that were actually clogging up the worker threads, right? If so, why? I figured that in the unforce_rtp_proxy() case, the rtpproxy module simply sends fire-and-forget UDP messages down the UDP control socket without any sort of blocking for acknowledgement, since in this case the call must be released on the rtpproxy side without doing any rewriting of SDP on the Kamailio side (unlike in the case where rtpproxy is engaged). Thus, there should be no need to wait for ports to substitute into the message. Or is the same response-wait mechanism used regardless, even in the unforce_rtp_proxy() case, for programmatic reasons? More broadly, is there any way that this scenario can be prevented? In other words, is there a way to work around an outage of all rtpproxies in the set without tying up workers, or at least tying them up less severely? Thanks! -- Alex [1] Is this a reasonable assumption? The reason I do this is that I don't see a way to find out if rtpproxy was engaged from the body of a CANCEL message. I do check for a ;proxy_media RR parameter when handling BYEs, but since a CANCEL is not an in-dialog request, I'm not sure what to do except to call unforce_rtp_proxy()/rtpproxy_manage() indiscriminately, without resorting to storing state in htable or other complications I don't want. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ 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
Re: [SR-Users] use append_hf() and remove_hf() on the same message
Le Wed, 6 Nov 2013 12:48:47 +0100,
Daniel-Constantin Mierla mico...@gmail.com a écrit :
What defines you set for each of the cases? I see there is an else
left open inside the #!ifdef, which ends up in getting an append_hf()
if the define id is set.
Hello Daniel,
thanks, you figured it right: the WITH_NAT define was set. I changed the
pcscf cfg example and somehow misread the #!ifdef/#!else and if/else
logic.
I changed the config back to
#!ifdef WITH_NAT
if (...) {
} else
#!endif
append_hf(Path: sip:term@ +
NETWORK_INTERNAL_IP_S+:+SIP_INTERNAL_PORT+;lr\r\n);
as it was intended in the first place, and everything went back to
normal.
Thanks
--
Camlle
___
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
Re: [SR-Users] Mitigation of unavailable rtpproxy
Hello, there are some parameters to control the timeout+retries for waiting a reply from rtpproxy: http://kamailio.org/docs/modules/stable/modules/rtpproxy.html#idp15243344 Looking it the code, it seems the value for timeout parameter is sec, but could be easily made miliseconds, because the function used inside is poll() which takes timeout as milisec. Cheers, Daniel On 11/6/13 2:05 PM, Alex Balashov wrote: Hello, (Sorry for cross-posting to -users and -dev; not really sure where this post belongs most.) A few days ago, I ran into an issue with a Kamailio server being somewhat unresponsive, during moderate call volume, on account of a down rtpproxy--the only rtpproxy in the set. This is rtpproxy classic, not ngcp-mediaproxy-ng. Rtpproxy was not actually engaged on any of the initial INVITEs going through the server; the server is configured to invoke it conditionally based on a setting, and the setting was not set for any endpoints. rtpproxy_manage() was never called. However, I call unforce_rtp_proxy() unconditionally in my config when handling CANCELs, reasoning that it can't do any harm if rtpproxy_manage() was not called before[1]. Nevertheless, it seemed to be the case that this situation was clogging up SIP worker threads, because some SIP messages were definitely dropped. Periodic log messages about inability to reach the rtpproxy were echoed as well. This problem cleared up almost immediately when the rtpproxy instance was restored into service. This raised some questions in my mind about the relationship between rtpproxy management and SIP worker thread utilisation. I assume it was my indiscriminate unforce_rtp_proxy() calls that were actually clogging up the worker threads, right? If so, why? I figured that in the unforce_rtp_proxy() case, the rtpproxy module simply sends fire-and-forget UDP messages down the UDP control socket without any sort of blocking for acknowledgement, since in this case the call must be released on the rtpproxy side without doing any rewriting of SDP on the Kamailio side (unlike in the case where rtpproxy is engaged). Thus, there should be no need to wait for ports to substitute into the message. Or is the same response-wait mechanism used regardless, even in the unforce_rtp_proxy() case, for programmatic reasons? More broadly, is there any way that this scenario can be prevented? In other words, is there a way to work around an outage of all rtpproxies in the set without tying up workers, or at least tying them up less severely? Thanks! -- Alex [1] Is this a reasonable assumption? The reason I do this is that I don't see a way to find out if rtpproxy was engaged from the body of a CANCEL message. I do check for a ;proxy_media RR parameter when handling BYEs, but since a CANCEL is not an in-dialog request, I'm not sure what to do except to call unforce_rtp_proxy()/rtpproxy_manage() indiscriminately, without resorting to storing state in htable or other complications I don't want. -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - ___ 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
Re: [SR-Users] dispatcher: ds_options_callback, Setting the state failed
Hi, see comments inline. On Wed, Nov 6, 2013 at 12:35 PM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, you message is not clear for me ... see some comments inline. On 11/5/13 2:22 PM, Seudin Kasumovic wrote: Hi, Test configuration uses OPTION for ping method. In log below host 198.51.100.68 probed first but reply come latter then 192.0.2.4. Seams that only last probed uri tried for setting state other hosts. Are you saying that only the state for the last probed uri is updated? Yes. Also, DEBUG log is broken. (kamailio version: kamailio 4.1.0-pre1 (i386/linux)). What is broken with it? More details will help seeing the issue, dry messages don't help that much. Log is produced with debug=3 for tm and dispatcher module, I tried with debug=5 but not get more verbose then posted logs. Debug output of these lines are not complete when update failed (cut off after ''): DEBUG: dispatcher [dispatch.c:2359]: ds_options_callback(): OPTIONS-Request was finished with code 200 (to 192.0.2.4:5090 ERROR: dispatcher [dispatch.c:2372]: ds_options_callback(): Setting the state failed (192.0.2.4:5090 Regards, Seudin Cheers, Daniel Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: dispatcher [dispatch.c:2420]: ds_check_timer(): probing set #28, URI sip: 198.51.100.68:5060 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:243]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=sip:172.16.23.130 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:182]: dlg2hash(): DEBUG: dlg2hash: 33871 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:345]: t_uac_prepare(): executing event_route[tm:local-request] Nov 5 12:48:01 localhost kamailio[23729]: INFO: script: 1280:tm:local-request OPTIONS sip:198.51.100.68:5060 --ID= 77db7ea0-23729@172.16.23.5 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:410]: t_uac_prepare(): apply new updates to sip msg Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: dispatcher [dispatch.c:2420]: ds_check_timer(): probing set #0, URI sip: 192.0.2.4:5090 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:243]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=sip:172.16.23.130 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:182]: dlg2hash(): DEBUG: dlg2hash: 33872 Nov 5 12:48:01 localhost kamailio[23729]: DEBUG: tm [uac.c:345]: t_uac_prepare(): executing event_route[tm:local-request] Nov 5 12:48:01 localhost kamailio[23729]: INFO: script: 1280:tm:local-request OPTIONS sip:192.0.2.4:5090 --ID= 77db7ea1-23729@172.16.23.5 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=54 global id=53 T start=(nil) Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 33871 label 0 branch 0 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_lookup.c:1003]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0xb492a8a8)! Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=54 global id=54 T end=0xb492a8a8 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:2205]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0) Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:1309]: t_should_relay_response(): - T_code=0, new_code=200 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:2085]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:2122]: local_reply(): DEBUG: local transaction completed Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0xb492a8a8, callback type 1024, id 0 entered Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: dispatcher [dispatch.c:2359]: ds_options_callback(): OPTIONS-Request was finished with code 200 (to 192.0.2.4:5090 Nov 5 12:48:01 localhost kamailio[23725]: ERROR: dispatcher [dispatch.c:2372]: ds_options_callback(): Setting the state failed ( 192.0.2.4:5090 Nov 5 12:48:01 localhost kamailio[23725]: DEBUG: tm [t_reply.c:1667]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=50 global id=49 T start=(nil) Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 33872 label 0 branch 0 Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_lookup.c:1003]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0xb492c918)! Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=50 global id=50 T end=0xb492c918 Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm
Re: [SR-Users] Mitigation of unavailable rtpproxy
On 11/06/2013 08:45 AM, Daniel-Constantin Mierla wrote: there are some parameters to control the timeout+retries for waiting a reply from rtpproxy: http://kamailio.org/docs/modules/stable/modules/rtpproxy.html#idp15243344 Looking it the code, it seems the value for timeout parameter is sec, but could be easily made miliseconds, because the function used inside is poll() which takes timeout as milisec. Thank you, Daniel. 1. So, am I right to assume that the unforce_rtp_proxy() call waits for timeout and blocks the worker while doing so? 2. Is there any harm in calling unforce_rtp_proxy() for Call-IDs rtpproxy doesn't know about? is there a 'better' best practice for handling CANCELs where it is unknown whether rtpproxy was engaged on the initial call (because it is an option, nat_uac_detect, etc)? -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ 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
[SR-Users] Google search
Hi guys, this happens to me all the time: when I search for documentation about a specific Kamailio module on Google, I always land on outdated entries usually from Kamailio 1.6.x. Although this seems trivial and I could simply update the URL to the current version of Kamailio, this may be not so obvious for new users and they may end up reading expired documentation and/or implementing non-optimal solutions to their problems. is there a way to only allow indexation of the last documentation? Something like removing the version or adding an HTTP 301 to old entries? Regards, -- Carlos http://caruizdiaz.com +595981146623 ___ 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
Re: [SR-Users] Mitigation of unavailable rtpproxy
On 11/6/13 2:58 PM, Alex Balashov wrote: On 11/06/2013 08:45 AM, Daniel-Constantin Mierla wrote: there are some parameters to control the timeout+retries for waiting a reply from rtpproxy: http://kamailio.org/docs/modules/stable/modules/rtpproxy.html#idp15243344 Looking it the code, it seems the value for timeout parameter is sec, but could be easily made miliseconds, because the function used inside is poll() which takes timeout as milisec. Thank you, Daniel. 1. So, am I right to assume that the unforce_rtp_proxy() call waits for timeout and blocks the worker while doing so? iirc, yes, each command has a reply. You can put the control socket on udp/network and use ngrep for a quick check. 2. Is there any harm in calling unforce_rtp_proxy() for Call-IDs rtpproxy doesn't know about? is there a 'better' best practice for handling CANCELs where it is unknown whether rtpproxy was engaged on the initial call (because it is an option, nat_uac_detect, etc)? No, it is no harm to call rtpproxy for non-existing sessions. You can even skip it, there is a session timeout in rtpproxy -- I don't know default value, but probably can be set via command line parameter -- so if you are not short in ports, you can just leave rtpproxy alone with closed calls without calling unforce command. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - ___ 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
Re: [SR-Users] Google search
Hello, On 11/6/13 7:15 PM, Carlos Ruiz Díaz wrote: Hi guys, this happens to me all the time: when I search for documentation about a specific Kamailio module on Google, I always land on outdated entries usually from Kamailio 1.6.x. Although this seems trivial and I could simply update the URL to the current version of Kamailio, this may be not so obvious for new users and they may end up reading expired documentation and/or implementing non-optimal solutions to their problems. is there a way to only allow indexation of the last documentation? Something like removing the version or adding an HTTP 301 to old entries? removing is not a good option, still lot of people use old versions. I wanted for long time, but no spare cycles for, anyhow, one of items in the to-do list once we get the tech admin group is to look at deploying a search engine for kamailio.org and related relevant sites. If one can suggest a good application to use, reply here (ideally open source, mysql+php based, not to install lot of extra dependencies that we don't have already for other need). Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - ___ 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
[SR-Users] #cfgutils: sleep(x) does not work in failure_route
Hello list, I have troubles using the function usleep(x) or sleep(x) (the behaviour is the same) of the cfgutils module (http://kamailio.org/docs/modules/3.2.x/modules_k/cfgutils.html#idp76968) in the failure_route. According documentation, this function could be used in any route, including the failure_route, too. However, when I call this function, it does not show any reaction, if a transaction was already answered with a provisional response. It is still working fine, when a transaction is timing out, as no target socket is reachable. This is confusing me! Please find below some xlog messages from my configuration file in two scenarios (function |t_set_fr(2, 1); is identic in both scenarios|): (1) scenario 1 is including a primary target, looked up in the registrar DB, which is unreachable; after transaction timeout I have inserted the function sleep() in the failure_route for forcing a delay = here it is working fine (see timestamp) (2) scenario 2 is including a primary target which is responding, but not establishing the session; after transaction timeout the procedure is still the same as in scenario (1) = here is no delay visible in the log and practically detectable From my point of view, this is a malfuntion! Does anybody see it different? I´ve tested these scenarios with kamailio-3.2.x and kamailio-3.3.x - no difference. Thanks for any hints! Klaus # SCENARIO (1) ORIG TARGET IS UNREACHABLE ## Nov 6 15:58:25 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -|XLOG|-: RELAY is reached for RU: sip:117002@10.16.48.226:5678, From: sip:110101@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 1107651805@10.16.48.71 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY is reached with Code: 408 From: sip:110101@10.16.48.71 To: sip:115300@10.16.48.44 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: failure_route FAILRELAY is reached because of a BRANCH_TIMEOUT of RU: sip:117002@10.16.48.226:5678 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY s l e e p 2000ms / 2s Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY s l e p t 2000ms / 2s Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -|XLOG|-: RELAYFB is reached for RU: sip:117003@10.16.48.226:7001, From: sip:110101@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 1107651805@10.16.48.71 # SCENARIO (2) ORIG TARGET IS REACHABLE ## Nov 6 16:02:14 sipsrvnode1 /usr/sbin/kamailio[29034]: INFO: -|XLOG|-: RELAY is reached for RU: sip:117002@10.16.48.226:5678, From: sip:110101@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 553330101@10.16.48.71 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY is reached with Code: 408 From: sip:@10.16.48.71 To: sip:4000@10.16.48.44 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: failure_route FAILRELAY is reached because of a BRANCH_TIMEOUT of RU: sip:117002@10.16.48.44 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY s l e e p 2000ms / 2s Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY s l e p t 2000ms / 2s Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: RELAYFB is reached for RU: sip:117003@10.16.48.44, From: sip:@10.16.48.71, To: sip:4000@10.16.48.44, Method: INVITE, Call-ID: 553330101@10.16.48.71 ___ 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
[SR-Users] #TM: timing problem in serial forking (INVITE vs. CANCEL)
Hello list, I have troubles with serial forking in kamailio 3.2.4, which is mixed with parallel forking. In the scenario that an initial INVITE message, which is addressed to sip:A, is coming in to the server, it is doing a lookup in the DB and forking (parallel) the request to e.g. 3 SIP user agents. I have set the timer to 20 seconds transaction timeout and after that timeout, the server is handling the original request in the FAILURE_ROUTE[xy]. In this failure route, the request-URI username is overwritten to an alternative one -- e.g. sip:B. Then the server is doing a DB lookup again and forking the request to the number of registered user agents. A specialiy of this scenario is that it can be possible, that user agents have registered for username A and username B -- in other words: they are members of the parallel forking group in serial forking step 1 and step 2. When the CANCEL and INVITE message would be sent out (to the user agents) in the correct order, then it would be no problem. But in my case the server is sending the new INVITE message (2^nd step in the serial forking procedure) to user agents BEFORE the CANCEL request. Therefore, these user agents are rejecting the INVITE message with 500. Signalisation scenario == INVITE - SRV SRV - INVITE (branch-1) UA1 SRV - INVITE (branch-2) UA2 SRV - INVITE (branch-3) UA3 SRV - 180 (branch-1) UA1 SRV - 180 (branch-2) UA2 SRV - 180 (branch-3) UA3 . [timeout] SRV - CANCEL (branch-1) UA1 SRV - CANCEL (branch-2) UA2 SRV - INVITE (branch-4) UA4 SRV - INVITE (branch-5) UA5 SRV - INVITE (branch-6) UA3(!!!) SRV - CANCEL (branch-3) UA3 SRV - 500 (branch-6)UA3 It was quasi reproduceable that only the last branch of the initial transaction had that timing problem (INVITE - vs - CANCEL). My question is: why does the server send the (last) CANCEL message only after the INVITE message for some branch(es)? Could this behaviour be prohibited in any way? Thanks in advance! Klaus ___ 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
[SR-Users] Email alert
Hi I was wondering which module i could use to configure an email alert upon an event in kamailio.cfg file i.e. if .. then send to email address any ideas? thanks! Phillip ___ 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
Re: [SR-Users] Mitigation of unavailable rtpproxy
On Wed, Nov 6, 2013 at 12:03 PM, Daniel-Constantin Mierla mico...@gmail.com wrote: On 11/6/13 2:58 PM, Alex Balashov wrote: 2. Is there any harm in calling unforce_rtp_proxy() for Call-IDs rtpproxy doesn't know about? is there a 'better' best practice for handling CANCELs where it is unknown whether rtpproxy was engaged on the initial call (because it is an option, nat_uac_detect, etc)? No, it is no harm to call rtpproxy for non-existing sessions. You can even skip it, there is a session timeout in rtpproxy -- I don't know default value, but probably can be set via command line parameter -- so if you are not short in ports, you can just leave rtpproxy alone with closed calls without calling unforce command. I seem to recall that the default is to close the session after 60 seconds of no RTP, but I'm not able to verify that right now. Corey ___ 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
Re: [SR-Users] Email alert
Hi Phillip, On 06/11/2013, at 22:29, phillman25 phillma...@gmail.com wrote: Hi I was wondering which module i could use to configure an email alert upon an event in kamailio.cfg file i.e. if .. then send to email address any ideas? There's no module to do so, but as an alternative you could print a log message and use some monitoring program (ex. monit or fail2ban) to check the log file and send the alert if your message is found. Regards, Oriol. ___ 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
[SR-Users] 408 callee disconnect (complete SIP packet capture)
Both callee and caller successfully establish 2-way audio however callee client disconnects with 408 response. Any troubleshooting ideas would be appreciated. Regards, Aaron Kamailio Debug Logs and complete SIP packet capture: http://www.n00bunlimited.net/pastebin.php?show=64292 ___ 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
[SR-Users] Fwd: 408 callee disconnect (complete SIP packet capture)
Sorry, Here is the corrected link to my full sip capture: http://tny.cz/7436627c Original Message Subject: 408 callee disconnect (complete SIP packet capture) Date: Wed, 06 Nov 2013 21:12:59 -0600 From: kamai...@aaronlux.com Reply-To: kamai...@aaronlux.com To: sr-users@lists.sip-router.org Both callee and caller successfully establish 2-way audio however callee client disconnects with 408 response. Any troubleshooting ideas would be appreciated. Regards, Aaron Kamailio Debug Logs and complete SIP packet capture: http://www.n00bunlimited.net/pastebin.php?show=64292 ___ 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
[SR-Users] Function to test DB connection from route[]?
Hi all, Is there a function I can use to test database connection from the routing script in the cfg file? My dispatcher uses OPTIONS probing. When the destination receives the OPTIONS request, I'd like to detect the health status of the database connection before sending a 200 back. Note the OPTIONS request doesn't have a user part in the RURI. Hence, is_subscriber() and alias_db_lookup() don't work. Any suggestion? Regards, Allen Zhang ___ 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
Re: [SR-Users] #cfgutils: sleep(x) does not work in failure_route
Hello, I have an update: today I´ve tested with kamailio version 4.0.4, but the behaviour is still the same: it is working fine only when no response has been received; as soon as a provisional response is received, the failure route is ignoring the sleep function. Klaus Hello list, I have troubles using the function usleep(x) or sleep(x) (the behaviour is the same) of the cfgutils module (http://kamailio.org/docs/modules/3.2.x/modules_k/cfgutils.html#idp76968 ) in the failure_route. According documentation, this function could be used in any route, including the failure_route, too. However, when I call this function, it does not show any reaction, if a transaction was already answered with a provisional response. It is still working fine, when a transaction is timing out, as no target socket is reachable. This is confusing me! Please find below some xlog messages from my configuration file in two scenarios (function t_set_fr(2, 1); is identic in both scenarios): (1) scenario 1 is including a primary target, looked up in the registrar DB, which is unreachable; after transaction timeout I have inserted the function sleep() in the failure_route for forcing a delay = here it is working fine (see timestamp) (2) scenario 2 is including a primary target which is responding, but not establishing the session; after transaction timeout the procedure is still the same as in scenario (1) = here is no delay visible in the log and practically detectable From my point of view, this is a malfuntion! Does anybody see it different? I´ve tested these scenarios with kamailio-3.2.x and kamailio-3.3.x - no difference. Thanks for any hints! Klaus # SCENARIO (1) ORIG TARGET IS UNREACHABLE ## Nov 6 15:58:25 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -|XLOG|-: RELAY is reached for RU:sip:117002@10.16.48.226:5678 , From:sip:110101@10.16.48.71 , To:sip:115300@10.16.48.44 , Method: INVITE, Call-ID: 1107651805@10.16.48.71 mailto:1107651805@10.16.48.71 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY is reached with Code: 408 From:sip:110101@10.16.48.71 To:sip:115300@10.16.48.44 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: failure_route FAILRELAY is reached because of a BRANCH_TIMEOUT of RU:sip:117002@10.16.48.226:5678 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY s l e e p 2000ms / 2s Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY s l e p t 2000ms / 2s Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -|XLOG|-: RELAYFB is reached for RU:sip:117003@10.16.48.226:7001 , From:sip:110101@10.16.48.71 , To:sip:115300@10.16.48.44 , Method: INVITE, Call-ID: 1107651805@10.16.48.71 mailto:1107651805@10.16.48.71 # SCENARIO (2) ORIG TARGET IS REACHABLE ## Nov 6 16:02:14 sipsrvnode1 /usr/sbin/kamailio[29034]: INFO: -|XLOG|-: RELAY is reached for RU:sip:117002@10.16.48.226:5678 , From:sip:110101@10.16.48.71 , To:sip:115300@10.16.48.44 , Method: INVITE, Call-ID: 553330101@10.16.48.71 mailto:553330101@10.16.48.71 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY is reached with Code: 408 From:sip:@10.16.48.71 To:sip:4000@10.16.48.44 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: failure_route FAILRELAY is reached because of a BRANCH_TIMEOUT of RU:sip:117002@10.16.48.44 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY s l e e p 2000ms / 2s Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY s l e p t 2000ms / 2s Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: RELAYFB is reached for RU:sip:117003@10.16.48.44 , From:sip:@10.16.48.71 , To:sip:4000@10.16.48.44 , Method: INVITE, Call-ID: 553330101@10.16.48.71 mailto:553330101@10.16.48.71 ___ 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
