- sr-users - kamailio.org

BUG? - Dialog module timeout BYE is not ok.
by Uri Shacked 11 Nov '13

11 Nov '13

Hi, Following this issue, and the issue "BYE dialog timeout bad syntax" from Julia. I have 2 kamailio servers. srv1 creates a dlg_timeout BYE and sends it to srv2 that forwards the BYE to the next sip server (some other server...). I can definitely see that the BYE that is being forward is malformed. The TO header info is not complete (the port section for example). When a "normal" bye is received from srv1 (not dlg_timeout) all works fine. One thing that i do in this scenario, on srv2 i use uac_replace() on the TO header. So, it is OK that the final destination is different (i do translations). I attached the BYE from both servers. Any ideas? Thanks, Uri You probably meant the To and From headers, I'm guessing. Yeah, as long as there is no display name component, URIs in headers like that don't have to go in <>s. The way Kamailio sends it is grammatically valid, per RFC 3261. The user agents are at fault for not understanding it correctly. Alex Balashov <abalashov at evaristesys.com<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>> wrote: >*"BYE headers"? Which headers? *>* *>*Uri Shacked <ushacked at gmail.com <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>> wrote: *>* *>>*Hi, *>>* *>>*I think there is a bug with the BYE that is sent to the caller and *>>*callee *>>*when dialog timeout happends. *>>* *>> *The BYE headers are sent with no "<" or ">". *>>*So, some sip singaling points decline the BYE. *>>* *>>*BR, *>>*Uri *>>* *>>* *>>*------------------------------------------------------------------------ *>>* *>>*_______________________________________________ *>>*SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing *>*list *>>*sr-users at lists.sip-router.org<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> *>>*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-0670 *>*Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ *>* *>*_______________________________________________ *>*SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list * >*sr-users at lists.sip-router.org<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> *>*http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users * -- Sent from my Nexus 10, with all the figments of autocorrect that might imply. 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.sip-router.org/pipermail/sr-users/attachments/20130422/0c75272…>

4 11

Wrong "To" header in CANCEL, when "To" has been rewritten by uac_replace_to() in branch route
by Julia 10 Nov '13

10 Nov '13

Hello, I know it was already discussed, that not recommended to modify "To" header and no routing should ever be done on "To". But as long as there are carriers that do it, we need full support for this manipulation for all messages in the call flow. I found in list a few mails with the same problem of wrong header "To" in CANCEL after "To" rewriting. And one solution from Vitaliy Aleksandrov : http://lists.sip-router.org/pipermail/sr-dev/2012-October/016657.html "Kamailio builds "To" header from the received INVITE. Patch to fix it: --- ./kamailio-3.2.3/modules/tm/t_cancel.c 2012-08-22 10:39:21.000000000 +0300 +++ ./kamailio-3.2.3-fixed/modules/tm/t_cancel.c 2012-10-01 18:25:57.000000000 +0300 @@ -284,7 +284,7 @@ if (cfg_get(tm, tm_cfg, reparse_invite)) { /* build the CANCEL from the INVITE which was sent out */ cancel = build_local_reparse(t, branch, &len, CANCEL, CANCEL_LEN, - &t->to + NULL #ifdef CANCEL_REASON_SUPPORT , reason #endif /* CANCEL_REASON_SUPPORT */" We use header "To" manipulation in branch route (after failure route) and this patch solved our problem with "To" in CANCEL. But a patch is not committed. Is it possible to commit this solution? Thank you, Julia

2 4

Modify/Edit INVITE message.
by Aziz 09 Nov '13

09 Nov '13

Hello. I have a question about Kamailio configuration. Can I edit or modify the INVITE message content? For example, remove "To" or "Via" fields in the INVITE content. If yes, how can I do? Thanks.

2 1

#TM: timing problem in serial forking (INVITE vs. CANCEL)
by Klaus Feichtinger 08 Nov '13

08 Nov '13

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

2 2

UUID generation
by Grant Bagdasarian 08 Nov '13

08 Nov '13

Hello, Any plans for building a module which generates a UUID or building it into the core? Daniel once told me to use $sruid, which basically returns a unique value. It works good. I haven't had any duplicates yet, even under heavy load tests.

1 0

kamailio 4.0.4 '408' response
by kamailio＠AaronLux.com 08 Nov '13

08 Nov '13

