Hi, all
We have applied the openssl 1.0.1e patch described in the email chain
between Roberto Fichera and Daniel-Constantin Mierla back in August. But
Kamailio 4.0.4 still fails to start up and the log shows memory allocation
problem. By the way, we're running kamailio on RHEL 6.5. Wonder if we have
missed anything. Please advise. Thanks.
Ding
I am setting up Kamailio as an SBC and freeswitch to handle vm and conferences. When I dial 41 Kamailio sends the call to FS and I get the VM prompts, but when I dial 43 the call never hits FS. I am looking at FS in the cli and call never comes in. I get "407 proxy authentication required" from my sip client.
I am new to Kamailio and cant seem to figure it out.
My system is running CentOS 6.4. FS is installed via yum. Kamailio is complied running version 3.0
thanks,
Hi all
Having some problems with the following part of the script in a timer:
We have some kamailios running doing more or less the same job - they are used by a loadbalancer kamailio.
Actually I wanted to check the ip or systemname of the current system do perform some actions depending on the used kamailio - based on a timer
route[CDRS] {
sql_query("ca","call kamailio_cdrs()","rb");
sql_query("ca","call kamailio_rating()","rb");
xlog("timer routine: time is %TF\n");
xlog("…
[View More]L_ERR", "time [%Tf] method <%rm> r-uri <%ru> 2nd via <%{via[1]}>\n");
xlog("L_INFO", "CDRS- rated Host %Hi");
if %Hi = ipOfGateway1 then do something
else if %Hi = ipOfGateway2 then do something different
}
What I get in log
Nov 10 12:54:12 sipgw21 /usr/sbin/kamailio[16231]: ERROR: <script>: timer routine: time is %TF
Nov 10 12:54:12 sipgw21 /usr/sbin/kamailio[16231]: ERROR: <script>: time [%Tf] method <%rm> r-uri <%ru> 2nd via <%{via[1]}>
Nov 10 12:54:24 sipgw21 /usr/sbin/kamailio[16231]: INFO: <script>: CDRS- rated Host %Hi
The %-variables are not processed ... what am I doing wrong??
Thanks
Oli
[View Less]
Hi
I get the following error when trying to load the carrierroute module
load_module(): ERROR: load_module: could not open module </usr/lib64/kamailio/modules/carrierroute.so>: /usr/lib64/kamailio/modules/carrierroute.so: undefined symbol: cfg_set_error_function
I installed Kamailio 4.0.3 by apt-get on Ubuntu 12.04 lts
It seems, that with version 3.3 it is working ...
root@sipgw22:/home/triotel# kamailio -V
version: kamailio 4.0.3 (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, …
[View More]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: unknown
compiled on 17:03:55 Aug 19 2013 with gcc 4.6.3
[View Less]
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 …
[View More]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…>
[View Less]
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 …
[View More]"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
[View Less]
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.
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 …
[View More]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
[View Less]
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.