Below please find a filtered SIP packet capture showing a problem I'm having with callee '408' responses in kamailio 4.0.4. The '408' response occurs after both caller and callee successfully establish 2-way audio. In this setup kamailio is running behind a NAT and both SIP clients connect via WAN and rtpproxy is started with the following command 'rtpproxy -F -l 192.168.1.LAN -A 66.41.221.WAN -s unix:/var/run/rtpproxy.sock -d DBUG:LOG_LOCAL0 -m 10000 -M 20000' Ports 5061 and Ports 10000-20000 are forwarded to the kamailio server and kamailio has TLS enabled. Please let me know if you know if you need more info. Thanks, Aaron # Filtered SIP capture showing only 408 response: http://pastebin.com/pBcZNGA4 # rtpproxy -v Basic version: 20040107 Extension 20050322: Support for multiple RTP streams and MOH Extension 20060704: Support for extra parameter in the V command Extension 20071116: Support for RTP re-packetization Extension 20071218: Support for forking (copying) RTP stream Extension 20080403: Support for RTP statistics querying Extension 20081102: Support for setting codecs in the update/lookup command Extension 20081224: Support for session timeout notifications Extension 20090810: Support for automatic bridging # kamailio -v version: kamailio 4.0.4 (i386/linux) cabe58 flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: cabe58 compiled on 01:07:11 Nov 2 2013 with gcc 4.4.7

2 1

1 via header
by phillman25 08 Nov '13

08 Nov '13

Dear List I am trying to interconnect with a Cisco Call manager express, i am sending the INVITE message with the below format: INVITE sip:22775019@81.21.39.153 SIP/2.0 Record-Route: <sip:81.21.38.33;lr=on;ftag=685329680;did=671.51a2> Via: SIP/2.0/UDP 81.21.38.33;branch=z9hG4bKda1d.291eab1622fb619ec7df3ca647581a19.0 Via: SIP/2.0/UDP 81.21.35.22:5060;branch=z9hG4bKterm-4a32-99665015-6855A22775019-37284 From: 99665015 <sip:99665015@81.21.35.22;user=phone>;tag=685329680 To: 6855A22775019 <sip:6855A22775019@81.21.38.33;user=phone> Call-ID: 6fea2437-2d338fcf-4efc6b90-2d08(a)81.21.35.22 CSeq: 1 INVITE Supported: timer Session-Expires: 1800 Min-SE: 1800 Contact: <sip:99665015@81.21.35.22:5060> Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE Max-Forwards: 69 Content-Type: application/sdp Content-Length: 528 P-hint: outbound v=0 o=- 3099173 0 IN IP4 81.21.35.44 s=Cisco SDP 0 c=IN IP4 81.21.35.44 t=0 0 m=audio 52168 RTP/AVP 0 8 18 99 102 103 104 4 105 3 106 107 108 125 101 100 a=rtpmap:99 G.726-16/8000 a=rtpmap:102 G.726-24/8000 a=rtpmap:103 G.726-32/8000 a=rtpmap:104 G.723.1-H/8000 a=rtpmap:105 G.723.1-L/8000 a=rtpmap:106 G.729b/8000 a=rtpmap:107 G.723.1a-H/8000 a=rtpmap:108 G.723.1a-L/8000 a=rtpmap:125 G.nX64/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=nortpproxy:yes The Cisco Manager Express replies by sending the TRYING message in the below format with 1 via header: SIP/2.0 100 Trying Via: SIP/2.0/UDP 81.21.38.33;branch=z9hG4bKda1d.291eab1622fb619ec7df3ca647581a19.0,SIP/2.0/UDP 81.21.35.22:5060 ;branch=z9hG4bKterm-4a32-99665015-6855A22775019-37284 From: 99665015 <sip:99665015@81.21.35.22;user=phone>;tag=685329680 To: 6855A22775019 <sip:6855A22775019@81.21.38.33;user=phone> Date: Tue, 05 Nov 2013 18:24:17 GMT Call-ID: 6fea2437-2d338fcf-4efc6b90-2d08(a)81.21.35.22 CSeq: 1 INVITE Allow-Events: telephone-event Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Seems like Kamailio is not accepting this, is the Trying message from the client correct? Is it correct that he is sending 1 via header with 2 IP's as opposed to 2 via headers with 1 IP in each via header? Otherwise is there a solution for this? Thanks in advance Phillip

2 1

Where do I place the logic for modifying auth and call requests?
by erik＠valerius.se 08 Nov '13

08 Nov '13

Hello everyone. Some of my confusion probably comes from me coming from the web development world and not software dev, but I would greatly appreciate any response to the following question: I use the MySQL auth for my subscribers which is working great. However, let's say that I add the column "valid_until" in the subscriber table and want to check if today's date is less than the caller's valid_until value. I can set up the sqlops module without a problem and get the actual value, but I have no idea where I place the logic to compare it to a date and then pass on the OK message to Kamailio to continue the request. Is this done with embedded scripts? Or right there in the config file? Where can I find a list of what parts of the call request are exposed for customization from Kamailio? I'd greatly prefer to do things in Python or JavaScript, if that matters. Many thanks in advance! Erik Eklund

2 2

RTPproxy support in Wireshark
by Peter Lemenkov 08 Nov '13

08 Nov '13

Hello All! First of all I'm sorry for the crossposting. For those who unaware of what's going inside Wireshark project - I'm working on a "classic" RTPproxy protocol dissector. Most of the patches already accepted, and Wireshark's RTPproxy parser is already usable. Few more patches should land in trunk quite soon. As for rtpproxy-ng - I plan to add support for its protocol as well (right after I finish with this one). If you're using Fedora Linux, then Wireshark from the repository already compiled with RTPproxy protocol dissection support. -- With best regards, Peter Lemenkov.

1 0

Mitigation of unavailable rtpproxy
by Alex Balashov 07 Nov '13

07 Nov '13

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/

3 5

Kamctl ping works as my unix user, not in root nor kamailio user
by Benjamin Henrion 07 Nov '13

07 Nov '13

Hi, I am trying to find out why kamctl ping sip:1.2.3.4:5060 works with my unix user (got a 200 OK), while it does not with kamailio nor root user (I got a 408 timeout). Any idea? The permissions of the socket in /tmp are like this: ======================================= srw------- 1 root root 0 Oct 31 01:01 kamailio_ctl prw-rw---- 1 kamailio kamailio 0 Nov 7 13:55 kamailio_fifo srw-rw-rw- 1 kamailio kamailio 0 Oct 31 01:01 kamailio_socket ======================================= Best, -- Benjamin Henrion <bhenrion at ffii.org> FFII Brussels - +32-484-566109 - +32-2-4148403 "In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators."

2 1

SIP registration
by Mudasser 07 Nov '13

07 Nov '13

Hello I am devloping the chat/call application like viber,whatsapp etc in Android using sip. I want to know how i can register the sip account with ur sevrer. what's code which i need to write in my application.suppose if i want to chat or call between other person how i can get register without telling user that i am going for sip registration means there i cam not going to display sip registration form etc. where i can save user message and how i can maintain user info like dispaly name , display pic etc.is there any serverside databse involvement to save messages,pic etc or sip sever maintain automatically. Kindly describe in details as i am new in Android Thank you Best Regards Mudasser Tufail Senior Software Engineer

1 0

Re: [SR-Users] #cfgutils: sleep(x) does not work in failure_route
by Klaus Feichtinger 07 Nov '13

07 Nov '13

Hello Daniel, I´ve patched the code and found that the return value of the 'sleep' command is - as expected - differing in the scenarios. For scenario 1 (no provisional response), the return value is '0' and for scenario 2, the return value is '2' (see log output): scenario 1: Nov 7 12:40:51 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-: <FAILRELAY> s l e e p 2000ms / 2s Nov 7 12:40:51 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:650]: sleep 2 seconds Nov 7 12:40:53 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:652]: sleep-rc 0 Nov 7 12:40:53 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-: <FAILRELAY> s l e p t 2000ms / 2s scenario 2: Nov 7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-: <FAILRELAY> s l e e p 2000ms / 2s Nov 7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:650]: sleep 2 seconds Nov 7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:652]: sleep-rc 2 Nov 7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-: <FAILRELAY> s l e p t 2000ms / 2s This means that the sleep command is interrupted (in scenario 2) by a signal, as the return value is representing the "number of seconds left to sleep, if the call was interrupted by a signal handler.". Which signal is interrupting "sleep" in this scenario (only) :-( ? Klaus > Daniel-Constantin Mierla <miconda(a)gmail.com> hat am 7. November 2013 um 10:36 > geschrieben: > > Hello, > > can you try to see if sleep_us() works? > > It is rather strange because sleep() from cfgutils just uses sleep() from > system library, nothing special internally... sleep is interrupted by signals > as well. Can you patch the function in kamailio to log the return code from > sleep()? > > Cheers, > Daniel > > On 11/7/13 8:40 AM, klaus.lists#inode.at wrote: > > > > 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(20000, 10000);" 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:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > > > INVITE, Call-ID: 1107651805(a)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:1101015555@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:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > > > INVITE, Call-ID: 1107651805(a)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:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > > > INVITE, Call-ID: 553330101(a)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:5555@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:5555@10.16.48.71> , To:<sip:4000@10.16.48.44> , Method: INVITE, > > > Call-ID: 553330101(a)10.16.48.71 <mailto:553330101@10.16.48.71> > > > > > > > > > > > > > > > > > > _______________________________________________ > > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > > sr-users(a)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://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> - >

1 0

IM Broadcasting
by sipatse＠in.gr 07 Nov '13

07 Nov '13

1 0

Function to test DB connection from route[]?
by Allen Zhang 07 Nov '13

07 Nov '13

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

2 1

Re: [SR-Users] #cfgutils: sleep(x) does not work in failure_route
by klaus.lists#inode.at 07 Nov '13

07 Nov '13

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(20000, 10000);" 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:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > INVITE, Call-ID: 1107651805(a)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:1101015555@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:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > INVITE, Call-ID: 1107651805(a)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:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > INVITE, Call-ID: 553330101(a)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:5555@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:5555@10.16.48.71> , To:<sip:4000@10.16.48.44> , Method: INVITE, > Call-ID: 553330101(a)10.16.48.71 <mailto:553330101@10.16.48.71> >

2 1

Email alert
by phillman25 07 Nov '13

07 Nov '13

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 xxxx any ideas? thanks! Phillip

3 2

IM Broadcasting
by sipatse＠in.gr 07 Nov '13

07 Nov '13

1 0

408 callee hangup problem
by kamailio＠AaronLux.com 07 Nov '13

07 Nov '13

2 3

Google search
by Carlos Ruiz Díaz 06 Nov '13

06 Nov '13

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

3 2

#cfgutils: sleep(x) does not work in failure_route
by Klaus Feichtinger 06 Nov '13

06 Nov '13

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(20000, 10000);" 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:1101015555@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 1107651805(a)10.16.48.71 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-: <FAILRELAY> is reached with Code: 408 From: sip:1101015555@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:1101015555@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 1107651805(a)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:1101015555@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 553330101(a)10.16.48.71 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-: <FAILRELAY> is reached with Code: 408 From: sip:5555@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:5555@10.16.48.71, To: sip:4000@10.16.48.44, Method: INVITE, Call-ID: 553330101(a)10.16.48.71

1 0

dispatcher: ds_options_callback, Setting the state failed
by Seudin Kasumovic 06 Nov '13

06 Nov '13

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. Also, DEBUG log is broken. (kamailio version: kamailio 4.1.0-pre1 (i386/linux)). 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(a)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(a)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 [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]: DEBUG: tm [t_reply.c:2122]: local_reply(): DEBUG: local transaction completed Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0xb492c918, callback type 1024, id 0 entered Nov 5 12:48:01 localhost kamailio[23726]: DEBUG: dispatcher [dispatch.c:2359]: ds_options_callback(): OPTIONS-Request was finished with code 200 (to sip:192.0.2.4:5090, group 0) ds_list shows: SET_NO:: 2 SET:: 28 URI:: sip:198.51.100.68:5060 flags=TX priority=1 attrs= SET:: 0 URI:: sip:192.0.2.4:5090 flags=AP priority=1 attrs= -- Seudin Kasumovic

2 2

use append_hf() and remove_hf() on the same message
by Camille Oudot 06 Nov '13

06 Nov '13

Hi, I'm using remove_hf() and append_hf() to manipulate the sip headers on my application. Apparently, calling insert_hf("foo") after remove_hf("bar") if bar is the last header (not including Content-Length) is a bad idea, foo doesn't get inserted (I understand that the append_hf() command tries to insert foo after bar, and since bar just disappeared, well, it fails) What is the safest way to both remove and append headers on the same message? Regards -- Camille

2 4

dialog stats reported by app_perl
by mayamatakeshi 06 Nov '13

06 Nov '13

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

2 2

TLS - No ServerHello
by Coy Cardwell 05 Nov '13

05 Nov '13

Hi all. We are using Kamailio 4.0.4 in an Edge Proxy to Central Registrar configuration. The system is in a functional state. Oddly, when we enable TLS, the Kamailio server never responds with a Server Hello to the Client Hello for TLS, so a connection is never established. Has anyone seen anything like this? There are no errors anywhere, the server just never responds to the initial TLS Client Hello. We know the packet arrives and is acknowledged at the TCP level. Just a bit stumped.

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users