From omarlabs188 at gmail.com Sun Jul 1 02:54:08 2012
From: omarlabs188 at gmail.com (Omar Labs 188 Gmail)
Date: Sat, 30 Jun 2012 20:54:08 -0400
Subject: [SR-Users] Kamailio Unexpectedly Terminating
In-Reply-To: <4FEBD368.1050204@akan.net>
References: <4F98539A.3080307@akan.net> <4F990A47.9080904@gmail.com>
<4F99A51B.3040909@akan.net> <4F9C1F7C.2080204@akan.net>
<4F9D0BF5.10506@gmail.com> <4FA341FA.3070606@akan.net>
<4FA38B8E.9020900@gmail.com> <4FA5475D.60104@akan.net>
<4FAA2555.1050903@gmail.com> <4FAABCDE.1040305@akan.net>
<4FBC876A.2020907@akan.net> <4FC48EFC.8050605@akan.net>
<4FC49397.3040806@gmail.com> <4FC58569.1060201@akan.net>
<4FC634F3.3020802@gmail.com> <4FC67090.6000306@akan.net>
<4FC67440.1030300@gmail.com> <4FCA7968.90008@akan.net>
<4FCC5C64.90401@gmail.com> <4FD5F395.20308@gmail.com>
<4FD64332.3030104@akan.net> <4FD6E6C9.8050301@gmail.com>
<4FD78614.7020708@akan.net> <4FD7D91A.9070803@akan.net>
<4FE47283.9090700@akan.net> <4FE81BE0.5070802@gmail.com>
<4FEBD368.1050204@akan.net>
Message-ID: <430C2BA8-6B84-495E-AE93-2E36A8A60EB9@gmail.com>
Just to let you know
I made a lot of tests using different modules including carrierroute, I do have the bus error also after the first call and core dump.
thank you
O
On Jun 27, 2012, at 11:45 PM, Akan wrote:
> Daniel,
>
> i did a repull from git, compiled, installed and re-test of Kamailio and got the same error in the same program's location as previous (in tm_funcs.c). Here are the commands that I entered to make sure I did everything correctly:
>
> mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignment
> cd /usr/local/src/kamailio/kamailio-3.2-noalignment
> git clone --depth 1 git://git.sip-router.org/sip-router kamailio
> cd kamailio
> |gmake proper
> gmake prefix=/opt/kamailio-3.2 FLAVOUR=kamailio cfg
> vi modules.lst
> | gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all
> |gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs install
>
> Makefile:363: config.mak: No such file or directory
> normal Makefile.defs exec
> target architecture <sparc64>, host architecture <sparc64>
> generating autover.h ...
> making config...
> Makefile.defs defs skipped
> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c endianness.c -o endianness.o -MMD -MP
> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c select_buf.c -o select_buf.o -MMD -MP
>
> ||
> Thanks
>
> Nathaniel
>
> |
> On 6/25/2012 3:05 AM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> thanks for troubleshooting further -- as I expected, it is a memalign problem, but some confusing reports by not using always the patches I made to registrar module to align the structure, made thinking is something else. Now is no longer in registrar, but in another module.
>>
>> There might be many of these, can you try to compile first without strict alignment to 8 bytes? Checking quickly to gcc, the option should be |-mno-faster-structs
>>
>> So try:
>>
>> make proper
>> make FLAVOUR=kamailio cfg|
>> make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all|
>> ...
>>
>> By providing Q=0, you will see all compile flags, verify that |-mno-faster-structs is there.
>>
>> Cheers,
>> Daniel
>> |
>> On 6/22/12 3:26 PM, Akan wrote:
>>> Hello,
>>>
>>> After doing some research, this is what I found out. On Solaris Sparc 64bit system, there is a mandatory alignment of memory accesses and also for data types. I went thru the core dump, disassembled the code and located the instruction that produced the error. The registers addresses in questioned are on a 4 byte alignment but not an 8 byte or 16 byte alignment. .The earlier patch must have forced the alignment which is why the error did not occur in the program common.c. It looks like there is a similar situation in t_funcs.c.
>>>
>>> Here is a link that I found that can better explain:
>>> http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html
>>>
>>> Core was generated by `/opt/kamailio-3.2/sbin/kamailio'.
>>> Program terminated with signal 10, Bus error.
>>> #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, proto=0, replicate=0) at t_funcs.c:352
>>> 352 if (!t_reply( t, p_msg , 100 ,
>>>
>>> 0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1
>>> 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1
>>> 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 <t_reply at plt>
>>> *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3*
>>> 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0
>>> 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14 <t_relay_to+1844>
>>> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0
>>> 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460 <t_relay_to+128>
>>>
>>> End of assembler dump.
>>> (gdb) info registers g1
>>> g1 0xffffffff7666c3e4 -2308520988
>>> (gdb) info registers o3
>>> o3 0x18f3d0 1635280
>>>
>>> I hope this helps in trying to resolve this problem and to find a solution. Also, if you need a sparc system to test with, just let me know. We can help from a sparc perspective.
>>>
>>> Thanks
>>>
>>> Nathaniel
>>>
>>>
>>
>>
>> --
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2012.0.2180 / Virus Database: 2437/5091 - Release Date: 06/24/12
>>
>
>
>
> _______________________________________________
> 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
>
From omarlabs188 at gmail.com Sun Jul 1 06:28:54 2012
From: omarlabs188 at gmail.com (Omar Labs 188 Gmail)
Date: Sun, 1 Jul 2012 00:28:54 -0400
Subject: [SR-Users] TCP Forwarding error: cannot forward to af 2,
proto 2 no correspondinglistening socket
Message-ID: <DAE61B84-8584-4171-8FEE-452202E5FE79@gmail.com>
tried many versions
in version 1.4 i have this error:
Jun 29 21:25:04 [7309] ERROR:core:forward_request: cannot forward to af 2, proto 2 no correspondinglistening socket
i do have the TCP port listen explicitly
the line for disable-tcp is commented.
listen=udp:192.168.169.169:5060
listen=udp:192.168.169.169:5060
if ( src_ip == 192.168.169.180 ) {
forward("tcp:192.168.170.156:5060");
}
I tried already many options related the forward command , using variables and using forward();
``Listening on
udp: 192.168.169.169 [192.168.169.169]:5060
tcp: 192.168.169.169 [192.168.169.169]:5060
Aliases:
tcp: loghost:5060
tcp: kamtest01:5060
udp: loghost:5060
udp: kamtest01:5060
bash-3.00# telnet 192.168.169.169 5060
Trying 192.168.169.169...
Connected to 192.168.169.169.
Escape character is '^]'.
Connection to 192.168.169.169 closed by foreign host.
bash-3.00# kamctl ps
Process:: ID=0 PID=4541 Type=attendant
Process:: ID=1 PID=4542 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=2 PID=4543 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=3 PID=4544 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=4 PID=4545 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=5 PID=4546 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=6 PID=4547 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=7 PID=4548 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=8 PID=4549 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=9 PID=4550 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=10 PID=4551 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=11 PID=4552 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=12 PID=4553 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=13 PID=4554 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=14 PID=4555 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=15 PID=4556 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=16 PID=4557 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=17 PID=4558 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=18 PID=4559 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=19 PID=4560 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=20 PID=4561 Type=SIP receiver udp:192.168.169.169:5060
Process:: ID=21 PID=4562 Type=timer
Process:: ID=22 PID=4563 Type=MI FIFO
Process:: ID=23 PID=4564 Type=TCP receiver
Process:: ID=24 PID=4565 Type=TCP receiver
Process:: ID=25 PID=4566 Type=TCP receiver
Process:: ID=26 PID=4567 Type=TCP receiver
Process:: ID=27 PID=4568 Type=TCP receiver
Process:: ID=28 PID=4569 Type=TCP receiver
Process:: ID=29 PID=4570 Type=TCP receiver
Process:: ID=30 PID=4571 Type=TCP receiver
Process:: ID=31 PID=4572 Type=TCP receiver
Process:: ID=32 PID=4573 Type=TCP receiver
Process:: ID=33 PID=4574 Type=TCP main
O
From jh at tutpro.com Mon Jul 2 08:48:04 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Mon, 2 Jul 2012 09:48:04 +0300
Subject: [SR-Users] Possible bad lcr module,
after upgrade to 3.3.0 from 3.2
In-Reply-To: <CADJsLxgYkB+6sYT9XvLiHqt2xHxEY-UXQSGCzeMkZqAVSonZYg@mail.gmail.com>
References: <CADJsLxgXLm-iPzZVVQQk=Lvqg69uk527uxeyQCWGZzCxc08rAQ@mail.gmail.com>
<20450.49498.112879.142272@siika.tutpro.com>
<CADJsLxhV0-MPBUGi9XtQi=f=H=9L5vAQcpHrwo7GMZUCPe5k+Q@mail.gmail.com>
<20450.55305.266927.929348@siika.tutpro.com>
<CADJsLxj1SV41WnwiLK7iwTLuUL1kBvAJOmdmaSPGKss6ez+geg@mail.gmail.com>
<20450.60144.595521.82936@siika.tutpro.com>
<CADJsLxjRTpnVnBvZHUGXOrvkbU5BryiS3+J_tHzZcT7hB5VfQQ@mail.gmail.com>
<20450.64858.987000.752415@siika.tutpro.com>
<CADJsLxhdQYCM7js9sfA7aZvUjSAnykf-dGuMqf4XB-pc3wF5-g@mail.gmail.com>
<CADJsLxgYkB+6sYT9XvLiHqt2xHxEY-UXQSGCzeMkZqAVSonZYg@mail.gmail.com>
Message-ID: <20465.17444.614513.107789@siika.tutpro.com>
Alexey Mechanoshin writes:
> and if restart kamailio, again skipping from syslog:
> skipping disabled <gw/rule> = <1/5>
> skipping disabled <gw/rule> = <3/5>
i tried again with your lcr table records (enclosed) and i do not get those
skipping messages. i cannot do anything more unless i'm able to
reproduce your problem.
-- juha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.sql
Type: application/octet-stream
Size: 5046 bytes
Desc: test2.sql
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120702/d0117328/attachment.obj>
From omarlabs188 at gmail.com Mon Jul 2 00:47:46 2012
From: omarlabs188 at gmail.com (Omar Labs 188 Gmail)
Date: Sun, 1 Jul 2012 18:47:46 -0400
Subject: [SR-Users] Kamailio Unexpectedly Terminating
In-Reply-To: <430C2BA8-6B84-495E-AE93-2E36A8A60EB9@gmail.com>
References: <4F98539A.3080307@akan.net> <4F990A47.9080904@gmail.com>
<4F99A51B.3040909@akan.net> <4F9C1F7C.2080204@akan.net>
<4F9D0BF5.10506@gmail.com> <4FA341FA.3070606@akan.net>
<4FA38B8E.9020900@gmail.com> <4FA5475D.60104@akan.net>
<4FAA2555.1050903@gmail.com> <4FAABCDE.1040305@akan.net>
<4FBC876A.2020907@akan.net> <4FC48EFC.8050605@akan.net>
<4FC49397.3040806@gmail.com> <4FC58569.1060201@akan.net>
<4FC634F3.3020802@gmail.com> <4FC67090.6000306@akan.net>
<4FC67440.1030300@gmail.com> <4FCA7968.90008@akan.net>
<4FCC5C64.90401@gmail.com> <4FD5F395.20308@gmail.com>
<4FD64332.3030104@akan.net> <4FD6E6C9.8050301@gmail.com>
<4FD78614.7020708@akan.net> <4FD7D91A.9070803@akan.net>
<4FE47283.9090700@akan.net> <4FE81BE0.5070802@gmail.com>
<4FEBD368.1050204@akan.net>
<430C2BA8-6B84-495E-AE93-2E36A8A60EB9@gmail.com>
Message-ID: <CFD3E709-0581-43E8-81D7-3CC7AA44D67C@gmail.com>
I tried in solaris the version kamailio 3.3.0 Bus error. For solaris I have had that same issue in any version above the 1.4.3.
If i test in Suse, kamailio crashes when the radius or Diameter module is enabled. this i tested with versions 3.1 3.2 i am checking if i can get the gdb for all this.
I was unable to build it yet for 3.3.0
thank you
O
On Jun 30, 2012, at 8:54 PM, Omar Labs 188 Gmail wrote:
> Just to let you know
>
> I made a lot of tests using different modules including carrierroute, I do have the bus error also after the first call and core dump.
>
>
> thank you
> O
>
>
>
>
>
> On Jun 27, 2012, at 11:45 PM, Akan wrote:
>
>> Daniel,
>>
>> i did a repull from git, compiled, installed and re-test of Kamailio and got the same error in the same program's location as previous (in tm_funcs.c). Here are the commands that I entered to make sure I did everything correctly:
>>
>> mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignment
>> cd /usr/local/src/kamailio/kamailio-3.2-noalignment
>> git clone --depth 1 git://git.sip-router.org/sip-router kamailio
>> cd kamailio
>> |gmake proper
>> gmake prefix=/opt/kamailio-3.2 FLAVOUR=kamailio cfg
>> vi modules.lst
>> | gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all
>> |gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs install
>>
>> Makefile:363: config.mak: No such file or directory
>> normal Makefile.defs exec
>> target architecture <sparc64>, host architecture <sparc64>
>> generating autover.h ...
>> making config...
>> Makefile.defs defs skipped
>> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c endianness.c -o endianness.o -MMD -MP
>> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c select_buf.c -o select_buf.o -MMD -MP
>>
>> ||
>> Thanks
>>
>> Nathaniel
>>
>> |
>> On 6/25/2012 3:05 AM, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> thanks for troubleshooting further -- as I expected, it is a memalign problem, but some confusing reports by not using always the patches I made to registrar module to align the structure, made thinking is something else. Now is no longer in registrar, but in another module.
>>>
>>> There might be many of these, can you try to compile first without strict alignment to 8 bytes? Checking quickly to gcc, the option should be |-mno-faster-structs
>>>
>>> So try:
>>>
>>> make proper
>>> make FLAVOUR=kamailio cfg|
>>> make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all|
>>> ...
>>>
>>> By providing Q=0, you will see all compile flags, verify that |-mno-faster-structs is there.
>>>
>>> Cheers,
>>> Daniel
>>> |
>>> On 6/22/12 3:26 PM, Akan wrote:
>>>> Hello,
>>>>
>>>> After doing some research, this is what I found out. On Solaris Sparc 64bit system, there is a mandatory alignment of memory accesses and also for data types. I went thru the core dump, disassembled the code and located the instruction that produced the error. The registers addresses in questioned are on a 4 byte alignment but not an 8 byte or 16 byte alignment. .The earlier patch must have forced the alignment which is why the error did not occur in the program common.c. It looks like there is a similar situation in t_funcs.c.
>>>>
>>>> Here is a link that I found that can better explain:
>>>> http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html
>>>>
>>>> Core was generated by `/opt/kamailio-3.2/sbin/kamailio'.
>>>> Program terminated with signal 10, Bus error.
>>>> #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, proto=0, replicate=0) at t_funcs.c:352
>>>> 352 if (!t_reply( t, p_msg , 100 ,
>>>>
>>>> 0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1
>>>> 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1
>>>> 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 <t_reply at plt>
>>>> *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3*
>>>> 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0
>>>> 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14 <t_relay_to+1844>
>>>> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0
>>>> 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460 <t_relay_to+128>
>>>>
>>>> End of assembler dump.
>>>> (gdb) info registers g1
>>>> g1 0xffffffff7666c3e4 -2308520988
>>>> (gdb) info registers o3
>>>> o3 0x18f3d0 1635280
>>>>
>>>> I hope this helps in trying to resolve this problem and to find a solution. Also, if you need a sparc system to test with, just let me know. We can help from a sparc perspective.
>>>>
>>>> Thanks
>>>>
>>>> Nathaniel
>>>>
>>>>
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla -http://www.asipto.com
>>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>>
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>> Version: 2012.0.2180 / Virus Database: 2437/5091 - Release Date: 06/24/12
>>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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
>
From Marco.Barthel at de.bosch.com Mon Jul 2 10:29:02 2012
From: Marco.Barthel at de.bosch.com (Barthel Marco (CI/AFU1))
Date: Mon, 2 Jul 2012 10:29:02 +0200
Subject: [SR-Users] How to access reason phrase of winning reply in
failure_route
Message-ID: <44C56CFBDEDE184893B6FAD3401140D141240E3D21@SI-MBX02.de.bosch.com>
All,
how do I access the reason phrase of winning reply in failure_route?
The reply code can be accessed via $T_reply_code. Is there something similar for the reason phrase?
Mit freundlichen Gr??en / Best regards
Marco Barthel
Robert Bosch GmbH
(CI/AFU1)
www.bosch.com
Tel. +49 711 811-3602341
marco.barthel at de.bosch.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Gesch?ftsf?hrung: Volkmar Denner, Siegfried Dais;
Stefan Asenkerschbaumer, Bernd Bohr, Rudolf Colm, Dirk Hoheisel, Christoph K?bel, Uwe Raschke,
Wolf-Henning Scheider, Werner Struth, Peter Tyroller
From agranig at sipwise.com Mon Jul 2 11:04:03 2012
From: agranig at sipwise.com (Andreas Granig)
Date: Mon, 02 Jul 2012 11:04:03 +0200
Subject: [SR-Users] How to access reason phrase of winning reply in
failure_route
In-Reply-To: <44C56CFBDEDE184893B6FAD3401140D141240E3D21@SI-MBX02.de.bosch.com>
References: <44C56CFBDEDE184893B6FAD3401140D141240E3D21@SI-MBX02.de.bosch.com>
Message-ID: <4FF16403.6080003@sipwise.com>
Hi,
On 07/02/2012 10:29 AM, Barthel Marco (CI/AFU1) wrote:
> how do I access the reason phrase of winning reply in failure_route?
> The reply code can be accessed via $T_reply_code. Is there something similar for the reason phrase?
The tmx module exports $T_rpl(), which you can use like this to access
the reason: $T_rpl($rr)
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120702/0f2dff38/attachment.pgp>
From miconda at gmail.com Mon Jul 2 21:15:57 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 02 Jul 2012 21:15:57 +0200
Subject: [SR-Users] TCP Forwarding error: cannot forward to af 2,
proto 2 no correspondinglistening socket
In-Reply-To: <DAE61B84-8584-4171-8FEE-452202E5FE79@gmail.com>
References: <DAE61B84-8584-4171-8FEE-452202E5FE79@gmail.com>
Message-ID: <4FF1F36D.6020803@gmail.com>
Hello,
can you send the output with debug=3 for version 3.2.x or 3.3.x?
Cheers,
Daniel
On 7/1/12 6:28 AM, Omar Labs 188 Gmail wrote:
> tried many versions
> in version 1.4 i have this error:
> Jun 29 21:25:04 [7309] ERROR:core:forward_request: cannot forward to af 2, proto 2 no correspondinglistening socket
>
> i do have the TCP port listen explicitly
> the line for disable-tcp is commented.
>
> listen=udp:192.168.169.169:5060
> listen=udp:192.168.169.169:5060
>
> if ( src_ip == 192.168.169.180 ) {
> forward("tcp:192.168.170.156:5060");
> }
>
>
> I tried already many options related the forward command , using variables and using forward();
>
> ``Listening on
> udp: 192.168.169.169 [192.168.169.169]:5060
> tcp: 192.168.169.169 [192.168.169.169]:5060
> Aliases:
> tcp: loghost:5060
> tcp: kamtest01:5060
> udp: loghost:5060
> udp: kamtest01:5060
>
>
> bash-3.00# telnet 192.168.169.169 5060
> Trying 192.168.169.169...
> Connected to 192.168.169.169.
> Escape character is '^]'.
> Connection to 192.168.169.169 closed by foreign host.
>
> bash-3.00# kamctl ps
> Process:: ID=0 PID=4541 Type=attendant
> Process:: ID=1 PID=4542 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=2 PID=4543 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=3 PID=4544 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=4 PID=4545 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=5 PID=4546 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=6 PID=4547 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=7 PID=4548 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=8 PID=4549 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=9 PID=4550 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=10 PID=4551 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=11 PID=4552 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=12 PID=4553 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=13 PID=4554 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=14 PID=4555 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=15 PID=4556 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=16 PID=4557 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=17 PID=4558 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=18 PID=4559 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=19 PID=4560 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=20 PID=4561 Type=SIP receiver udp:192.168.169.169:5060
> Process:: ID=21 PID=4562 Type=timer
> Process:: ID=22 PID=4563 Type=MI FIFO
> Process:: ID=23 PID=4564 Type=TCP receiver
> Process:: ID=24 PID=4565 Type=TCP receiver
> Process:: ID=25 PID=4566 Type=TCP receiver
> Process:: ID=26 PID=4567 Type=TCP receiver
> Process:: ID=27 PID=4568 Type=TCP receiver
> Process:: ID=28 PID=4569 Type=TCP receiver
> Process:: ID=29 PID=4570 Type=TCP receiver
> Process:: ID=30 PID=4571 Type=TCP receiver
> Process:: ID=31 PID=4572 Type=TCP receiver
> Process:: ID=32 PID=4573 Type=TCP receiver
> Process:: ID=33 PID=4574 Type=TCP main
>
> O
>
>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Mon Jul 2 21:20:35 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 02 Jul 2012 21:20:35 +0200
Subject: [SR-Users] cfgutils lock / unlock + $sht() variables.
In-Reply-To: <4FEE18FB.5020500@gmail.com>
References: <4FEE18FB.5020500@gmail.com>
Message-ID: <4FF1F483.6020109@gmail.com>
Hello,
On 6/29/12 11:07 PM, Vitaliy Aleksandrov wrote:
> Hi all,
>
> I use $sht() pseudo-variabled provided by htable module for caching
> various information about sip customers. I thought that htable has
> some locking mechanism inside it and today while i was reading
> core-cookbook i payed attention to one example with the lock/unlock
> functions and $sht():
>
> lock("calls-to::10.10.10.10");
> $sht(a=>calls-to::10.10.10.10) =
> $sht(a=>calls-to::10.10.10.10) + 1;
> unlock("calls-to::10.10.10.10");
>
> According to that example an explicit locking mechanism should be used
> when i want to write something to a hash table.
> On the other hand there are no locks in htable documentation.
>
> So the question is when do the explicit locks should be used and for
> what purpose ?
reading and writing in hash table is under the lock. But the increment
operation as it is presented above requires first to read and then to
write -- for that is recommended you use a lock to avoid races.
If it is just increment/decrement operation in htable, then you can use
$shtinc(...)/$shtdec(...) for it:
http://www.kamailio.org/wiki/cookbooks/3.3.x/pseudovariables#shtinc_htable_key
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Mon Jul 2 21:27:51 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 02 Jul 2012 21:27:51 +0200
Subject: [SR-Users] Kamailio Unexpectedly Terminating
In-Reply-To: <CFD3E709-0581-43E8-81D7-3CC7AA44D67C@gmail.com>
References: <4F98539A.3080307@akan.net> <4F990A47.9080904@gmail.com>
<4F99A51B.3040909@akan.net> <4F9C1F7C.2080204@akan.net>
<4F9D0BF5.10506@gmail.com> <4FA341FA.3070606@akan.net>
<4FA38B8E.9020900@gmail.com> <4FA5475D.60104@akan.net>
<4FAA2555.1050903@gmail.com> <4FAABCDE.1040305@akan.net>
<4FBC876A.2020907@akan.net> <4FC48EFC.8050605@akan.net>
<4FC49397.3040806@gmail.com> <4FC58569.1060201@akan.net>
<4FC634F3.3020802@gmail.com> <4FC67090.6000306@akan.net>
<4FC67440.1030300@gmail.com> <4FCA7968.90008@akan.net>
<4FCC5C64.90401@gmail.com> <4FD5F395.20308@gmail.com>
<4FD64332.3030104@akan.net> <4FD6E6C9.8050301@gmail.com>
<4FD78614.7020708@akan.net> <4FD7D91A.9070803@akan.net>
<4FE47283.9090700@akan.net> <4FE81BE0.5070802@gmail.com>
<4FEBD368.1050204@akan.net>
<430C2BA8-6B84-495E-AE93-2E36A8A60EB9@gmail.com>
<CFD3E709-0581-43E8-81D7-3CC7AA44D67C@gmail.com>
Message-ID: <4FF1F637.5050302@gmail.com>
Hello,
for solaris sparc64 you have to find the option for compiler not to
build with strict alignment requirement for structures. I checked
quickly on the web in some man pages, but I am not sure I got the right
solution (what I previously sent on this thread).
If anyone can allocate resources to check all the structure, will be
another variant, at some time/money expence, but I guess the fast will
be the right flag to compiler.
Cheers,
Daniel
On 7/2/12 12:47 AM, Omar Labs 188 Gmail wrote:
> I tried in solaris the version kamailio 3.3.0 Bus error. For solaris I have had that same issue in any version above the 1.4.3.
>
> If i test in Suse, kamailio crashes when the radius or Diameter module is enabled. this i tested with versions 3.1 3.2 i am checking if i can get the gdb for all this.
>
> I was unable to build it yet for 3.3.0
>
> thank you
>
> O
>
> On Jun 30, 2012, at 8:54 PM, Omar Labs 188 Gmail wrote:
>
>> Just to let you know
>>
>> I made a lot of tests using different modules including carrierroute, I do have the bus error also after the first call and core dump.
>>
>>
>> thank you
>> O
>>
>>
>>
>>
>>
>> On Jun 27, 2012, at 11:45 PM, Akan wrote:
>>
>>> Daniel,
>>>
>>> i did a repull from git, compiled, installed and re-test of Kamailio and got the same error in the same program's location as previous (in tm_funcs.c). Here are the commands that I entered to make sure I did everything correctly:
>>>
>>> mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignment
>>> cd /usr/local/src/kamailio/kamailio-3.2-noalignment
>>> git clone --depth 1 git://git.sip-router.org/sip-router kamailio
>>> cd kamailio
>>> |gmake proper
>>> gmake prefix=/opt/kamailio-3.2 FLAVOUR=kamailio cfg
>>> vi modules.lst
>>> | gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all
>>> |gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs install
>>>
>>> Makefile:363: config.mak: No such file or directory
>>> normal Makefile.defs exec
>>> target architecture <sparc64>, host architecture <sparc64>
>>> generating autover.h ...
>>> making config...
>>> Makefile.defs defs skipped
>>> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c endianness.c -o endianness.o -MMD -MP
>>> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c select_buf.c -o select_buf.o -MMD -MP
>>>
>>> ||
>>> Thanks
>>>
>>> Nathaniel
>>>
>>> |
>>> On 6/25/2012 3:05 AM, Daniel-Constantin Mierla wrote:
>>>> Hello,
>>>>
>>>> thanks for troubleshooting further -- as I expected, it is a memalign problem, but some confusing reports by not using always the patches I made to registrar module to align the structure, made thinking is something else. Now is no longer in registrar, but in another module.
>>>>
>>>> There might be many of these, can you try to compile first without strict alignment to 8 bytes? Checking quickly to gcc, the option should be |-mno-faster-structs
>>>>
>>>> So try:
>>>>
>>>> make proper
>>>> make FLAVOUR=kamailio cfg|
>>>> make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all|
>>>> ...
>>>>
>>>> By providing Q=0, you will see all compile flags, verify that |-mno-faster-structs is there.
>>>>
>>>> Cheers,
>>>> Daniel
>>>> |
>>>> On 6/22/12 3:26 PM, Akan wrote:
>>>>> Hello,
>>>>>
>>>>> After doing some research, this is what I found out. On Solaris Sparc 64bit system, there is a mandatory alignment of memory accesses and also for data types. I went thru the core dump, disassembled the code and located the instruction that produced the error. The registers addresses in questioned are on a 4 byte alignment but not an 8 byte or 16 byte alignment. .The earlier patch must have forced the alignment which is why the error did not occur in the program common.c. It looks like there is a similar situation in t_funcs.c.
>>>>>
>>>>> Here is a link that I found that can better explain:
>>>>> http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html
>>>>>
>>>>> Core was generated by `/opt/kamailio-3.2/sbin/kamailio'.
>>>>> Program terminated with signal 10, Bus error.
>>>>> #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, proto=0, replicate=0) at t_funcs.c:352
>>>>> 352 if (!t_reply( t, p_msg , 100 ,
>>>>>
>>>>> 0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1
>>>>> 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1
>>>>> 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 <t_reply at plt>
>>>>> *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3*
>>>>> 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0
>>>>> 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14 <t_relay_to+1844>
>>>>> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0
>>>>> 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460 <t_relay_to+128>
>>>>>
>>>>> End of assembler dump.
>>>>> (gdb) info registers g1
>>>>> g1 0xffffffff7666c3e4 -2308520988
>>>>> (gdb) info registers o3
>>>>> o3 0x18f3d0 1635280
>>>>>
>>>>> I hope this helps in trying to resolve this problem and to find a solution. Also, if you need a sparc system to test with, just let me know. We can help from a sparc perspective.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Nathaniel
>>>>>
>>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierla -http://www.asipto.com
>>>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>>>
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>>> Version: 2012.0.2180 / Virus Database: 2437/5091 - Release Date: 06/24/12
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Mon Jul 2 21:29:30 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 02 Jul 2012 21:29:30 +0200
Subject: [SR-Users] Kamailio Unexpectedly Terminating
In-Reply-To: <4FEBD368.1050204@akan.net>
References: <4F98539A.3080307@akan.net> <4F990A47.9080904@gmail.com>
<4F99A51B.3040909@akan.net> <4F9C1F7C.2080204@akan.net>
<4F9D0BF5.10506@gmail.com> <4FA341FA.3070606@akan.net>
<4FA38B8E.9020900@gmail.com> <4FA5475D.60104@akan.net>
<4FAA2555.1050903@gmail.com> <4FAABCDE.1040305@akan.net>
<4FBC876A.2020907@akan.net> <4FC48EFC.8050605@akan.net>
<4FC49397.3040806@gmail.com> <4FC58569.1060201@akan.net>
<4FC634F3.3020802@gmail.com> <4FC67090.6000306@akan.net>
<4FC67440.1030300@gmail.com> <4FCA7968.90008@akan.net>
<4FCC5C64.90401@gmail.com> <4FD5F395.20308@gmail.com>
<4FD64332.3030104@akan.net> <4FD6E6C9.8050301@gmail.com>
<4FD78614.7020708@akan.net> <4FD7D91A.9070803@akan.net>
<4FE47283.9090700@akan.net> <4FE81BE0.5070802@gmail.com>
<4FEBD368.1050204@akan.net>
Message-ID: <4FF1F69A.20302@gmail.com>
Hello,
you will have to read the manual of the compiler and the specifics of
the operating system to build it without 64b alignment requirements. I
attempted to find it on the web, bit it may have not been the right one.
Cheers,
Daniel
On 6/28/12 5:45 AM, Akan wrote:
> Daniel,
>
> i did a repull from git, compiled, installed and re-test of Kamailio
> and got the same error in the same program's location as previous (in
> tm_funcs.c). Here are the commands that I entered to make sure I did
> everything correctly:
>
> mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignment
> cd /usr/local/src/kamailio/kamailio-3.2-noalignment
> git clone --depth 1 git://git.sip-router.org/sip-router kamailio
> cd kamailio
> |gmake proper
> gmake prefix=/opt/kamailio-3.2 FLAVOUR=kamailio cfg
> vi modules.lst
> | gmake prefix=/opt/kamailio-3.2 Q=0
> CC_EXTRA_OPTS=|-mno-faster-structs all
> |gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs
> install
>
> Makefile:363: config.mak: No such file or directory
> normal Makefile.defs exec
> target architecture <sparc64>, host architecture <sparc64>
> generating autover.h ...
> making config...
> Makefile.defs defs skipped
> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc
> -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs
> -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_'
> -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64
> -D__OS_solaris -DSER_VER=3002003
> -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM
> -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP
> -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER
> -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS
> -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024
> -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME
> -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION
> -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c endianness.c -o
> endianness.o -MMD -MP
> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc
> -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs
> -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_'
> -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64
> -D__OS_solaris -DSER_VER=3002003
> -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM
> -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP
> -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER
> -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS
> -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024
> -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME
> -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION
> -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c select_buf.c -o
> select_buf.o -MMD -MP
>
> ||
> Thanks
>
> Nathaniel
>
> |
> On 6/25/2012 3:05 AM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> thanks for troubleshooting further -- as I expected, it is a memalign
>> problem, but some confusing reports by not using always the patches I
>> made to registrar module to align the structure, made thinking is
>> something else. Now is no longer in registrar, but in another module.
>>
>> There might be many of these, can you try to compile first without
>> strict alignment to 8 bytes? Checking quickly to gcc, the option
>> should be |-mno-faster-structs
>>
>> So try:
>>
>> make proper
>> make FLAVOUR=kamailio cfg|
>> make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all|
>> ...
>>
>> By providing Q=0, you will see all compile flags, verify that
>> |-mno-faster-structs is there.
>>
>> Cheers,
>> Daniel
>> |
>> On 6/22/12 3:26 PM, Akan wrote:
>>> Hello,
>>>
>>> After doing some research, this is what I found out. On Solaris
>>> Sparc 64bit system, there is a mandatory alignment of memory
>>> accesses and also for data types. I went thru the core dump,
>>> disassembled the code and located the instruction that produced the
>>> error. The registers addresses in questioned are on a 4 byte
>>> alignment but not an 8 byte or 16 byte alignment. .The earlier patch
>>> must have forced the alignment which is why the error did not occur
>>> in the program common.c. It looks like there is a similar situation
>>> in t_funcs.c.
>>>
>>> Here is a link that I found that can better explain:
>>> http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html
>>>
>>> Core was generated by `/opt/kamailio-3.2/sbin/kamailio'.
>>> Program terminated with signal 10, Bus error.
>>> #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0,
>>> proto=0, replicate=0) at t_funcs.c:352
>>> 352 if (!t_reply( t, p_msg , 100 ,
>>>
>>> 0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1
>>> 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1
>>> 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 <t_reply at plt>
>>> *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3*
>>> 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0
>>> 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14
>>> <t_relay_to+1844>
>>> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0
>>> 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460
>>> <t_relay_to+128>
>>>
>>> End of assembler dump.
>>> (gdb) info registers g1
>>> g1 0xffffffff7666c3e4 -2308520988
>>> (gdb) info registers o3
>>> o3 0x18f3d0 1635280
>>>
>>> I hope this helps in trying to resolve this problem and to find a
>>> solution. Also, if you need a sparc system to test with, just let me
>>> know. We can help from a sparc perspective.
>>>
>>> Thanks
>>>
>>> Nathaniel
>>>
>>>
>>
>>
>> --
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012
>> -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012
>> -http://asipto.com/u/kpw
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2012.0.2180 / Virus Database: 2437/5091 - Release Date:
>> 06/24/12
>>
>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Mon Jul 2 21:34:52 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 02 Jul 2012 21:34:52 +0200
Subject: [SR-Users] Binding arbitrary TLS socket
In-Reply-To: <4FEC6D09.8000908@sipwise.com>
References: <4FEC6BAE.2080007@sipwise.com> <4FEC6D09.8000908@sipwise.com>
Message-ID: <4FF1F7DC.8030705@gmail.com>
Hello,
On 6/28/12 4:41 PM, Andreas Granig wrote:
> On 06/28/2012 04:35 PM, Andreas Granig wrote:
>> Got some problems when I tried this, not sure how this is intended to work:
>>
>> listen=tls:192.168.51.133:4343
>>
>> When starting kamailio 3.3, I get the following error:
>>
>> ERROR: <core> [tcp_main.c:2915]: ERROR: tcp_init: bind(10,
>> 0x7f5eea45db24, 16) on 192.168.51.133:4343 : Address already in use
>> ERROR: tls [tls_init.c:314]: Error while initializing TCP part of TLS
>> socket 192.168.51.133:4343
>>
>> What works though is if I explicitely bind a TCP socket one port below
>> the TLS socket, like this:
>>
>> listen=tcp:192.168.51.133:4342
>> listen=tls:192.168.51.133:4343
>>
>> Is this how it's intended to work? Is there a specific reason for this
>> behavior?
> Hmmmm, tried playing around with odd and even ports for tls, and now it
> also works with the original approach from above (binding to TLS without
> binding a TCP socket one port below that).
>
> Maybe there was something wrong with my system somewhere (an old socket
> still in use or something, although netstat didn't show up anything).
> Does kamailio reuse old sockets for TCP/TLS?
grepping for SO_REUSEADDR flag revealed it is in use, but haven't looked
in the code to see if it depends on other conditions.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From Auro.Tripathy at wdc.com Tue Jul 3 02:25:58 2012
From: Auro.Tripathy at wdc.com (Auro Tripathy)
Date: Tue, 3 Jul 2012 00:25:58 +0000
Subject: [SR-Users] Does there exist a tutorial on the Kamailio SIP/XMPP
Gateway configuration?
Message-ID: <EB778D84070B8843BF00498252ABA0624320C9A0@WDKSJEXMB02.msj.wdc.com>
I'm finding that I may have to piece together (the configuration info) from version emails/presentations.
Reluctantly, I'll take that approach...unless someone has a lucid HOWTO on the topic?
Again, I'm new to the domain and I appreciate the subject-matter experts that have helped out so far.
-Auro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120703/e1374383/attachment.htm>
From timo.teras at iki.fi Tue Jul 3 08:02:34 2012
From: timo.teras at iki.fi (Timo Teras)
Date: Tue, 3 Jul 2012 09:02:34 +0300
Subject: [SR-Users] uac module From header rewriting problems
Message-ID: <20120703090234.3937cb50@vostro>
Hi,
I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
however even with the latest versions I'm still seeing corruption in
From headers when they are rewritten for the whole dialogue
(from_restore_mode=auto, the default).
I spent some time analyzing the problem and the problem seems to be
connected with the fact that only the bitwise difference of the
original and modified URI are stored (XOR). The only purpose for this
appears to be the idea to save only the difference in the rr params
instead of two full URIs.
However, it appears that in many cases (especially call transfer) the
From header will be altered during dialogue. This is explicitly allowed
in RFC 3261 ? 20.20:
The From header field indicates the initiator of the request. This
may be different from the initiator of the dialog.
I've seen this in practise with few commercial SIP stacks. Sometimes
the changes are minor, or even trivial - but with the difference
encoding having even one character changed (e.g. case), being deleted or
added will result in the whole header being corrupted.
I'm now wondering if we should just store both URIs in the rr params.
While taking little more space, it should fix us sending garbage to the
wire (which usually results in dropped call as the remote will reject
the garbage messages).
Any better ideas?
Cheers,
Timo
From miconda at gmail.com Tue Jul 3 12:16:38 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 03 Jul 2012 12:16:38 +0200
Subject: [SR-Users] uac module From header rewriting problems
In-Reply-To: <20120703090234.3937cb50@vostro>
References: <20120703090234.3937cb50@vostro>
Message-ID: <4FF2C686.5030205@gmail.com>
Hello,
On 7/3/12 8:02 AM, Timo Teras wrote:
> Hi,
>
> I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
> however even with the latest versions I'm still seeing corruption in
> From headers when they are rewritten for the whole dialogue
> (from_restore_mode=auto, the default).
>
> I spent some time analyzing the problem and the problem seems to be
> connected with the fact that only the bitwise difference of the
> original and modified URI are stored (XOR). The only purpose for this
> appears to be the idea to save only the difference in the rr params
> instead of two full URIs.
>
> However, it appears that in many cases (especially call transfer) the
> From header will be altered during dialogue. This is explicitly allowed
> in RFC 3261 ? 20.20:
> The From header field indicates the initiator of the request. This
> may be different from the initiator of the dialog.
>
> I've seen this in practise with few commercial SIP stacks. Sometimes
> the changes are minor, or even trivial - but with the difference
> encoding having even one character changed (e.g. case), being deleted or
> added will result in the whole header being corrupted.
>
> I'm now wondering if we should just store both URIs in the rr params.
> While taking little more space, it should fix us sending garbage to the
> wire (which usually results in dropped call as the remote will reject
> the garbage messages).
>
> Any better ideas?
it makes sense storing the entire value. Not sure if anyone else will
want to be made configurable via mod param, I will go for simplest
approach and have only the correct option, it will help in code maintenance.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Tue Jul 3 12:25:06 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 03 Jul 2012 12:25:06 +0200
Subject: [SR-Users] Releasing v3.1.6 - end of packaging maintenance for 3.1
branch
Message-ID: <4FF2C882.4040006@gmail.com>
Hello,
in the near future I will package 3.1.6 to mark the end of releasing
from 3.1 branch. Of course, patches can still go into that branch, but
there is no intent to package again from it.
If anyone is willing to push other commits before the packages, please
do it in then next 1-2 days. I will do it when I get enough spare time
for it, with a short notice before it in that day.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From niklas at tese.se Tue Jul 3 14:34:01 2012
From: niklas at tese.se (Niklas Larsson)
Date: Tue, 03 Jul 2012 14:34:01 +0200
Subject: [SR-Users] Event when location expires?
Message-ID: <4FF2E6B9.2050809@tese.se>
Hi all,
is there a way to get a event / log / something when an registry expires?
/niklas
From timo.teras at iki.fi Tue Jul 3 15:49:31 2012
From: timo.teras at iki.fi (Timo Teras)
Date: Tue, 3 Jul 2012 16:49:31 +0300
Subject: [SR-Users] uac module From header rewriting problems
In-Reply-To: <4FF2C686.5030205@gmail.com>
References: <20120703090234.3937cb50@vostro>
<4FF2C686.5030205@gmail.com>
Message-ID: <20120703164931.0bae88b3@vostro>
On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Hello,
>
> On 7/3/12 8:02 AM, Timo Teras wrote:
> > Hi,
> >
> > I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
> > however even with the latest versions I'm still seeing corruption in
> > From headers when they are rewritten for the whole dialogue
> > (from_restore_mode=auto, the default).
> >
> > I spent some time analyzing the problem and the problem seems to be
> > connected with the fact that only the bitwise difference of the
> > original and modified URI are stored (XOR). The only purpose for
> > this appears to be the idea to save only the difference in the rr
> > params instead of two full URIs.
> >
> > However, it appears that in many cases (especially call transfer)
> > the From header will be altered during dialogue. This is explicitly
> > allowed in RFC 3261 ? 20.20:
> > The From header field indicates the initiator of the request.
> > This may be different from the initiator of the dialog.
> >
> > I've seen this in practise with few commercial SIP stacks. Sometimes
> > the changes are minor, or even trivial - but with the difference
> > encoding having even one character changed (e.g. case), being
> > deleted or added will result in the whole header being corrupted.
> >
> > I'm now wondering if we should just store both URIs in the rr
> > params. While taking little more space, it should fix us sending
> > garbage to the wire (which usually results in dropped call as the
> > remote will reject the garbage messages).
> >
> > Any better ideas?
>
> it makes sense storing the entire value. Not sure if anyone else will
> want to be made configurable via mod param, I will go for simplest
> approach and have only the correct option, it will help in code
> maintenance.
Sounds good. Should probably do it for the stable branches too. I can
help with some of this, if needed. You have any estimate for the fix?
- Timo
From Gary.Chen at lightyear.net Tue Jul 3 15:52:06 2012
From: Gary.Chen at lightyear.net (Gary Chen)
Date: Tue, 3 Jul 2012 09:52:06 -0400
Subject: [SR-Users] ACK and BYE messages uses wrong socket.
Message-ID: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A58@lyepkyexc.LYEPLYEXC.local>
Kamailio 3.2.0
I am trying to setup kamailio to do the sip trunking. It receive the sip traffic from customer and then send it to carrier.
I have two NIC interface's assigned with three IP's:
Interface 1: ( Public IP's)
x.x.130.34
x.x.130.36 floating IP
interface 2: (private IP's)
10.10.1.31
.36 is a floating IP assigned by Linux-HA (heartbeat/pacemaker).
I only want to use .36 to receive and send sip traffic.
I uses force_send_socket() to send INVITE with .36 IP. But the ACK message always want to use .34 IP even the Route header has .36 in it unless I force it with force_send_socket() .
How can I fix this problem?
See below for the SIP messages: (x.x.128.205 is customer IP, x.x.129.200 is PSTN gateway IP)
U x.x.128.205:51694 -> x.x.130.36:5060
INVITE sip:5033441174 at x.x.130.36:5060 SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG
4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.3
6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20
5..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254113-3191264919-256
0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, CO
MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forwards: 70..Remote-P
arty-ID: <sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Timestamp: 1341322661
..Contact: <sip:5024427578 at x.x.128.205:5060>..Expires: 180..Allow-Events: telephone-event..Conte
nt-Type: application/sdp..Content-Length: 366....v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio 19312 RTP/AVP 125 0 18 100 10
1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8000..a
=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=rtpmap:101 telephone-event/8000
..a=fmtp:101 0-16..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9
hG4bK1D3CD1;rport=51694..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:502244117
4 at x.x.130.36>..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq: 101 INVITE..Se
rver: LVS Proxy 1.0..Content-Length: 0....
#
U x.x.130.36:5060 -> x.x.129.200:5060
INVITE sip:15033441174 at x.x.129.200:5060 SIP/2.0..Record-Route: <sip:x.x.130.36;lr=on>..Via: S
IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport
=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:50224
41174 at x.x.130.36>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
E39A at x.x.128.205..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254
113-3191264919-2560877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANC
EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forw
ards: 69..Remote-Party-ID: <sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Tim
estamp: 1341322661..Contact: <sip:5024427578 at x.x.128.205:51694>..Expires: 180..Allow-Events: tel
ephone-event..Content-Type: application/sdp..Content-Length: 375....v=0..o=CiscoSystemsSIP-GW-UserA
gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4 10.200.1.51..t=0 0..m=audio 20464 RTP/AVP 12
5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G7
29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=rtpmap:101 telephone-
event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP 216.4
9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>;tag=24513088
-D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Cal
l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp: 1341322661..Server: Cisco-SIPG
ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events: telephone-event..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/
UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>;ta
g=24513088-D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:4
1 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp: 1341322661..Server:
Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq: 6708..Allow: INVITE, OPTIONS, B
YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: tele
phone-event..Contact: <sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>..Content-Disposition: session;handling=required..Content-Type: application/sdp..Content-Length: 2
90....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP Call..c=IN IP4 216
.49.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 x.x.129.200..a=rtpmap:0 PCMU/8000.
.a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD
1..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>;tag=F
0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at 216.
49.128.205..Timestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 10
0rel..RSeq: 6708..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact: <sip:15033441174 at x.x.129.200:50
60>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Disposition: session;handling=required..Conte
nt-Type: application/sdp..Content-Length: 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN I
P4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480 RTP/AVP 0 101 100..c=IN
IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpm
ap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
#
U x.x.128.205:51694 -> x.x.130.36:5060
PRACK sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9h
G4bK1D4474..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.
36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
E39A at x.x.128.205..CSeq: 102 PRACK..RAck: 6708 101 INVITE..Route: <sip:x.x.130.36;lr=on>..Max-
Forwards: 70..Content-Length: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
PRACK sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bK92c
e.4def8436.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:50
24427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Dat
e: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq
: 102 PRACK..RAck: 6708 101 INVITE..Max-Forwards: 69..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.34:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bK92ce.4def8436.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59
..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID
: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 102
PRACK..Content-Length: 0....
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:
5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se
rver: Cisco-SIPGateway/IOS-12.x..CSeq: 102 PRACK..Content-Length: 0....
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59
..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID
: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp: 1341322661..Server: Cisco-SIPGatew
ay/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSC
RIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact: <sip:15033441174 at 216.
49.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Type: application/sdp..Content-L
ength: 290....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP Call..c=IN
IP4 x.x.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 x.x.129.200..a=rtpmap:0 PC
MU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 19
2-194..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:
5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti
mestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, B
YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: tele
phone-event..Contact: <sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>..Content-Type: application/sdp..Content-Length: 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2
116 IN IP4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480 RTP/AVP 0 101 10
0..c=IN IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16
..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
#
U x.x.128.205:51694 -> x.x.130.36:5060
ACK sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG4
bK1D5DA6..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36
>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E3
9A at x.x.128.205..Route: <sip:x.x.130.36;lr=on>..Max-Forwards: 70..CSeq: 101 ACK..Content-Lengt
h: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
ACK sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKcydzi
gwkX..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D5DA6..From: <sip:5024427578
@x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue,
03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards
: 69..CSeq: 101 ACK..Content-Length: 0....
#
U x.x.128.205:51694 -> x.x.130.36:5060
BYE sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG4
bK1D61CE7..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.3
6>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E
39A at x.x.128.205..User-Agent: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 70..Route: <sip:x.x.130
.36;lr=on>..Timestamp: 1341322666..CSeq: 103 BYE..Reason: Q.850;cause=16..Content-Length: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
BYE sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKa2ce.
4ba2ee65.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:502
4427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date
: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User-
Agent: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 69..Timestamp: 1341322666..CSeq: 103 BYE..Reason: Q
.850;cause=16..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.34:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKa2ce.4ba2ee65.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D5
9..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-I
D: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server: Cisco-SIPGateway/IOS-12.x..Timestamp
: 1341322666..Content-Length: 0..CSeq: 103 BYE....
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip
:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..
Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S
erver: Cisco-SIPGateway/IOS-12.x..Timestamp: 1341322666..Content-Length: 0..CSeq: 103 BYE....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120703/9efdc3e3/attachment-0001.htm>
From miconda at gmail.com Tue Jul 3 16:23:45 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 03 Jul 2012 16:23:45 +0200
Subject: [SR-Users] uac module From header rewriting problems
In-Reply-To: <20120703164931.0bae88b3@vostro>
References: <20120703090234.3937cb50@vostro> <4FF2C686.5030205@gmail.com>
<20120703164931.0bae88b3@vostro>
Message-ID: <4FF30071.9060803@gmail.com>
On 7/3/12 3:49 PM, Timo Teras wrote:
> On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla
> <miconda at gmail.com> wrote:
>
>> Hello,
>>
>> On 7/3/12 8:02 AM, Timo Teras wrote:
>>> Hi,
>>>
>>> I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
>>> however even with the latest versions I'm still seeing corruption in
>>> From headers when they are rewritten for the whole dialogue
>>> (from_restore_mode=auto, the default).
>>>
>>> I spent some time analyzing the problem and the problem seems to be
>>> connected with the fact that only the bitwise difference of the
>>> original and modified URI are stored (XOR). The only purpose for
>>> this appears to be the idea to save only the difference in the rr
>>> params instead of two full URIs.
>>>
>>> However, it appears that in many cases (especially call transfer)
>>> the From header will be altered during dialogue. This is explicitly
>>> allowed in RFC 3261 ? 20.20:
>>> The From header field indicates the initiator of the request.
>>> This may be different from the initiator of the dialog.
>>>
>>> I've seen this in practise with few commercial SIP stacks. Sometimes
>>> the changes are minor, or even trivial - but with the difference
>>> encoding having even one character changed (e.g. case), being
>>> deleted or added will result in the whole header being corrupted.
>>>
>>> I'm now wondering if we should just store both URIs in the rr
>>> params. While taking little more space, it should fix us sending
>>> garbage to the wire (which usually results in dropped call as the
>>> remote will reject the garbage messages).
>>>
>>> Any better ideas?
>> it makes sense storing the entire value. Not sure if anyone else will
>> want to be made configurable via mod param, I will go for simplest
>> approach and have only the correct option, it will help in code
>> maintenance.
> Sounds good. Should probably do it for the stable branches too. I can
> help with some of this, if needed. You have any estimate for the fix?
I just expressed my opinion on how to fix it, but there is no plan for
me to work on it in the near future, being caught in other tasks and
traveling. So you can go ahead and make a patch to fix it for master,
then later, based on the impact, it can be backported.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From vitalik.voip at gmail.com Tue Jul 3 16:26:49 2012
From: vitalik.voip at gmail.com (Vitaliy Aleksandrov)
Date: Tue, 03 Jul 2012 17:26:49 +0300
Subject: [SR-Users] ACK and BYE messages uses wrong socket.
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A58@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A58@lyepkyexc.LYEPLYEXC.local>
Message-ID: <4FF30129.60905@gmail.com>
Have you specified interfaces with "listen" command ?
I had a problem as you described and have fixed it by moving a listen
directive with a "floating ip" to the top of the list.
So you can try to specify interfaces you will use for SIP and set a
"virtual ip" at the top of that list.
> Kamailio 3.2.0
>
> I am trying to setup kamailio to do the sip trunking. It receive the
> sip traffic from customer and then send it to carrier.
>
> I have two NIC interface's assigned with three IP's:
>
> Interface 1: ( Public IP's)
>
> x.x.130.34
>
> x.x.130.36 floating IP
>
> interface 2: (private IP's)
>
> 10.10.1.31
>
> .36 is a floating IP assigned by Linux-HA (heartbeat/pacemaker).
>
> I only want to use .36 to receive and send sip traffic.
>
> I uses force_send_socket() to send INVITE with .36 IP. But the ACK
> message always want to use .34 IP even the Route header has .36 in it
> unless I force it with force_send_socket() .
>
> How can I fix this problem?
>
> See below for the SIP messages: (x.x.128.205 is customer IP,
> x.x.129.200 is PSTN gateway IP)
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> INVITE sip:5033441174 at x.x.130.36:5060 SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG
>
> 4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.3
>
> 6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20
>
> 5..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid:
> 411443261-3293254113-3191264919-256
>
> 0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE,
> OPTIONS, BYE, CANCEL, ACK, PRACK, CO
>
> MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101
> INVITE..Max-Forwards: 70..Remote-P
>
> arty-ID:
> <sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Timestamp:
> 1341322661
>
> ..Contact: <sip:5024427578 at x.x.128.205:5060>..Expires:
> 180..Allow-Events: telephone-event..Conte
>
> nt-Type: application/sdp..Content-Length:
> 366....v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
>
> 4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio
> 19312 RTP/AVP 125 0 18 100 10
>
> 1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0
> PCMU/8000..a=rtpmap:18 G729/8000..a
>
> =fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100
> 192-194..a=rtpmap:101 telephone-event/8000
>
> ..a=fmtp:101 0-16..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 100 trying -- your call is important to us..Via:
> SIP/2.0/UDP x.x.128.205:5060;branch=z9
>
> hG4bK1D3CD1;rport=51694..From:
> <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:502244117
>
> 4 at x.x.130.36>..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq: 101 INVITE..Se
>
> rver: LVS Proxy 1.0..Content-Length: 0....
>
> #
>
> U x.x.130.36:5060 -> x.x.129.200:5060
>
> INVITE sip:15033441174 at x.x.129.200:5060 SIP/2.0..Record-Route:
> <sip:x.x.130.36;lr=on>..Via: S
>
> IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via:
> SIP/2.0/UDP x.x.128.205:5060;rport
>
> =51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:50224
>
> 41174 at x.x.130.36>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3
>
> E39A at x.x.128.205..Supported: 100rel,timer,replaces..Min-SE:
> 1800..Cisco-Guid: 411443261-3293254
>
> 113-3191264919-2560877466..User-Agent:
> Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANC
>
> EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE,
> REGISTER..CSeq: 101 INVITE..Max-Forw
>
> ards: 69..Remote-Party-ID:
> <sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Tim
>
> estamp: 1341322661..Contact:
> <sip:5024427578 at x.x.128.205:51694>..Expires: 180..Allow-Events: tel
>
> ephone-event..Content-Type: application/sdp..Content-Length:
> 375....v=0..o=CiscoSystemsSIP-GW-UserA
>
> gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4
> 10.200.1.51..t=0 0..m=audio 20464 RTP/AVP 12
>
> 5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125
> X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G7
>
> 29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100
> 192-194..a=rtpmap:101 telephone-
>
> event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 100 Trying..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP 216.4
>
> 9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205>;tag=24513088
>
> -D59..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue,
> 03 Jul 2012 13:37:41 GMT..Cal
>
> l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp:
> 1341322661..Server: Cisco-SIPG
>
> ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events:
> telephone-event..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/
>
> UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205>;ta
>
> g=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012
> 13:37:4
>
> 1 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp:
> 1341322661..Server:
>
> Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq:
> 6708..Allow: INVITE, OPTIONS, B
>
> YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO,
> UPDATE, REGISTER..Allow-Events: tele
>
> phone-event..Contact:
> <sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>
> >..Content-Disposition: session;handling=required..Content-Type:
> application/sdp..Content-Length: 2
>
> 90....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4
> x.x.129.200..s=SIP Call..c=IN IP4 216
>
> .49.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4
> x.x.129.200..a=rtpmap:0 PCMU/8000.
>
> .a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100
> X-NSE/8000..a=fmtp:100 192-194..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD
>
> 1..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>;tag=F
>
> 0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at 216.
>
> 49.128.205..Timestamp: 1341322661..Server:
> Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 10
>
> 0rel..RSeq: 6708..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK,
> COMET, REFER, SUBSCRIBE, NOTIFY,
>
> INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact:
> <sip:15033441174 at x.x.129.200:50
>
> 60>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Disposition:
> session;handling=required..Conte
>
> nt-Type: application/sdp..Content-Length:
> 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN I
>
> P4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480
> RTP/AVP 0 101 100..c=IN
>
> IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101
> telephone-event/8000..a=fmtp:101 0-16..a=rtpm
>
> ap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> PRACK sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9h
>
> G4bK1D4474..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.
>
> 36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3
>
> E39A at x.x.128.205..CSeq: 102 PRACK..RAck: 6708 101 INVITE..Route:
> <sip:x.x.130.36;lr=on>..Max-
>
> Forwards: 70..Content-Length: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> PRACK sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bK92c
>
> e.4def8436.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:50
>
> 24427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Dat
>
> e: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq
>
> : 102 PRACK..RAck: 6708 101 INVITE..Max-Forwards:
> 69..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.34:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bK92ce.4def8436.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D4474..From:
> <sip:5024427578 at x.x.128.205>;tag=24513088-D59
>
> ..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03
> Jul 2012 13:37:41 GMT..Call-ID
>
> : 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server:
> Cisco-SIPGateway/IOS-12.x..CSeq: 102
>
> PRACK..Content-Length: 0....
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:
>
> 5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
>
> ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se
>
> rver: Cisco-SIPGateway/IOS-12.x..CSeq: 102 PRACK..Content-Length: 0....
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205>;tag=24513088-D59
>
> ..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03
> Jul 2012 13:37:41 GMT..Call-ID
>
> : 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp:
> 1341322661..Server: Cisco-SIPGatew
>
> ay/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, BYE, CANCEL,
> ACK, PRACK, COMET, REFER, SUBSC
>
> RIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events:
> telephone-event..Contact: <sip:15033441174 at 216.
>
> 49.129.200:5060>..Record-Route:
> <sip:x.x.130.36;lr=on>..Content-Type: application/sdp..Content-L
>
> ength: 290....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4
> x.x.129.200..s=SIP Call..c=IN
>
> IP4 x.x.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4
> x.x.129.200..a=rtpmap:0 PC
>
> MU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101
> 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 19
>
> 2-194..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:
>
> 5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
>
> ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti
>
> mestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101
> INVITE..Allow: INVITE, OPTIONS, B
>
> YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO,
> UPDATE, REGISTER..Allow-Events: tele
>
> phone-event..Contact:
> <sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>
> >..Content-Type: application/sdp..Content-Length:
> 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2
>
> 116 IN IP4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0
> 0..m=audio 19480 RTP/AVP 0 101 10
>
> 0..c=IN IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101
> telephone-event/8000..a=fmtp:101 0-16
>
> ..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> ACK sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG4
>
> bK1D5DA6..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36
>
> >;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E3
>
> 9A at x.x.128.205..Route: <sip:x.x.130.36;lr=on>..Max-Forwards:
> 70..CSeq: 101 ACK..Content-Lengt
>
> h: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> ACK sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKcydzi
>
> gwkX..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D5DA6..From: <sip:5024427578
>
> @x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue,
>
> 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards
>
> : 69..CSeq: 101 ACK..Content-Length: 0....
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> BYE sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG4
>
> bK1D61CE7..From: <sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.3
>
> 6>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E
>
> 39A at x.x.128.205..User-Agent:
> Cisco-SIPGateway/IOS-12.x..Max-Forwards: 70..Route: <sip:x.x.130
>
> .36;lr=on>..Timestamp: 1341322666..CSeq: 103 BYE..Reason:
> Q.850;cause=16..Content-Length: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> BYE sip:15033441174 at x.x.129.200:5060 SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKa2ce.
>
> 4ba2ee65.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:502
>
> 4427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date
>
> : Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User-
>
> Agent: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 69..Timestamp:
> 1341322666..CSeq: 103 BYE..Reason: Q
>
> .850;cause=16..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.34:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKa2ce.4ba2ee65.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From:
> <sip:5024427578 at x.x.128.205>;tag=24513088-D5
>
> 9..To: <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03
> Jul 2012 13:37:46 GMT..Call-I
>
> D: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server:
> Cisco-SIPGateway/IOS-12.x..Timestamp
>
> : 1341322666..Content-Length: 0..CSeq: 103 BYE....
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip
>
> :5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>;tag=F0695368-74F..
>
> Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S
>
> erver: Cisco-SIPGateway/IOS-12.x..Timestamp:
> 1341322666..Content-Length: 0..CSeq: 103 BYE....
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120703/df5c829f/attachment-0001.htm>
From miconda at gmail.com Tue Jul 3 16:27:32 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 03 Jul 2012 16:27:32 +0200
Subject: [SR-Users] Event when location expires?
In-Reply-To: <4FF2E6B9.2050809@tese.se>
References: <4FF2E6B9.2050809@tese.se>
Message-ID: <4FF30154.2020200@gmail.com>
Hello,
On 7/3/12 2:34 PM, Niklas Larsson wrote:
> Hi all,
>
> is there a way to get a event / log / something when an registry expires?
do you want for timer based expiration or for un-registration as well?
iirc, the is a log message, but printed as debug, you can change the
sources is you need. Then, maybe using pua_usrloc could be useful, as it
triggers a PUBLISH with each usrloc event...
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From Gary.Chen at lightyear.net Tue Jul 3 16:52:56 2012
From: Gary.Chen at lightyear.net (Gary Chen)
Date: Tue, 3 Jul 2012 10:52:56 -0400
Subject: [SR-Users] ACK and BYE messages uses wrong socket.
In-Reply-To: <4FF30129.60905@gmail.com>
References: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A58@lyepkyexc.LYEPLYEXC.local>
<4FF30129.60905@gmail.com>
Message-ID: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A6E@lyepkyexc.LYEPLYEXC.local>
Yes, I did the same thing as you mentioned and it still doing the same thing. Here is my setup:
mhomed=1
listen=udp:x.x.130.36:5060 # external IP
listen=udp:x.x.130.34:5060 # external IP
listen=udp:10.200.1.31:5060 # internal IP
If I removed .130.34, I got error saying no socket found.
Gary Chen
From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Vitaliy Aleksandrov
Sent: Tuesday, July 03, 2012 10:27 AM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Subject: Re: [SR-Users] ACK and BYE messages uses wrong socket.
Have you specified interfaces with "listen" command ?
I had a problem as you described and have fixed it by moving a listen directive with a "floating ip" to the top of the list.
So you can try to specify interfaces you will use for SIP and set a "virtual ip" at the top of that list.
Kamailio 3.2.0
I am trying to setup kamailio to do the sip trunking. It receive the sip traffic from customer and then send it to carrier.
I have two NIC interface's assigned with three IP's:
Interface 1: ( Public IP's)
x.x.130.34
x.x.130.36 floating IP
interface 2: (private IP's)
10.10.1.31
.36 is a floating IP assigned by Linux-HA (heartbeat/pacemaker).
I only want to use .36 to receive and send sip traffic.
I uses force_send_socket() to send INVITE with .36 IP. But the ACK message always want to use .34 IP even the Route header has .36 in it unless I force it with force_send_socket() .
How can I fix this problem?
See below for the SIP messages: (x.x.128.205 is customer IP, x.x.129.200 is PSTN gateway IP)
U x.x.128.205:51694 -> x.x.130.36:5060
INVITE sip:5033441174 at x.x.130.36:5060<mailto:sip:5033441174 at x.x.130.36:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG
4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.3<mailto:sip:5033441174 at x.x.130.3>
6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20>
5..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254113-3191264919-256
0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, CO
MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forwards: 70..Remote-P
arty-ID: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Timestamp: 1341322661
..Contact: <sip:5024427578 at x.x.128.205:5060><mailto:sip:5024427578 at x.x.128.205:5060>..Expires: 180..Allow-Events: telephone-event..Conte
nt-Type: application/sdp..Content-Length: 366....v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio 19312 RTP/AVP 125 0 18 100 10
1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8000..a
=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=rtpmap:101 telephone-event/8000
..a=fmtp:101 0-16..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9
hG4bK1D3CD1;rport=51694..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:502244117
4 at x.x.130.36<mailto:4 at x.x.130.36>>..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>: 101 INVITE..Se
rver: LVS Proxy 1.0..Content-Length: 0....
#
U x.x.130.36:5060 -> x.x.129.200:5060
INVITE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Record-Route: <sip:x.x.130.36;lr=on>..Via: S
IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport
=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:50224
41174 at x.x.130.36<mailto:41174 at x.x.130.36>>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
E39A at x.x.128.205..Supported<mailto:E39A at x.x.128.205..Supported>: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254
113-3191264919-2560877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANC
EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forw
ards: 69..Remote-Party-ID: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Tim
estamp: 1341322661..Contact: <sip:5024427578 at x.x.128.205:51694><mailto:sip:5024427578 at x.x.128.205:51694>..Expires: 180..Allow-Events: tel
ephone-event..Content-Type: application/sdp..Content-Length: 375....v=0..o=CiscoSystemsSIP-GW-UserA
gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4 10.200.1.51..t=0 0..m=audio 20464 RTP/AVP 12
5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G7
29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=rtpmap:101 telephone-
event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP 216.4
9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088
-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Cal
l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server: Cisco-SIPG
ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events: telephone-event..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/
UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;ta
g=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:4
1 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server:
Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq: 6708..Allow: INVITE, OPTIONS, B
YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: tele
phone-event..Contact: <sip:15033441174 at x.x.129.200:5060><mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>..Content-Disposition: session;handling=required..Content-Type: application/sdp..Content-Length: 2
90....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP Call..c=IN IP4 216
.49.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 x.x.129.200..a=rtpmap:0 PCMU/8000.
.a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD
1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F
0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at 216.
49.128.205..Timestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 10
0rel..RSeq: 6708..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact: <sip:15033441174 at x.x.129.200:50<mailto:sip:15033441174 at x.x.129.200:50>
60>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Disposition: session;handling=required..Conte
nt-Type: application/sdp..Content-Length: 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN I
P4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480 RTP/AVP 0 101 100..c=IN
IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpm
ap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
#
U x.x.128.205:51694 -> x.x.130.36:5060
PRACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9h
G4bK1D4474..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130<mailto:sip:5033441174 at x.x.130>.
36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
E39A at x.x.128.205..CSeq<mailto:E39A at x.x.128.205..CSeq>: 102 PRACK..RAck: 6708 101 INVITE..Route: <sip:x.x.130.36;lr=on>..Max-
Forwards: 70..Content-Length: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
PRACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bK92c
e.4def8436.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:50
24427578 at x.x.128.205<mailto:24427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Dat
e: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>
: 102 PRACK..RAck: 6708 101 INVITE..Max-Forwards: 69..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.34:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bK92ce.4def8436.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID
: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>: Cisco-SIPGateway/IOS-12.x..CSeq: 102
PRACK..Content-Length: 0....
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:
5024427578 at x.x.128.205<mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se>
rver: Cisco-SIPGateway/IOS-12.x..CSeq: 102 PRACK..Content-Length: 0....
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID
: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server: Cisco-SIPGatew
ay/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSC
RIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact: <sip:15033441174 at 216.
49.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Type: application/sdp..Content-L
ength: 290....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP Call..c=IN
IP4 x.x.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 x.x.129.200..a=rtpmap:0 PC
MU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 19
2-194..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:
5024427578 at x.x.128.205<mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti>
mestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, B
YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: tele
phone-event..Contact: <sip:15033441174 at x.x.129.200:5060><mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>..Content-Type: application/sdp..Content-Length: 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2
116 IN IP4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480 RTP/AVP 0 101 10
0..c=IN IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16
..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
#
U x.x.128.205:51694 -> x.x.130.36:5060
ACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG4
bK1D5DA6..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36<mailto:sip:5033441174 at x.x.130.36>
>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E3
9A at x.x.128.205<mailto:9A at x.x.128.205>..Route: <sip:x.x.130.36;lr=on>..Max-Forwards: 70..CSeq: 101 ACK..Content-Lengt
h: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
ACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKcydzi
gwkX..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D5DA6..From: <sip:5024427578
@x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue,
03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards>
: 69..CSeq: 101 ACK..Content-Length: 0....
#
U x.x.128.205:51694 -> x.x.130.36:5060
BYE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG4
bK1D61CE7..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.3<mailto:sip:5033441174 at x.x.130.3>
6>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E
39A at x.x.128.205..User-Agent<mailto:39A at x.x.128.205..User-Agent>: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 70..Route: <sip:x.x.130
.36;lr=on>..Timestamp: 1341322666..CSeq: 103 BYE..Reason: Q.850;cause=16..Content-Length: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
BYE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKa2ce.
4ba2ee65.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:502
4427578 at x.x.128.205<mailto:4427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date
: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User>-
Agent: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 69..Timestamp: 1341322666..CSeq: 103 BYE..Reason: Q
.850;cause=16..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.34:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKa2ce.4ba2ee65.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D5
9..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-I
D: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>: Cisco-SIPGateway/IOS-12.x..Timestamp
: 1341322666..Content-Length: 0..CSeq: 103 BYE....
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip
:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..
Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S>
erver: Cisco-SIPGateway/IOS-12.x..Timestamp: 1341322666..Content-Length: 0..CSeq: 103 BYE....
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120703/6d7bc0bd/attachment-0001.htm>
From timo.teras at iki.fi Tue Jul 3 17:16:59 2012
From: timo.teras at iki.fi (Timo Teras)
Date: Tue, 3 Jul 2012 18:16:59 +0300
Subject: [SR-Users] uac module From header rewriting problems
In-Reply-To: <4FF30071.9060803@gmail.com>
References: <20120703090234.3937cb50@vostro> <4FF2C686.5030205@gmail.com>
<20120703164931.0bae88b3@vostro> <4FF30071.9060803@gmail.com>
Message-ID: <20120703181659.4efadad1@vostro>
On Tue, 03 Jul 2012 16:23:45 +0200 Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
>
> On 7/3/12 3:49 PM, Timo Teras wrote:
> > On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla
> > <miconda at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> On 7/3/12 8:02 AM, Timo Teras wrote:
> >>> Hi,
> >>>
> >>> I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
> >>> however even with the latest versions I'm still seeing corruption
> >>> in From headers when they are rewritten for the whole dialogue
> >>> (from_restore_mode=auto, the default).
> >>>
> >>> I spent some time analyzing the problem and the problem seems to
> >>> be connected with the fact that only the bitwise difference of the
> >>> original and modified URI are stored (XOR). The only purpose for
> >>> this appears to be the idea to save only the difference in the rr
> >>> params instead of two full URIs.
> >>>
> >>> However, it appears that in many cases (especially call transfer)
> >>> the From header will be altered during dialogue. This is
> >>> explicitly allowed in RFC 3261 ? 20.20:
> >>> The From header field indicates the initiator of the request.
> >>> This may be different from the initiator of the dialog.
> >>>
> >>> I've seen this in practise with few commercial SIP stacks.
> >>> Sometimes the changes are minor, or even trivial - but with the
> >>> difference encoding having even one character changed (e.g.
> >>> case), being deleted or added will result in the whole header
> >>> being corrupted.
> >>>
> >>> I'm now wondering if we should just store both URIs in the rr
> >>> params. While taking little more space, it should fix us sending
> >>> garbage to the wire (which usually results in dropped call as the
> >>> remote will reject the garbage messages).
> >>>
> >>> Any better ideas?
> >> it makes sense storing the entire value. Not sure if anyone else
> >> will want to be made configurable via mod param, I will go for
> >> simplest approach and have only the correct option, it will help
> >> in code maintenance.
> > Sounds good. Should probably do it for the stable branches too. I
> > can help with some of this, if needed. You have any estimate for
> > the fix?
>
> I just expressed my opinion on how to fix it, but there is no plan
> for me to work on it in the near future, being caught in other tasks
> and traveling. So you can go ahead and make a patch to fix it for
> master, then later, based on the impact, it can be backported.
Ah. Ok. "I will go" just sounded like you'll do it. Sorry for
confusion. I'll try to take stab at it then when I get a minute for
it. :)
-Timo
From vitalik.voip at gmail.com Tue Jul 3 17:23:29 2012
From: vitalik.voip at gmail.com (Vitaliy Aleksandrov)
Date: Tue, 03 Jul 2012 18:23:29 +0300
Subject: [SR-Users] ACK and BYE messages uses wrong socket.
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A6E@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A58@lyepkyexc.LYEPLYEXC.local>
<4FF30129.60905@gmail.com>
<A6C2711F9706AF4992FFEC48EA19CA901740FC9A6E@lyepkyexc.LYEPLYEXC.local>
Message-ID: <4FF30E71.3050709@gmail.com>
Forgot to mention, i used such a configuration at Kamailio 3.1.5.
As i understood you have got this error on linux-HA slave server ?
For that purpose i used:
*|echo 1> /proc/sys/net/ipv4/ip_nonlocal_bind
|*|*
*|
It's not safe option in general. When ip_nonlocal_bind is enabled linux
kernel allows you to call bind() for the interfaces you don't have and
you can miss a configuration error.
But i think if you know what you are doing it quite safe.
|**|
|**|
>
> Yes, I did the same thing as you mentioned and it still doing the same
> thing. Here is my setup:
>
> mhomed=1
>
> listen=udp:x.x.130.36:5060 # external IP
>
> listen=udp:x.x.130.34:5060 # external IP
>
> listen=udp:10.200.1.31:5060 # internal IP
>
> If I removed .130.34, I got error saying no socket found.
>
> Gary Chen
>
> *From:*sr-users-bounces at lists.sip-router.org
> [mailto:sr-users-bounces at lists.sip-router.org] *On Behalf Of *Vitaliy
> Aleksandrov
> *Sent:* Tuesday, July 03, 2012 10:27 AM
> *To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> Users Mailing List
> *Subject:* Re: [SR-Users] ACK and BYE messages uses wrong socket.
>
> Have you specified interfaces with "listen" command ?
> I had a problem as you described and have fixed it by moving a listen
> directive with a "floating ip" to the top of the list.
> So you can try to specify interfaces you will use for SIP and set a
> "virtual ip" at the top of that list.
>
>
> Kamailio 3.2.0
>
> I am trying to setup kamailio to do the sip trunking. It receive the
> sip traffic from customer and then send it to carrier.
>
> I have two NIC interface's assigned with three IP's:
>
> Interface 1: ( Public IP's)
>
> x.x.130.34
>
> x.x.130.36 floating IP
>
> interface 2: (private IP's)
>
> 10.10.1.31
>
> .36 is a floating IP assigned by Linux-HA (heartbeat/pacemaker).
>
> I only want to use .36 to receive and send sip traffic.
>
> I uses force_send_socket() to send INVITE with .36 IP. But the ACK
> message always want to use .34 IP even the Route header has .36 in it
> unless I force it with force_send_socket() .
>
> How can I fix this problem?
>
> See below for the SIP messages: (x.x.128.205 is customer IP,
> x.x.129.200 is PSTN gateway IP)
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> INVITE sip:5033441174 at x.x.130.36:5060
> <mailto:sip:5033441174 at x.x.130.36:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG
>
> 4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.3 <mailto:sip:5033441174 at x.x.130.3>
>
> 6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20>
>
> 5..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid:
> 411443261-3293254113-3191264919-256
>
> 0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE,
> OPTIONS, BYE, CANCEL, ACK, PRACK, CO
>
> MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101
> INVITE..Max-Forwards: 70..Remote-P
>
> arty-ID: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Timestamp:
> 1341322661
>
> ..Contact: <sip:5024427578 at x.x.128.205:5060>
> <mailto:sip:5024427578 at x.x.128.205:5060>..Expires: 180..Allow-Events:
> telephone-event..Conte
>
> nt-Type: application/sdp..Content-Length:
> 366....v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
>
> 4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio
> 19312 RTP/AVP 125 0 18 100 10
>
> 1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0
> PCMU/8000..a=rtpmap:18 G729/8000..a
>
> =fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100
> 192-194..a=rtpmap:101 telephone-event/8000
>
> ..a=fmtp:101 0-16..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 100 trying -- your call is important to us..Via:
> SIP/2.0/UDP x.x.128.205:5060;branch=z9
>
> hG4bK1D3CD1;rport=51694..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:502244117
>
> 4 at x.x.130.36 <mailto:4 at x.x.130.36>>..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>: 101
> INVITE..Se
>
> rver: LVS Proxy 1.0..Content-Length: 0....
>
> #
>
> U x.x.130.36:5060 -> x.x.129.200:5060
>
> INVITE sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Record-Route:
> <sip:x.x.130.36;lr=on>..Via: S
>
> IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via:
> SIP/2.0/UDP x.x.128.205:5060;rport
>
> =51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:50224
>
> 41174 at x.x.130.36 <mailto:41174 at x.x.130.36>>..Date: Tue, 03 Jul 2012
> 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
>
> E39A at x.x.128.205..Supported <mailto:E39A at x.x.128.205..Supported>:
> 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254
>
> 113-3191264919-2560877466..User-Agent:
> Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANC
>
> EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE,
> REGISTER..CSeq: 101 INVITE..Max-Forw
>
> ards: 69..Remote-Party-ID: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Tim
>
> estamp: 1341322661..Contact: <sip:5024427578 at x.x.128.205:51694>
> <mailto:sip:5024427578 at x.x.128.205:51694>..Expires: 180..Allow-Events: tel
>
> ephone-event..Content-Type: application/sdp..Content-Length:
> 375....v=0..o=CiscoSystemsSIP-GW-UserA
>
> gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4
> 10.200.1.51..t=0 0..m=audio 20464 RTP/AVP 12
>
> 5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125
> X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G7
>
> 29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100
> 192-194..a=rtpmap:101 telephone-
>
> event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 100 Trying..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP 216.4
>
> 9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088
>
> -D59..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:41 GMT..Cal
>
> l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>:
> 1341322661..Server: Cisco-SIPG
>
> ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events:
> telephone-event..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/
>
> UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205> <mailto:sip:5024427578 at x.x.128.205>;ta
>
> g=24513088-D59..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:4
>
> 1 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>:
> 1341322661..Server:
>
> Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq:
> 6708..Allow: INVITE, OPTIONS, B
>
> YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO,
> UPDATE, REGISTER..Allow-Events: tele
>
> phone-event..Contact: <sip:15033441174 at x.x.129.200:5060>
> <mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route:
> <sip:x.x.130.36;lr=on
>
> >..Content-Disposition: session;handling=required..Content-Type:
> application/sdp..Content-Length: 2
>
> 90....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4
> x.x.129.200..s=SIP Call..c=IN IP4 216
>
> .49.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4
> x.x.129.200..a=rtpmap:0 PCMU/8000.
>
> .a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100
> X-NSE/8000..a=fmtp:100 192-194..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD
>
> 1..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36> <mailto:sip:5033441174 at x.x.130.36>;tag=F
>
> 0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at 216.
>
> 49.128.205..Timestamp: 1341322661..Server:
> Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 10
>
> 0rel..RSeq: 6708..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK,
> COMET, REFER, SUBSCRIBE, NOTIFY,
>
> INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact:
> <sip:15033441174 at x.x.129.200:50 <mailto:sip:15033441174 at x.x.129.200:50>
>
> 60>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Disposition:
> session;handling=required..Conte
>
> nt-Type: application/sdp..Content-Length:
> 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN I
>
> P4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480
> RTP/AVP 0 101 100..c=IN
>
> IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101
> telephone-event/8000..a=fmtp:101 0-16..a=rtpm
>
> ap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> PRACK sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9h
>
> G4bK1D4474..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130 <mailto:sip:5033441174 at x.x.130>.
>
> 36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3
>
> E39A at x.x.128.205..CSeq <mailto:E39A at x.x.128.205..CSeq>: 102
> PRACK..RAck: 6708 101 INVITE..Route: <sip:x.x.130.36;lr=on>..Max-
>
> Forwards: 70..Content-Length: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> PRACK sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bK92c
>
> e.4def8436.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:50
>
> 24427578 at x.x.128.205
> <mailto:24427578 at x.x.128.205>>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Dat
>
> e: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>
>
> : 102 PRACK..RAck: 6708 101 INVITE..Max-Forwards:
> 69..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.34:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bK92ce.4def8436.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D4474..From:
> <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
>
> ..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:41 GMT..Call-ID
>
> : 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>:
> Cisco-SIPGateway/IOS-12.x..CSeq: 102
>
> PRACK..Content-Length: 0....
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:
>
> 5024427578 at x.x.128.205
> <mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
>
> ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se>
>
> rver: Cisco-SIPGateway/IOS-12.x..CSeq: 102 PRACK..Content-Length: 0....
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
>
> ..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:41 GMT..Call-ID
>
> : 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>:
> 1341322661..Server: Cisco-SIPGatew
>
> ay/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, BYE, CANCEL,
> ACK, PRACK, COMET, REFER, SUBSC
>
> RIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events:
> telephone-event..Contact: <sip:15033441174 at 216.
>
> 49.129.200:5060>..Record-Route:
> <sip:x.x.130.36;lr=on>..Content-Type: application/sdp..Content-L
>
> ength: 290....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4
> x.x.129.200..s=SIP Call..c=IN
>
> IP4 x.x.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4
> x.x.129.200..a=rtpmap:0 PC
>
> MU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101
> 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 19
>
> 2-194..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:
>
> 5024427578 at x.x.128.205
> <mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
>
> ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti>
>
> mestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101
> INVITE..Allow: INVITE, OPTIONS, B
>
> YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO,
> UPDATE, REGISTER..Allow-Events: tele
>
> phone-event..Contact: <sip:15033441174 at x.x.129.200:5060>
> <mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route:
> <sip:x.x.130.36;lr=on
>
> >..Content-Type: application/sdp..Content-Length:
> 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2
>
> 116 IN IP4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0
> 0..m=audio 19480 RTP/AVP 0 101 10
>
> 0..c=IN IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101
> telephone-event/8000..a=fmtp:101 0-16
>
> ..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> ACK sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG4
>
> bK1D5DA6..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36 <mailto:sip:5033441174 at x.x.130.36>
>
> >;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E3
>
> 9A at x.x.128.205 <mailto:9A at x.x.128.205>..Route:
> <sip:x.x.130.36;lr=on>..Max-Forwards: 70..CSeq: 101 ACK..Content-Lengt
>
> h: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> ACK sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKcydzi
>
> gwkX..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D5DA6..From: <sip:5024427578
>
> @x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue,
>
> 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards>
>
> : 69..CSeq: 101 ACK..Content-Length: 0....
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> BYE sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG4
>
> bK1D61CE7..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.3 <mailto:sip:5033441174 at x.x.130.3>
>
> 6>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E
>
> 39A at x.x.128.205..User-Agent <mailto:39A at x.x.128.205..User-Agent>:
> Cisco-SIPGateway/IOS-12.x..Max-Forwards: 70..Route: <sip:x.x.130
>
> .36;lr=on>..Timestamp: 1341322666..CSeq: 103 BYE..Reason:
> Q.850;cause=16..Content-Length: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> BYE sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKa2ce.
>
> 4ba2ee65.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:502
>
> 4427578 at x.x.128.205
> <mailto:4427578 at x.x.128.205>>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date
>
> : Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User>-
>
> Agent: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 69..Timestamp:
> 1341322666..CSeq: 103 BYE..Reason: Q
>
> .850;cause=16..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.34:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKa2ce.4ba2ee65.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From:
> <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D5
>
> 9..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:46 GMT..Call-I
>
> D: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>:
> Cisco-SIPGateway/IOS-12.x..Timestamp
>
> : 1341322666..Content-Length: 0..CSeq: 103 BYE....
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip
>
> :5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..
>
> Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S>
>
> erver: Cisco-SIPGateway/IOS-12.x..Timestamp:
> 1341322666..Content-Length: 0..CSeq: 103 BYE....
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org <mailto:sr-users at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120703/73391069/attachment-0001.htm>
From Gary.Chen at lightyear.net Tue Jul 3 17:44:24 2012
From: Gary.Chen at lightyear.net (Gary Chen)
Date: Tue, 3 Jul 2012 11:44:24 -0400
Subject: [SR-Users] ACK and BYE messages uses wrong socket.
In-Reply-To: <4FF30E71.3050709@gmail.com>
References: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A58@lyepkyexc.LYEPLYEXC.local>
<4FF30129.60905@gmail.com>
<A6C2711F9706AF4992FFEC48EA19CA901740FC9A6E@lyepkyexc.LYEPLYEXC.local>
<4FF30E71.3050709@gmail.com>
Message-ID: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A81@lyepkyexc.LYEPLYEXC.local>
I already have net.ipv4.ip_nonlocal_bind = 1 in /etc/sysctl.conf
All I talked about is my master server with active floating IP: x.x.130.36
If I removed x.x.130.34 from configuration, my kamailio start fine. Only when I trying to send call the the gateway x.x.129.200, the ACK got error messages like this: [forward.c:220]: ERROR: get_out_socket: no socket found. force_send_socket() on ACK message can fix this problem. Here is my code on this part:
route[WITHINDLG] {
if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
}
force_send_socket(x.x.130.36:5060); # Should not have to use this.
t_on_failure("FAIL_ONE");
route(RELAY);
} else {
if (is_method("SUBSCRIBE") && uri == myself) {
# in-dialog subscribe requests
route(PRESENCE);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
t_relay();
exit;
} else {
# ACK without matching transaction ... ignore and discard
exit;
}
}
sl_send_reply("404","Check loose_route() failed!");
}
exit;
}
}
From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Vitaliy Aleksandrov
Sent: Tuesday, July 03, 2012 11:23 AM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Subject: Re: [SR-Users] ACK and BYE messages uses wrong socket.
Forgot to mention, i used such a configuration at Kamailio 3.1.5.
As i understood you have got this error on linux-HA slave server ?
For that purpose i used:
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
It's not safe option in general. When ip_nonlocal_bind is enabled linux kernel allows you to call bind() for the interfaces you don't have and you can miss a configuration error.
But i think if you know what you are doing it quite safe.
Yes, I did the same thing as you mentioned and it still doing the same thing. Here is my setup:
mhomed=1
listen=udp:x.x.130.36:5060 # external IP
listen=udp:x.x.130.34:5060 # external IP
listen=udp:10.200.1.31:5060 # internal IP
If I removed .130.34, I got error saying no socket found.
Gary Chen
From: sr-users-bounces at lists.sip-router.org<mailto:sr-users-bounces at lists.sip-router.org> [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Vitaliy Aleksandrov
Sent: Tuesday, July 03, 2012 10:27 AM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Subject: Re: [SR-Users] ACK and BYE messages uses wrong socket.
Have you specified interfaces with "listen" command ?
I had a problem as you described and have fixed it by moving a listen directive with a "floating ip" to the top of the list.
So you can try to specify interfaces you will use for SIP and set a "virtual ip" at the top of that list.
Kamailio 3.2.0
I am trying to setup kamailio to do the sip trunking. It receive the sip traffic from customer and then send it to carrier.
I have two NIC interface's assigned with three IP's:
Interface 1: ( Public IP's)
x.x.130.34
x.x.130.36 floating IP
interface 2: (private IP's)
10.10.1.31
.36 is a floating IP assigned by Linux-HA (heartbeat/pacemaker).
I only want to use .36 to receive and send sip traffic.
I uses force_send_socket() to send INVITE with .36 IP. But the ACK message always want to use .34 IP even the Route header has .36 in it unless I force it with force_send_socket() .
How can I fix this problem?
See below for the SIP messages: (x.x.128.205 is customer IP, x.x.129.200 is PSTN gateway IP)
U x.x.128.205:51694 -> x.x.130.36:5060
INVITE sip:5033441174 at x.x.130.36:5060<mailto:sip:5033441174 at x.x.130.36:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG
4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.3<mailto:sip:5033441174 at x.x.130.3>
6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20>
5..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254113-3191264919-256
0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, CO
MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forwards: 70..Remote-P
arty-ID: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Timestamp: 1341322661
..Contact: <sip:5024427578 at x.x.128.205:5060><mailto:sip:5024427578 at x.x.128.205:5060>..Expires: 180..Allow-Events: telephone-event..Conte
nt-Type: application/sdp..Content-Length: 366....v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio 19312 RTP/AVP 125 0 18 100 10
1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8000..a
=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=rtpmap:101 telephone-event/8000
..a=fmtp:101 0-16..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9
hG4bK1D3CD1;rport=51694..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:502244117
4 at x.x.130.36<mailto:4 at x.x.130.36>>..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>: 101 INVITE..Se
rver: LVS Proxy 1.0..Content-Length: 0....
#
U x.x.130.36:5060 -> x.x.129.200:5060
INVITE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Record-Route: <sip:x.x.130.36;lr=on>..Via: S
IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport
=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:50224
41174 at x.x.130.36<mailto:41174 at x.x.130.36>>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
E39A at x.x.128.205..Supported<mailto:E39A at x.x.128.205..Supported>: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254
113-3191264919-2560877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANC
EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forw
ards: 69..Remote-Party-ID: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Tim
estamp: 1341322661..Contact: <sip:5024427578 at x.x.128.205:51694><mailto:sip:5024427578 at x.x.128.205:51694>..Expires: 180..Allow-Events: tel
ephone-event..Content-Type: application/sdp..Content-Length: 375....v=0..o=CiscoSystemsSIP-GW-UserA
gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4 10.200.1.51..t=0 0..m=audio 20464 RTP/AVP 12
5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G7
29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=rtpmap:101 telephone-
event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP 216.4
9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088
-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Cal
l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server: Cisco-SIPG
ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events: telephone-event..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/
UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;ta
g=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:4
1 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server:
Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq: 6708..Allow: INVITE, OPTIONS, B
YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: tele
phone-event..Contact: <sip:15033441174 at x.x.129.200:5060><mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>..Content-Disposition: session;handling=required..Content-Type: application/sdp..Content-Length: 2
90....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP Call..c=IN IP4 216
.49.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 x.x.129.200..a=rtpmap:0 PCMU/8000.
.a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD
1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F
0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at 216.
49.128.205..Timestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 10
0rel..RSeq: 6708..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact: <sip:15033441174 at x.x.129.200:50<mailto:sip:15033441174 at x.x.129.200:50>
60>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Disposition: session;handling=required..Conte
nt-Type: application/sdp..Content-Length: 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN I
P4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480 RTP/AVP 0 101 100..c=IN
IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpm
ap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
#
U x.x.128.205:51694 -> x.x.130.36:5060
PRACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9h
G4bK1D4474..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130<mailto:sip:5033441174 at x.x.130>.
36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
E39A at x.x.128.205..CSeq<mailto:E39A at x.x.128.205..CSeq>: 102 PRACK..RAck: 6708 101 INVITE..Route: <sip:x.x.130.36;lr=on>..Max-
Forwards: 70..Content-Length: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
PRACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bK92c
e.4def8436.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:50
24427578 at x.x.128.205<mailto:24427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Dat
e: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>
: 102 PRACK..RAck: 6708 101 INVITE..Max-Forwards: 69..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.34:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bK92ce.4def8436.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID
: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>: Cisco-SIPGateway/IOS-12.x..CSeq: 102
PRACK..Content-Length: 0....
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:
5024427578 at x.x.128.205<mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se>
rver: Cisco-SIPGateway/IOS-12.x..CSeq: 102 PRACK..Content-Length: 0....
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID
: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server: Cisco-SIPGatew
ay/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSC
RIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact: <sip:15033441174 at 216.
49.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Type: application/sdp..Content-L
ength: 290....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP Call..c=IN
IP4 x.x.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 x.x.129.200..a=rtpmap:0 PC
MU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 19
2-194..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:
5024427578 at x.x.128.205<mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti>
mestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, B
YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: tele
phone-event..Contact: <sip:15033441174 at x.x.129.200:5060><mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>..Content-Type: application/sdp..Content-Length: 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2
116 IN IP4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480 RTP/AVP 0 101 10
0..c=IN IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16
..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
#
U x.x.128.205:51694 -> x.x.130.36:5060
ACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG4
bK1D5DA6..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36<mailto:sip:5033441174 at x.x.130.36>
>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E3
9A at x.x.128.205<mailto:9A at x.x.128.205>..Route: <sip:x.x.130.36;lr=on>..Max-Forwards: 70..CSeq: 101 ACK..Content-Lengt
h: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
ACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKcydzi
gwkX..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D5DA6..From: <sip:5024427578
@x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue,
03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards>
: 69..CSeq: 101 ACK..Content-Length: 0....
#
U x.x.128.205:51694 -> x.x.130.36:5060
BYE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG4
bK1D61CE7..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.3<mailto:sip:5033441174 at x.x.130.3>
6>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E
39A at x.x.128.205..User-Agent<mailto:39A at x.x.128.205..User-Agent>: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 70..Route: <sip:x.x.130
.36;lr=on>..Timestamp: 1341322666..CSeq: 103 BYE..Reason: Q.850;cause=16..Content-Length: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
BYE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKa2ce.
4ba2ee65.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:502
4427578 at x.x.128.205<mailto:4427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date
: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User>-
Agent: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 69..Timestamp: 1341322666..CSeq: 103 BYE..Reason: Q
.850;cause=16..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.34:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKa2ce.4ba2ee65.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D5
9..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-I
D: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>: Cisco-SIPGateway/IOS-12.x..Timestamp
: 1341322666..Content-Length: 0..CSeq: 103 BYE....
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip
:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..
Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S>
erver: Cisco-SIPGateway/IOS-12.x..Timestamp: 1341322666..Content-Length: 0..CSeq: 103 BYE....
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org<mailto:sr-users at 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 at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120703/bfa2f721/attachment-0001.htm>
From miconda at gmail.com Tue Jul 3 18:23:00 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 03 Jul 2012 18:23:00 +0200
Subject: [SR-Users] ACK and BYE messages uses wrong socket.
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A6E@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A58@lyepkyexc.LYEPLYEXC.local>
<4FF30129.60905@gmail.com>
<A6C2711F9706AF4992FFEC48EA19CA901740FC9A6E@lyepkyexc.LYEPLYEXC.local>
Message-ID: <4FF31C64.4090708@gmail.com>
Hello,
is .36 address available on the network interface when kamailio is started?
Also, use at least v3.2.3 (the latest in 3.2 series) to be sure you get
all the fixes since 3.2.0 and this is not related to some issue already
fixed.
Cheers,
Daniel
On 7/3/12 4:52 PM, Gary Chen wrote:
>
> Yes, I did the same thing as you mentioned and it still doing the same
> thing. Here is my setup:
>
> mhomed=1
>
> listen=udp:x.x.130.36:5060 # external IP
>
> listen=udp:x.x.130.34:5060 # external IP
>
> listen=udp:10.200.1.31:5060 # internal IP
>
> If I removed .130.34, I got error saying no socket found.
>
> Gary Chen
>
> *From:*sr-users-bounces at lists.sip-router.org
> [mailto:sr-users-bounces at lists.sip-router.org] *On Behalf Of *Vitaliy
> Aleksandrov
> *Sent:* Tuesday, July 03, 2012 10:27 AM
> *To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> Users Mailing List
> *Subject:* Re: [SR-Users] ACK and BYE messages uses wrong socket.
>
> Have you specified interfaces with "listen" command ?
> I had a problem as you described and have fixed it by moving a listen
> directive with a "floating ip" to the top of the list.
> So you can try to specify interfaces you will use for SIP and set a
> "virtual ip" at the top of that list.
>
>
> Kamailio 3.2.0
>
> I am trying to setup kamailio to do the sip trunking. It receive the
> sip traffic from customer and then send it to carrier.
>
> I have two NIC interface's assigned with three IP's:
>
> Interface 1: ( Public IP's)
>
> x.x.130.34
>
> x.x.130.36 floating IP
>
> interface 2: (private IP's)
>
> 10.10.1.31
>
> .36 is a floating IP assigned by Linux-HA (heartbeat/pacemaker).
>
> I only want to use .36 to receive and send sip traffic.
>
> I uses force_send_socket() to send INVITE with .36 IP. But the ACK
> message always want to use .34 IP even the Route header has .36 in it
> unless I force it with force_send_socket() .
>
> How can I fix this problem?
>
> See below for the SIP messages: (x.x.128.205 is customer IP,
> x.x.129.200 is PSTN gateway IP)
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> INVITE sip:5033441174 at x.x.130.36:5060
> <mailto:sip:5033441174 at x.x.130.36:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG
>
> 4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.3 <mailto:sip:5033441174 at x.x.130.3>
>
> 6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20>
>
> 5..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid:
> 411443261-3293254113-3191264919-256
>
> 0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE,
> OPTIONS, BYE, CANCEL, ACK, PRACK, CO
>
> MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101
> INVITE..Max-Forwards: 70..Remote-P
>
> arty-ID: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Timestamp:
> 1341322661
>
> ..Contact: <sip:5024427578 at x.x.128.205:5060>
> <mailto:sip:5024427578 at x.x.128.205:5060>..Expires: 180..Allow-Events:
> telephone-event..Conte
>
> nt-Type: application/sdp..Content-Length:
> 366....v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
>
> 4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio
> 19312 RTP/AVP 125 0 18 100 10
>
> 1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0
> PCMU/8000..a=rtpmap:18 G729/8000..a
>
> =fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100
> 192-194..a=rtpmap:101 telephone-event/8000
>
> ..a=fmtp:101 0-16..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 100 trying -- your call is important to us..Via:
> SIP/2.0/UDP x.x.128.205:5060;branch=z9
>
> hG4bK1D3CD1;rport=51694..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:502244117
>
> 4 at x.x.130.36 <mailto:4 at x.x.130.36>>..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>: 101
> INVITE..Se
>
> rver: LVS Proxy 1.0..Content-Length: 0....
>
> #
>
> U x.x.130.36:5060 -> x.x.129.200:5060
>
> INVITE sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Record-Route:
> <sip:x.x.130.36;lr=on>..Via: S
>
> IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via:
> SIP/2.0/UDP x.x.128.205:5060;rport
>
> =51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:50224
>
> 41174 at x.x.130.36 <mailto:41174 at x.x.130.36>>..Date: Tue, 03 Jul 2012
> 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
>
> E39A at x.x.128.205..Supported <mailto:E39A at x.x.128.205..Supported>:
> 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254
>
> 113-3191264919-2560877466..User-Agent:
> Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANC
>
> EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE,
> REGISTER..CSeq: 101 INVITE..Max-Forw
>
> ards: 69..Remote-Party-ID: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Tim
>
> estamp: 1341322661..Contact: <sip:5024427578 at x.x.128.205:51694>
> <mailto:sip:5024427578 at x.x.128.205:51694>..Expires: 180..Allow-Events: tel
>
> ephone-event..Content-Type: application/sdp..Content-Length:
> 375....v=0..o=CiscoSystemsSIP-GW-UserA
>
> gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4
> 10.200.1.51..t=0 0..m=audio 20464 RTP/AVP 12
>
> 5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125
> X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G7
>
> 29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100
> 192-194..a=rtpmap:101 telephone-
>
> event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 100 Trying..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP 216.4
>
> 9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088
>
> -D59..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:41 GMT..Cal
>
> l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>:
> 1341322661..Server: Cisco-SIPG
>
> ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events:
> telephone-event..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/
>
> UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205> <mailto:sip:5024427578 at x.x.128.205>;ta
>
> g=24513088-D59..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:4
>
> 1 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>:
> 1341322661..Server:
>
> Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq:
> 6708..Allow: INVITE, OPTIONS, B
>
> YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO,
> UPDATE, REGISTER..Allow-Events: tele
>
> phone-event..Contact: <sip:15033441174 at x.x.129.200:5060>
> <mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route:
> <sip:x.x.130.36;lr=on
>
> >..Content-Disposition: session;handling=required..Content-Type:
> application/sdp..Content-Length: 2
>
> 90....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4
> x.x.129.200..s=SIP Call..c=IN IP4 216
>
> .49.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4
> x.x.129.200..a=rtpmap:0 PCMU/8000.
>
> .a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100
> X-NSE/8000..a=fmtp:100 192-194..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD
>
> 1..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36> <mailto:sip:5033441174 at x.x.130.36>;tag=F
>
> 0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at 216.
>
> 49.128.205..Timestamp: 1341322661..Server:
> Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 10
>
> 0rel..RSeq: 6708..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK,
> COMET, REFER, SUBSCRIBE, NOTIFY,
>
> INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact:
> <sip:15033441174 at x.x.129.200:50 <mailto:sip:15033441174 at x.x.129.200:50>
>
> 60>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Disposition:
> session;handling=required..Conte
>
> nt-Type: application/sdp..Content-Length:
> 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN I
>
> P4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480
> RTP/AVP 0 101 100..c=IN
>
> IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101
> telephone-event/8000..a=fmtp:101 0-16..a=rtpm
>
> ap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> PRACK sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9h
>
> G4bK1D4474..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130 <mailto:sip:5033441174 at x.x.130>.
>
> 36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3
>
> E39A at x.x.128.205..CSeq <mailto:E39A at x.x.128.205..CSeq>: 102
> PRACK..RAck: 6708 101 INVITE..Route: <sip:x.x.130.36;lr=on>..Max-
>
> Forwards: 70..Content-Length: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> PRACK sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bK92c
>
> e.4def8436.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:50
>
> 24427578 at x.x.128.205
> <mailto:24427578 at x.x.128.205>>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Dat
>
> e: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>
>
> : 102 PRACK..RAck: 6708 101 INVITE..Max-Forwards:
> 69..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.34:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bK92ce.4def8436.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D4474..From:
> <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
>
> ..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:41 GMT..Call-ID
>
> : 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>:
> Cisco-SIPGateway/IOS-12.x..CSeq: 102
>
> PRACK..Content-Length: 0....
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:
>
> 5024427578 at x.x.128.205
> <mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
>
> ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se>
>
> rver: Cisco-SIPGateway/IOS-12.x..CSeq: 102 PRACK..Content-Length: 0....
>
> U x.x.129.200:5060 -> x.x.130.36:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From:
> <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
>
> ..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:41 GMT..Call-ID
>
> : 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>:
> 1341322661..Server: Cisco-SIPGatew
>
> ay/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, BYE, CANCEL,
> ACK, PRACK, COMET, REFER, SUBSC
>
> RIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events:
> telephone-event..Contact: <sip:15033441174 at 216.
>
> 49.129.200:5060>..Record-Route:
> <sip:x.x.130.36;lr=on>..Content-Type: application/sdp..Content-L
>
> ength: 290....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4
> x.x.129.200..s=SIP Call..c=IN
>
> IP4 x.x.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4
> x.x.129.200..a=rtpmap:0 PC
>
> MU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101
> 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 19
>
> 2-194..
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:
>
> 5024427578 at x.x.128.205
> <mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
>
> ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti>
>
> mestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101
> INVITE..Allow: INVITE, OPTIONS, B
>
> YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO,
> UPDATE, REGISTER..Allow-Events: tele
>
> phone-event..Contact: <sip:15033441174 at x.x.129.200:5060>
> <mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route:
> <sip:x.x.130.36;lr=on
>
> >..Content-Type: application/sdp..Content-Length:
> 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2
>
> 116 IN IP4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0
> 0..m=audio 19480 RTP/AVP 0 101 10
>
> 0..c=IN IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101
> telephone-event/8000..a=fmtp:101 0-16
>
> ..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> ACK sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG4
>
> bK1D5DA6..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36 <mailto:sip:5033441174 at x.x.130.36>
>
> >;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E3
>
> 9A at x.x.128.205 <mailto:9A at x.x.128.205>..Route:
> <sip:x.x.130.36;lr=on>..Max-Forwards: 70..CSeq: 101 ACK..Content-Lengt
>
> h: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> ACK sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKcydzi
>
> gwkX..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D5DA6..From: <sip:5024427578
>
> @x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue,
>
> 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards>
>
> : 69..CSeq: 101 ACK..Content-Length: 0....
>
> #
>
> U x.x.128.205:51694 -> x.x.130.36:5060
>
> BYE sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;branch=z9hG4
>
> bK1D61CE7..From: <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.3 <mailto:sip:5033441174 at x.x.130.3>
>
> 6>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E
>
> 39A at x.x.128.205..User-Agent <mailto:39A at x.x.128.205..User-Agent>:
> Cisco-SIPGateway/IOS-12.x..Max-Forwards: 70..Route: <sip:x.x.130
>
> .36;lr=on>..Timestamp: 1341322666..CSeq: 103 BYE..Reason:
> Q.850;cause=16..Content-Length: 0....
>
> #
>
> U x.x.130.34:5060 -> x.x.129.200:5060
>
> BYE sip:15033441174 at x.x.129.200:5060
> <mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKa2ce.
>
> 4ba2ee65.0..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:502
>
> 4427578 at x.x.128.205
> <mailto:4427578 at x.x.128.205>>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date
>
> : Tue, 03 Jul 2012 13:37:41 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User>-
>
> Agent: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 69..Timestamp:
> 1341322666..CSeq: 103 BYE..Reason: Q
>
> .850;cause=16..Content-Length: 0....
>
> #
>
> U x.x.129.200:5060 -> x.x.130.34:5060
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.130.34;branch=z9hG4bKa2ce.4ba2ee65.0,SIP/2.0/UDP x.x.12
>
> 8.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From:
> <sip:5024427578 at x.x.128.205>
> <mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D5
>
> 9..To: <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul
> 2012 13:37:46 GMT..Call-I
>
> D: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>:
> Cisco-SIPGateway/IOS-12.x..Timestamp
>
> : 1341322666..Content-Length: 0..CSeq: 103 BYE....
>
> #
>
> U x.x.130.36:5060 -> x.x.128.205:51694
>
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip
>
> :5024427578 at x.x.128.205>;tag=24513088-D59..To:
> <sip:5033441174 at x.x.130.36>
> <mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..
>
> Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-ID:
> 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S
> <mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S>
>
> erver: Cisco-SIPGateway/IOS-12.x..Timestamp:
> 1341322666..Content-Length: 0..CSeq: 103 BYE....
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org <mailto:sr-users at 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 at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120703/69b1e983/attachment-0001.htm>
From miconda at gmail.com Wed Jul 4 13:18:39 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 04 Jul 2012 13:18:39 +0200
Subject: [SR-Users] uac module From header rewriting problems
In-Reply-To: <20120703181659.4efadad1@vostro>
References: <20120703090234.3937cb50@vostro> <4FF2C686.5030205@gmail.com>
<20120703164931.0bae88b3@vostro> <4FF30071.9060803@gmail.com>
<20120703181659.4efadad1@vostro>
Message-ID: <4FF4268F.50408@gmail.com>
On 7/3/12 5:16 PM, Timo Teras wrote:
> On Tue, 03 Jul 2012 16:23:45 +0200 Daniel-Constantin Mierla
> <miconda at gmail.com> wrote:
>
>> On 7/3/12 3:49 PM, Timo Teras wrote:
>>> On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla
>>> <miconda at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> On 7/3/12 8:02 AM, Timo Teras wrote:
>>>>> Hi,
>>>>>
>>>>> I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
>>>>> however even with the latest versions I'm still seeing corruption
>>>>> in From headers when they are rewritten for the whole dialogue
>>>>> (from_restore_mode=auto, the default).
>>>>>
>>>>> I spent some time analyzing the problem and the problem seems to
>>>>> be connected with the fact that only the bitwise difference of the
>>>>> original and modified URI are stored (XOR). The only purpose for
>>>>> this appears to be the idea to save only the difference in the rr
>>>>> params instead of two full URIs.
>>>>>
>>>>> However, it appears that in many cases (especially call transfer)
>>>>> the From header will be altered during dialogue. This is
>>>>> explicitly allowed in RFC 3261 ? 20.20:
>>>>> The From header field indicates the initiator of the request.
>>>>> This may be different from the initiator of the dialog.
>>>>>
>>>>> I've seen this in practise with few commercial SIP stacks.
>>>>> Sometimes the changes are minor, or even trivial - but with the
>>>>> difference encoding having even one character changed (e.g.
>>>>> case), being deleted or added will result in the whole header
>>>>> being corrupted.
>>>>>
>>>>> I'm now wondering if we should just store both URIs in the rr
>>>>> params. While taking little more space, it should fix us sending
>>>>> garbage to the wire (which usually results in dropped call as the
>>>>> remote will reject the garbage messages).
>>>>>
>>>>> Any better ideas?
>>>> it makes sense storing the entire value. Not sure if anyone else
>>>> will want to be made configurable via mod param, I will go for
>>>> simplest approach and have only the correct option, it will help
>>>> in code maintenance.
>>> Sounds good. Should probably do it for the stable branches too. I
>>> can help with some of this, if needed. You have any estimate for
>>> the fix?
>> I just expressed my opinion on how to fix it, but there is no plan
>> for me to work on it in the near future, being caught in other tasks
>> and traveling. So you can go ahead and make a patch to fix it for
>> master, then later, based on the impact, it can be backported.
> Ah. Ok. "I will go" just sounded like you'll do it. Sorry for
> confusion. I'll try to take stab at it then when I get a minute for
> it. :)
"I would go" would have been more appropriate, indeed. I can help
reviewing when you have it, nothing else in short term unfortunately.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From agranig at sipwise.com Wed Jul 4 15:14:54 2012
From: agranig at sipwise.com (Andreas Granig)
Date: Wed, 04 Jul 2012 15:14:54 +0200
Subject: [SR-Users] Removing display-name with uac_replace_from
Message-ID: <4FF441CE.4070300@sipwise.com>
Hi,
in kamailio 3.3, doing
uac_replace_from("", "$var(myuri)");
doesn't remove the old Display part anymore (although the documentation
still says it should), the debug log is:
DEBUG: uac [uac.c:499]: dsp=(nil) (len=0) , uri=0x7fff87f6b840 (len=28)
DEBUG: uac [replace.c:324]: uri to replace [sip:a at example.org]
DEBUG: uac [replace.c:325]: replacement uri is [sip:b at example.org]
DEBUG: uac [replace.c:383]: encode
is=<UEtlSyomCD8kIi8/SnlZMzNyS29QS2VLanBKeg--> len=40
So no hint that the old display is being removed. When doing
uac_replace_from("foo", "$var(myuri)");
then there's an additional line like this:
DEBUG: uac [replace.c:284]: removing display ["olddisplay"]
which is missing when I put an empty string in the first parameter.
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120704/a4d152a6/attachment.pgp>
From miconda at gmail.com Wed Jul 4 21:42:23 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 04 Jul 2012 21:42:23 +0200
Subject: [SR-Users] Removing display-name with uac_replace_from
In-Reply-To: <4FF441CE.4070300@sipwise.com>
References: <4FF441CE.4070300@sipwise.com>
Message-ID: <4FF49C9F.9070109@gmail.com>
Hello,
On 7/4/12 3:14 PM, Andreas Granig wrote:
> Hi,
>
> in kamailio 3.3, doing
>
> uac_replace_from("", "$var(myuri)");
>
> doesn't remove the old Display part anymore (although the documentation
> still says it should), the debug log is:
>
> DEBUG: uac [uac.c:499]: dsp=(nil) (len=0) , uri=0x7fff87f6b840 (len=28)
> DEBUG: uac [replace.c:324]: uri to replace [sip:a at example.org]
> DEBUG: uac [replace.c:325]: replacement uri is [sip:b at example.org]
> DEBUG: uac [replace.c:383]: encode
> is=<UEtlSyomCD8kIi8/SnlZMzNyS29QS2VLanBKeg--> len=40
>
> So no hint that the old display is being removed. When doing
>
> uac_replace_from("foo", "$var(myuri)");
>
> then there's an additional line like this:
>
> DEBUG: uac [replace.c:284]: removing display ["olddisplay"]
>
> which is missing when I put an empty string in the first parameter.
quick look into the sources shows that fixup makes the display parameter
null if its length is 0 -- perhaps introduced in the patch that unified
the fixup to work also for replacing the To header display. If you have
time and urgent need, you can push a fix for it asap, otherwise I will
look at it once getting some spare time out of traveling.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From agranig at sipwise.com Thu Jul 5 00:32:03 2012
From: agranig at sipwise.com (Andreas Granig)
Date: Thu, 05 Jul 2012 00:32:03 +0200
Subject: [SR-Users] Removing display-name with uac_replace_from
In-Reply-To: <4FF49C9F.9070109@gmail.com>
References: <4FF441CE.4070300@sipwise.com> <4FF49C9F.9070109@gmail.com>
Message-ID: <4FF4C463.7020004@sipwise.com>
Hi,
On 07/04/2012 09:42 PM, Daniel-Constantin Mierla wrote:
> quick look into the sources shows that fixup makes the display parameter
> null if its length is 0 -- perhaps introduced in the patch that unified
> the fixup to work also for replacing the To header display. If you have
> time and urgent need, you can push a fix for it asap, otherwise I will
> look at it once getting some spare time out of traveling.
Ok, I'll have a look at it tomorrow and push a fix.
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120705/044faa65/attachment.pgp>
From Gary.Chen at lightyear.net Thu Jul 5 15:46:20 2012
From: Gary.Chen at lightyear.net (Gary Chen)
Date: Thu, 5 Jul 2012 09:46:20 -0400
Subject: [SR-Users] ACK and BYE messages uses wrong socket.
In-Reply-To: <4FF31C64.4090708@gmail.com>
References: <A6C2711F9706AF4992FFEC48EA19CA901740FC9A58@lyepkyexc.LYEPLYEXC.local>
<4FF30129.60905@gmail.com>
<A6C2711F9706AF4992FFEC48EA19CA901740FC9A6E@lyepkyexc.LYEPLYEXC.local>
<4FF31C64.4090708@gmail.com>
Message-ID: <A6C2711F9706AF4992FFEC48EA19CA901740FC9AEE@lyepkyexc.LYEPLYEXC.local>
Yes, it is available when kamailio started. I tried the latest version (3.2.3) and it did the same thing.
If I removed listen=udp:x.x.130.34:5060 (primary IP on the NIC) from configuration file, it will report error when trying to relay() the message like this:
ERROR: <core> [forward.c:220]: ERROR: get_out_socket: no socket found
It seems that kamailio does not populate default socket with secondary IP (floating IP) and you have to use force_send_socket() to send the message.
Gary
From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
Sent: Tuesday, July 03, 2012 12:23 PM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Gary Chen
Subject: Re: [SR-Users] ACK and BYE messages uses wrong socket.
Hello,
is .36 address available on the network interface when kamailio is started?
Also, use at least v3.2.3 (the latest in 3.2 series) to be sure you get all the fixes since 3.2.0 and this is not related to some issue already fixed.
Cheers,
Daniel
On 7/3/12 4:52 PM, Gary Chen wrote:
Yes, I did the same thing as you mentioned and it still doing the same thing. Here is my setup:
mhomed=1
listen=udp:x.x.130.36:5060 # external IP
listen=udp:x.x.130.34:5060 # external IP
listen=udp:10.200.1.31:5060 # internal IP
If I removed .130.34, I got error saying no socket found.
Gary Chen
From: sr-users-bounces at lists.sip-router.org<mailto:sr-users-bounces at lists.sip-router.org> [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Vitaliy Aleksandrov
Sent: Tuesday, July 03, 2012 10:27 AM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Subject: Re: [SR-Users] ACK and BYE messages uses wrong socket.
Have you specified interfaces with "listen" command ?
I had a problem as you described and have fixed it by moving a listen directive with a "floating ip" to the top of the list.
So you can try to specify interfaces you will use for SIP and set a "virtual ip" at the top of that list.
Kamailio 3.2.0
I am trying to setup kamailio to do the sip trunking. It receive the sip traffic from customer and then send it to carrier.
I have two NIC interface's assigned with three IP's:
Interface 1: ( Public IP's)
x.x.130.34
x.x.130.36 floating IP
interface 2: (private IP's)
10.10.1.31
.36 is a floating IP assigned by Linux-HA (heartbeat/pacemaker).
I only want to use .36 to receive and send sip traffic.
I uses force_send_socket() to send INVITE with .36 IP. But the ACK message always want to use .34 IP even the Route header has .36 in it unless I force it with force_send_socket() .
How can I fix this problem?
See below for the SIP messages: (x.x.128.205 is customer IP, x.x.129.200 is PSTN gateway IP)
U x.x.128.205:51694 -> x.x.130.36:5060
INVITE sip:5033441174 at x.x.130.36:5060<mailto:sip:5033441174 at x.x.130.36:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG
4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.3<mailto:sip:5033441174 at x.x.130.3>
6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.20>
5..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254113-3191264919-256
0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, CO
MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forwards: 70..Remote-P
arty-ID: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Timestamp: 1341322661
..Contact: <sip:5024427578 at x.x.128.205:5060><mailto:sip:5024427578 at x.x.128.205:5060>..Expires: 180..Allow-Events: telephone-event..Conte
nt-Type: application/sdp..Content-Length: 366....v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio 19312 RTP/AVP 125 0 18 100 10
1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8000..a
=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=rtpmap:101 telephone-event/8000
..a=fmtp:101 0-16..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9
hG4bK1D3CD1;rport=51694..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:502244117
4 at x.x.130.36<mailto:4 at x.x.130.36>>..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>: 101 INVITE..Se
rver: LVS Proxy 1.0..Content-Length: 0....
#
U x.x.130.36:5060 -> x.x.129.200:5060
INVITE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Record-Route: <sip:x.x.130.36;lr=on>..Via: S
IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport
=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:50224
41174 at x.x.130.36<mailto:41174 at x.x.130.36>>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
E39A at x.x.128.205..Supported<mailto:E39A at x.x.128.205..Supported>: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 411443261-3293254
113-3191264919-2560877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANC
EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forw
ards: 69..Remote-Party-ID: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;party=calling;screen=no;privacy=off..Tim
estamp: 1341322661..Contact: <sip:5024427578 at x.x.128.205:51694><mailto:sip:5024427578 at x.x.128.205:51694>..Expires: 180..Allow-Events: tel
ephone-event..Content-Type: application/sdp..Content-Length: 375....v=0..o=CiscoSystemsSIP-GW-UserA
gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4 10.200.1.51..t=0 0..m=audio 20464 RTP/AVP 12
5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G7
29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=rtpmap:101 telephone-
event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP 216.4
9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088
-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Cal
l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server: Cisco-SIPG
ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events: telephone-event..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/
UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;ta
g=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:4
1 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server:
Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq: 6708..Allow: INVITE, OPTIONS, B
YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: tele
phone-event..Contact: <sip:15033441174 at x.x.129.200:5060><mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>..Content-Disposition: session;handling=required..Content-Type: application/sdp..Content-Length: 2
90....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP Call..c=IN IP4 216
.49.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 x.x.129.200..a=rtpmap:0 PCMU/8000.
.a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD
1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F
0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at 216.
49.128.205..Timestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 10
0rel..RSeq: 6708..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact: <sip:15033441174 at x.x.129.200:50<mailto:sip:15033441174 at x.x.129.200:50>
60>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Disposition: session;handling=required..Conte
nt-Type: application/sdp..Content-Length: 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN I
P4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480 RTP/AVP 0 101 100..c=IN
IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpm
ap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
#
U x.x.128.205:51694 -> x.x.130.36:5060
PRACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9h
G4bK1D4474..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130<mailto:sip:5033441174 at x.x.130>.
36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
E39A at x.x.128.205..CSeq<mailto:E39A at x.x.128.205..CSeq>: 102 PRACK..RAck: 6708 101 INVITE..Route: <sip:x.x.130.36;lr=on>..Max-
Forwards: 70..Content-Length: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
PRACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bK92c
e.4def8436.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:50
24427578 at x.x.128.205<mailto:24427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Dat
e: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..CSeq>
: 102 PRACK..RAck: 6708 101 INVITE..Max-Forwards: 69..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.34:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bK92ce.4def8436.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID
: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>: Cisco-SIPGateway/IOS-12.x..CSeq: 102
PRACK..Content-Length: 0....
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D4474..From: <sip:
5024427578 at x.x.128.205<mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Se>
rver: Cisco-SIPGateway/IOS-12.x..CSeq: 102 PRACK..Content-Length: 0....
U x.x.129.200:5060 -> x.x.130.36:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59
..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID
: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Timestamp>: 1341322661..Server: Cisco-SIPGatew
ay/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSC
RIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: telephone-event..Contact: <sip:15033441174 at 216.
49.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on>..Content-Type: application/sdp..Content-L
ength: 290....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP Call..c=IN
IP4 x.x.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 x.x.129.200..a=rtpmap:0 PC
MU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 X-NSE/8000..a=fmtp:100 19
2-194..
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: <sip:
5024427578 at x.x.128.205<mailto:5024427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..D
ate: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Ti>
mestamp: 1341322661..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Allow: INVITE, OPTIONS, B
YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..Allow-Events: tele
phone-event..Contact: <sip:15033441174 at x.x.129.200:5060><mailto:sip:15033441174 at x.x.129.200:5060>..Record-Route: <sip:x.x.130.36;lr=on
>..Content-Type: application/sdp..Content-Length: 305....v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2
116 IN IP4 x.x.130.66..s=SIP Call..c=IN IP4 x.x.130.66..t=0 0..m=audio 19480 RTP/AVP 0 101 10
0..c=IN IP4 x.x.130.66..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16
..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=nortpproxy:yes..
#
U x.x.128.205:51694 -> x.x.130.36:5060
ACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG4
bK1D5DA6..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36<mailto:sip:5033441174 at x.x.130.36>
>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E3
9A at x.x.128.205<mailto:9A at x.x.128.205>..Route: <sip:x.x.130.36;lr=on>..Max-Forwards: 70..CSeq: 101 ACK..Content-Lengt
h: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
ACK sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKcydzi
gwkX..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D5DA6..From: <sip:5024427578
@x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue,
03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Max-Forwards>
: 69..CSeq: 101 ACK..Content-Length: 0....
#
U x.x.128.205:51694 -> x.x.130.36:5060
BYE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.128.205:5060;branch=z9hG4
bK1D61CE7..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.3<mailto:sip:5033441174 at x.x.130.3>
6>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E
39A at x.x.128.205..User-Agent<mailto:39A at x.x.128.205..User-Agent>: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 70..Route: <sip:x.x.130
.36;lr=on>..Timestamp: 1341322666..CSeq: 103 BYE..Reason: Q.850;cause=16..Content-Length: 0....
#
U x.x.130.34:5060 -> x.x.129.200:5060
BYE sip:15033441174 at x.x.129.200:5060<mailto:sip:15033441174 at x.x.129.200:5060> SIP/2.0..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKa2ce.
4ba2ee65.0..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:502
4427578 at x.x.128.205<mailto:4427578 at x.x.128.205>>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date
: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..User>-
Agent: Cisco-SIPGateway/IOS-12.x..Max-Forwards: 69..Timestamp: 1341322666..CSeq: 103 BYE..Reason: Q
.850;cause=16..Content-Length: 0....
#
U x.x.129.200:5060 -> x.x.130.34:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.130.34;branch=z9hG4bKa2ce.4ba2ee65.0,SIP/2.0/UDP x.x.12
8.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip:5024427578 at x.x.128.205><mailto:sip:5024427578 at x.x.128.205>;tag=24513088-D5
9..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-I
D: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..Server>: Cisco-SIPGateway/IOS-12.x..Timestamp
: 1341322666..Content-Length: 0..CSeq: 103 BYE....
#
U x.x.130.36:5060 -> x.x.128.205:51694
SIP/2.0 200 OK..Via: SIP/2.0/UDP x.x.128.205:5060;rport=51694;branch=z9hG4bK1D61CE7..From: <sip
:5024427578 at x.x.128.205>;tag=24513088-D59..To: <sip:5033441174 at x.x.130.36><mailto:sip:5033441174 at x.x.130.36>;tag=F0695368-74F..
Date: Tue, 03 Jul 2012 13:37:46 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S<mailto:1887588D-C44B11E1-BE38D697-98A3E39A at x.x.128.205..S>
erver: Cisco-SIPGateway/IOS-12.x..Timestamp: 1341322666..Content-Length: 0..CSeq: 103 BYE....
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org<mailto:sr-users at 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 at lists.sip-router.org<mailto:sr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120705/08b13693/attachment-0001.htm>
From agranig at sipwise.com Fri Jul 6 01:36:05 2012
From: agranig at sipwise.com (Andreas Granig)
Date: Fri, 06 Jul 2012 01:36:05 +0200
Subject: [SR-Users] Removing display-name with uac_replace_from
In-Reply-To: <4FF4C463.7020004@sipwise.com>
References: <4FF441CE.4070300@sipwise.com> <4FF49C9F.9070109@gmail.com>
<4FF4C463.7020004@sipwise.com>
Message-ID: <4FF624E5.8050404@sipwise.com>
Hi,
The attached patch does the trick for me, but I'd rather like to have a
second opinion on it for any potential side effects before pushing it.
The point here is that the fixup function didn't change (beside the
name) between 3.1 and 3.3, however 3.1 used dedicated w_replace_from1()
and w_replace_from2(), whereas 3.3 uses one unified w_replace_from(),
which breaks the behavior the fixup function is providing.
Thanks,
Andreas
On 07/05/2012 12:32 AM, Andreas Granig wrote:
> Hi,
>
> On 07/04/2012 09:42 PM, Daniel-Constantin Mierla wrote:
>> quick look into the sources shows that fixup makes the display parameter
>> null if its length is 0 -- perhaps introduced in the patch that unified
>> the fixup to work also for replacing the To header display. If you have
>> time and urgent need, you can push a fix for it asap, otherwise I will
>> look at it once getting some spare time out of traveling.
>
> Ok, I'll have a look at it tomorrow and push a fix.
>
> Andreas
>
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uac.patch
Type: text/x-patch
Size: 590 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120706/e1949f97/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120706/e1949f97/attachment.pgp>
From intel at intrans.baku.az Fri Jul 6 19:59:01 2012
From: intel at intrans.baku.az (intel at intrans.baku.az)
Date: Fri, 6 Jul 2012 22:59:01 +0500 (AZST)
Subject: [SR-Users] How to proxy/authenticate on third party sip server?
In-Reply-To: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
Message-ID: <24241.85.132.76.4.1341597541.squirrel@mail.az>
Can anybody help me with configuration kamailio to authenticate call on
3rd party server?
I want to authenticate(and proxy) call's on other server.
for example, user A have account on my server(let it be A at myserver.com)
and account on other server (let it be AA at hisserver.com)
myserver.com keeps A's credentials for AA at hisserver.com
when A is registered on myserver.com, he make call to B at othersip.com
(using myserver.com as a proxy)
Kamailio on myserver authenticate itself on hisserver as AA at hisserver.com,
makes call to destination, and connect it to A.
How can I setup kamailio for such behavior?
Which module should I use?
UAC seems can authenticate on another server, but I don't sure that it do
what I want. (I've tried it, but without much success)
From zanebupt at 163.com Mon Jul 9 08:36:07 2012
From: zanebupt at 163.com (=?GBK?B?1cU=?=)
Date: Mon, 9 Jul 2012 14:36:07 +0800 (CST)
Subject: [SR-Users] future features?
Message-ID: <68c3f0a8.b495.1386a73c1a4.Coremail.zanebupt@163.com>
Hello Dear all,
I'm new one to participate into this discussion. I have worked on VOIP and SIP communication solution for several years.
I'm very excited about the new features in v3.3. They save me many work which I planed to dig hard.
My question is whether there is a web page or discuss forum for future features for Kamailio? There is a fure feature page on sip-router.org but it's very out of date.
I think it's important to catch up with potential wanted feature and the new draft which is closely watched by kamailio team.
Thanks!
Best
Regards
Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120709/53859585/attachment.htm>
From aftnix at gmail.com Mon Jul 9 13:27:40 2012
From: aftnix at gmail.com (Aft nix)
Date: Mon, 9 Jul 2012 17:27:40 +0600
Subject: [SR-Users] sip over tls is not working
Message-ID: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
Hi,
I have enabled tls parameters as follows:
in kamailio.cfg
listen = tls:<IP>:<PORT>
in tls.cfg
[server:<IP>:<PORT>]
method = TLSv1
verify_certificate = no
require_certificate = no
private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
Now if i try to connect to this interface using openssl s_client, it
does connects,
but now server certificate is sent from kamailio.
kamailio log shows this :
<core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
<core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
<core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
<core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
0xb5701580), fd_no=11
<core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
fd_no=12 called
<core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
<core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
connection passed to the least busy one (3289651)
<core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
[tls:<IP>:<PORT>], 0xb5701580
<core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid 2491)
I'm using kamailio from git. its updated to the latest.
Thanks in advance.
--
-aft
From abalashov at evaristesys.com Mon Jul 9 13:52:54 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 09 Jul 2012 07:52:54 -0400
Subject: [SR-Users] usrloc concurrency
Message-ID: <45sx10tiip6kyi4hc2db8c7n.1341834774856@email.android.com>
(Reposting from sr-dev because, in retrospect, it makes more sense here.)
Does anyone know of any issues running usrloc with DB backing ('location') in a multi-master DB-replicated environment? I am referring to plain usrloc, not p_usrloc.
I have such an environment set up with db_mode = 1 (immediate write-through) and have run into a problem where Kamailio occasionally stops writing to the location table for no apparent reason. I am wondering if this is because another Kamailio instance bound to the secondary replica is performing a DB sync as well, and at some point they collide in some sort of race condition. Would db_mode 2 fix? Would anything fix? Is this even the problem?
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com
From klaus.mailinglists at pernau.at Mon Jul 9 15:04:38 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Mon, 09 Jul 2012 15:04:38 +0200
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
Message-ID: <4FFAD6E6.4030503@pernau.at>
Use wireshark to analyze the TLS handshake
regards
klaus
On 09.07.2012 13:27, Aft nix wrote:
> Hi,
>
> I have enabled tls parameters as follows:
>
> in kamailio.cfg
>
> listen = tls:<IP>:<PORT>
>
> in tls.cfg
>
> [server:<IP>:<PORT>]
> method = TLSv1
> verify_certificate = no
> require_certificate = no
> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>
> Now if i try to connect to this interface using openssl s_client, it
> does connects,
> but now server certificate is sent from kamailio.
>
> kamailio log shows this :
>
> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
> 0xb5701580), fd_no=11
> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
> fd_no=12 called
> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
> connection passed to the least busy one (3289651)
> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
> [tls:<IP>:<PORT>], 0xb5701580
> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid 2491)
>
> I'm using kamailio from git. its updated to the latest.
> Thanks in advance.
>
From miconda at gmail.com Mon Jul 9 18:24:05 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 09 Jul 2012 18:24:05 +0200
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <4FFAD6E6.4030503@pernau.at>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFAD6E6.4030503@pernau.at>
Message-ID: <4FFB05A5.6030607@gmail.com>
Hello,
also, can you provide more details about the case? Is it with the very
first connection or you do some load testing and at some point you get
this issue?
Can you reproduce it always? Do you set different number of workers per
socket? What is the output of 'kamctl ps'?
Have you tried with 3.3 branch as well or just master branch?
Cheers,
Daniel
On 7/9/12 3:04 PM, Klaus Darilion wrote:
> Use wireshark to analyze the TLS handshake
>
> regards
> klaus
>
> On 09.07.2012 13:27, Aft nix wrote:
>> Hi,
>>
>> I have enabled tls parameters as follows:
>>
>> in kamailio.cfg
>>
>> listen = tls:<IP>:<PORT>
>>
>> in tls.cfg
>>
>> [server:<IP>:<PORT>]
>> method = TLSv1
>> verify_certificate = no
>> require_certificate = no
>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>>
>> Now if i try to connect to this interface using openssl s_client, it
>> does connects,
>> but now server certificate is sent from kamailio.
>>
>> kamailio log shows this :
>>
>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
>> 0xb5701580), fd_no=11
>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
>> fd_no=12 called
>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
>> connection passed to the least busy one (3289651)
>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
>> [tls:<IP>:<PORT>], 0xb5701580
>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid
>> 2491)
>>
>> I'm using kamailio from git. its updated to the latest.
>> Thanks in advance.
>>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Mon Jul 9 18:32:31 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 09 Jul 2012 18:32:31 +0200
Subject: [SR-Users] future features?
In-Reply-To: <68c3f0a8.b495.1386a73c1a4.Coremail.zanebupt@163.com>
References: <68c3f0a8.b495.1386a73c1a4.Coremail.zanebupt@163.com>
Message-ID: <4FFB079F.5060200@gmail.com>
Hello,
we could create a wiki page for future plans, not sure if devs will
start using it. There was a roadmap plan when there were some obvious
core SIP RFC requirements to be done, but we that part completed, now it
is more like each own needs getting developed.
Usually the people discuss it on sr-dev at lists.sip-router.org mailing
list, announcing the plan and looking to see if anyone else is doing the
same just to avoid duplicate efforts:
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
So, if people want to use a wiki page for listing future feature, just
create an account on wiki portal and start the page (just please use a
dokuwiki namespace, not to store the page in the root folder -- it could
be under 'devel', this namespace is there already, so the page can be
created under a wiki local link such as [[devel:future]]).
Cheers,
Daniel
On 7/9/12 8:36 AM, ? wrote:
> Hello Dear all,
> I'm new one to participate into this discussion. I have worked on VOIP
> and SIP communication solution for several years.
> I'm very excited about the new features in v3.3. They save me many
> work which I planed to dig hard.
> My question is whether there is a web page or discuss forum for future
> features for Kamailio? There is a fure feature page on sip-router.org
> but it's very out of date.
> I think it's important to catch up with potential wanted feature and
> the new draft which is closely watched by kamailio team.
> Thanks!
> Best
> Regards
>
> Victor
>
>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120709/800c27d0/attachment.htm>
From miconda at gmail.com Mon Jul 9 18:37:08 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 09 Jul 2012 18:37:08 +0200
Subject: [SR-Users] How to proxy/authenticate on third party sip server?
In-Reply-To: <24241.85.132.76.4.1341597541.squirrel@mail.az>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
<24241.85.132.76.4.1341597541.squirrel@mail.az>
Message-ID: <4FFB08B4.8070805@gmail.com>
Hello,
On 7/6/12 7:59 PM, intel at intrans.baku.az wrote:
> Can anybody help me with configuration kamailio to authenticate call on
> 3rd party server?
>
> I want to authenticate(and proxy) call's on other server.
>
> for example, user A have account on my server(let it be A at myserver.com)
> and account on other server (let it be AA at hisserver.com)
> myserver.com keeps A's credentials for AA at hisserver.com
> when A is registered on myserver.com, he make call to B at othersip.com
> (using myserver.com as a proxy)
> Kamailio on myserver authenticate itself on hisserver as AA at hisserver.com,
> makes call to destination, and connect it to A.
>
> How can I setup kamailio for such behavior?
> Which module should I use?
> UAC seems can authenticate on another server, but I don't sure that it do
> what I want. (I've tried it, but without much success)
indeed, the uac module is the one that can provide what you want, with
some limitations in regard to cseq incrementation. You have to set a
failure route and if the reply code is 407, the sent the realm/username
and password to the avps specified by the appropriate module parameters
-- the next tree at:
*
http://kamailio.org/docs/modules/stable/modules_k/uac.html#auth-realm-avp-id
Then call uac_auth() and relay again.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Mon Jul 9 18:38:49 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 09 Jul 2012 18:38:49 +0200
Subject: [SR-Users] Removing display-name with uac_replace_from
In-Reply-To: <4FF624E5.8050404@sipwise.com>
References: <4FF441CE.4070300@sipwise.com> <4FF49C9F.9070109@gmail.com>
<4FF4C463.7020004@sipwise.com> <4FF624E5.8050404@sipwise.com>
Message-ID: <4FFB0919.5000009@gmail.com>
Hello,
On 7/6/12 1:36 AM, Andreas Granig wrote:
> Hi,
>
> The attached patch does the trick for me, but I'd rather like to have a
> second opinion on it for any potential side effects before pushing it.
looks ok, go ahead and push it in master and then backport it.
>
> The point here is that the fixup function didn't change (beside the
> name) between 3.1 and 3.3, however 3.1 used dedicated w_replace_from1()
> and w_replace_from2(), whereas 3.3 uses one unified w_replace_from(),
> which breaks the behavior the fixup function is providing.
I see, thanks for clarifications.
Cheers,
Daniel
>
> Thanks,
> Andreas
>
> On 07/05/2012 12:32 AM, Andreas Granig wrote:
>> Hi,
>>
>> On 07/04/2012 09:42 PM, Daniel-Constantin Mierla wrote:
>>> quick look into the sources shows that fixup makes the display parameter
>>> null if its length is 0 -- perhaps introduced in the patch that unified
>>> the fixup to work also for replacing the To header display. If you have
>>> time and urgent need, you can push a fix for it asap, otherwise I will
>>> look at it once getting some spare time out of traveling.
>> Ok, I'll have a look at it tomorrow and push a fix.
>>
>> Andreas
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120709/c86d0ffb/attachment-0001.htm>
From aftnix at gmail.com Mon Jul 9 18:51:47 2012
From: aftnix at gmail.com (Aft nix)
Date: Mon, 9 Jul 2012 22:51:47 +0600
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <4FFAD6E6.4030503@pernau.at>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFAD6E6.4030503@pernau.at>
Message-ID: <CAGuaRCvzJ11tvM_N6zGewXmpPmhUniptVCYT__y=tJrfWN3ROQ@mail.gmail.com>
On Mon, Jul 9, 2012 at 7:04 PM, Klaus Darilion
<klaus.mailinglists at pernau.at> wrote:
> Use wireshark to analyze the TLS handshake
>
Thanks for the suggestion. I'll analyze it and post my findings.
> regards
> klaus
>
>
> On 09.07.2012 13:27, Aft nix wrote:
>>
>> Hi,
>>
>> I have enabled tls parameters as follows:
>>
>> in kamailio.cfg
>>
>> listen = tls:<IP>:<PORT>
>>
>> in tls.cfg
>>
>> [server:<IP>:<PORT>]
>> method = TLSv1
>> verify_certificate = no
>> require_certificate = no
>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>>
>> Now if i try to connect to this interface using openssl s_client, it
>> does connects,
>> but now server certificate is sent from kamailio.
>>
>> kamailio log shows this :
>>
>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
>> 0xb5701580), fd_no=11
>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
>> fd_no=12 called
>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
>> connection passed to the least busy one (3289651)
>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
>> [tls:<IP>:<PORT>], 0xb5701580
>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid 2491)
>>
>> I'm using kamailio from git. its updated to the latest.
>> Thanks in advance.
>>
>
--
-aft
From peter.dunkley at crocodile-rcs.com Mon Jul 9 19:17:13 2012
From: peter.dunkley at crocodile-rcs.com (Peter Dunkley)
Date: Mon, 09 Jul 2012 18:17:13 +0100
Subject: [SR-Users] [Fwd: [sr-dev] WebSocket Server support in Kamailio
master]
Message-ID: <1341854233.7243.8.camel@pd-notebook-linux.croc.internal>
-------- Forwarded Message --------
From: Peter Dunkley <peter.dunkley at crocodile-rcs.com>
Reply-to: Development mailing list of the sip-router project
<sr-dev at lists.sip-router.org>
To: sr-dev at lists.sip-router.org
Subject: [sr-dev] WebSocket Server support in Kamailio master
Date: Sat, 7 Jul 2012 18:29:23 +0100
Hello,
I have merged the pd/websocket branch into Kamailio master. This means
that you can now connect SIP over WebSocket
(draft-ibc-sipcore-sip-websocket-02) clients to Kamailio using the "ws://"
and "wss://" protocols.
Some customisation of the websocket module is possible through modparams,
but for most users the defaults should be OK. The WebSocket module uses
the xhttp and sl modules for the initial handshake, and (unless you have
both a Kamailio installation and WebSocket SIP client supporting GRUU,
Outbound[1], and Path[2]) nathelper for request routing and the core
force_rport() function for response routing (a new nat_uac_test() has been
added to detect whether a message has arrived on a WebSocket). There is
an example kamailio.cfg in the websocket module directory.
[1] Kamailio does not currently support Outbound
[2] I have not updated the Path module for WebSockets
I believe that, once Kamailio supports Outbound and WebSocket support is
added to the Path module (and you have a SIP over WebSocket client that
supports this), it will be possible to use the websocket module without
the nathelper module and force_rport() and without needing to change the
websocket module or Kamailio core code.
If you want to use secure WebSockets (wss) as well as ordinary WebSockets
just configure TLS and listen on an appropriate port.
I have added WebSocket support to some modules, but there are definitely
going to be others (modules/lcr, modules/sipcapture,
modules_k/nat_traversal, modules_k/path, modules_k/seas, and
modules_k/snmpstats, at least) that need updating too. WebSockets is an
unusual transport, so I have put a few notes together for anyone who needs
to use it in the code (including adding support to additional modules):
- A WebSocket server cannot initiate a WebSocket connection. So a
WebSocket connection (over TCP or TLS) is like a TCP/TLS connection coming
from behind a NAT. This is why nathelper aliasing and force_rport() is
used for the routing, and "set_..._no_connect()" is always used (it's set
within the websocket module).
- WebSocket (PROTO_WS) and secure WebSocket (PROTO_WSS) connections are
just upgraded TCP and TLS connections, so there are no listening sockets
for PROTO_WS and PROTO_WSS. This means that, when deciding on what
transport is being used, you need to look at the proto set in the
tcp_connection, receive_info, and/or dest_info structure for the message -
looking at the socket_info structure (that the message has arrived on or
will be sent on) will not give you the right answer.
- Although WebSocket (PROTO_WS) and secure WebSocket (PROTO_WSS) are
different internal protocols there is only one SIP transport type for both
";transport=ws" (WS and WSS are explicitly used in Via: headers though).
This means that you can't tell whether the transport parameter in an
R-URI, Route/Record-Route, or Contact-URI is for WebSockets or secure
WebSockets. As long as the message makes it into the WebSocket module
everything will be OK as that module sorts it all out, but it has led to
slightly more complex checks being required in some of the code relating
to record-routing to handle this - and it may have an effect on other
modules too.
Please give the new module a go and let me know about any issues you find,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120709/a6649b94/attachment.htm>
From intel at intrans.baku.az Tue Jul 10 11:50:45 2012
From: intel at intrans.baku.az (intel at intrans.baku.az)
Date: Tue, 10 Jul 2012 14:50:45 +0500 (AZST)
Subject: [SR-Users] =?utf-8?b?IFJlOsKgwqBIb3fCoHRvwqBwcm94eS9hdXRoZW50aWNh?=
=?utf-8?b?dGXCoG9uwqB0aGlyZMKgcGFydHnCoHNpcMKgc2VydmVyPw==?=
In-Reply-To: <4FFB08B4.8070805@gmail.com>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
<24241.85.132.76.4.1341597541.squirrel@mail.az>
<4FFB08B4.8070805@gmail.com>
Message-ID: <28622.85.132.76.4.1341913845.squirrel@mail.az>
Daniel-Constantin Mierla said:
> Hello,
>
> On 7/6/12 7:59 PM, intel at intrans.baku.az wrote:
>> Can anybody help me with configuration kamailio to authenticate call on
>> 3rd party server?
>>
>> I want to authenticate(and proxy) call's on other server.
>>
>> for example, user A have account on my server(let it be A at myserver.com)
>> and account on other server (let it be AA at hisserver.com)
>> myserver.com keeps A's credentials for AA at hisserver.com
>> when A is registered on myserver.com, he make call to B at othersip.com
>> (using myserver.com as a proxy)
>> Kamailio on myserver authenticate itself on hisserver as
>> AA at hisserver.com,
>> makes call to destination, and connect it to A.
>>
>> How can I setup kamailio for such behavior?
>> Which module should I use?
>> UAC seems can authenticate on another server, but I don't sure that it
>> do
>> what I want. (I've tried it, but without much success)
> indeed, the uac module is the one that can provide what you want, with
> some limitations in regard to cseq incrementation. You have to set a
> failure route and if the reply code is 407, the sent the realm/username
> and password to the avps specified by the appropriate module parameters
> -- the next tree at:
>
> *
> http://kamailio.org/docs/modules/stable/modules_k/uac.html#auth-realm-avp-id
>
> Then call uac_auth() and relay again.
You mean, i need set auth_*_avp with credentials. set failure route, send
request to auth_proxy (btw, how? ) and call uac_auth() in failure route,
correct?
I've tried to use uacreg sql table and uac_reg_request_to, but there was
some problems:
1) in uac_reg_request_to with mode 1 mistake (it found credentials only if
l_uuid==l_username)
i've opened ticket on bugtracker
http://sourceforge.net/tracker/?func=detail&aid=3540479&group_id=139143&atid=743020
2) uac_reg_request_to changes uri in request and instead INVITE
sip:B at othersip.com makes INVITE sip:AA at hisserver.com
if comment out
snprintf(ruri, MAX_URI_SIZE, "sip:%.*s@%.*s",
reg->r_username.len, reg->r_username.s,
reg->r_domain.len, reg->r_domain.s);
and so on seems working, but I'm don't sure that such modification don't
break something else
(pretty sure that breaks, but don't know where exactly :)
3)uacreg table loaded on startup, and AFAIK there is no way to modify it
dynamically,
so if you change something in this table you MUST restart kamailio (not
convinient)
I've tried to make RPC for adding new record in htable (using
reg_ht_add()), but it returns error and in log I can see
ERROR: uac [uac_reg.c:313]: no more shm
> Cheers,
> Daniel
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
--
From miconda at gmail.com Tue Jul 10 11:43:48 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 10 Jul 2012 11:43:48 +0200
Subject: [SR-Users]
=?utf-8?b?wqDCoEhvd8KgdG/CoHByb3h5L2F1dGhlbnRpY2F0ZcKg?=
=?utf-8?b?b27CoHRoaXJkwqBwYXJ0ecKgc2lwwqBzZXJ2ZXI/?=
In-Reply-To: <28622.85.132.76.4.1341913845.squirrel@mail.az>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
<24241.85.132.76.4.1341597541.squirrel@mail.az>
<4FFB08B4.8070805@gmail.com>
<28622.85.132.76.4.1341913845.squirrel@mail.az>
Message-ID: <4FFBF954.50104@gmail.com>
On 7/10/12 11:50 AM, intel at intrans.baku.az wrote:
> Daniel-Constantin Mierla said:
>> Hello,
>>
>> On 7/6/12 7:59 PM, intel at intrans.baku.az wrote:
>>> Can anybody help me with configuration kamailio to authenticate call on
>>> 3rd party server?
>>>
>>> I want to authenticate(and proxy) call's on other server.
>>>
>>> for example, user A have account on my server(let it be A at myserver.com)
>>> and account on other server (let it be AA at hisserver.com)
>>> myserver.com keeps A's credentials for AA at hisserver.com
>>> when A is registered on myserver.com, he make call to B at othersip.com
>>> (using myserver.com as a proxy)
>>> Kamailio on myserver authenticate itself on hisserver as
>>> AA at hisserver.com,
>>> makes call to destination, and connect it to A.
>>>
>>> How can I setup kamailio for such behavior?
>>> Which module should I use?
>>> UAC seems can authenticate on another server, but I don't sure that it
>>> do
>>> what I want. (I've tried it, but without much success)
>> indeed, the uac module is the one that can provide what you want, with
>> some limitations in regard to cseq incrementation. You have to set a
>> failure route and if the reply code is 407, the sent the realm/username
>> and password to the avps specified by the appropriate module parameters
>> -- the next tree at:
>>
>> *
>> http://kamailio.org/docs/modules/stable/modules_k/uac.html#auth-realm-avp-id
>>
>> Then call uac_auth() and relay again.
> You mean, i need set auth_*_avp with credentials. set failure route, send
> request to auth_proxy (btw, how? ) and call uac_auth() in failure route,
> correct?
t_relay() is one of the functions to sent the request further.
>
> I've tried to use uacreg sql table and uac_reg_request_to, but there was
> some problems:
> 1) in uac_reg_request_to with mode 1 mistake (it found credentials only if
> l_uuid==l_username)
> i've opened ticket on bugtracker
> http://sourceforge.net/tracker/?func=detail&aid=3540479&group_id=139143&atid=743020
> 2) uac_reg_request_to changes uri in request and instead INVITE
> sip:B at othersip.com makes INVITE sip:AA at hisserver.com
> if comment out
> snprintf(ruri, MAX_URI_SIZE, "sip:%.*s@%.*s",
> reg->r_username.len, reg->r_username.s,
> reg->r_domain.len, reg->r_domain.s);
> and so on seems working, but I'm don't sure that such modification don't
> break something else
> (pretty sure that breaks, but don't know where exactly :)
> 3)uacreg table loaded on startup, and AFAIK there is no way to modify it
> dynamically,
> so if you change something in this table you MUST restart kamailio (not
> convinient)
> I've tried to make RPC for adding new record in htable (using
> reg_ht_add()), but it returns error and in log I can see
> ERROR: uac [uac_reg.c:313]: no more shm
If you have a lot of records, you need to allocate more shared memory,
via -m command line parameter.
uacreg is to register for incoming calls, it is not used for
authentication of outgoing calls. Use uac_auth() instead, as I said in
previous email.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From intel at intrans.baku.az Tue Jul 10 12:14:43 2012
From: intel at intrans.baku.az (intel at intrans.baku.az)
Date: Tue, 10 Jul 2012 15:14:43 +0500 (AZST)
Subject: [SR-Users] =?utf-8?b?IFJlOsKgwqDCoEhvd8KgdG/CoHByb3h5L2F1dGhlbnRp?=
=?utf-8?b?Y1JlOsKgwqDCoEhvd8KgdG/CoHByb3h5L2F1dGhlbnRpY2F0ZcKgb27CoHRo?=
=?utf-8?b?aVJlOsKgwqDCoEhvd8KgdG/CoHByb3h5L2F1dGhlbnRpY2F0ZcKgb27CoHRo?=
=?utf-8?b?aXJkwqBwYXJ0ecKgc2lwwqBzZXJ2ZXI/?=
In-Reply-To: <4FFBF954.50104@gmail.com>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
<24241.85.132.76.4.1341597541.squirrel@mail.az>
<4FFB08B4.8070805@gmail.com>
<28622.85.132.76.4.1341913845.squirrel@mail.az>
<4FFBF954.50104@gmail.com>
Message-ID: <35224.85.132.76.4.1341915283.squirrel@mail.az>
Daniel-Constantin Mierla said:
>
> On 7/10/12 11:50 AM, intel at intrans.baku.az wrote:
>> Daniel-Constantin Mierla said:
>>> Hello,
>>>
>>> On 7/6/12 7:59 PM, intel at intrans.baku.az wrote:
>>>> Can anybody help me with configuration kamailio to authenticate call
>>>> on
>>>> 3rd party server?
>>>>
>>>> I want to authenticate(and proxy) call's on other server.
>>>>
>>>> for example, user A have account on my server(let it be
>>>> A at myserver.com)
>>>> and account on other server (let it be AA at hisserver.com)
>>>> myserver.com keeps A's credentials for AA at hisserver.com
>>>> when A is registered on myserver.com, he make call to B at othersip.com
>>>> (using myserver.com as a proxy)
>>>> Kamailio on myserver authenticate itself on hisserver as
>>>> AA at hisserver.com,
>>>> makes call to destination, and connect it to A.
>>>>
>>>> How can I setup kamailio for such behavior?
>>>> Which module should I use?
>>>> UAC seems can authenticate on another server, but I don't sure that it
>>>> do
>>>> what I want. (I've tried it, but without much success)
>>> indeed, the uac module is the one that can provide what you want, with
>>> some limitations in regard to cseq incrementation. You have to set a
>>> failure route and if the reply code is 407, the sent the realm/username
>>> and password to the avps specified by the appropriate module parameters
>>> -- the next tree at:
>>>
>>> *
>>> http://kamailio.org/docs/modules/stable/modules_k/uac.html#auth-realm-avp-id
>>>
>>> Then call uac_auth() and relay again.
>> You mean, i need set auth_*_avp with credentials. set failure route,
>> send
>> request to auth_proxy (btw, how? ) and call uac_auth() in failure route,
>> correct?
> t_relay() is one of the functions to sent the request further.
I mean how set next hop not to final destination, but to auth_proxy?
>
>>
>> I've tried to use uacreg sql table and uac_reg_request_to, but there was
>> some problems:
>> 1) in uac_reg_request_to with mode 1 mistake (it found credentials only
>> if
>> l_uuid==l_username)
>> i've opened ticket on bugtracker
>> http://sourceforge.net/tracker/?func=detail&aid=3540479&group_id=139143&atid=743020
>> 2) uac_reg_request_to changes uri in request and instead INVITE
>> sip:B at othersip.com makes INVITE sip:AA at hisserver.com
>> if comment out
>> snprintf(ruri, MAX_URI_SIZE, "sip:%.*s@%.*s",
>> reg->r_username.len, reg->r_username.s,
>> reg->r_domain.len, reg->r_domain.s);
>> and so on seems working, but I'm don't sure that such modification don't
>> break something else
>> (pretty sure that breaks, but don't know where exactly :)
>> 3)uacreg table loaded on startup, and AFAIK there is no way to modify it
>> dynamically,
>> so if you change something in this table you MUST restart kamailio
>> (not
>> convinient)
>> I've tried to make RPC for adding new record in htable (using
>> reg_ht_add()), but it returns error and in log I can see
>> ERROR: uac [uac_reg.c:313]: no more shm
> If you have a lot of records, you need to allocate more shared memory,
> via -m command line parameter.
19 records in table -OK
1 record in table and try to add using RPC (self modified uac_reg.c) - no
more shm.
I think than there is not shortage of shared memory, but something
forgotten in function for RPC. Here is src
static void rpc_uac_reg_add(rpc_t* rpc, void* ctx)
{
reg_uac_t reg ;
str l_uuid, l_username, l_domain, r_username, r_domain, realm,
auth_username, auth_password, auth_proxy;
int expire;
if(_reg_htable==NULL)
{
rpc->fault(ctx, 500, "Not enabled");
return;
}
if (rpc->scan(ctx, "SSSSSSSSSd", &l_uuid, &l_username, &l_domain,
&r_username, &r_domain, &realm, &auth_username, &auth_password,
&auth_proxy, &expire) < 0) {
return;
}
memset(®, 0, sizeof(reg_uac_t));;
/* check for NULL values ?!?! */
reg.l_uuid=l_uuid;
reg.l_username=l_username;
reg.l_domain=l_domain;
reg.r_username=r_username;
reg.r_domain=r_domain;
reg.realm=realm;
reg.auth_username=auth_username;
reg.auth_password=auth_password;
reg.auth_proxy=auth_proxy;
reg.expires = expire;
if(reg_ht_add(®)<0)
{
rpc->fault(ctx, 500, "Error adding reg to htable");
return;
}
}
>
> uacreg is to register for incoming calls, it is not used for
> authentication of outgoing calls. Use uac_auth() instead, as I said in
> previous email.
>
I'll try.
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
--
From miconda at gmail.com Tue Jul 10 12:16:51 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 10 Jul 2012 12:16:51 +0200
Subject: [SR-Users]
=?utf-8?b?wqBIb3fCoHRvwqBwcm94eS9hdXRoZW50aWNhdGXCoG9u?=
=?utf-8?b?wqB0aGlyZC4uLg==?=
In-Reply-To: <35224.85.132.76.4.1341915283.squirrel@mail.az>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
<24241.85.132.76.4.1341597541.squirrel@mail.az>
<4FFB08B4.8070805@gmail.com>
<28622.85.132.76.4.1341913845.squirrel@mail.az>
<4FFBF954.50104@gmail.com>
<35224.85.132.76.4.1341915283.squirrel@mail.az>
Message-ID: <4FFC0113.8090400@gmail.com>
On 7/10/12 12:14 PM, intel at intrans.baku.az wrote:
> Daniel-Constantin Mierla said:
>> On 7/10/12 11:50 AM, intel at intrans.baku.az wrote:
>>> Daniel-Constantin Mierla said:
>>>> Hello,
>>>>
>>>> On 7/6/12 7:59 PM, intel at intrans.baku.az wrote:
>>>>> Can anybody help me with configuration kamailio to authenticate call
>>>>> on
>>>>> 3rd party server?
>>>>>
>>>>> I want to authenticate(and proxy) call's on other server.
>>>>>
>>>>> for example, user A have account on my server(let it be
>>>>> A at myserver.com)
>>>>> and account on other server (let it be AA at hisserver.com)
>>>>> myserver.com keeps A's credentials for AA at hisserver.com
>>>>> when A is registered on myserver.com, he make call to B at othersip.com
>>>>> (using myserver.com as a proxy)
>>>>> Kamailio on myserver authenticate itself on hisserver as
>>>>> AA at hisserver.com,
>>>>> makes call to destination, and connect it to A.
>>>>>
>>>>> How can I setup kamailio for such behavior?
>>>>> Which module should I use?
>>>>> UAC seems can authenticate on another server, but I don't sure that it
>>>>> do
>>>>> what I want. (I've tried it, but without much success)
>>>> indeed, the uac module is the one that can provide what you want, with
>>>> some limitations in regard to cseq incrementation. You have to set a
>>>> failure route and if the reply code is 407, the sent the realm/username
>>>> and password to the avps specified by the appropriate module parameters
>>>> -- the next tree at:
>>>>
>>>> *
>>>> http://kamailio.org/docs/modules/stable/modules_k/uac.html#auth-realm-avp-id
>>>>
>>>> Then call uac_auth() and relay again.
>>> You mean, i need set auth_*_avp with credentials. set failure route,
>>> send
>>> request to auth_proxy (btw, how? ) and call uac_auth() in failure route,
>>> correct?
>> t_relay() is one of the functions to sent the request further.
> I mean how set next hop not to final destination, but to auth_proxy?
>
>>> I've tried to use uacreg sql table and uac_reg_request_to, but there was
>>> some problems:
>>> 1) in uac_reg_request_to with mode 1 mistake (it found credentials only
>>> if
>>> l_uuid==l_username)
>>> i've opened ticket on bugtracker
>>> http://sourceforge.net/tracker/?func=detail&aid=3540479&group_id=139143&atid=743020
>>> 2) uac_reg_request_to changes uri in request and instead INVITE
>>> sip:B at othersip.com makes INVITE sip:AA at hisserver.com
>>> if comment out
>>> snprintf(ruri, MAX_URI_SIZE, "sip:%.*s@%.*s",
>>> reg->r_username.len, reg->r_username.s,
>>> reg->r_domain.len, reg->r_domain.s);
>>> and so on seems working, but I'm don't sure that such modification don't
>>> break something else
>>> (pretty sure that breaks, but don't know where exactly :)
>>> 3)uacreg table loaded on startup, and AFAIK there is no way to modify it
>>> dynamically,
>>> so if you change something in this table you MUST restart kamailio
>>> (not
>>> convinient)
>>> I've tried to make RPC for adding new record in htable (using
>>> reg_ht_add()), but it returns error and in log I can see
>>> ERROR: uac [uac_reg.c:313]: no more shm
>> If you have a lot of records, you need to allocate more shared memory,
>> via -m command line parameter.
> 19 records in table -OK
> 1 record in table and try to add using RPC (self modified uac_reg.c) - no
> more shm.
can you set debug=3 in you config file, try again and send all log
messages of the operation here?
Cheers,
DAniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Tue Jul 10 12:21:52 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 10 Jul 2012 12:21:52 +0200
Subject: [SR-Users] usrloc concurrency
In-Reply-To: <45sx10tiip6kyi4hc2db8c7n.1341834774856@email.android.com>
References: <45sx10tiip6kyi4hc2db8c7n.1341834774856@email.android.com>
Message-ID: <4FFC0240.7090400@gmail.com>
I asked also on devel list, but no follow up there, so here again for
the sake of going on with the conversation on this forum:
Is this like blocking or just not writing to db, but in memory
everything is ok? iirc, all db failed operations should be reported as
error to syslog, do you get any?
Cheers,
Daniel
On 7/9/12 1:52 PM, Alex Balashov wrote:
> (Reposting from sr-dev because, in retrospect, it makes more sense here.)
>
> Does anyone know of any issues running usrloc with DB backing ('location') in a multi-master DB-replicated environment? I am referring to plain usrloc, not p_usrloc.
>
> I have such an environment set up with db_mode = 1 (immediate write-through) and have run into a problem where Kamailio occasionally stops writing to the location table for no apparent reason. I am wondering if this is because another Kamailio instance bound to the secondary replica is performing a DB sync as well, and at some point they collide in some sort of race condition. Would db_mode 2 fix? Would anything fix? Is this even the problem?
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Tue Jul 10 12:24:08 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 10 Jul 2012 12:24:08 +0200
Subject: [SR-Users] Does there exist a tutorial on the Kamailio SIP/XMPP
Gateway configuration?
In-Reply-To: <EB778D84070B8843BF00498252ABA0624320C9A0@WDKSJEXMB02.msj.wdc.com>
References: <EB778D84070B8843BF00498252ABA0624320C9A0@WDKSJEXMB02.msj.wdc.com>
Message-ID: <4FFC02C8.3040503@gmail.com>
Hello,
On 7/3/12 2:25 AM, Auro Tripathy wrote:
>
> I'm finding that I may have to piece together (the configuration info)
> from version emails/presentations.
>
> Reluctantly, I'll take that approach...unless someone has a lucid
> HOWTO on the topic?
>
> Again, I'm new to the domain and I appreciate the subject-matter
> experts that have helped out so far.
>
I am not aware of any online tutorial for this topic. You can start a
wiki page for it (at http://www.kamailio.org/wiki/), if you collect from
email archive, then others may contribute and make its content richer.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120710/d76cce92/attachment.htm>
From intel at intrans.baku.az Tue Jul 10 12:47:30 2012
From: intel at intrans.baku.az (intel at intrans.baku.az)
Date: Tue, 10 Jul 2012 15:47:30 +0500 (AZST)
Subject: [SR-Users] =?utf-8?b?IFJlOsKgwqBIb3fCoHRvwqBwcm94eS9hdXRoZW50aWNh?=
=?utf-8?b?dGXCoG9uwqB0aGlyZC4uLg==?=
In-Reply-To: <4FFC0113.8090400@gmail.com>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
<24241.85.132.76.4.1341597541.squirrel@mail.az>
<4FFB08B4.8070805@gmail.com>
<28622.85.132.76.4.1341913845.squirrel@mail.az>
<4FFBF954.50104@gmail.com>
<35224.85.132.76.4.1341915283.squirrel@mail.az>
<4FFC0113.8090400@gmail.com>
Message-ID: <43032.85.132.76.4.1341917250.squirrel@mail.az>
Daniel-Constantin Mierla said:
>
> On 7/10/12 12:14 PM, intel at intrans.baku.az wrote:
>> Daniel-Constantin Mierla said:
>>> On 7/10/12 11:50 AM, intel at intrans.baku.az wrote:
>>>> Daniel-Constantin Mierla said:
>>>>> Hello,
>>>>>
>>>>> On 7/6/12 7:59 PM, intel at intrans.baku.az wrote:
>>>>>> Can anybody help me with configuration kamailio to authenticate call
>>>>>> on
>>>>>> 3rd party server?
>>>>>>
>>>>>> I want to authenticate(and proxy) call's on other server.
>>>>>>
>>>>>> for example, user A have account on my server(let it be
>>>>>> A at myserver.com)
>>>>>> and account on other server (let it be AA at hisserver.com)
>>>>>> myserver.com keeps A's credentials for AA at hisserver.com
>>>>>> when A is registered on myserver.com, he make call to B at othersip.com
>>>>>> (using myserver.com as a proxy)
>>>>>> Kamailio on myserver authenticate itself on hisserver as
>>>>>> AA at hisserver.com,
>>>>>> makes call to destination, and connect it to A.
>>>>>>
>>>>>> How can I setup kamailio for such behavior?
>>>>>> Which module should I use?
>>>>>> UAC seems can authenticate on another server, but I don't sure that
>>>>>> it
>>>>>> do
>>>>>> what I want. (I've tried it, but without much success)
>>>>> indeed, the uac module is the one that can provide what you want,
>>>>> with
>>>>> some limitations in regard to cseq incrementation. You have to set a
>>>>> failure route and if the reply code is 407, the sent the
>>>>> realm/username
>>>>> and password to the avps specified by the appropriate module
>>>>> parameters
>>>>> -- the next tree at:
>>>>>
>>>>> *
>>>>> http://kamailio.org/docs/modules/stable/modules_k/uac.html#auth-realm-avp-id
>>>>>
>>>>> Then call uac_auth() and relay again.
>>>> You mean, i need set auth_*_avp with credentials. set failure route,
>>>> send
>>>> request to auth_proxy (btw, how? ) and call uac_auth() in failure
>>>> route,
>>>> correct?
>>> t_relay() is one of the functions to sent the request further.
>> I mean how set next hop not to final destination, but to auth_proxy?
>>
>>>> I've tried to use uacreg sql table and uac_reg_request_to, but there
>>>> was
>>>> some problems:
>>>> 1) in uac_reg_request_to with mode 1 mistake (it found credentials
>>>> only
>>>> if
>>>> l_uuid==l_username)
>>>> i've opened ticket on bugtracker
>>>> http://sourceforge.net/tracker/?func=detail&aid=3540479&group_id=139143&atid=743020
>>>> 2) uac_reg_request_to changes uri in request and instead INVITE
>>>> sip:B at othersip.com makes INVITE sip:AA at hisserver.com
>>>> if comment out
>>>> snprintf(ruri, MAX_URI_SIZE, "sip:%.*s@%.*s",
>>>> reg->r_username.len, reg->r_username.s,
>>>> reg->r_domain.len, reg->r_domain.s);
>>>> and so on seems working, but I'm don't sure that such modification
>>>> don't
>>>> break something else
>>>> (pretty sure that breaks, but don't know where exactly :)
>>>> 3)uacreg table loaded on startup, and AFAIK there is no way to modify
>>>> it
>>>> dynamically,
>>>> so if you change something in this table you MUST restart kamailio
>>>> (not
>>>> convinient)
>>>> I've tried to make RPC for adding new record in htable (using
>>>> reg_ht_add()), but it returns error and in log I can see
>>>> ERROR: uac [uac_reg.c:313]: no more shm
>>> If you have a lot of records, you need to allocate more shared memory,
>>> via -m command line parameter.
>> 19 records in table -OK
>> 1 record in table and try to add using RPC (self modified uac_reg.c) -
>> no
>> more shm.
> can you set debug=3 in you config file, try again and send all log
> messages of the operation here?
>
debug=4
kamctl sercmd uac.reg_add 1 2 3 4 5 6 7 8 sip:85.132.76.182:36999 100
database engine 'DB_BERKELEY' loaded
Control engine 'FIFO' loaded
entering ser_cmd uac.reg_add 1 2 3 4 5 6 7 8 sip:85.132.76.182:36999 100
error: 500 - Error adding reg to htable
in log:
Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: DEBUG: ctl
[../../io_wait.h:390]: DBG: io_watch_add(0x7fc0e9310680, 15, 3,
0x2066670), fd_no=1
Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: DEBUG: ctl
[io_listener.c:453]: handle_stream read: new connection (1) on
/tmp/kamailio_ctl
Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: ERROR: uac
[uac_reg.c:313]: no more shm
Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: DEBUG: ctl
[io_listener.c:506]: handle_stream read: eof on /tmp/kamailio_ctl
Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: DEBUG: ctl
[../../io_wait.h:617]: DBG: io_watch_del (0x7fc0e9310680, 15, -1, 0x10)
fd_no=2 called
uac_reg.c is modified, so line 313 in it is not exist in distribution
sources.
there is
nr = (reg_uac_t*)shm_malloc(sizeof(reg_uac_t) + len);
if(nr==NULL)
{
LM_ERR("no more shm\n");// 313 is here!
return -1;
}
the full source of function in previous message.
> Cheers,
> DAniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
--
From intel at intrans.baku.az Tue Jul 10 12:55:25 2012
From: intel at intrans.baku.az (intel at intrans.baku.az)
Date: Tue, 10 Jul 2012 15:55:25 +0500 (AZST)
Subject: [SR-Users] =?utf-8?b?IFJlOsKgwqBIb3fCoHRvwqBwcm94eS9hdXRoZW50aWNh?=
=?utf-8?b?dGXCoG9uwqB0aGlyZC4uLg==?=
In-Reply-To: <43032.85.132.76.4.1341917250.squirrel@mail.az>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
<24241.85.132.76.4.1341597541.squirrel@mail.az>
<4FFB08B4.8070805@gmail.com>
<28622.85.132.76.4.1341913845.squirrel@mail.az>
<4FFBF954.50104@gmail.com>
<35224.85.132.76.4.1341915283.squirrel@mail.az>
<4FFC0113.8090400@gmail.com>
<43032.85.132.76.4.1341917250.squirrel@mail.az>
Message-ID: <45558.85.132.76.4.1341917725.squirrel@mail.az>
intel at intrans.baku.az said:
>
> Daniel-Constantin Mierla said:
>>
>> On 7/10/12 12:14 PM, intel at intrans.baku.az wrote:
>>> Daniel-Constantin Mierla said:
>>>> On 7/10/12 11:50 AM, intel at intrans.baku.az wrote:
>>>>> Daniel-Constantin Mierla said:
>>>>>> Hello,
>>>>>>
>>>>>> On 7/6/12 7:59 PM, intel at intrans.baku.az wrote:
>>>>>>> Can anybody help me with configuration kamailio to authenticate
>>>>>>> call
>>>>>>> on
>>>>>>> 3rd party server?
>>>>>>>
>>>>>>> I want to authenticate(and proxy) call's on other server.
>>>>>>>
>>>>>>> for example, user A have account on my server(let it be
>>>>>>> A at myserver.com)
>>>>>>> and account on other server (let it be AA at hisserver.com)
>>>>>>> myserver.com keeps A's credentials for AA at hisserver.com
>>>>>>> when A is registered on myserver.com, he make call to
>>>>>>> B at othersip.com
>>>>>>> (using myserver.com as a proxy)
>>>>>>> Kamailio on myserver authenticate itself on hisserver as
>>>>>>> AA at hisserver.com,
>>>>>>> makes call to destination, and connect it to A.
>>>>>>>
>>>>>>> How can I setup kamailio for such behavior?
>>>>>>> Which module should I use?
>>>>>>> UAC seems can authenticate on another server, but I don't sure that
>>>>>>> it
>>>>>>> do
>>>>>>> what I want. (I've tried it, but without much success)
>>>>>> indeed, the uac module is the one that can provide what you want,
>>>>>> with
>>>>>> some limitations in regard to cseq incrementation. You have to set a
>>>>>> failure route and if the reply code is 407, the sent the
>>>>>> realm/username
>>>>>> and password to the avps specified by the appropriate module
>>>>>> parameters
>>>>>> -- the next tree at:
>>>>>>
>>>>>> *
>>>>>> http://kamailio.org/docs/modules/stable/modules_k/uac.html#auth-realm-avp-id
>>>>>>
>>>>>> Then call uac_auth() and relay again.
>>>>> You mean, i need set auth_*_avp with credentials. set failure route,
>>>>> send
>>>>> request to auth_proxy (btw, how? ) and call uac_auth() in failure
>>>>> route,
>>>>> correct?
>>>> t_relay() is one of the functions to sent the request further.
>>> I mean how set next hop not to final destination, but to auth_proxy?
>>>
>>>>> I've tried to use uacreg sql table and uac_reg_request_to, but there
>>>>> was
>>>>> some problems:
>>>>> 1) in uac_reg_request_to with mode 1 mistake (it found credentials
>>>>> only
>>>>> if
>>>>> l_uuid==l_username)
>>>>> i've opened ticket on bugtracker
>>>>> http://sourceforge.net/tracker/?func=detail&aid=3540479&group_id=139143&atid=743020
>>>>> 2) uac_reg_request_to changes uri in request and instead INVITE
>>>>> sip:B at othersip.com makes INVITE sip:AA at hisserver.com
>>>>> if comment out
>>>>> snprintf(ruri, MAX_URI_SIZE, "sip:%.*s@%.*s",
>>>>> reg->r_username.len, reg->r_username.s,
>>>>> reg->r_domain.len, reg->r_domain.s);
>>>>> and so on seems working, but I'm don't sure that such modification
>>>>> don't
>>>>> break something else
>>>>> (pretty sure that breaks, but don't know where exactly :)
>>>>> 3)uacreg table loaded on startup, and AFAIK there is no way to modify
>>>>> it
>>>>> dynamically,
>>>>> so if you change something in this table you MUST restart kamailio
>>>>> (not
>>>>> convinient)
>>>>> I've tried to make RPC for adding new record in htable (using
>>>>> reg_ht_add()), but it returns error and in log I can see
>>>>> ERROR: uac [uac_reg.c:313]: no more shm
>>>> If you have a lot of records, you need to allocate more shared memory,
>>>> via -m command line parameter.
>>> 19 records in table -OK
>>> 1 record in table and try to add using RPC (self modified uac_reg.c) -
>>> no
>>> more shm.
>> can you set debug=3 in you config file, try again and send all log
>> messages of the operation here?
>>
>
> debug=4
>
> kamctl sercmd uac.reg_add 1 2 3 4 5 6 7 8 sip:85.132.76.182:36999 100
> database engine 'DB_BERKELEY' loaded
> Control engine 'FIFO' loaded
> entering ser_cmd uac.reg_add 1 2 3 4 5 6 7 8 sip:85.132.76.182:36999 100
> error: 500 - Error adding reg to htable
>
> in log:
>
> Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: DEBUG: ctl
> [../../io_wait.h:390]: DBG: io_watch_add(0x7fc0e9310680, 15, 3,
> 0x2066670), fd_no=1
> Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: DEBUG: ctl
> [io_listener.c:453]: handle_stream read: new connection (1) on
> /tmp/kamailio_ctl
> Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: ERROR: uac
> [uac_reg.c:313]: no more shm
> Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: DEBUG: ctl
> [io_listener.c:506]: handle_stream read: eof on /tmp/kamailio_ctl
> Jul 10 15:29:07 dsdb01 /usr/sbin/kamailio[526]: DEBUG: ctl
> [../../io_wait.h:617]: DBG: io_watch_del (0x7fc0e9310680, 15, -1, 0x10)
> fd_no=2 called
>
> uac_reg.c is modified, so line 313 in it is not exist in distribution
> sources.
> there is
>
> nr = (reg_uac_t*)shm_malloc(sizeof(reg_uac_t) + len);
> if(nr==NULL)
> {
> LM_ERR("no more shm\n");// 313 is here!
> return -1;
> }
>
> the full source of function in previous message.
Sorry, i've mistaken.
this is part of standard function reg_ht_add(), not my addition
BTW, I also wrote RPCS uac.reg_dump_byuuid and uac.reg_dump_byuser to get
just one record from hash table, to where should I send patches for
including this fuctionality in mainstream?
>
>
>> Cheers,
>> DAniel
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
>> http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
>> http://asipto.com/u/kpw
>>
>>
>
>
> --
>
>
--
From aftnix at gmail.com Tue Jul 10 12:44:08 2012
From: aftnix at gmail.com (Aft nix)
Date: Tue, 10 Jul 2012 16:44:08 +0600
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <4FFB05A5.6030607@gmail.com>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFAD6E6.4030503@pernau.at> <4FFB05A5.6030607@gmail.com>
Message-ID: <CAGuaRCuYLyNJtp-qkRDdACF5g7mQsVRo7BoYKTz4vYAXxir-ug@mail.gmail.com>
On Mon, Jul 9, 2012 at 10:24 PM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Hello,
>
> also, can you provide more details about the case? Is it with the very first
> connection or you do some load testing and at some point you get this issue?
>
No, its not a part of load testing. it happens on the first connection.
> Can you reproduce it always?
Yes i can reproduce it.
>Do you set different number of workers per
> socket? What is the output of 'kamctl ps'?
No. both are 4. (udp and tls )
I have downgraded the lab machine to do some testing. so i can't give
kamctl ps of the faulty
installation at this moment. kamailio-3.2.x is deployed in our
production servers, and it worked flawlessly.
this is the output of kamctl ps from a 3.2.x. it uses the same config
file as i was using with git master branch.
[root at server kamailio-3.2.3]# kamctl ps
Process:: ID=0 PID=31109 Type=attendant
Process:: ID=1 PID=31110 Type=udp receiver child=0 sock=<IP>:<PORT>
Process:: ID=2 PID=31111 Type=udp receiver child=1 sock=<IP>:<PORT>
Process:: ID=3 PID=31112 Type=udp receiver child=2 sock=<IP>:<PORT>
Process:: ID=4 PID=31113 Type=udp receiver child=3 sock=<IP>:<PORT>
Process:: ID=5 PID=31114 Type=slow timer
Process:: ID=6 PID=31115 Type=timer
Process:: ID=7 PID=31116 Type=MI FIFO
Process:: ID=8 PID=31117 Type=ctl handler
Process:: ID=9 PID=31118 Type=TIMER NH
Process:: ID=10 PID=31119 Type=tcp receiver child=0
Process:: ID=11 PID=31120 Type=tcp receiver child=1
Process:: ID=12 PID=31121 Type=tcp receiver child=2
Process:: ID=13 PID=31122 Type=tcp receiver child=3
Process:: ID=14 PID=31123 Type=tcp main process
>
> Have you tried with 3.3 branch as well or just master branch?
>
I've got this in master branch. haven't tried it with 3.3 branch.
On the side note similar issue was reported by a guy earlier this year
in this list which went
unnoticed. here is the link to that mail :
http://lists.sip-router.org/pipermail/sr-users/2012-April/072683.html
His issue seems similar to me.
Cheers
> Cheers,
> Daniel
>
>
> On 7/9/12 3:04 PM, Klaus Darilion wrote:
>>
>> Use wireshark to analyze the TLS handshake
>>
>> regards
>> klaus
>>
>> On 09.07.2012 13:27, Aft nix wrote:
>>>
>>> Hi,
>>>
>>> I have enabled tls parameters as follows:
>>>
>>> in kamailio.cfg
>>>
>>> listen = tls:<IP>:<PORT>
>>>
>>> in tls.cfg
>>>
>>> [server:<IP>:<PORT>]
>>> method = TLSv1
>>> verify_certificate = no
>>> require_certificate = no
>>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>>> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>>>
>>> Now if i try to connect to this interface using openssl s_client, it
>>> does connects,
>>> but now server certificate is sent from kamailio.
>>>
>>> kamailio log shows this :
>>>
>>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
>>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
>>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
>>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
>>> 0xb5701580), fd_no=11
>>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
>>> fd_no=12 called
>>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
>>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
>>> connection passed to the least busy one (3289651)
>>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
>>> [tls:<IP>:<PORT>], 0xb5701580
>>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid
>>> 2491)
>>>
>>> I'm using kamailio from git. its updated to the latest.
>>> Thanks in advance.
>>>
>>
>>
>> _______________________________________________
>> 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
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
--
-aft
From abalashov at evaristesys.com Tue Jul 10 13:19:24 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 10 Jul 2012 07:19:24 -0400
Subject: [SR-Users] usrloc concurrency
In-Reply-To: <4FFC0240.7090400@gmail.com>
References: <45sx10tiip6kyi4hc2db8c7n.1341834774856@email.android.com>
<4FFC0240.7090400@gmail.com>
Message-ID: <4FFC0FBC.40309@evaristesys.com>
On 07/10/2012 06:21 AM, Daniel-Constantin Mierla wrote:
> I asked also on devel list, but no follow up there, so here again for
> the sake of going on with the conversation on this forum:
>
> Is this like blocking or just not writing to db, but in memory
> everything is ok? iirc, all db failed operations should be reported as
> error to syslog, do you get any?
Sorry Daniel, I must have missed your reply on the devel list! My
apologies.
To answer your questions:
1) Yes, this is just not writing to the DB; there is no evidence of
blocking, nor evidence of database impact outside of usrloc. All other
DB-backed modules write fine.
2) Yes, the contact bindings are stored in memory, so everything
"works". However, certain internal needs rely on being able to see the
bindings in the DB.
3) No DB or other complaints from Kamailio internally in syslog.
The next logical step would be to turn up debug logs, but the problem is
that this issue is extremely difficult to consistently reproduce, which
makes me think there is some sort of exotic race condition afoot.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From intel at intrans.baku.az Tue Jul 10 14:09:16 2012
From: intel at intrans.baku.az (intel at intrans.baku.az)
Date: Tue, 10 Jul 2012 17:09:16 +0500 (AZST)
Subject:
=?utf-8?Q?Re:=C2=A0=C2=A0[SR-Users]=C2=A0How=C2=A0to=C2=A0proxy/authentic?=
Re:  [SR-Users] How to proxy/authenticate on thiRe:  [SR-User
s] How to proxy/a
=?utf-8?Q?Re:  [SR-Users] How to proxy/authenticRe:=C2=A0=C2=A0[SR-U?=
sers] How to proxy/authenticate on thiRe:  [SR-Users] HowÂ
=?utf-8?Q?Re:  [SR-Users] How to proxy/authenticRe:  [SR-Users]?=
=?utf-8?Q?=C2=A0How=C2=A0to=C2=A0proxy/authenticate=C2=A0on=C2=A0thiRe:?=
=?utf-8?Q?=C2=A0=C2=A0[SR-Users]=C2=A0How=C2=A0to=C2=A0proxy/authenticate?=
=?utf-8?Q?=C2=A0on=C2=A0third=C2=A0party=C2=A0sip=C2=A0server=3F?=
In-Reply-To: <35224.85.132.76.4.1341915283.squirrel@mail.az>
References: <mailman.870.1341495993.2421.sr-users@lists.sip-router.org>
<24241.85.132.76.4.1341597541.squirrel@mail.az>
<4FFB08B4.8070805@gmail.com>
<28622.85.132.76.4.1341913845.squirrel@mail.az>
<4FFBF954.50104@gmail.com>
<35224.85.132.76.4.1341915283.squirrel@mail.az>
Message-ID: <15850.85.132.76.4.1341922156.squirrel@mail.az>
intel at intrans.baku.az said:
>
> Daniel-Constantin Mierla said:
>>
>> On 7/10/12 11:50 AM, intel at intrans.baku.az wrote:
>>> Daniel-Constantin Mierla said:
>>>> Hello,
>>>>
>>>> On 7/6/12 7:59 PM, intel at intrans.baku.az wrote:
>>>>> Can anybody help me with configuration kamailio to authenticate call
>>>>> on
>>>>> 3rd party server?
>>>>>
>>>>> I want to authenticate(and proxy) call's on other server.
>>>>>
>>>>> for example, user A have account on my server(let it be
>>>>> A at myserver.com)
>>>>> and account on other server (let it be AA at hisserver.com)
>>>>> myserver.com keeps A's credentials for AA at hisserver.com
>>>>> when A is registered on myserver.com, he make call to B at othersip.com
>>>>> (using myserver.com as a proxy)
>>>>> Kamailio on myserver authenticate itself on hisserver as
>>>>> AA at hisserver.com,
>>>>> makes call to destination, and connect it to A.
>>>>>
>>>>> How can I setup kamailio for such behavior?
>>>>> Which module should I use?
>>>>> UAC seems can authenticate on another server, but I don't sure that
>>>>> it
>>>>> do
>>>>> what I want. (I've tried it, but without much success)
>>>> indeed, the uac module is the one that can provide what you want, with
>>>> some limitations in regard to cseq incrementation. You have to set a
>>>> failure route and if the reply code is 407, the sent the
>>>> realm/username
>>>> and password to the avps specified by the appropriate module
>>>> parameters
>>>> -- the next tree at:
>>>>
>>>> *
>>>> http://kamailio.org/docs/modules/stable/modules_k/uac.html#auth-realm-avp-id
>>>>
>>>> Then call uac_auth() and relay again.
>>> You mean, i need set auth_*_avp with credentials. set failure route,
>>> send
>>> request to auth_proxy (btw, how? ) and call uac_auth() in failure
>>> route,
>>> correct?
>> t_relay() is one of the functions to sent the request further.
>
> I mean how set next hop not to final destination, but to auth_proxy?
rewritehostport("hisserver.com:port"); in config enough or need additional
modifications of request?
--
From jianjun365222 at gmail.com Wed Jul 11 04:23:04 2012
From: jianjun365222 at gmail.com (mike)
Date: Wed, 11 Jul 2012 10:23:04 +0800
Subject: [SR-Users] is kamilio support RFC5626 now ?
Message-ID: <CAOfBJcwJR306vLRWUnacWCC9Y73Db4uy4p=61hcmsprZ5myEjw@mail.gmail.com>
dear kamilio developers :
i read the kamilio 3.3.0' s new features , it say it support
outbound , and i have place to handle reg-id and sip.instance . so , i
wonder if the kamilio3.3.0 support RFC5626 now?so that the
kamilio can be used as a edge proxy . i ask why because i can't find where
kamilio add flow-token and path for the register request.
thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120711/9fdc4f12/attachment.htm>
From miconda at gmail.com Wed Jul 11 08:58:57 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 11 Jul 2012 08:58:57 +0200
Subject: [SR-Users] usrloc concurrency
In-Reply-To: <4FFC0FBC.40309@evaristesys.com>
References: <45sx10tiip6kyi4hc2db8c7n.1341834774856@email.android.com>
<4FFC0240.7090400@gmail.com> <4FFC0FBC.40309@evaristesys.com>
Message-ID: <4FFD2431.2000505@gmail.com>
Hello,
On 7/10/12 1:19 PM, Alex Balashov wrote:
> On 07/10/2012 06:21 AM, Daniel-Constantin Mierla wrote:
>
>> I asked also on devel list, but no follow up there, so here again for
>> the sake of going on with the conversation on this forum:
>>
>> Is this like blocking or just not writing to db, but in memory
>> everything is ok? iirc, all db failed operations should be reported as
>> error to syslog, do you get any?
>
> Sorry Daniel, I must have missed your reply on the devel list! My
> apologies.
>
> To answer your questions:
>
> 1) Yes, this is just not writing to the DB; there is no evidence of
> blocking, nor evidence of database impact outside of usrloc. All other
> DB-backed modules write fine.
>
> 2) Yes, the contact bindings are stored in memory, so everything
> "works". However, certain internal needs rely on being able to see
> the bindings in the DB.
>
> 3) No DB or other complaints from Kamailio internally in syslog.
>
> The next logical step would be to turn up debug logs, but the problem
> is that this issue is extremely difficult to consistently reproduce,
> which makes me think there is some sort of exotic race condition afoot.
is it sporadically, only for few records, or once it started is for all
records? Do you have small max registration interval?
Anything particular in database server logs?
You can eventually enable logging of sql queries in the database server
and see if they get to the server or not. Alternative is to capture the
traffic to the database if it is over the net.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Wed Jul 11 09:00:55 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 11 Jul 2012 09:00:55 +0200
Subject: [SR-Users] is kamilio support RFC5626 now ?
In-Reply-To: <CAOfBJcwJR306vLRWUnacWCC9Y73Db4uy4p=61hcmsprZ5myEjw@mail.gmail.com>
References: <CAOfBJcwJR306vLRWUnacWCC9Y73Db4uy4p=61hcmsprZ5myEjw@mail.gmail.com>
Message-ID: <4FFD24A7.1050609@gmail.com>
Hello,
On 7/11/12 4:23 AM, mike wrote:
> dear kamilio developers :
>
> i read the kamilio 3.3.0' s new features , it say it support outbound
> , and i have place to handle reg-id and sip.instance . so , i wonder
> if the kamilio3.3.0 support RFC5626 now?so that the
> kamilio can be used as a edge proxy . i ask why because i can't find
> where kamilio add flow-token and path for the register request.
sip.instance and reg-id are handled by the registrar/usrloc modules.
Path has to be added by intermediary proxies and it is also handled by
registrar module. If the intermediary proxies are kamailio, then adding
path is possible via path module.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From michal.yachimovitz at gmail.com Wed Jul 11 09:25:33 2012
From: michal.yachimovitz at gmail.com (Michal Yachimovitz)
Date: Wed, 11 Jul 2012 10:25:33 +0300
Subject: [SR-Users] start kamailio
Message-ID: <CAJNAYwtKhikMEFYbXjKPee6C0EYPNm8oa2K75Rt+uayOSLUW9A@mail.gmail.com>
Hello
I installed kamailio version 3.2.0 and followed the instructions in
http://www.kamailio.org/wiki/install/3.2.x/git web site
Whene I permormed the command /etc/init.d/kamailio start I got the
following errors.
The modules are in the correct directory so actually I do not understand
the error.
I will be happy if someone can help me solve this issue:
[root at kamailio-dev-lab ~]# */etc/init.d/kamailio start
*
Not starting Kamailio: invalid configuration file!
0(8569) ERROR: <core> [sr_module.c:565]: ERROR: load_module: could not
open module </usr/local/lib/kamailio/modules/db_mysql.so>:
/usr/local/lib/kamailio/modules/db_mysql.so: undefined symbol: SSL_CTX_free
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 214, column 12-24: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <mi_fifo> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 217, column 12-23: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <kex> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 218, column 12-19: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <tmx> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 220, column 12-19: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <rr> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 222, column 12-18: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <pv> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 223, column 12-18: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <maxfwd> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 224, column 12-22: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <usrloc> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 225, column 12-22: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <registrar> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 226, column 12-25: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <textops> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 227, column 12-23: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <siputils> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 228, column 12-24: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <xlog> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 229, column 12-20: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <acc> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 234, column 12-19: failed to
load module
0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
find module <auth_db> in </usr/local/lib/kamailio/modules>
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 238, column 12-23: failed to
load module
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <mi_fifo> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 287, column 54: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <rr> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 301, column 35: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <rr> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 303, column 35: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <registrar> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 307, column 44: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <registrar> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 313, column 42: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <acc> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 318, column 33: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <acc> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 319, column 32: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <acc> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 320, column 36: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <acc> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 324, column 38: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <acc> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 326, column 30: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <acc> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 327, column 37: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <acc> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 330, column 45: Can't set module
parameter
0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
matching <acc> found
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 331, column 45: Can't set module
parameter
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 346, column 30-34: syntax error
0(8569) : <core> [cfg.y:3529]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 346, column 30-34: Invalid
arguments
0(8569) : <core> [cfg.y:3532]: parse error in config file
/usr/local/etc/kamailio/kamailio.cfg, line 346, column 35:
ERROR: bad config file (30 errors)
[root at kamailio-dev-lab ~]#
Thanks in advance
Michal Yachimovitz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120711/a840140c/attachment.htm>
From oej at edvina.net Wed Jul 11 09:28:12 2012
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 11 Jul 2012 09:28:12 +0200
Subject: [SR-Users] is kamilio support RFC5626 now ?
In-Reply-To: <4FFD24A7.1050609@gmail.com>
References: <CAOfBJcwJR306vLRWUnacWCC9Y73Db4uy4p=61hcmsprZ5myEjw@mail.gmail.com>
<4FFD24A7.1050609@gmail.com>
Message-ID: <9669C420-DD07-4B34-A8DE-641058A2C15D@edvina.net>
11 jul 2012 kl. 09:00 skrev Daniel-Constantin Mierla:
> Hello,
>
> On 7/11/12 4:23 AM, mike wrote:
>> dear kamilio developers :
>>
>> i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now?so that the
>> kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request.
> sip.instance and reg-id are handled by the registrar/usrloc modules. Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module.
How do you recognize the flows and switch between them in case of failure?
/O
From govoiper at gmail.com Wed Jul 11 09:43:29 2012
From: govoiper at gmail.com (SamyGo)
Date: Wed, 11 Jul 2012 12:43:29 +0500
Subject: [SR-Users] start kamailio
In-Reply-To: <CAJNAYwtKhikMEFYbXjKPee6C0EYPNm8oa2K75Rt+uayOSLUW9A@mail.gmail.com>
References: <CAJNAYwtKhikMEFYbXjKPee6C0EYPNm8oa2K75Rt+uayOSLUW9A@mail.gmail.com>
Message-ID: <CAJUJwti-aw2hGRR6EDVjDg+8YtY44jZpsokA+6HvYjCuJb=61w@mail.gmail.com>
Hi,
Verify your "mpath=" directive in kamailio.cfg file.
Its just unable to find the directory holding all the modules.
If you're using a 64bit machine then I can only guess that you need to
change mpath to "mpath= /usr/local/lib*64*/kamailio/modules/ "
Regards,
Sammy
On Wed, Jul 11, 2012 at 12:25 PM, Michal Yachimovitz <
michal.yachimovitz at gmail.com> wrote:
> Hello
>
> I installed kamailio version 3.2.0 and followed the instructions in
> http://www.kamailio.org/wiki/install/3.2.x/git web site
>
> Whene I permormed the command /etc/init.d/kamailio start I got the
> following errors.
>
> The modules are in the correct directory so actually I do not understand
> the error.
>
> I will be happy if someone can help me solve this issue:
>
>
>
> [root at kamailio-dev-lab ~]# */etc/init.d/kamailio start
> *
> Not starting Kamailio: invalid configuration file!
>
> 0(8569) ERROR: <core> [sr_module.c:565]: ERROR: load_module: could not
> open module </usr/local/lib/kamailio/modules/db_mysql.so>:
> /usr/local/lib/kamailio/modules/db_mysql.so: undefined symbol: SSL_CTX_free
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 214, column 12-24: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <mi_fifo> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 217, column 12-23: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <kex> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 218, column 12-19: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <tmx> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 220, column 12-19: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <rr> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 222, column 12-18: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <pv> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 223, column 12-18: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <maxfwd> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 224, column 12-22: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <usrloc> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 225, column 12-22: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <registrar> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 226, column 12-25: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <textops> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 227, column 12-23: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <siputils> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 228, column 12-24: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <xlog> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 229, column 12-20: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <acc> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 234, column 12-19: failed to
> load module
> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
> find module <auth_db> in </usr/local/lib/kamailio/modules>
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 238, column 12-23: failed to
> load module
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <mi_fifo> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 287, column 54: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <rr> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 301, column 35: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <rr> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 303, column 35: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <registrar> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 307, column 44: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <registrar> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 313, column 42: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <acc> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 318, column 33: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <acc> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 319, column 32: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <acc> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 320, column 36: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <acc> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 324, column 38: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <acc> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 326, column 30: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <acc> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 327, column 37: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <acc> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 330, column 45: Can't set module
> parameter
> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
> matching <acc> found
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 331, column 45: Can't set module
> parameter
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 30-34: syntax error
> 0(8569) : <core> [cfg.y:3529]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 30-34: Invalid
> arguments
> 0(8569) : <core> [cfg.y:3532]: parse error in config file
> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 35:
> ERROR: bad config file (30 errors)
> [root at kamailio-dev-lab ~]#
>
>
> Thanks in advance
>
> Michal Yachimovitz
>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120711/163281ec/attachment-0001.htm>
From michal.yachimovitz at gmail.com Wed Jul 11 10:02:36 2012
From: michal.yachimovitz at gmail.com (Michal Yachimovitz)
Date: Wed, 11 Jul 2012 11:02:36 +0300
Subject: [SR-Users] start kamailio
In-Reply-To: <CAJUJwti-aw2hGRR6EDVjDg+8YtY44jZpsokA+6HvYjCuJb=61w@mail.gmail.com>
References: <CAJNAYwtKhikMEFYbXjKPee6C0EYPNm8oa2K75Rt+uayOSLUW9A@mail.gmail.com>
<CAJUJwti-aw2hGRR6EDVjDg+8YtY44jZpsokA+6HvYjCuJb=61w@mail.gmail.com>
Message-ID: <CAJNAYwuJH-7c66ru5zOLJizU3vbo_o0hBNKmyBy8CkpZ6iQ1Kg@mail.gmail.com>
Hi
Thanks, but the mpath is correct
If you have another idea it will be appreciated.
Michal
2012/7/11 SamyGo <govoiper at gmail.com>
> Hi,
>
> Verify your "mpath=" directive in kamailio.cfg file.
> Its just unable to find the directory holding all the modules.
> If you're using a 64bit machine then I can only guess that you need to
> change mpath to "mpath= /usr/local/lib*64*/kamailio/modules/ "
>
> Regards,
> Sammy
>
>
> On Wed, Jul 11, 2012 at 12:25 PM, Michal Yachimovitz <
> michal.yachimovitz at gmail.com> wrote:
>
>> Hello
>>
>> I installed kamailio version 3.2.0 and followed the instructions in
>> http://www.kamailio.org/wiki/install/3.2.x/git web site
>>
>> Whene I permormed the command /etc/init.d/kamailio start I got the
>> following errors.
>>
>> The modules are in the correct directory so actually I do not understand
>> the error.
>>
>> I will be happy if someone can help me solve this issue:
>>
>>
>>
>> [root at kamailio-dev-lab ~]# */etc/init.d/kamailio start
>> *
>> Not starting Kamailio: invalid configuration file!
>>
>> 0(8569) ERROR: <core> [sr_module.c:565]: ERROR: load_module: could not
>> open module </usr/local/lib/kamailio/modules/db_mysql.so>:
>> /usr/local/lib/kamailio/modules/db_mysql.so: undefined symbol: SSL_CTX_free
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 214, column 12-24: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <mi_fifo> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 217, column 12-23: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <kex> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 218, column 12-19: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <tmx> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 220, column 12-19: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <rr> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 222, column 12-18: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <pv> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 223, column 12-18: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <maxfwd> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 224, column 12-22: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <usrloc> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 225, column 12-22: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <registrar> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 226, column 12-25: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <textops> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 227, column 12-23: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <siputils> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 228, column 12-24: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <xlog> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 229, column 12-20: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <acc> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 234, column 12-19: failed to
>> load module
>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>> find module <auth_db> in </usr/local/lib/kamailio/modules>
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 238, column 12-23: failed to
>> load module
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <mi_fifo> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 287, column 54: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <rr> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 301, column 35: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <rr> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 303, column 35: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <registrar> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 307, column 44: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <registrar> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 313, column 42: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <acc> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 318, column 33: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <acc> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 319, column 32: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <acc> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 320, column 36: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <acc> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 324, column 38: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <acc> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 326, column 30: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <acc> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 327, column 37: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <acc> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 330, column 45: Can't set module
>> parameter
>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>> matching <acc> found
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 331, column 45: Can't set module
>> parameter
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 30-34: syntax error
>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 30-34: Invalid
>> arguments
>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 35:
>> ERROR: bad config file (30 errors)
>> [root at kamailio-dev-lab ~]#
>>
>>
>> Thanks in advance
>>
>> Michal Yachimovitz
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120711/231d05a6/attachment.htm>
From miconda at gmail.com Wed Jul 11 10:03:47 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 11 Jul 2012 10:03:47 +0200
Subject: [SR-Users] is kamilio support RFC5626 now ?
In-Reply-To: <CAOfBJcyznmmbq0y8gdhi7QQFxChdCd=LbbyLFGmSkxphJqQV9Q@mail.gmail.com>
References: <CAOfBJcwJR306vLRWUnacWCC9Y73Db4uy4p=61hcmsprZ5myEjw@mail.gmail.com>
<4FFD24A7.1050609@gmail.com>
<CAOfBJcyznmmbq0y8gdhi7QQFxChdCd=LbbyLFGmSkxphJqQV9Q@mail.gmail.com>
Message-ID: <4FFD3363.2020505@gmail.com>
FYI: private emails sent from mailing lists discussions are simply
ignored, keep the mailing list in the discussion. Thanks.
On 7/11/12 9:13 AM, mike wrote:
> yes , i know that the path could be added by the path module , but
> ,the problem is the flow token,such as the path
>
> Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib at ep1.example.com
> <mailto:S8p4WPbOnHbuyh5iJvJIW3ib at ep1.example.com>;lr;ob>
>
>
> the VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib is the token , so , where the
> kamilio 3.3 handle it ?
>
>
> On Wed, Jul 11, 2012 at 3:00 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
> Hello,
>
>
> On 7/11/12 4:23 AM, mike wrote:
>
> dear kamilio developers :
>
> i read the kamilio 3.3.0' s new features , it say it support
> outbound , and i have place to handle reg-id and sip.instance
> . so , i wonder if the kamilio3.3.0 support RFC5626 now?so
> that the
> kamilio can be used as a edge proxy . i ask why because i
> can't find where kamilio add flow-token and path for the
> register request.
>
> sip.instance and reg-id are handled by the registrar/usrloc
> modules. Path has to be added by intermediary proxies and it is
> also handled by registrar module. If the intermediary proxies are
> kamailio, then adding path is possible via path module.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
> http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120711/661d785b/attachment-0001.htm>
From govoiper at gmail.com Wed Jul 11 10:13:49 2012
From: govoiper at gmail.com (SamyGo)
Date: Wed, 11 Jul 2012 13:13:49 +0500
Subject: [SR-Users] start kamailio
In-Reply-To: <CAJNAYwuJH-7c66ru5zOLJizU3vbo_o0hBNKmyBy8CkpZ6iQ1Kg@mail.gmail.com>
References: <CAJNAYwtKhikMEFYbXjKPee6C0EYPNm8oa2K75Rt+uayOSLUW9A@mail.gmail.com>
<CAJUJwti-aw2hGRR6EDVjDg+8YtY44jZpsokA+6HvYjCuJb=61w@mail.gmail.com>
<CAJNAYwuJH-7c66ru5zOLJizU3vbo_o0hBNKmyBy8CkpZ6iQ1Kg@mail.gmail.com>
Message-ID: <CAJUJwtjkhkbBjrAokctgTeK_7D7O7qN5jMtxa3ydfes7wUSmJw@mail.gmail.com>
there is also another directory as modules_k which needs to be included in
mpath see that as well.
Is the error log same (OO) !! It clearly is screaming for help
trying desperately to find the modules ! Did you forgot to compile the
modules !
On Wed, Jul 11, 2012 at 1:02 PM, Michal Yachimovitz <
michal.yachimovitz at gmail.com> wrote:
> Hi
> Thanks, but the mpath is correct
> If you have another idea it will be appreciated.
>
> Michal
>
> 2012/7/11 SamyGo <govoiper at gmail.com>
>
>> Hi,
>>
>> Verify your "mpath=" directive in kamailio.cfg file.
>> Its just unable to find the directory holding all the modules.
>> If you're using a 64bit machine then I can only guess that you need to
>> change mpath to "mpath= /usr/local/lib*64*/kamailio/modules/ "
>>
>> Regards,
>> Sammy
>>
>>
>> On Wed, Jul 11, 2012 at 12:25 PM, Michal Yachimovitz <
>> michal.yachimovitz at gmail.com> wrote:
>>
>>> Hello
>>>
>>> I installed kamailio version 3.2.0 and followed the instructions in
>>> http://www.kamailio.org/wiki/install/3.2.x/git web site
>>>
>>> Whene I permormed the command /etc/init.d/kamailio start I got the
>>> following errors.
>>>
>>> The modules are in the correct directory so actually I do not understand
>>> the error.
>>>
>>> I will be happy if someone can help me solve this issue:
>>>
>>>
>>>
>>> [root at kamailio-dev-lab ~]# */etc/init.d/kamailio start
>>> *
>>> Not starting Kamailio: invalid configuration file!
>>>
>>> 0(8569) ERROR: <core> [sr_module.c:565]: ERROR: load_module: could not
>>> open module </usr/local/lib/kamailio/modules/db_mysql.so>:
>>> /usr/local/lib/kamailio/modules/db_mysql.so: undefined symbol: SSL_CTX_free
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 214, column 12-24: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <mi_fifo> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 217, column 12-23: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <kex> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 218, column 12-19: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <tmx> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 220, column 12-19: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <rr> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 222, column 12-18: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <pv> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 223, column 12-18: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <maxfwd> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 224, column 12-22: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <usrloc> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 225, column 12-22: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <registrar> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 226, column 12-25: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <textops> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 227, column 12-23: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <siputils> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 228, column 12-24: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <xlog> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 229, column 12-20: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <acc> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 234, column 12-19: failed to
>>> load module
>>> 0(8569) ERROR: <core> [sr_module.c:553]: ERROR: load_module: could not
>>> find module <auth_db> in </usr/local/lib/kamailio/modules>
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 238, column 12-23: failed to
>>> load module
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <mi_fifo> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 287, column 54: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <rr> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 301, column 35: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <rr> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 303, column 35: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <registrar> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 307, column 44: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <registrar> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 313, column 42: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <acc> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 318, column 33: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <acc> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 319, column 32: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <acc> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 320, column 36: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <acc> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 324, column 38: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <acc> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 326, column 30: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <acc> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 327, column 37: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <acc> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 330, column 45: Can't set module
>>> parameter
>>> 0(8569) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No module
>>> matching <acc> found
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 331, column 45: Can't set module
>>> parameter
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 30-34: syntax error
>>> 0(8569) : <core> [cfg.y:3529]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 30-34: Invalid
>>> arguments
>>> 0(8569) : <core> [cfg.y:3532]: parse error in config file
>>> /usr/local/etc/kamailio/kamailio.cfg, line 346, column 35:
>>> ERROR: bad config file (30 errors)
>>> [root at kamailio-dev-lab ~]#
>>>
>>>
>>> Thanks in advance
>>>
>>> Michal Yachimovitz
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120711/0a65ed30/attachment.htm>
From klaus.mailinglists at pernau.at Wed Jul 11 11:24:07 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Wed, 11 Jul 2012 11:24:07 +0200
Subject: [SR-Users] DB create statements
Message-ID: <4FFD4637.90400@pernau.at>
Hi!
For some reason I need to the enter the SQL statements manually on the
DB server (I do not want to copy the scripts to the DB server and there
is no superuser access over the network)
Is there a simple method to get all the SQL commands to create the
kamailio database?
I see there are all the files in "/usr/share/kamailio/postgres/" and
lots of other SQL statements in /usr/lib/kamailio/kamctl/kamdbctl.pgsql.
Does anyone know of a simple method to get all the raw SQL queries?
Thanks
Klaus
From aftnix at gmail.com Wed Jul 11 11:31:52 2012
From: aftnix at gmail.com (Aft nix)
Date: Wed, 11 Jul 2012 15:31:52 +0600
Subject: [SR-Users] DB create statements
In-Reply-To: <4FFD4637.90400@pernau.at>
References: <4FFD4637.90400@pernau.at>
Message-ID: <CAGuaRCsB32ZJPn5rZj83nteOqPqp79UnY4sxEm6rpsUadpB16A@mail.gmail.com>
On Wed, Jul 11, 2012 at 3:24 PM, Klaus Darilion
<klaus.mailinglists at pernau.at> wrote:
> Hi!
>
> For some reason I need to the enter the SQL statements manually on the DB
> server (I do not want to copy the scripts to the DB server and there is no
> superuser access over the network)
>
> Is there a simple method to get all the SQL commands to create the kamailio
> database?
>
Hi,
You can look at this module. you can query a sql database from your kamailio.cfg
http://kamailio.org/docs/modules/stable/modules_k/sqlops.html
Cheers.
> I see there are all the files in "/usr/share/kamailio/postgres/" and lots of
> other SQL statements in /usr/lib/kamailio/kamctl/kamdbctl.pgsql. Does anyone
> know of a simple method to get all the raw SQL queries?
>
> Thanks
> Klaus
>
>
>
> _______________________________________________
> 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
--
-aft
From klaus.mailinglists at pernau.at Wed Jul 11 14:25:50 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Wed, 11 Jul 2012 14:25:50 +0200
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <CAGuaRCuYLyNJtp-qkRDdACF5g7mQsVRo7BoYKTz4vYAXxir-ug@mail.gmail.com>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFAD6E6.4030503@pernau.at> <4FFB05A5.6030607@gmail.com>
<CAGuaRCuYLyNJtp-qkRDdACF5g7mQsVRo7BoYKTz4vYAXxir-ug@mail.gmail.com>
Message-ID: <4FFD70CE.6020404@pernau.at>
Does it work with your web browser?
https://ip.address.ofyour.proxy:5061/
At least the TLS handshake should work.
If you add the following snippet to your config you should also see the
response in your browser:
event_route[xhttp:request] {
xhttp_reply("200", "OK", "text/html","<html><body>OK - $hu -
[$si:$sp]</body></html>");
}
regards
Klaus
On 10.07.2012 12:44, Aft nix wrote:
> On Mon, Jul 9, 2012 at 10:24 PM, Daniel-Constantin Mierla
> <miconda at gmail.com> wrote:
>> Hello,
>>
>> also, can you provide more details about the case? Is it with the very first
>> connection or you do some load testing and at some point you get this issue?
>>
>
> No, its not a part of load testing. it happens on the first connection.
>
>> Can you reproduce it always?
>
> Yes i can reproduce it.
>
>> Do you set different number of workers per
>> socket? What is the output of 'kamctl ps'?
>
> No. both are 4. (udp and tls )
>
> I have downgraded the lab machine to do some testing. so i can't give
> kamctl ps of the faulty
> installation at this moment. kamailio-3.2.x is deployed in our
> production servers, and it worked flawlessly.
>
> this is the output of kamctl ps from a 3.2.x. it uses the same config
> file as i was using with git master branch.
>
> [root at server kamailio-3.2.3]# kamctl ps
> Process:: ID=0 PID=31109 Type=attendant
> Process:: ID=1 PID=31110 Type=udp receiver child=0 sock=<IP>:<PORT>
> Process:: ID=2 PID=31111 Type=udp receiver child=1 sock=<IP>:<PORT>
> Process:: ID=3 PID=31112 Type=udp receiver child=2 sock=<IP>:<PORT>
> Process:: ID=4 PID=31113 Type=udp receiver child=3 sock=<IP>:<PORT>
> Process:: ID=5 PID=31114 Type=slow timer
> Process:: ID=6 PID=31115 Type=timer
> Process:: ID=7 PID=31116 Type=MI FIFO
> Process:: ID=8 PID=31117 Type=ctl handler
> Process:: ID=9 PID=31118 Type=TIMER NH
> Process:: ID=10 PID=31119 Type=tcp receiver child=0
> Process:: ID=11 PID=31120 Type=tcp receiver child=1
> Process:: ID=12 PID=31121 Type=tcp receiver child=2
> Process:: ID=13 PID=31122 Type=tcp receiver child=3
> Process:: ID=14 PID=31123 Type=tcp main process
>
>>
>> Have you tried with 3.3 branch as well or just master branch?
>>
>
> I've got this in master branch. haven't tried it with 3.3 branch.
>
> On the side note similar issue was reported by a guy earlier this year
> in this list which went
> unnoticed. here is the link to that mail :
>
> http://lists.sip-router.org/pipermail/sr-users/2012-April/072683.html
>
> His issue seems similar to me.
>
> Cheers
>> Cheers,
>> Daniel
>>
>>
>> On 7/9/12 3:04 PM, Klaus Darilion wrote:
>>>
>>> Use wireshark to analyze the TLS handshake
>>>
>>> regards
>>> klaus
>>>
>>> On 09.07.2012 13:27, Aft nix wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have enabled tls parameters as follows:
>>>>
>>>> in kamailio.cfg
>>>>
>>>> listen = tls:<IP>:<PORT>
>>>>
>>>> in tls.cfg
>>>>
>>>> [server:<IP>:<PORT>]
>>>> method = TLSv1
>>>> verify_certificate = no
>>>> require_certificate = no
>>>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>>>> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>>>>
>>>> Now if i try to connect to this interface using openssl s_client, it
>>>> does connects,
>>>> but now server certificate is sent from kamailio.
>>>>
>>>> kamailio log shows this :
>>>>
>>>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
>>>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
>>>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
>>>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
>>>> 0xb5701580), fd_no=11
>>>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
>>>> fd_no=12 called
>>>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
>>>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
>>>> connection passed to the least busy one (3289651)
>>>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
>>>> [tls:<IP>:<PORT>], 0xb5701580
>>>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid
>>>> 2491)
>>>>
>>>> I'm using kamailio from git. its updated to the latest.
>>>> Thanks in advance.
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
>> http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
>> http://asipto.com/u/kpw
>>
>
>
>
From klaus.mailinglists at pernau.at Wed Jul 11 14:44:44 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Wed, 11 Jul 2012 14:44:44 +0200
Subject: [SR-Users] DB create statements
In-Reply-To: <4FFD4637.90400@pernau.at>
References: <4FFD4637.90400@pernau.at>
Message-ID: <4FFD753C.9090407@pernau.at>
For the files: I solved my problem by changing the
/usr/lib/kamailio/kamctl/kamdbctl.pgsql script to write all queries to
stdout instead sending it to the DB, e.g:
# execute sql command with optional db name
sql_query()
{
if [ $TRYONLY -eq 1 ] ; then
if [ $# -gt 1 ] ; then
shift
echo "$@"
else
cat
fi
else
if [ $# -gt 1 ] ; then
if [ -n "$1" ]; then
DB="$1"
else
DB=""
fi
shift
$CMD -d $DB -c "$@"
else
$CMD "$@"
fi
fi
}
And then call "TRYONLY=1 kamdbctl create"
regards
Klaus
On 11.07.2012 11:24, Klaus Darilion wrote:
> Hi!
>
> For some reason I need to the enter the SQL statements manually on the
> DB server (I do not want to copy the scripts to the DB server and there
> is no superuser access over the network)
>
> Is there a simple method to get all the SQL commands to create the
> kamailio database?
>
> I see there are all the files in "/usr/share/kamailio/postgres/" and
> lots of other SQL statements in /usr/lib/kamailio/kamctl/kamdbctl.pgsql.
> Does anyone know of a simple method to get all the raw SQL queries?
>
> Thanks
> Klaus
>
>
>
> _______________________________________________
> 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
From klaus.mailinglists at pernau.at Wed Jul 11 14:56:43 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Wed, 11 Jul 2012 14:56:43 +0200
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
Message-ID: <4FFD780B.1020605@pernau.at>
I just tested TLS with Kamailio 3.3.0 and Eyebeam and it works. Make
sure to specify "ca_list" if intermediate certificates are used.
regards
Klaus
On 09.07.2012 13:27, Aft nix wrote:
> Hi,
>
> I have enabled tls parameters as follows:
>
> in kamailio.cfg
>
> listen = tls:<IP>:<PORT>
>
> in tls.cfg
>
> [server:<IP>:<PORT>]
> method = TLSv1
> verify_certificate = no
> require_certificate = no
> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>
> Now if i try to connect to this interface using openssl s_client, it
> does connects,
> but now server certificate is sent from kamailio.
>
> kamailio log shows this :
>
> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
> 0xb5701580), fd_no=11
> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
> fd_no=12 called
> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
> connection passed to the least busy one (3289651)
> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
> [tls:<IP>:<PORT>], 0xb5701580
> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid 2491)
>
> I'm using kamailio from git. its updated to the latest.
> Thanks in advance.
>
From miconda at gmail.com Wed Jul 11 15:16:04 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 11 Jul 2012 15:16:04 +0200
Subject: [SR-Users] is kamilio support RFC5626 now ?
In-Reply-To: <9669C420-DD07-4B34-A8DE-641058A2C15D@edvina.net>
References: <CAOfBJcwJR306vLRWUnacWCC9Y73Db4uy4p=61hcmsprZ5myEjw@mail.gmail.com>
<4FFD24A7.1050609@gmail.com>
<9669C420-DD07-4B34-A8DE-641058A2C15D@edvina.net>
Message-ID: <4FFD7C94.60004@gmail.com>
On 7/11/12 9:28 AM, Olle E. Johansson wrote:
> 11 jul 2012 kl. 09:00 skrev Daniel-Constantin Mierla:
>
>> Hello,
>>
>> On 7/11/12 4:23 AM, mike wrote:
>>> dear kamilio developers :
>>>
>>> i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now?so that the
>>> kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request.
>> sip.instance and reg-id are handled by the registrar/usrloc modules. Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module.
> How do you recognize the flows and switch between them in case of failure?
the flow switching part is not implemented in the module. the
sip.instance and reg-id are used to update the location record. Haven't
looked at it, but it might be possible to do the switching via config
operations.
Cheerss,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From oej at edvina.net Wed Jul 11 15:18:41 2012
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 11 Jul 2012 15:18:41 +0200
Subject: [SR-Users] GRUU support in Kamailio
Message-ID: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
Hey,
Been trying to understand the GRUU support in Kamailio. I see that the registrar saves sip.instance - but I don't see any functions to generate gruu URIs or store them. A public GRUU is valid forever for a sip.instance and should propably be saved into some sort of database table. A temporary GRUU is only valid for as long as a device registers with the same Call-ID.
Please give me pointers to what I have missed!
Thanks,
/O
---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
From oej at edvina.net Wed Jul 11 15:21:52 2012
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 11 Jul 2012 15:21:52 +0200
Subject: [SR-Users] is kamilio support RFC5626 now ?
In-Reply-To: <4FFD7C94.60004@gmail.com>
References: <CAOfBJcwJR306vLRWUnacWCC9Y73Db4uy4p=61hcmsprZ5myEjw@mail.gmail.com>
<4FFD24A7.1050609@gmail.com>
<9669C420-DD07-4B34-A8DE-641058A2C15D@edvina.net>
<4FFD7C94.60004@gmail.com>
Message-ID: <6956999D-7AD8-44CC-9011-E9D814A238A1@edvina.net>
11 jul 2012 kl. 15:16 skrev Daniel-Constantin Mierla:
>
> On 7/11/12 9:28 AM, Olle E. Johansson wrote:
>> 11 jul 2012 kl. 09:00 skrev Daniel-Constantin Mierla:
>>
>>> Hello,
>>>
>>> On 7/11/12 4:23 AM, mike wrote:
>>>> dear kamilio developers :
>>>>
>>>> i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now?so that the
>>>> kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request.
>>> sip.instance and reg-id are handled by the registrar/usrloc modules. Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module.
>> How do you recognize the flows and switch between them in case of failure?
> the flow switching part is not implemented in the module. the sip.instance and reg-id are used to update the location record. Haven't looked at it, but it might be possible to do the switching via config operations.
Cool.
There has to be a way to easily handle two registrations with the same instance.ID as one contact in all operations in regards to lookup() and forking.
You want to know that you have more than one flow for the same contact (i.e. the same device). And possibly which flow (which ingres proxy) that is currently active.
/O
From miconda at gmail.com Wed Jul 11 15:28:06 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 11 Jul 2012 15:28:06 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
Message-ID: <4FFD7F66.1030104@gmail.com>
Hello,
On 7/11/12 3:18 PM, Olle E. Johansson wrote:
> Hey,
> Been trying to understand the GRUU support in Kamailio. I see that the registrar saves sip.instance - but I don't see any functions to generate gruu URIs or store them. A public GRUU is valid forever for a sip.instance and should propably be saved into some sort of database table. A temporary GRUU is only valid for as long as a device registers with the same Call-ID.
>
> Please give me pointers to what I have missed!
if you follow the git log for registrar and usrloc module during 3.3
development you will spot quicker the related parts of code.
The public gruu is built based on sip.instance value, as recommended by
rfc, therefore is no need to store anything else.
The temp gruu is the ruid (record unique id) value plus the hash code of
the aor - ruid is uniquely generated using the code from internal
libutils/sruid.{c,h}
Using these approaches, the gruu addresses are built reusing some values
from the location records, no need for special tables.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From oej at edvina.net Wed Jul 11 15:36:09 2012
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 11 Jul 2012 15:36:09 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <4FFD7F66.1030104@gmail.com>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
Message-ID: <EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
> Hello,
>
> On 7/11/12 3:18 PM, Olle E. Johansson wrote:
>> Hey,
>> Been trying to understand the GRUU support in Kamailio. I see that the registrar saves sip.instance - but I don't see any functions to generate gruu URIs or store them. A public GRUU is valid forever for a sip.instance and should propably be saved into some sort of database table. A temporary GRUU is only valid for as long as a device registers with the same Call-ID.
>>
>> Please give me pointers to what I have missed!
> if you follow the git log for registrar and usrloc module during 3.3 development you will spot quicker the related parts of code.
Will do... But you know my cravings for documentation .-)
>
> The public gruu is built based on sip.instance value, as recommended by rfc, therefore is no need to store anything else.
So how do I route a SIP request to a public GRUU outside or inside of a dialog?
>
> The temp gruu is the ruid (record unique id) value plus the hash code of the aor - ruid is uniquely generated using the code from internal libutils/sruid.{c,h}
> Using these approaches, the gruu addresses are built reusing some values from the location records, no need for special tables.
Clever. ;-)
/O
From miconda at gmail.com Wed Jul 11 15:42:13 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 11 Jul 2012 15:42:13 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
Message-ID: <4FFD82B5.6060402@gmail.com>
Hello,
On 7/11/12 3:36 PM, Olle E. Johansson wrote:
> 11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
>
>> Hello,
>>
>> On 7/11/12 3:18 PM, Olle E. Johansson wrote:
>>> Hey,
>>> Been trying to understand the GRUU support in Kamailio. I see that the registrar saves sip.instance - but I don't see any functions to generate gruu URIs or store them. A public GRUU is valid forever for a sip.instance and should propably be saved into some sort of database table. A temporary GRUU is only valid for as long as a device registers with the same Call-ID.
>>>
>>> Please give me pointers to what I have missed!
>> if you follow the git log for registrar and usrloc module during 3.3 development you will spot quicker the related parts of code.
> Will do... But you know my cravings for documentation .-)
this is more devel insight documentation, not much to affect the users.
>
>> The public gruu is built based on sip.instance value, as recommended by rfc, therefore is no need to store anything else.
> So how do I route a SIP request to a public GRUU outside or inside of a dialog?
lookup(location) does automatically the logic - for outside of dialog is
the same like so far, no change in config.
For within dialog, you can use is_gruu() function to detect if the r-uri
is gruu and then you can call lookup(location). If r-uri is a gruu, then
lookup(location) searches for an exact match on temp/pub gruu value and
will not add extra branches with the rest of records for the AoR (if
pub-gruu), just updates with the record for the r-uri.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From oej at edvina.net Wed Jul 11 15:44:41 2012
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 11 Jul 2012 15:44:41 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <4FFD82B5.6060402@gmail.com>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
<4FFD82B5.6060402@gmail.com>
Message-ID: <862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
11 jul 2012 kl. 15:42 skrev Daniel-Constantin Mierla:
> Hello,
>
> On 7/11/12 3:36 PM, Olle E. Johansson wrote:
>> 11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
>>
>>> Hello,
>>>
>>> On 7/11/12 3:18 PM, Olle E. Johansson wrote:
>>>> Hey,
>>>> Been trying to understand the GRUU support in Kamailio. I see that the registrar saves sip.instance - but I don't see any functions to generate gruu URIs or store them. A public GRUU is valid forever for a sip.instance and should propably be saved into some sort of database table. A temporary GRUU is only valid for as long as a device registers with the same Call-ID.
>>>>
>>>> Please give me pointers to what I have missed!
>>> if you follow the git log for registrar and usrloc module during 3.3 development you will spot quicker the related parts of code.
>> Will do... But you know my cravings for documentation .-)
> this is more devel insight documentation, not much to affect the users.
>
>>
>>> The public gruu is built based on sip.instance value, as recommended by rfc, therefore is no need to store anything else.
>> So how do I route a SIP request to a public GRUU outside or inside of a dialog?
>
> lookup(location) does automatically the logic - for outside of dialog is the same like so far, no change in config.
>
> For within dialog, you can use is_gruu() function to detect if the r-uri is gruu and then you can call lookup(location). If r-uri is a gruu, then lookup(location) searches for an exact match on temp/pub gruu value and will not add extra branches with the rest of records for the AoR (if pub-gruu), just updates with the record for the r-uri.
Sweet. Thanks for the response!
So it's all hidden in the user location magic. :-)
/O
From aftnix at gmail.com Wed Jul 11 16:20:20 2012
From: aftnix at gmail.com (Aft nix)
Date: Wed, 11 Jul 2012 20:20:20 +0600
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <4FFD780B.1020605@pernau.at>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFD780B.1020605@pernau.at>
Message-ID: <CAGuaRCsF5g+3CnTysW8-AYoczgURdFZjQR5q7oRqoxp=avDK_A@mail.gmail.com>
On Wed, Jul 11, 2012 at 6:56 PM, Klaus Darilion
<klaus.mailinglists at pernau.at> wrote:
> I just tested TLS with Kamailio 3.3.0 and Eyebeam and it works. Make sure to
> specify "ca_list" if intermediate certificates are used.
>
I was working with master branch, not 3.3 branch.
>
> regards
> Klaus
>
> On 09.07.2012 13:27, Aft nix wrote:
>>
>> Hi,
>>
>> I have enabled tls parameters as follows:
>>
>> in kamailio.cfg
>>
>> listen = tls:<IP>:<PORT>
>>
>> in tls.cfg
>>
>> [server:<IP>:<PORT>]
>> method = TLSv1
>> verify_certificate = no
>> require_certificate = no
>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>>
>> Now if i try to connect to this interface using openssl s_client, it
>> does connects,
>> but now server certificate is sent from kamailio.
>>
>> kamailio log shows this :
>>
>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
>> 0xb5701580), fd_no=11
>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
>> fd_no=12 called
>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
>> connection passed to the least busy one (3289651)
>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
>> [tls:<IP>:<PORT>], 0xb5701580
>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid 2491)
>>
>> I'm using kamailio from git. its updated to the latest.
>> Thanks in advance.
>>
>
--
-aft
From aftnix at gmail.com Wed Jul 11 16:22:06 2012
From: aftnix at gmail.com (Aft nix)
Date: Wed, 11 Jul 2012 20:22:06 +0600
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <4FFD70CE.6020404@pernau.at>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFAD6E6.4030503@pernau.at> <4FFB05A5.6030607@gmail.com>
<CAGuaRCuYLyNJtp-qkRDdACF5g7mQsVRo7BoYKTz4vYAXxir-ug@mail.gmail.com>
<4FFD70CE.6020404@pernau.at>
Message-ID: <CAGuaRCv-TrEMoWMQWvBfFyLci_3XD5nvxDwfktp1a1XEgMONTQ@mail.gmail.com>
On Wed, Jul 11, 2012 at 6:25 PM, Klaus Darilion
<klaus.mailinglists at pernau.at> wrote:
> Does it work with your web browser?
>
> https://ip.address.ofyour.proxy:5061/
>
> At least the TLS handshake should work.
>
Yes i've tested that way. It shows server not found. I think the
problem is not related to
tls. The TCP connection is not established in the first place. You
will get the a hint of this
by reading the debug log i gave in my initial mail.
> If you add the following snippet to your config you should also see the
> response in your browser:
>
> event_route[xhttp:request] {
> xhttp_reply("200", "OK", "text/html","<html><body>OK - $hu -
> [$si:$sp]</body></html>");
> }
>
>
> regards
> Klaus
>
>
>
> On 10.07.2012 12:44, Aft nix wrote:
>>
>> On Mon, Jul 9, 2012 at 10:24 PM, Daniel-Constantin Mierla
>> <miconda at gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> also, can you provide more details about the case? Is it with the very
>>> first
>>> connection or you do some load testing and at some point you get this
>>> issue?
>>>
>>
>> No, its not a part of load testing. it happens on the first connection.
>>
>>> Can you reproduce it always?
>>
>>
>> Yes i can reproduce it.
>>
>>> Do you set different number of workers per
>>> socket? What is the output of 'kamctl ps'?
>>
>>
>> No. both are 4. (udp and tls )
>>
>> I have downgraded the lab machine to do some testing. so i can't give
>> kamctl ps of the faulty
>> installation at this moment. kamailio-3.2.x is deployed in our
>> production servers, and it worked flawlessly.
>>
>> this is the output of kamctl ps from a 3.2.x. it uses the same config
>> file as i was using with git master branch.
>>
>> [root at server kamailio-3.2.3]# kamctl ps
>> Process:: ID=0 PID=31109 Type=attendant
>> Process:: ID=1 PID=31110 Type=udp receiver child=0 sock=<IP>:<PORT>
>> Process:: ID=2 PID=31111 Type=udp receiver child=1 sock=<IP>:<PORT>
>> Process:: ID=3 PID=31112 Type=udp receiver child=2 sock=<IP>:<PORT>
>> Process:: ID=4 PID=31113 Type=udp receiver child=3 sock=<IP>:<PORT>
>> Process:: ID=5 PID=31114 Type=slow timer
>> Process:: ID=6 PID=31115 Type=timer
>> Process:: ID=7 PID=31116 Type=MI FIFO
>> Process:: ID=8 PID=31117 Type=ctl handler
>> Process:: ID=9 PID=31118 Type=TIMER NH
>> Process:: ID=10 PID=31119 Type=tcp receiver child=0
>> Process:: ID=11 PID=31120 Type=tcp receiver child=1
>> Process:: ID=12 PID=31121 Type=tcp receiver child=2
>> Process:: ID=13 PID=31122 Type=tcp receiver child=3
>> Process:: ID=14 PID=31123 Type=tcp main process
>>
>>>
>>> Have you tried with 3.3 branch as well or just master branch?
>>>
>>
>> I've got this in master branch. haven't tried it with 3.3 branch.
>>
>> On the side note similar issue was reported by a guy earlier this year
>> in this list which went
>> unnoticed. here is the link to that mail :
>>
>> http://lists.sip-router.org/pipermail/sr-users/2012-April/072683.html
>>
>> His issue seems similar to me.
>>
>> Cheers
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/9/12 3:04 PM, Klaus Darilion wrote:
>>>>
>>>>
>>>> Use wireshark to analyze the TLS handshake
>>>>
>>>> regards
>>>> klaus
>>>>
>>>> On 09.07.2012 13:27, Aft nix wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have enabled tls parameters as follows:
>>>>>
>>>>> in kamailio.cfg
>>>>>
>>>>> listen = tls:<IP>:<PORT>
>>>>>
>>>>> in tls.cfg
>>>>>
>>>>> [server:<IP>:<PORT>]
>>>>> method = TLSv1
>>>>> verify_certificate = no
>>>>> require_certificate = no
>>>>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>>>>> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>>>>>
>>>>> Now if i try to connect to this interface using openssl s_client, it
>>>>> does connects,
>>>>> but now server certificate is sent from kamailio.
>>>>>
>>>>> kamailio log shows this :
>>>>>
>>>>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT
>>>>> IP>
>>>>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
>>>>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
>>>>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
>>>>> 0xb5701580), fd_no=11
>>>>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
>>>>> fd_no=12 called
>>>>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
>>>>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp
>>>>> receiver,
>>>>> connection passed to the least busy one (3289651)
>>>>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity
>>>>> on
>>>>> [tls:<IP>:<PORT>], 0xb5701580
>>>>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid
>>>>> 2491)
>>>>>
>>>>> I'm using kamailio from git. its updated to the latest.
>>>>> Thanks in advance.
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.com
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
>>> http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
>>> http://asipto.com/u/kpw
>>>
>>
>>
>>
>
--
-aft
From klaus.mailinglists at pernau.at Wed Jul 11 17:14:10 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Wed, 11 Jul 2012 17:14:10 +0200
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <CAGuaRCsF5g+3CnTysW8-AYoczgURdFZjQR5q7oRqoxp=avDK_A@mail.gmail.com>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFD780B.1020605@pernau.at>
<CAGuaRCsF5g+3CnTysW8-AYoczgURdFZjQR5q7oRqoxp=avDK_A@mail.gmail.com>
Message-ID: <4FFD9842.4070809@pernau.at>
Maybe there were some changes fore websocket support which cause
problems. Do plain TCP connections work?
klaus
On 11.07.2012 16:20, Aft nix wrote:
> On Wed, Jul 11, 2012 at 6:56 PM, Klaus Darilion
> <klaus.mailinglists at pernau.at> wrote:
>> I just tested TLS with Kamailio 3.3.0 and Eyebeam and it works. Make sure to
>> specify "ca_list" if intermediate certificates are used.
>>
>
> I was working with master branch, not 3.3 branch.
>
>>
>> regards
>> Klaus
>>
>> On 09.07.2012 13:27, Aft nix wrote:
>>>
>>> Hi,
>>>
>>> I have enabled tls parameters as follows:
>>>
>>> in kamailio.cfg
>>>
>>> listen = tls:<IP>:<PORT>
>>>
>>> in tls.cfg
>>>
>>> [server:<IP>:<PORT>]
>>> method = TLSv1
>>> verify_certificate = no
>>> require_certificate = no
>>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>>> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
>>>
>>> Now if i try to connect to this interface using openssl s_client, it
>>> does connects,
>>> but now server certificate is sent from kamailio.
>>>
>>> kamailio log shows this :
>>>
>>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
>>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
>>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
>>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
>>> 0xb5701580), fd_no=11
>>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
>>> fd_no=12 called
>>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
>>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
>>> connection passed to the least busy one (3289651)
>>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
>>> [tls:<IP>:<PORT>], 0xb5701580
>>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid 2491)
>>>
>>> I'm using kamailio from git. its updated to the latest.
>>> Thanks in advance.
>>>
>>
>
>
>
From peter.dunkley at crocodile-rcs.com Wed Jul 11 17:37:49 2012
From: peter.dunkley at crocodile-rcs.com (Peter Dunkley)
Date: Wed, 11 Jul 2012 16:37:49 +0100
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <4FFD9842.4070809@pernau.at>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFD780B.1020605@pernau.at>
<CAGuaRCsF5g+3CnTysW8-AYoczgURdFZjQR5q7oRqoxp=avDK_A@mail.gmail.com>
<4FFD9842.4070809@pernau.at>
Message-ID: <1342021069.8471.6.camel@pd-notebook-linux.croc.internal>
Hi,
WebSockets over TLS works which requires establishing a TLS connection
and exchanging an HTTP request and response. It doesn't sound like this
connection is even getting passed the TLS handshake part?
Peter
On Wed, 2012-07-11 at 17:14 +0200, Klaus Darilion wrote:
> Maybe there were some changes fore websocket support which cause
> problems. Do plain TCP connections work?
>
> klaus
>
> On 11.07.2012 16:20, Aft nix wrote:
> > On Wed, Jul 11, 2012 at 6:56 PM, Klaus Darilion
> > <klaus.mailinglists at pernau.at> wrote:
> >> I just tested TLS with Kamailio 3.3.0 and Eyebeam and it works. Make sure to
> >> specify "ca_list" if intermediate certificates are used.
> >>
> >
> > I was working with master branch, not 3.3 branch.
> >
> >>
> >> regards
> >> Klaus
> >>
> >> On 09.07.2012 13:27, Aft nix wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have enabled tls parameters as follows:
> >>>
> >>> in kamailio.cfg
> >>>
> >>> listen = tls:<IP>:<PORT>
> >>>
> >>> in tls.cfg
> >>>
> >>> [server:<IP>:<PORT>]
> >>> method = TLSv1
> >>> verify_certificate = no
> >>> require_certificate = no
> >>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
> >>> certificate = /usr/local/etc/kamailio/kamailio-selfsigned.pem
> >>>
> >>> Now if i try to connect to this interface using openssl s_client, it
> >>> does connects,
> >>> but now server certificate is sent from kamailio.
> >>>
> >>> kamailio log shows this :
> >>>
> >>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT IP>
> >>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
> >>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
> >>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
> >>> 0xb5701580), fd_no=11
> >>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
> >>> fd_no=12 called
> >>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
> >>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp receiver,
> >>> connection passed to the least busy one (3289651)
> >>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity on
> >>> [tls:<IP>:<PORT>], 0xb5701580
> >>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid 2491)
> >>>
> >>> I'm using kamailio from git. its updated to the latest.
> >>> Thanks in advance.
> >>>
> >>
> >
> >
> >
>
>
> _______________________________________________
> 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
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120711/3af726ca/attachment-0001.htm>
From oej at edvina.net Wed Jul 11 17:54:17 2012
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 11 Jul 2012 17:54:17 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
<4FFD82B5.6060402@gmail.com>
<862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
Message-ID: <816DB4EA-4BC3-4946-8D67-1634C9024397@edvina.net>
11 jul 2012 kl. 15:44 skrev Olle E. Johansson:
>
> 11 jul 2012 kl. 15:42 skrev Daniel-Constantin Mierla:
>
>> Hello,
>>
>> On 7/11/12 3:36 PM, Olle E. Johansson wrote:
>>> 11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
>>>
>>>> Hello,
>>>>
>>>> On 7/11/12 3:18 PM, Olle E. Johansson wrote:
>>>>> Hey,
>>>>> Been trying to understand the GRUU support in Kamailio. I see that the registrar saves sip.instance - but I don't see any functions to generate gruu URIs or store them. A public GRUU is valid forever for a sip.instance and should propably be saved into some sort of database table. A temporary GRUU is only valid for as long as a device registers with the same Call-ID.
>>>>>
>>>>> Please give me pointers to what I have missed!
>>>> if you follow the git log for registrar and usrloc module during 3.3 development you will spot quicker the related parts of code.
>>> Will do... But you know my cravings for documentation .-)
>> this is more devel insight documentation, not much to affect the users.
>>
>>>
>>>> The public gruu is built based on sip.instance value, as recommended by rfc, therefore is no need to store anything else.
>>> So how do I route a SIP request to a public GRUU outside or inside of a dialog?
>>
>> lookup(location) does automatically the logic - for outside of dialog is the same like so far, no change in config.
>>
>> For within dialog, you can use is_gruu() function to detect if the r-uri is gruu and then you can call lookup(location). If r-uri is a gruu, then lookup(location) searches for an exact match on temp/pub gruu value and will not add extra branches with the rest of records for the AoR (if pub-gruu), just updates with the record for the r-uri.
>
> Sweet. Thanks for the response!
>
> So it's all hidden in the user location magic. :-)
Reading source code and documentation again...
I see that the gruu_enabled() parameter enables gruu if there's an instance ID in the contact.
The requirement is also that there has to be a supported: gruu
The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a good indication
that you have GRUU support in the UA.
" When a UA compliant to this specification generates a REGISTER
request (initial or refresh), it MUST include the Supported header
field in the request. The value of that header field MUST include
"gruu" as one of the option tags. This alerts the registrar for the
domain that the UA supports the GRUU mechanism."
From RFC 5627.
Disclaimer: I've only read the source code. Ashamed that I haven't tried. Will do a.s.a.p.
/O
From ibc at aliax.net Wed Jul 11 17:57:22 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 11 Jul 2012 17:57:22 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <816DB4EA-4BC3-4946-8D67-1634C9024397@edvina.net>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
<4FFD82B5.6060402@gmail.com>
<862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
<816DB4EA-4BC3-4946-8D67-1634C9024397@edvina.net>
Message-ID: <CALiegfkBs=zOVrGd+B35Kfdecrr=NvsEoqA1dtD51OwbiS7_6g@mail.gmail.com>
2012/7/11 Olle E. Johansson <oej at edvina.net>:
> I see that the gruu_enabled() parameter enables gruu if there's an instance ID in the contact.
>
> The requirement is also that there has to be a supported: gruu
>
> The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a good indication
> that you have GRUU support in the UA.
>
> " When a UA compliant to this specification generates a REGISTER
> request (initial or refresh), it MUST include the Supported header
> field in the request. The value of that header field MUST include
> "gruu" as one of the option tags. This alerts the registrar for the
> domain that the UA supports the GRUU mechanism."
>
> From RFC 5627.
I agree that checking "gruu" option tag in the Supported/Require
header of the REGISTER is needed.
--
I?aki Baz Castillo
<ibc at aliax.net>
From oej at edvina.net Wed Jul 11 17:58:54 2012
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 11 Jul 2012 17:58:54 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <CALiegfkBs=zOVrGd+B35Kfdecrr=NvsEoqA1dtD51OwbiS7_6g@mail.gmail.com>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
<4FFD82B5.6060402@gmail.com>
<862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
<816DB4EA-4BC3-4946-8D67-1634C9024397@edvina.net>
<CALiegfkBs=zOVrGd+B35Kfdecrr=NvsEoqA1dtD51OwbiS7_6g@mail.gmail.com>
Message-ID: <6AE4204B-2DE6-40A9-AC6F-FBD88B5A287C@edvina.net>
11 jul 2012 kl. 17:57 skrev I?aki Baz Castillo:
> 2012/7/11 Olle E. Johansson <oej at edvina.net>:
>> I see that the gruu_enabled() parameter enables gruu if there's an instance ID in the contact.
>>
>> The requirement is also that there has to be a supported: gruu
>>
>> The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a good indication
>> that you have GRUU support in the UA.
>>
>> " When a UA compliant to this specification generates a REGISTER
>> request (initial or refresh), it MUST include the Supported header
>> field in the request. The value of that header field MUST include
>> "gruu" as one of the option tags. This alerts the registrar for the
>> domain that the UA supports the GRUU mechanism."
>>
>> From RFC 5627.
>
>
> I agree that checking "gruu" option tag in the Supported/Require
> header of the REGISTER is needed.
Remember that I might have missed that part of the code. I will try to test :-)
It might just be a documentation error.
/O
From ibc at aliax.net Wed Jul 11 18:01:18 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 11 Jul 2012 18:01:18 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <6AE4204B-2DE6-40A9-AC6F-FBD88B5A287C@edvina.net>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
<4FFD82B5.6060402@gmail.com>
<862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
<816DB4EA-4BC3-4946-8D67-1634C9024397@edvina.net>
<CALiegfkBs=zOVrGd+B35Kfdecrr=NvsEoqA1dtD51OwbiS7_6g@mail.gmail.com>
<6AE4204B-2DE6-40A9-AC6F-FBD88B5A287C@edvina.net>
Message-ID: <CALiegf=HH8nA-CKWUYhMa=QS75bdx2aMSODRkQ6cV92ViXVE7g@mail.gmail.com>
2012/7/11 Olle E. Johansson <oej at edvina.net>:
> Remember that I might have missed that part of the code. I will try to test :-)
> It might just be a documentation error.
Sure, I just mean that it should work as you pointed out :)
--
I?aki Baz Castillo
<ibc at aliax.net>
From miconda at gmail.com Wed Jul 11 18:06:33 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 11 Jul 2012 18:06:33 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <6AE4204B-2DE6-40A9-AC6F-FBD88B5A287C@edvina.net>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
<4FFD82B5.6060402@gmail.com>
<862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
<816DB4EA-4BC3-4946-8D67-1634C9024397@edvina.net>
<CALiegfkBs=zOVrGd+B35Kfdecrr=NvsEoqA1dtD51OwbiS7_6g@mail.gmail.com>
<6AE4204B-2DE6-40A9-AC6F-FBD88B5A287C@edvina.net>
Message-ID: <4FFDA489.1020809@gmail.com>
On 7/11/12 5:58 PM, Olle E. Johansson wrote:
> 11 jul 2012 kl. 17:57 skrev I?aki Baz Castillo:
>
>> 2012/7/11 Olle E. Johansson <oej at edvina.net>:
>>> I see that the gruu_enabled() parameter enables gruu if there's an instance ID in the contact.
>>>
>>> The requirement is also that there has to be a supported: gruu
>>>
>>> The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a good indication
>>> that you have GRUU support in the UA.
>>>
>>> " When a UA compliant to this specification generates a REGISTER
>>> request (initial or refresh), it MUST include the Supported header
>>> field in the request. The value of that header field MUST include
>>> "gruu" as one of the option tags. This alerts the registrar for the
>>> domain that the UA supports the GRUU mechanism."
>>>
>>> From RFC 5627.
>>
>> I agree that checking "gruu" option tag in the Supported/Require
>> header of the REGISTER is needed.
> Remember that I might have missed that part of the code. I will try to test :-)
> It might just be a documentation error.
gruu addresses are built for REGISTER reply only if the gruu tag is in
supported header, see code at:
modules_k/registrar/reply.c +190
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From oej at edvina.net Wed Jul 11 18:13:43 2012
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 11 Jul 2012 18:13:43 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <4FFDA489.1020809@gmail.com>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
<4FFD82B5.6060402@gmail.com>
<862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
<816DB4EA-4BC3-4946-8D67-1634C9024397@edvina.net>
<CALiegfkBs=zOVrGd+B35Kfdecrr=NvsEoqA1dtD51OwbiS7_6g@mail.gmail.com>
<6AE4204B-2DE6-40A9-AC6F-FBD88B5A287C@edvina.net>
<4FFDA489.1020809@gmail.com>
Message-ID: <7D1ADAF9-3199-47BF-9130-70861F92AD61@edvina.net>
11 jul 2012 kl. 18:06 skrev Daniel-Constantin Mierla:
> On 7/11/12 5:58 PM, Olle E. Johansson wrote:
>> 11 jul 2012 kl. 17:57 skrev I?aki Baz Castillo:
>>
>>> 2012/7/11 Olle E. Johansson <oej at edvina.net>:
>>>> I see that the gruu_enabled() parameter enables gruu if there's an instance ID in the contact.
>>>>
>>>> The requirement is also that there has to be a supported: gruu
>>>>
>>>> The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a good indication
>>>> that you have GRUU support in the UA.
>>>>
>>>> " When a UA compliant to this specification generates a REGISTER
>>>> request (initial or refresh), it MUST include the Supported header
>>>> field in the request. The value of that header field MUST include
>>>> "gruu" as one of the option tags. This alerts the registrar for the
>>>> domain that the UA supports the GRUU mechanism."
>>>>
>>>> From RFC 5627.
>>>
>>> I agree that checking "gruu" option tag in the Supported/Require
>>> header of the REGISTER is needed.
>> Remember that I might have missed that part of the code. I will try to test :-)
>> It might just be a documentation error.
> gruu addresses are built for REGISTER reply only if the gruu tag is in supported header, see code at:
>
> modules_k/registrar/reply.c +190
Ok! Great!
So I will file a documentation bug, assign that to myself for not noticing this and try to commit and cause work for the rest of you :-)
Thanks for your patience, Daniel!
/O
From ibc at aliax.net Wed Jul 11 18:16:40 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 11 Jul 2012 18:16:40 +0200
Subject: [SR-Users] GRUU support in Kamailio
In-Reply-To: <7D1ADAF9-3199-47BF-9130-70861F92AD61@edvina.net>
References: <473A4967-D4A0-44DA-9392-F0266522DA16@edvina.net>
<4FFD7F66.1030104@gmail.com>
<EC4F80C8-8E3B-438D-A4D9-F04660169A7D@edvina.net>
<4FFD82B5.6060402@gmail.com>
<862B517F-BAFA-4390-8C4E-410BD54E8DBB@edvina.net>
<816DB4EA-4BC3-4946-8D67-1634C9024397@edvina.net>
<CALiegfkBs=zOVrGd+B35Kfdecrr=NvsEoqA1dtD51OwbiS7_6g@mail.gmail.com>
<6AE4204B-2DE6-40A9-AC6F-FBD88B5A287C@edvina.net>
<4FFDA489.1020809@gmail.com>
<7D1ADAF9-3199-47BF-9130-70861F92AD61@edvina.net>
Message-ID: <CALiegfmcE3WkzSTmZf1Dxop+_Ow3AEJVBYcS4fEJoqJhUS1H-w@mail.gmail.com>
2012/7/11 Olle E. Johansson <oej at edvina.net>:
> Thanks for your patience, Daniel!
And even more thanks for the code!
I will test it in depth very soon.
--
I?aki Baz Castillo
<ibc at aliax.net>
From amar at smarttel.com.np Wed Jul 11 18:54:54 2012
From: amar at smarttel.com.np (amar at smarttel.com.np)
Date: Wed, 11 Jul 2012 22:39:54 +0545
Subject: [SR-Users] GRUU support in Kamailio
Message-ID: <3zT5KXGSM2Rp.rCNkj1vN@smtp.ntc.net.np>
A
-original message-
Subject: Re: [SR-Users] GRUU support in Kamailio
From: I?aki Baz Castillo <ibc at aliax.net>
Date: 11/07/2012 10:08 pm
2012/7/11 Olle E. Johansson <oej at edvina.net>:
> Thanks for your patience, Daniel!
And even more thanks for the code!
I will test it in depth very soon.
--
I?aki Baz Castillo
<ibc at aliax.net>
_______________________________________________
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
From g.wolzak at online.nl Wed Jul 11 20:41:37 2012
From: g.wolzak at online.nl (Gertjan Wolzak)
Date: Wed, 11 Jul 2012 20:41:37 +0200
Subject: [SR-Users] failure route correct..?
Message-ID: <4FFDC8E1.9080902@online.nl>
Hello All,
I am trying to get a failure route to work, I have got it working partially.
When a call comes in, first I check the db_alias, if that is positive I
do a lookup location and relay if the location is valid.
But sometimes the sip client is still registered in the location table,
but not connected anymore, mainly with wifi connected clients.
So, I have got the time out on 3 seconds (fr_timer). When that hits I
have configured the following failure route:
failure_route[NOTONLINE]
{
xlog("SCRIPT: Notonline failure route\n");
t_on_failure("STOP");
if (t_is_canceled())
{
exit;
}
if (t_check_status("408"))
{
xlog("SCRIPT: Status is time out");
$rU = $avp(orig_called); /( called number and alias id
not equal, so have to revert the rU back to the called number)/
prefix("9993"); /( needed to get the right manipulation
done within asterisk)/
xlog("SCRIPT: uri is $ru");
$ru = "sip:" + $rU + "@w.x.y.x:5060";
xlog("SCRIPT: uri is $ru"); (w.x.y.z
ip address of the asterisk box)
append_branch();
t_relay_to_udp("w.x.y.x","5060");
break;
}
}
I am not sure if the above is correct. I have based this on an old
"voicemail" failure route I could find.
It is working correct, the call is forwarded to an Asterisk box, where
some manipulation is done and then send to an pstn gateway.
The only problem I have is one way audio. RTP from the called number
reaches the callee but not vice versa.
Now I am wondering, can that be caused by the failure route, or should I
be looking in another direction?
Hope someone can give me a pointer.
Thanks.
Gertjan Wolzak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120711/231f4d3b/attachment.htm>
From aftnix at gmail.com Wed Jul 11 20:45:12 2012
From: aftnix at gmail.com (Aft nix)
Date: Thu, 12 Jul 2012 00:45:12 +0600
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <1342021069.8471.6.camel@pd-notebook-linux.croc.internal>
References: <CAGuaRCvOWTiMc4tqCgKYEaPFiVDmT9t9NsQS+RHnTrFtHJzGwQ@mail.gmail.com>
<4FFD780B.1020605@pernau.at>
<CAGuaRCsF5g+3CnTysW8-AYoczgURdFZjQR5q7oRqoxp=avDK_A@mail.gmail.com>
<4FFD9842.4070809@pernau.at>
<1342021069.8471.6.camel@pd-notebook-linux.croc.internal>
Message-ID: <CAGuaRCt7oi_3Ou=9b1iQ3LkvR7cQyYX_C6jGMVyHR4-fi+xkBw@mail.gmail.com>
On Wed, Jul 11, 2012 at 9:37 PM, Peter Dunkley
<peter.dunkley at crocodile-rcs.com> wrote:
>
> Hi,
>
> WebSockets over TLS works which requires establishing a TLS connection and
> exchanging an HTTP request and response. It doesn't sound like this
> connection is even getting passed the TLS handshake part?
>
> Peter
>
Hi,
That was my first guess. I will run some tests with plain tcp socket
and post update.
cheers.
>
> On Wed, 2012-07-11 at 17:14 +0200, Klaus Darilion wrote:
>
> Maybe there were some changes fore websocket support which cause
> problems. Do plain TCP connections work?
>
> klaus
>
> On 11.07.2012 16:20, Aft nix wrote:
> > On Wed, Jul 11, 2012 at 6:56 PM, Klaus Darilion
> > <klaus.mailinglists at pernau.at> wrote:
> >> I just tested TLS with Kamailio 3.3.0 and Eyebeam and it works. Make
> >> sure to
> >> specify "ca_list" if intermediate certificates are used.
> >>
> >
> > I was working with master branch, not 3.3 branch.
> >
> >>
> >> regards
> >> Klaus
> >>
> >> On 09.07.2012 13:27, Aft nix wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have enabled tls parameters as follows:
> >>>
> >>> in kamailio.cfg
> >>>
> >>> listen = tls:<IP>:<PORT>
> >>>
> >>> in tls.cfg
> >>>
> >>> [server:<IP>:<PORT>]
> >>> method = TLSv1
> >>> verify_certificate = no
> >>> require_certificate = no
> >>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
> >>> certificate = /usr/local/etc/kamailio/
> kamailio-selfsigned.pem
> >>>
> >>> Now if i try to connect to this interface using openssl s_client, it
> >>> does connects,
> >>> but now server certificate is sent from kamailio.
> >>>
> >>> kamailio log shows this :
> >>>
> >>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT
> >>> IP>
> >>> <core> [tcp_main.c:1089]: tcpconn_new: on port 40727, type 3
> >>> <core> [tcp_main.c:1400]: tcpconn_add: hashes: 2614:2652:2494, 2
> >>> <core> [io_wait.h:390]: DBG: io_watch_add(0x82535e0, 23, 2,
> >>> 0xb5701580), fd_no=11
> >>> <core> [io_wait.h:617]: DBG: io_watch_del (0x82535e0, 23, -1, 0x0)
> >>> fd_no=12 called
> >>> <core> [tcp_main.c:4296]: tcp: DBG: sending to child, events 1
> >>> <core> [tcp_main.c:3963]: WARNING: send2child: no free tcp
> >>> receiver,
> >>> connection passed to the least busy one (3289651)
> >>> <core> [tcp_main.c:3967]: selected tcp worker 0 0(8) for activity
> >>> on
> >>> [tls:<IP>:<PORT>], 0xb5701580
> >>> <core> [tcp_main.c:3576]: BUG: handle_ser_child: fd -1 for 0 (pid
> >>> 2491)
> >>>
> >>> I'm using kamailio from git. its updated to the latest.
> >>> Thanks in advance.
> >>>
> >>
> >
> >
> >
>
>
> _______________________________________________
> 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
>
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
--
-aft
From peter.dunkley at crocodile-rcs.com Wed Jul 11 21:33:22 2012
From: peter.dunkley at crocodile-rcs.com (Peter Dunkley)
Date: Wed, 11 Jul 2012 20:33:22 +0100
Subject: [SR-Users] sip over tls is not working
Message-ID: <a53dad8a511fa51269d81244f04cc5fd.squirrel@crocodile-rcs.com>
Hi,
I have just built Kamailio from Git master, configured TCP and TLS, and an
HTTP event route. I was able to connect to Kamailio over TLS using Google
Chrome (and saw the "SSL Error: The site's security certificate is not
trusted!" page). After I clicked on "Proceed anyway" I saw the log
message I put in the HTTP event route come out.
I also logged in with Jitsi using TLS and that worked fine too.
I tried this with both the WebSocket module loaded and without it, and it
worked in both cases.
I also tried the above with TCP and that worked fine as well.
As far as I can tell TLS is working in Kamailio Git master.
Regards,
Peter
> On Wed, Jul 11, 2012 at 9:37 PM, Peter Dunkley
> <peter.dunkley at crocodile-rcs.com> wrote:
>>
>> Hi,
>>
>> WebSockets over TLS works which requires establishing a TLS connection
>> and
>> exchanging an HTTP request and response. It doesn't sound like this
>> connection is even getting passed the TLS handshake part?
>>
>> Peter
>>
>
> Hi,
> That was my first guess. I will run some tests with plain tcp socket
> and post update.
>
> cheers.
>
>>
>> On Wed, 2012-07-11 at 17:14 +0200, Klaus Darilion wrote:
>>
>> Maybe there were some changes fore websocket support which cause
>> problems. Do plain TCP connections work?
>>
>> klaus
>>
>> On 11.07.2012 16:20, Aft nix wrote:
>> > On Wed, Jul 11, 2012 at 6:56 PM, Klaus Darilion
>> > <klaus.mailinglists at pernau.at> wrote:
>> >> I just tested TLS with Kamailio 3.3.0 and Eyebeam and it works. Make
>> >> sure to
>> >> specify "ca_list" if intermediate certificates are used.
>> >>
>> >
>> > I was working with master branch, not 3.3 branch.
>> >
>> >>
>> >> regards
>> >> Klaus
>> >>
>> >> On 09.07.2012 13:27, Aft nix wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I have enabled tls parameters as follows:
>> >>>
>> >>> in kamailio.cfg
>> >>>
>> >>> listen = tls:<IP>:<PORT>
>> >>>
>> >>> in tls.cfg
>> >>>
>> >>> [server:<IP>:<PORT>]
>> >>> method = TLSv1
>> >>> verify_certificate = no
>> >>> require_certificate = no
>> >>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>> >>> certificate = /usr/local/etc/kamailio/
>> kamailio-selfsigned.pem
>> >>>
>> >>> Now if i try to connect to this interface using openssl s_client, it
>> >>> does connects,
>> >>> but now server certificate is sent from kamailio.
>> >>>
>> >>> kamailio log shows this :
>> >>>
>> >>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT
>> >>> IP>
>> >>> <core> [tcp_main.c:10
From forums at akan.net Thu Jul 12 10:08:49 2012
From: forums at akan.net (Akan)
Date: Thu, 12 Jul 2012 03:08:49 -0500
Subject: [SR-Users] Kamailio Unexpectedly Terminating
In-Reply-To: <4FF1F637.5050302@gmail.com>
References: <4F98539A.3080307@akan.net> <4F990A47.9080904@gmail.com>
<4F99A51B.3040909@akan.net> <4F9C1F7C.2080204@akan.net>
<4F9D0BF5.10506@gmail.com> <4FA341FA.3070606@akan.net>
<4FA38B8E.9020900@gmail.com> <4FA5475D.60104@akan.net>
<4FAA2555.1050903@gmail.com> <4FAABCDE.1040305@akan.net>
<4FBC876A.2020907@akan.net> <4FC48EFC.8050605@akan.net>
<4FC49397.3040806@gmail.com> <4FC58569.1060201@akan.net>
<4FC634F3.3020802@gmail.com> <4FC67090.6000306@akan.net>
<4FC67440.1030300@gmail.com> <4FCA7968.90008@akan.net>
<4FCC5C64.90401@gmail.com> <4FD5F395.20308@gmail.com>
<4FD64332.3030104@akan.net> <4FD6E6C9.8050301@gmail.com>
<4FD78614.7020708@akan.net> <4FD7D91A.9070803@akan.net>
<4FE47283.9090700@akan.net> <4FE81BE0.5070802@gmail.com>
<4FEBD368.1050204@akan.net>
<430C2BA8-6B84-495E-AE93-2E36A8A60EB9@gmail.com>
<CFD3E709-0581-43E8-81D7-3CC7AA44D67C@gmail.com>
<4FF1F637.5050302@gmail.com>
Message-ID: <4FFE8611.8060606@akan.net>
I have been looking for a compiler option but so far I have not found
one. I would like to resolve all of the issues regarding solaris sparc64
and kamailio. We have a environment that can be used and I can perform a
lot of research and analysis. I am not an expert C programmer, even
though I have several years programming in another environment and
language. Please let me know what I can do to help. With that in mind,
here is what my latest research came up with. A core dump was being
produced in t_funcs.c at line 352. In GDB, I looked at the assembler
code that was produced from the source code. The line of code causing
the problem was "if (!t_reply( t, p_msg , 100 , cfg_get(tm, tm_cfg,
tm_auto_inv_100_r)))". I thought it was one of the structs that was
causing the misalignment, so in order to determine which one, I issued
"disas /m" to look at the assembler code to see which instruction and
which struct that was causing the problem. The statement that was
causing the dump was a "ldx" operation after a "call". I tried
separating the valued in the "if" statement to further isolate the
issue. As it turns out, the return value from the call to "t_reply" is
what is causing the alignment problem. I have included the full trace
and the disassemble code with the highlighted code being the problem.
Loaded symbols for /lib/sparcv9/ld.so.1
Core was generated by `./kamailio'.
Program terminated with signal 11, Segmentation fault.
#0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0,
proto=0, replicate=0) at t_funcs.c:352
352 if (!t_reply( t, p_msg , 100 ,
(gdb) disas /m
352 if (!t_reply( t, p_msg , 100 ,
0xffffffff7bd2b7a0 <+960>: ldx [ %fp + 0x7f7 ], %o0
0xffffffff7bd2b7a4 <+964>: mov %i0, %o1
0xffffffff7bd2b7ac <+972>: mov 0x64, %o2
* 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 <t_reply at plt>
=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3*
0xffffffff7bd2b7c0 <+992>: cmp %o0, 0
0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14
<t_relay_to+1844>
0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0
0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460
<t_relay_to+128>
0xffffffff7bd2b7d0 <+1008>: nop
---Type <return> to continue, or q <return> to quit---
353 cfg_get(tm, tm_cfg, tm_auto_inv_100_r)))
0xffffffff7bd2b79c <+956>: ta 1
0xffffffff7bd2b7a8 <+968>: or %g1, 0x308, %g1
0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1
0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1
354 DBG("SER: ERROR: t_reply (100)\n");
0xffffffff7bd2bb14 <+1844>: call 0xffffffff7be9b7c0
<get_debug_level at plt>
Thanks
Nathaniel
On 7/2/2012 2:27 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> for solaris sparc64 you have to find the option for compiler not to
> build with strict alignment requirement for structures. I checked
> quickly on the web in some man pages, but I am not sure I got the
> right solution (what I previously sent on this thread).
>
> If anyone can allocate resources to check all the structure, will be
> another variant, at some time/money expence, but I guess the fast will
> be the right flag to compiler.
>
> Cheers,
> Daniel
>
> On 7/2/12 12:47 AM, Omar Labs 188 Gmail wrote:
>> I tried in solaris the version kamailio 3.3.0 Bus error. For solaris
>> I have had that same issue in any version above the 1.4.3.
>>
>> If i test in Suse, kamailio crashes when the radius or Diameter
>> module is enabled. this i tested with versions 3.1 3.2 i am checking
>> if i can get the gdb for all this.
>>
>> I was unable to build it yet for 3.3.0
>>
>> thank you
>>
>> O
>>
>> On Jun 30, 2012, at 8:54 PM, Omar Labs 188 Gmail wrote:
>>
>>> Just to let you know
>>>
>>> I made a lot of tests using different modules including
>>> carrierroute, I do have the bus error also after the first call and
>>> core dump.
>>>
>>>
>>> thank you
>>> O
>>>
>>>
>>>
>>>
>>>
>>> On Jun 27, 2012, at 11:45 PM, Akan wrote:
>>>
>>>> Daniel,
>>>>
>>>> i did a repull from git, compiled, installed and re-test of
>>>> Kamailio and got the same error in the same program's location as
>>>> previous (in tm_funcs.c). Here are the commands that I entered to
>>>> make sure I did everything correctly:
>>>>
>>>> mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignment
>>>> cd /usr/local/src/kamailio/kamailio-3.2-noalignment
>>>> git clone --depth 1 git://git.sip-router.org/sip-router kamailio
>>>> cd kamailio
>>>> |gmake proper
>>>> gmake prefix=/opt/kamailio-3.2 FLAVOUR=kamailio cfg
>>>> vi modules.lst
>>>> | gmake prefix=/opt/kamailio-3.2 Q=0
>>>> CC_EXTRA_OPTS=|-mno-faster-structs all
>>>> |gmake prefix=/opt/kamailio-3.2 Q=0
>>>> CC_EXTRA_OPTS=|-mno-faster-structs install
>>>>
>>>> Makefile:363: config.mak: No such file or directory
>>>> normal Makefile.defs exec
>>>> target architecture <sparc64>, host architecture <sparc64>
>>>> generating autover.h ...
>>>> making config...
>>>> Makefile.defs defs skipped
>>>> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc
>>>> -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs
>>>> -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"'
>>>> -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"'
>>>> -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003
>>>> -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM
>>>> -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP
>>>> -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE
>>>> -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP
>>>> -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT
>>>> -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE
>>>> -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD
>>>> -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT
>>>> -DHAVE_FILIO_H -c endianness.c -o endianness.o -MMD -MP
>>>> gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc
>>>> -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs
>>>> -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"'
>>>> -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"'
>>>> -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003
>>>> -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM
>>>> -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP
>>>> -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE
>>>> -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP
>>>> -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT
>>>> -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE
>>>> -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD
>>>> -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT
>>>> -DHAVE_FILIO_H -c select_buf.c -o select_buf.o -MMD -MP
>>>>
>>>> ||
>>>> Thanks
>>>>
>>>> Nathaniel
>>>>
>>>> |
>>>> On 6/25/2012 3:05 AM, Daniel-Constantin Mierla wrote:
>>>>> Hello,
>>>>>
>>>>> thanks for troubleshooting further -- as I expected, it is a
>>>>> memalign problem, but some confusing reports by not using always
>>>>> the patches I made to registrar module to align the structure,
>>>>> made thinking is something else. Now is no longer in registrar,
>>>>> but in another module.
>>>>>
>>>>> There might be many of these, can you try to compile first without
>>>>> strict alignment to 8 bytes? Checking quickly to gcc, the option
>>>>> should be |-mno-faster-structs
>>>>>
>>>>> So try:
>>>>>
>>>>> make proper
>>>>> make FLAVOUR=kamailio cfg|
>>>>> make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all|
>>>>> ...
>>>>>
>>>>> By providing Q=0, you will see all compile flags, verify that
>>>>> |-mno-faster-structs is there.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>> |
>>>>> On 6/22/12 3:26 PM, Akan wrote:
>>>>>> Hello,
>>>>>>
>>>>>> After doing some research, this is what I found out. On Solaris
>>>>>> Sparc 64bit system, there is a mandatory alignment of memory
>>>>>> accesses and also for data types. I went thru the core dump,
>>>>>> disassembled the code and located the instruction that produced
>>>>>> the error. The registers addresses in questioned are on a 4 byte
>>>>>> alignment but not an 8 byte or 16 byte alignment. .The earlier
>>>>>> patch must have forced the alignment which is why the error did
>>>>>> not occur in the program common.c. It looks like there is a
>>>>>> similar situation in t_funcs.c.
>>>>>>
>>>>>> Here is a link that I found that can better explain:
>>>>>> http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html
>>>>>>
>>>>>>
>>>>>> Core was generated by `/opt/kamailio-3.2/sbin/kamailio'.
>>>>>> Program terminated with signal 10, Bus error.
>>>>>> #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698,
>>>>>> proxy=0x0, proto=0, replicate=0) at t_funcs.c:352
>>>>>> 352 if (!t_reply( t, p_msg , 100 ,
>>>>>>
>>>>>> 0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1
>>>>>> 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1
>>>>>> 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 <t_reply at plt>
>>>>>> *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3*
>>>>>> 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0
>>>>>> 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14
>>>>>> <t_relay_to+1844>
>>>>>> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0
>>>>>> 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460
>>>>>> <t_relay_to+128>
>>>>>>
>>>>>> End of assembler dump.
>>>>>> (gdb) info registers g1
>>>>>> g1 0xffffffff7666c3e4 -2308520988
>>>>>> (gdb) info registers o3
>>>>>> o3 0x18f3d0 1635280
>>>>>>
>>>>>> I hope this helps in trying to resolve this problem and to find a
>>>>>> solution. Also, if you need a sparc system to test with, just let
>>>>>> me know. We can help from a sparc perspective.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Nathaniel
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Daniel-Constantin Mierla -http://www.asipto.com
>>>>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>>>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012
>>>>> -http://asipto.com/u/katu
>>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012
>>>>> -http://asipto.com/u/kpw
>>>>>
>>>>> No virus found in this message.
>>>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>>>> Version: 2012.0.2180 / Virus Database: 2437/5091 - Release Date:
>>>>> 06/24/12
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
(gdb) bt full
#0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, proto=0, replicate=0) at t_funcs.c:352
ret = 0
new_tran = <value optimized out>
t = 0xffffffff76673b80
dst = {send_sock = 0x0, to = {s = {sa_family = 65535, sa_data = "??\177??\021\000\000\000\001\000\003\063\060"}, sin = {sin_family = 65535,
sin_port = 65535, sin_addr = {S_un = {S_un_b = {s_b1 = 127 '\177', s_b2 = 255 '?', s_b3 = 196 '?', s_b4 = 17 '\021'}, S_un_w = {s_w1 = 32767,
s_w2 = 50193}, S_addr = 2147468305}}, sin_zero = "\000\000\000\001\000\003\063\060"}, sin6 = {sin6_family = 65535, sin6_port = 65535,
sin6_flowinfo = 2147468305, sin6_addr = {_S6_un = {_S6_u8 = "\000\000\000\001\000\003\063\060\000\000\000\000\000\000\003p", _S6_u32 = {1, 209712,
0, 880}, __S6_align = 1}}, sin6_scope_id = 0, __sin6_src_id = 0}}, id = 0, proto = 0 '\000', send_flags = {f = 0 '\000',
blst_imask = 0 '\000'}}
port = <value optimized out>
host = {s = 0xffffffff788076d0 "", len = -1}
#1 0x000000010002f314 in do_action (h=0xffffffff7fffd250, a=0x1004a11f0, msg=0x10047c698) at action.c:1145
ret = -5
v = <value optimized out>
dst = {send_sock = 0x1004a07f8, to = {s = {sa_family = 0, sa_data = "\000\001\000A?\200????\177??A"}, sin = {sin_family = 0, sin_port = 1, sin_addr = {
S_un = {S_un_b = {s_b1 = 0 '\000', s_b2 = 65 'A', s_b3 = 202 '?', s_b4 = 128 '\200'}, S_un_w = {s_w1 = 65, s_w2 = 51840}, S_addr = 4311680}},
sin_zero = "????\177??A"}, sin6 = {sin6_family = 0, sin6_port = 1, sin6_flowinfo = 4311680, sin6_addr = {_S6_un = {
_S6_u8 = "????\177??A\000\000\000\001\000\003??", _S6_u32 = {4294967295, 2147469633, 1, 238292}, __S6_align = 4294967295}},
sin6_scope_id = 4294967295, __sin6_src_id = 2060552320}}, id = -1, proto = 121 'y', send_flags = {f = 48 '0', blst_imask = 121 'y'}}
tmp = <value optimized out>
new_uri = <value optimized out>
end = <value optimized out>
crt = <value optimized out>
cmd = <value optimized out>
len = <value optimized out>
user = <value optimized out>
uri = {user = {s = 0x2b0 <Address 0x2b0 out of bounds>, len = -1}, passwd = {s = 0x7ffffc00 <Address 0x7ffffc00 out of bounds>, len = 0}, host = {
s = 0x2000 <Address 0x2000 out of bounds>, len = 1}, port = {s = 0x0, len = 0}, params = {s = 0xffffffff7ec3c000 "", len = 0}, sip_params = {
s = 0x6 <Address 0x6 out of bounds>, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, transport = {
s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0xffffffff7fffd260 "", len = 0}, maddr = {
s = 0x100420d30 "????~?s|????~?s|????~?s\200", len = 0}, method = {s = 0xffffffff78706ba8 "if", len = -1}, lr = {s = 0x100033330 "@", len = -1}, r2 = {
s = 0xffffffff7fffd29e "??????~?s|", len = -1}, gr = {s = 0xffffffff7fffd2b9 "???~?s|", len = -1}, transport_val = {s = 0xffffffff7fffffff "",
len = -1}, ttl_val = {s = 0x1 <Address 0x1 out of bounds>, len = -1}, user_param_val = {s = 0x4 <Address 0x4 out of bounds>, len = -1}, maddr_val = {
s = 0x2 <Address 0x2 out of bounds>, len = 0}, method_val = {s = 0xffffffff7be96d80 "", len = -1}, lr_val = {s = 0x1004a05d0 "", len = 1}, r2_val = {
s = 0xffffffff7fffd480 "????~?s}????\177???", len = 0}, gr_val = {s = 0x100000 <Address 0x100000 out of bounds>, len = -1}}
next_hop = {user = {s = 0x10002df90 "@", len = 1}, passwd = {s = 0x100216270 "%2d(%d) %s: %sCalling SELECT %p \n", len = 0}, host = {
s = 0x18f3d0 <Address 0x18f3d0 out of bounds>, len = 1}, port = {s = 0xffffffff7ec3c000 "", len = -1}, params = {
s = 0x1000279e0 "@\r\n`\232\021b\230\020o?\034?\027`\034\003", len = 1}, sip_params = {s = 0xffffffff7ec4737d " (=", len = 0}, headers = {
s = 0xffffffff7ffff400 "", len = 1}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, transport = {s = 0x0, len = -1}, ttl = {
s = 0xffffffff7fffd050 "", len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x1 <Address 0x1 out of bounds>, len = -1}, method = {
s = 0x100000 <Address 0x100000 out of bounds>, len = 0}, lr = {s = 0xffffffff7ec48084 "", len = 0}, r2 = {s = 0x2400 <Address 0x2400 out of bounds>,
len = 0}, gr = {s = 0xffffffff78706dc8 "%2d(%d) %s: %s c=[%s] l=%d a=%d n=%.*s\n", len = 0}, transport_val = {
s = 0x18f3d0 <Address 0x18f3d0 out of bounds>, len = -1}, ttl_val = {s = 0x37ffffff7ec3c000 <Address 0x37ffffff7ec3c000 out of bounds>, len = -1},
user_param_val = {s = 0xffffffff78704230 "@\004\016\224?s??\020o?\\?F\200", len = 1}, maddr_val = {s = 0xffffffff7ec48084 "", len = 0}, method_val = {
s = 0x0, len = 0}, lr_val = {s = 0x0, len = 1}, r2_val = {s = 0x1a <Address 0x1a out of bounds>, len = -1}, gr_val = {
s = 0x4d4 <Address 0x4d4 out of bounds>, len = 0}}
u = <value optimized out>
port = <value optimized out>
dst_host = <value optimized out>
i = <value optimized out>
flags = <value optimized out>
avp = <value optimized out>
st = {flags = 0, id = 0, name = {n = 0, s = {s = 0x1639 <Address 0x1639 out of bounds>, len = 1}, re = 0x1639}, avp = 0xffffffff787075d0}
sct = <value optimized out>
sjt = <value optimized out>
rve = <value optimized out>
mct = <value optimized out>
rv = <value optimized out>
rv1 = <value optimized out>
c1 = {cache_type = 4294967295, val_type = 2126803836, c = {avp_val = {n = 0, s = {s = 0x2 <Address 0x2 out of bounds>, len = -1}, re = 0x2}, pval = {rs = {
s = 0x2 <Address 0x2 out of bounds>, len = -1}, ri = -1, flags = 2021690136}}, i2s = "????x\200\201\230\000\000\000\001\000\067'@????x\200"}
s = {s = 0x1002200f0 "/opt/kamailio-3.2/etc/kamailio/kamailio.cfg", len = 0}
srevp = {0x1004a11f0, 0x10047c698}
mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE,
u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0,
str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0},
data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0,
---Type <return> to continue, or q <return> to quit---
select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {
type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0,
string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}}
#2 0x000000010002df98 in run_actions (h=0xffffffff7fffd250, a=0x1004a11f0, msg=0x10047c698) at action.c:1644
t = <value optimized out>
ret = <value optimized out>
mod = <value optimized out>
ms = 0
#3 0x00000001000381d0 in run_actions_safe (h=0xffffffff7ffff400, a=0x1004a11f0, msg=0x10047c698) at action.c:1708
ctx = {rec_lev = 1, run_flags = 0, last_retcode = 0, jmp_env = {2147470993, -2147497807, 4295157136, -2147497567, 4295197128, -2168160124, 4297161816, -1,
-2168163460, 1, 95, -2168163460}}
ret = 2147471952
ign_on_break = 0
#4 0x00000001000f15e8 in rval_get_int (h=0xffffffff7ffff400, msg=0x10047c698, i=0xffffffff7fffd770, rv=0x1004a1768, cache=0x0) at rvalue.c:920
r_avp = <value optimized out>
avp_val = {n = 0, s = {s = 0x0, len = -1}, re = 0x0}
pval = {rs = {s = 0x0, len = 0}, ri = 0, flags = 2147482624}
tmp = {s = 0x2520 <Address 0x2520 out of bounds>, len = 0}
s = 0x0
r = <value optimized out>
ret = 0
destroy_pval = 0
#5 0x00000001000f6d3c in rval_expr_eval_int (h=0xffffffff7ffff400, msg=0x10047c698, res=0xffffffff7fffd770, rve=0x1004a1760) at rvalue.c:1914
i1 = <value optimized out>
i2 = <value optimized out>
ret = -1
c1 = {cache_type = RV_CACHE_EMPTY, val_type = RV_NONE, c = {avp_val = {n = 0, s = {s = 0x7fffffff <Address 0x7fffffff out of bounds>, len = 0},
re = 0x7fffffff}, pval = {rs = {s = 0x7fffffff <Address 0x7fffffff out of bounds>, len = 0}, ri = 0, flags = 0}},
i2s = "????~?\200\204\000\000\000\000\000\000% \000\000\000\000\000"}
c2 = {cache_type = RV_CACHE_PVAR, val_type = 4328752, c = {avp_val = {n = -1, s = {s = 0xffffffff78706dc8 "%2d(%d) %s: %s c=[%s] l=%d a=%d n=%.*s\n",
len = 0}, re = 0xffffffff78706dc8}, pval = {rs = {s = 0xffffffff78706dc8 "%2d(%d) %s: %s c=[%s] l=%d a=%d n=%.*s\n", len = 0}, ri = 0,
flags = 1635280}}, i2s = "\000\000\000\000\000\000\001h????~??\000????\177?"}
rv1 = <value optimized out>
rv2 = <value optimized out>
#6 0x00000001000f6aac in rval_expr_eval_int (h=0xffffffff7ffff400, msg=0x10047c698, res=0xffffffff7fffdc10, rve=0x1004a1e30) at rvalue.c:1922
i1 = <value optimized out>
i2 = <value optimized out>
ret = -1
c1 = {cache_type = 4294967295, val_type = 2126807172, c = {avp_val = {n = 1, s = {
s = 0x100217c58 "%salert - action [%s (%d)] cfg [%s:%d] took too long [%u ms]\n", len = 0}, re = 0x100217c58}, pval = {rs = {
s = 0x100217c58 "%salert - action [%s (%d)] cfg [%s:%d] took too long [%u ms]\n", len = 0}, ri = 0, flags = 2147483647}},
i2s = "\000\000\000\000\177??\000\000\000\000\000\000\000\000\000????~?"}
c2 = {cache_type = RV_CACHE_EMPTY, val_type = 9504, c = {avp_val = {n = 0, s = {s = 0x2400 <Address 0x2400 out of bounds>, len = -1}, re = 0x2400},
pval = {rs = {s = 0x2400 <Address 0x2400 out of bounds>, len = -1}, ri = 0, flags = 1}},
i2s = "\000\000\000\000\177???\000\000\000\000\177??\000\000\000\000\000\000"}
rv1 = <value optimized out>
rv2 = <value optimized out>
#7 0x000000010002fce0 in do_action (h=0xffffffff7ffff400, a=0x1004a1460, msg=0x10047c698) at action.c:1121
ret = -5
v = <value optimized out>
dst = {send_sock = 0x1002200f0, to = {s = {sa_family = 0, sa_data = "\000\000\000\000\004\206\000\000\000\000\000\000\000\006"}, sin = {sin_family = 0,
sin_port = 0, sin_addr = {S_un = {S_un_b = {s_b1 = 0 '\000', s_b2 = 0 '\000', s_b3 = 4 '\004', s_b4 = 134 '\206'}, S_un_w = {s_w1 = 0, s_w2 = 1158},
S_addr = 1158}}, sin_zero = "\000\000\000\000\000\000\000\006"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 1158, sin6_addr = {
_S6_un = {_S6_u8 = "\000\000\000\000\000\000\000\006\000\000\000\000\000\000\000\005", _S6_u32 = {0, 6, 0, 5}, __S6_align = 0}},
sin6_scope_id = 4294967295, __sin6_src_id = 2020633376}}, id = 0, proto = 0 '\000', send_flags = {f = 0 '\000', blst_imask = 0 '\000'}}
tmp = <value optimized out>
new_uri = <value optimized out>
end = <value optimized out>
crt = <value optimized out>
cmd = <value optimized out>
len = <value optimized out>
user = <value optimized out>
uri = {user = {s = 0xffffffff7fffdb11 "", len = -1}, passwd = {s = 0x1001407f0 "\237?@", len = 0}, host = {s = 0x10048e13d "oexten)", len = 6}, port = {
s = 0x2400 <Address 0x2400 out of bounds>, len = -1}, params = {s = 0x10047c698 "", len = -1}, sip_params = {
s = 0xe00001632 <Address 0xe00001632 out of bounds>, len = 273}, headers = {s = 0x10048e13d "oexten)", len = 6}, port_no = 0, proto = 0,
type = ERROR_URI_T, flags = URI_USER_NORMALIZE, transport = {s = 0x600826ba0 <Address 0x600826ba0 out of bounds>, len = -1}, ttl = {
s = 0x9703b7265 <Address 0x9703b7265 out of bounds>, len = 1}, user_param = {s = 0x10048cfb8 "", len = 0}, maddr = {
s = 0xffff0001 <Address 0xffff0001 out of bounds>, len = -1}, method = {s = 0xffffffff7fffdb11 "", len = -1}, lr = {
---Type <return> to continue, or q <return> to quit---
s = 0x1000f215c "@\001\071Y\224\020", len = 0}, r2 = {s = 0x5c <Address 0x5c out of bounds>, len = 0}, gr = {s = 0xffffffff76666f68 "????vfo\030",
len = 1}, transport_val = {s = 0xe0 <Address 0xe0 out of bounds>, len = 0}, ttl_val = {s = 0x1 <Address 0x1 out of bounds>, len = 0},
user_param_val = {s = 0x7ffffc00 <Address 0x7ffffc00 out of bounds>, len = 0}, maddr_val = {s = 0xffffffff7ec48084 "", len = 0}, method_val = {
s = 0x2400 <Address 0x2400 out of bounds>, len = -1}, lr_val = {s = 0x10047c698 "", len = -1}, r2_val = {s = 0x10047c698 "", len = -1}, gr_val = {
s = 0xfffffffb7fffdae8 <Address 0xfffffffb7fffdae8 out of bounds>, len = -1}}
next_hop = {user = {s = 0x1000f23cc "\177???\232\a??\200? ", len = 1}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = -1},
params = {s = 0xffffffff7fffdb70 "", len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x1 <Address 0x1 out of bounds>, len = 0}, port_no = 0,
proto = 0, type = 2147482624, flags = 0, transport = {s = 0xffffffff7ec48084 "", len = 0}, ttl = {s = 0x2400 <Address 0x2400 out of bounds>, len = 1},
user_param = {s = 0xffffffff78706dc8 "%2d(%d) %s: %s c=[%s] l=%d a=%d n=%.*s\n", len = 0}, maddr = {s = 0x18f3d0 <Address 0x18f3d0 out of bounds>,
len = 0}, method = {s = 0xffffffff7ec3c000 "", len = -1}, lr = {s = 0xffffffff78704230 "@\004\016\224?s??\020o?\\?F\200", len = 1}, r2 = {
s = 0x100476226 "sip:nkeeling3 at 209.252.110.415080", len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 1}, ttl_val = {
s = 0x6 <Address 0x6 out of bounds>, len = 0}, user_param_val = {s = 0x486 <Address 0x486 out of bounds>, len = 0}, maddr_val = {
s = 0xffffffff7ec4737c ": (=", len = 0}, method_val = {s = 0xffffffff788076d0 "", len = -1}, lr_val = {s = 0xffffffff78808198 "????", len = 1},
r2_val = {s = 0xffffffff78808b38 "????vf??????vfi?", len = 1}, gr_val = {s = 0x10041ca80 "", len = -1}}
u = <value optimized out>
port = <value optimized out>
dst_host = <value optimized out>
i = <value optimized out>
flags = <value optimized out>
avp = <value optimized out>
st = {flags = 0, id = 0, name = {n = 4, s = {s = 0x400000106 <Address 0x400000106 out of bounds>, len = 0}, re = 0x400000106}, avp = 0x0}
sct = <value optimized out>
sjt = <value optimized out>
rve = 0x1004a1e30
mct = <value optimized out>
rv = <value optimized out>
rv1 = <value optimized out>
c1 = {cache_type = RV_CACHE_PVAR, val_type = 238292, c = {avp_val = {n = 0, s = {s = 0x0, len = 0}, re = 0x0}, pval = {rs = {s = 0x0, len = 0}, ri = 0,
flags = 7}}, i2s = "\000\000\000\000\000\000\026\071\000\000\000\001\000$?\230????xp"}
s = {s = 0x0, len = 0}
srevp = {0x1004a1460, 0x10047c698}
mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE,
u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0,
str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0},
data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0,
select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {
type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0,
string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}}
#8 0x000000010002df98 in run_actions (h=0xffffffff7ffff400, a=0x1004a0450, msg=0x10047c698) at action.c:1644
t = <value optimized out>
ret = <value optimized out>
mod = <value optimized out>
ms = 0
#9 0x000000010002f830 in do_action (h=0xffffffff7ffff400, a=0x1004943c0, msg=0x10047c698) at action.c:761
ret = -5
v = <value optimized out>
dst = {send_sock = 0x1002200f0, to = {s = {sa_family = 0, sa_data = "\000\000\000\000\003=\000\000\000\000\000\000\000\006"}, sin = {sin_family = 0,
sin_port = 0, sin_addr = {S_un = {S_un_b = {s_b1 = 0 '\000', s_b2 = 0 '\000', s_b3 = 3 '\003', s_b4 = 61 '='}, S_un_w = {s_w1 = 0, s_w2 = 829},
S_addr = 829}}, sin_zero = "\000\000\000\000\000\000\000\006"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 829, sin6_addr = {
_S6_un = {_S6_u8 = "\000\000\000\000\000\000\000\006\000\000\000\000\000\000\000\005", _S6_u32 = {0, 6, 0, 5}, __S6_align = 0}},
sin6_scope_id = 4294967295, __sin6_src_id = 2020633376}}, id = 0, proto = 0 '\000', send_flags = {f = 0 '\000', blst_imask = 36 '$'}}
tmp = <value optimized out>
new_uri = <value optimized out>
end = <value optimized out>
crt = <value optimized out>
cmd = <value optimized out>
len = <value optimized out>
user = <value optimized out>
uri = {user = {s = 0x4216a1 <Address 0x4216a1 out of bounds>, len = -1}, passwd = {s = 0x217ba8 <Address 0x217ba8 out of bounds>, len = 0}, host = {
s = 0x2000 <Address 0x2000 out of bounds>, len = -1}, port = {s = 0x3000000000 <Address 0x3000000000 out of bounds>, len = 0}, params = {
s = 0x14 <Address 0x14 out of bounds>, len = 0}, sip_params = {s = 0x5 <Address 0x5 out of bounds>, len = 0}, headers = {
s = 0x100420d30 "????~?s|????~?s|????~?s\200", len = 0}, port_no = 65535, proto = 65535, type = 2020633512, flags = 4294967295, transport = {
s = 0x100033330 "@", len = -1}, ttl = {s = 0xffffffff7fffe34e "??????~?s|", len = -1}, user_param = {s = 0xffffffff7fffe369 "???~?s|", len = -1},
maddr = {s = 0x7fffffff <Address 0x7fffffff out of bounds>, len = -1}, method = {s = 0xffffffff7ec4bf78 "-", len = -1}, lr = {
s = 0x100007f2d202b <Address 0x100007f2d202b out of bounds>, len = -1}, r2 = {s = 0x5a <Address 0x5a out of bounds>, len = 96}, gr = {
s = 0x2400 <Address 0x2400 out of bounds>, len = -1}, transport_val = {s = 0x1004665a8 "", len = 1}, ttl_val = {
s = 0x18f3d0 <Address 0x18f3d0 out of bounds>, len = 0}, user_param_val = {s = 0xffffffff7ffff400 "", len = -1}, maddr_val = {
s = 0x1000f15e0 "\177?\032?\220\020", len = -1}, method_val = {s = 0x1004665a8 "", len = 1}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0},
---Type <return> to continue, or q <return> to quit---
gr_val = {s = 0x100000000 "\177ELF\002\002\001", len = 0}}
next_hop = {user = {s = 0xffffffff7fffd5b1 "", len = 1}, passwd = {s = 0xffffffff7fffd6a1 "", len = 1}, host = {s = 0x0, len = 0}, port = {s = 0x0,
len = -1}, params = {s = 0xffffffff7fffe100 "", len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0,
type = 2147482624, flags = 0, transport = {s = 0xffffffff7ec48084 "", len = 0}, ttl = {s = 0x2400 <Address 0x2400 out of bounds>, len = 1},
user_param = {s = 0xffffffff78706dc8 "%2d(%d) %s: %s c=[%s] l=%d a=%d n=%.*s\n", len = 0}, maddr = {s = 0x18f3d0 <Address 0x18f3d0 out of bounds>,
len = 0}, method = {s = 0xffffffff7ec3c000 "", len = -1}, lr = {s = 0xffffffff78704230 "@\004\016\224?s??\020o?\\?F\200", len = 0}, r2 = {s = 0x0,
len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 1}, ttl_val = {s = 0x6 <Address 0x6 out of bounds>, len = 0}, user_param_val = {
s = 0x33d <Address 0x33d out of bounds>, len = 0}, maddr_val = {s = 0xffffffff7ec48084 "", len = 0}, method_val = {s = 0xffffffff788076d0 "",
len = -1}, lr_val = {s = 0xffffffff78808198 "????", len = 1}, r2_val = {s = 0xffffffff78808b38 "????vf??????vfi?", len = 1}, gr_val = {
s = 0x10041ca80 "", len = -1}}
u = <value optimized out>
port = <value optimized out>
dst_host = <value optimized out>
i = 12
flags = <value optimized out>
avp = <value optimized out>
st = {flags = 1, id = 66, name = {n = -1, s = {s = 0xffffffff7a9068d0 "%2d(%d) %s: %s%.*s", len = 1}, re = 0xffffffff7a9068d0}, avp = 0x18f3d0}
sct = <value optimized out>
sjt = <value optimized out>
rve = <value optimized out>
mct = <value optimized out>
rv = 0x0
rv1 = <value optimized out>
c1 = {cache_type = RV_CACHE_PVAR, val_type = 238292, c = {avp_val = {n = -1, s = {s = 0xffffffff7ec4737c ": (=", len = -1}, re = 0xffffffff7ec4737c},
pval = {rs = {s = 0xffffffff7ec4737c ": (=", len = -1}, ri = 0, flags = 7}}, i2s = "\000\000\000\000\000\000\026\071\000\000\000\001\000$?\230????xp"}
s = {s = 0x100140908 "@\b?\206\220\020", len = -1}
srevp = {0x1004943c0, 0x10047c698}
mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE,
u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0,
str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0},
data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0,
select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {
type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0,
string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}}
#10 0x000000010002df98 in run_actions (h=0xffffffff7ffff400, a=0x10048ca08, msg=0x10047c698) at action.c:1644
t = <value optimized out>
ret = <value optimized out>
mod = <value optimized out>
ms = 0
#11 0x000000010002f830 in do_action (h=0xffffffff7ffff400, a=0x10045e678, msg=0x10047c698) at action.c:761
ret = -5
v = <value optimized out>
dst = {send_sock = 0xffffffffffffffff, to = {s = {sa_family = 0, sa_data = "\000\000\000\000\000\000????\177??1"}, sin = {sin_family = 0, sin_port = 0,
sin_addr = {S_un = {S_un_b = {s_b1 = 0 '\000', s_b2 = 0 '\000', s_b3 = 0 '\000', s_b4 = 0 '\000'}, S_un_w = {s_w1 = 0, s_w2 = 0}, S_addr = 0}},
sin_zero = "????\177??1"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {_S6_un = {
_S6_u8 = "????\177??1\000\000\000\001\000\002??", _S6_u32 = {4294967295, 2147475505, 1, 195800}, __S6_align = 4294967295}},
sin6_scope_id = 4294967295, __sin6_src_id = 2020633512}}, id = 0, proto = 0 '\000', send_flags = {f = 0 '\000', blst_imask = 36 '$'}}
tmp = <value optimized out>
new_uri = <value optimized out>
end = <value optimized out>
crt = <value optimized out>
cmd = <value optimized out>
len = <value optimized out>
user = <value optimized out>
uri = {user = {s = 0x0, len = 0}, passwd = {s = 0x7ffffc00 <Address 0x7ffffc00 out of bounds>, len = 0}, host = {s = 0xffffffff7ec48084 "", len = 0},
port = {s = 0x2400 <Address 0x2400 out of bounds>, len = -1}, params = {s = 0x10047c698 "", len = -1}, sip_params = {s = 0x10045d210 "", len = 0},
headers = {s = 0xfc0 <Address 0xfc0 out of bounds>, len = -1}, port_no = 0, proto = 1, type = 1010996, flags = 4294967295, transport = {
s = 0x100033330 "@", len = 0}, ttl = {s = 0x25 <Address 0x25 out of bounds>, len = 1}, user_param = {s = 0x1 <Address 0x1 out of bounds>, len = 1},
maddr = {s = 0xd00420d30 <Address 0xd00420d30 out of bounds>, len = -1}, method = {s = 0x1 <Address 0x1 out of bounds>, len = -1}, lr = {
s = 0x4 <Address 0x4 out of bounds>, len = -1}, r2 = {s = 0x2 <Address 0x2 out of bounds>, len = 0}, gr = {s = 0x0, len = 1}, transport_val = {
s = 0xe0 <Address 0xe0 out of bounds>, len = 0}, ttl_val = {s = 0x1c <Address 0x1c out of bounds>, len = 0}, user_param_val = {
s = 0xffffffff7ec48084 "", len = 0}, maddr_val = {s = 0xffffffff788076d0 "", len = -1}, method_val = {s = 0x10047c698 "", len = -1}, lr_val = {
s = 0x10045d208 "", len = -1}, r2_val = {s = 0xec4 <Address 0xec4 out of bounds>, len = -1}, gr_val = {s = 0x1000f6aa4 "\177???\224\a???\222 ",
len = 0}}
next_hop = {user = {s = 0xffffffff7fffdb41 "", len = 1}, passwd = {s = 0xffffffff7fffdc31 "", len = 1}, host = {s = 0x0, len = 0}, port = {s = 0x0,
len = -1}, params = {s = 0xffffffff7fffe690 "????\177??", len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = -1}, port_no = 0,
proto = 0, type = 64, flags = 0, transport = {s = 0xffffffff7ec48084 "", len = 0}, ttl = {s = 0x2400 <Address 0x2400 out of bounds>, len = 1},
user_param = {s = 0xffffffff78706dc8 "%2d(%d) %s: %s c=[%s] l=%d a=%d n=%.*s\n", len = 0}, maddr = {s = 0x18f3d0 <Address 0x18f3d0 out of bounds>,
---Type <return> to continue, or q <return> to quit---
len = 0}, method = {s = 0xffffffff7ec3c000 "", len = -1}, lr = {s = 0xffffffff78704230 "@\004\016\224?s??\020o?\\?F\200", len = 1}, r2 = {
s = 0x10045b605 "oexten)", len = 6}, gr = {
s = 0x10089be5b "nkeeling3 at akanvoice.com SIP/2.0\r\nCall-ID: 709c8bdf3a590d1ff8707ff8a72bfb4e at 0.0.0.0\r\nCSeq: 2 INVITE\r\nFrom: \"N Keeling\" <sip:nkeeling at akanvoice.com>;tag=ed705cf4\r\nTo: <sip:nkeeling3 at akanvoice.com>\r\nMax-"..., len = 9}, transport_val = {s = 0x37 <Address 0x37 out of bounds>, len = 1},
ttl_val = {s = 0x11 <Address 0x11 out of bounds>, len = 0}, user_param_val = {s = 0x34c <Address 0x34c out of bounds>, len = 0}, maddr_val = {
s = 0xffffffff7ec48084 "", len = 0}, method_val = {s = 0xffffffff788076d0 "", len = -1}, lr_val = {s = 0xffffffff78808198 "????", len = 0}, r2_val = {
s = 0x7 <Address 0x7 out of bounds>, len = 0}, gr_val = {s = 0x7ffffc00 <Address 0x7ffffc00 out of bounds>, len = 0}}
u = <value optimized out>
port = <value optimized out>
dst_host = <value optimized out>
i = 9
flags = <value optimized out>
avp = <value optimized out>
st = {flags = 1, id = 66, name = {n = -1, s = {s = 0xffffffff7a9068d0 "%2d(%d) %s: %s%.*s", len = 0}, re = 0xffffffff7a9068d0}, avp = 0x18f3d0}
sct = <value optimized out>
sjt = <value optimized out>
rve = <value optimized out>
mct = <value optimized out>
rv = 0x0
rv1 = <value optimized out>
c1 = {cache_type = 4294967295, val_type = 2126807172, c = {avp_val = {n = 0, s = {s = 0x2520 <Address 0x2520 out of bounds>, len = -1}, re = 0x2520},
pval = {rs = {s = 0x2520 <Address 0x2520 out of bounds>, len = -1}, ri = -1, flags = 2147480576}},
i2s = "\000\000\000\001\000G?\230????\177???\000\000\000\001\000E"}
s = {s = 0x100140908 "@\b?\206\220\020", len = -1}
srevp = {0x10045e678, 0x10047c698}
mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE,
u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0,
str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0},
data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0,
select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {
type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0,
string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}}
#12 0x000000010002df98 in run_actions (h=0xffffffff7ffff400, a=0x10045cc58, msg=0x10047c698) at action.c:1644
t = <value optimized out>
ret = <value optimized out>
mod = <value optimized out>
ms = 0
#13 0x000000010002fd40 in do_action (h=0xffffffff7ffff400, a=0x100461548, msg=0x10047c698) at action.c:1136
ret = 1
v = 1
dst = {send_sock = 0x1002200f0, to = {s = {sa_family = 0, sa_data = "\000\000\000\000\002?\000\000\000\000\000\000\000\006"}, sin = {sin_family = 0,
sin_port = 0, sin_addr = {S_un = {S_un_b = {s_b1 = 0 '\000', s_b2 = 0 '\000', s_b3 = 2 '\002', s_b4 = 214 '?'}, S_un_w = {s_w1 = 0, s_w2 = 726},
S_addr = 726}}, sin_zero = "\000\000\000\000\000\000\000\006"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 726, sin6_addr = {
_S6_un = {_S6_u8 = "\000\000\000\000\000\000\000\006\000\000\000\000\000\000\000\005", _S6_u32 = {0, 6, 0, 5}, __S6_align = 0}},
sin6_scope_id = 4294967295, __sin6_src_id = 2020633376}}, id = -1, proto = 123 '{', send_flags = {f = 212 '?', blst_imask = 151 '\227'}}
tmp = <value optimized out>
new_uri = <value optimized out>
end = <value optimized out>
crt = <value optimized out>
cmd = <value optimized out>
len = <value optimized out>
user = <value optimized out>
uri = {user = {s = 0x4216a1 <Address 0x4216a1 out of bounds>, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 1}, port = {
s = 0x100451590 "", len = -1}, params = {s = 0x1000381c8 "\177??N?'?\223?\a?\223?: ", len = -1}, sip_params = {s = 0xffffffff7ec3c000 "", len = -1},
headers = {s = 0xffffffff7bd669f4 "@\004?\213?X`\200\020o??\001", len = -1}, port_no = 0, proto = 1, type = 1010996, flags = 0, transport = {s = 0x0,
len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x100420c30 "", len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {
s = 0x7ffffc00 <Address 0x7ffffc00 out of bounds>, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 1}, transport_val = {s = 0x0, len = 0},
ttl_val = {s = 0x1008817a8 '\001' <repeats 200 times>..., len = 1}, user_param_val = {
s = 0x1004216a1 " (((((", ' ' <repeats 18 times>, "H", '\020' <repeats 15 times>, "\204\204\204\204\204\204\204\204\204\204\020\020\020\020\020\020\020\201\201\201\201\201\201", '\001' <repeats 20 times>, "\020\020\020\020\020\020\202\202\202\202\202\202", '\002' <repeats 20 times>, "\020\020\020\020 ",
len = 1}, maddr_val = {s = 0x30 <Address 0x30 out of bounds>, len = 0}, method_val = {s = 0x1004bf167 "ip:nkeeling3 at 209.252.110.41", len = 0},
lr_val = {s = 0x0, len = -1}, r2_val = {s = 0xffffffff7bd685d4 "@\004?\223?X`\200\020o??\001", len = -1}, gr_val = {s = 0x0, len = 1}}
next_hop = {user = {s = 0x7fffe0d1 <Address 0x7fffe0d1 out of bounds>, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0,
len = -1}, params = {s = 0xffffffff7fffec20 "", len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = -1}, port_no = 0, proto = 0,
type = ERROR_URI_T, flags = 0, transport = {s = 0xffffffff7ec48084 "", len = 0}, ttl = {s = 0x2400 <Address 0x2400 out of bounds>, len = 1},
user_param = {s = 0xffffffff78706dc8 "%2d(%d) %s: %s c=[%s] l=%d a=%d n=%.*s\n", len = 0}, maddr = {s = 0x18f3d0 <Address 0x18f3d0 out of bounds>,
len = 0}, method = {s = 0xffffffff7ec3c000 "", len = -1}, lr = {s = 0xffffffff78704230 "@\004\016\224?s??\020o?\\?F\200", len = 0}, r2 = {s = 0x0,
len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 1}, ttl_val = {s = 0x6 <Address 0x6 out of bounds>, len = 0}, user_param_val = {
---Type <return> to continue, or q <return> to quit---
s = 0x2d6 <Address 0x2d6 out of bounds>, len = 0}, maddr_val = {s = 0x7 <Address 0x7 out of bounds>, len = 0}, method_val = {
s = 0xffffffff788076d0 "", len = -1}, lr_val = {s = 0xffffffff78808198 "????", len = 1}, r2_val = {s = 0xffffffff78808b38 "????vf??????vfi?",
len = 1}, gr_val = {s = 0x10041ca80 "", len = -1}}
u = <value optimized out>
port = <value optimized out>
dst_host = <value optimized out>
i = <value optimized out>
flags = <value optimized out>
avp = <value optimized out>
st = {flags = 0, id = 0, name = {n = 0, s = {s = 0x0, len = 0}, re = 0x0}, avp = 0x1639}
sct = <value optimized out>
sjt = <value optimized out>
rve = <value optimized out>
mct = <value optimized out>
rv = <value optimized out>
rv1 = <value optimized out>
c1 = {cache_type = RV_CACHE_PVAR, val_type = 238292, c = {avp_val = {n = 0, s = {s = 0x0, len = -1}, re = 0x0}, pval = {rs = {s = 0x0, len = -1}, ri = 0,
flags = 7}}, i2s = "\000\000\000\000\000\000\026\071\000\000\000\001\000$?\230????xp"}
s = {s = 0x100452b20 "", len = 0}
srevp = {0x100461548, 0x10047c698}
mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE,
u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0,
str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0},
data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0,
select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {
type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0,
string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}}
#14 0x000000010002df98 in run_actions (h=0xffffffff7ffff400, a=0x10045c190, msg=0x10047c698) at action.c:1644
t = <value optimized out>
ret = <value optimized out>
mod = <value optimized out>
ms = 0
#15 0x000000010002f830 in do_action (h=0xffffffff7ffff400, a=0x100455728, msg=0x10047c698) at action.c:761
ret = -5
v = <value optimized out>
dst = {send_sock = 0x0, to = {s = {sa_family = 0, sa_data = "\000\001\000%\220\000\000\000\000\000\000\000\000\a"}, sin = {sin_family = 0, sin_port = 1,
sin_addr = {S_un = {S_un_b = {s_b1 = 0 '\000', s_b2 = 37 '%', s_b3 = 144 '\220', s_b4 = 0 '\000'}, S_un_w = {s_w1 = 37, s_w2 = 36864},
S_addr = 2461696}}, sin_zero = "\000\000\000\000\000\000\000\a"}, sin6 = {sin6_family = 0, sin6_port = 1, sin6_flowinfo = 2461696, sin6_addr = {
_S6_un = {_S6_u8 = "\000\000\000\000\000\000\000\a\000\000\000\000\000\000\000", _S6_u32 = {0, 7, 0, 0}, __S6_align = 0}}, sin6_scope_id = 0,
__sin6_src_id = 1048576}}, id = 0, proto = 0 '\000', send_flags = {f = 16 '\020', blst_imask = 3 '\003'}}
tmp = <value optimized out>
new_uri = <value optimized out>
end = <value optimized out>
crt = <value optimized out>
cmd = <value optimized out>
len = <value optimized out>
user = <value optimized out>
uri = {user = {s = 0x3900000000000000 <Address 0x3900000000000000 out of bounds>, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0},
port = {s = 0x0, len = 1}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0,
type = ERROR_URI_T, flags = 0, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0},
method = {s = 0x0, len = 1}, lr = {
s = 0x10089c10f " 1017\r\nTH: dih\r\n\r\nv=0\r\no=nkeeling 0 0 IN IP4 192.168.1.151\r\ns=-\r\nc=IN IP4 192.168.1.151\r\nt=0 0\r\nm=audio 5020 RTP/AVP 9 96 97 98 100 0 8 102 3 103 5 6 4 101\r\na=rtpmap:9 G722/8000\r\na=rtpmap:96 SILK/2400"..., len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0},
transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {
s = 0x0, len = 1}, lr_val = {s = 0x6ba00000000 <Address 0x6ba00000000 out of bounds>, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0,
len = 0}}
next_hop = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0},
sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, transport = {s = 0x0, len = 0},
ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = -1}, r2 = {
s = 0xffffffff7ffff250 "", len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0xfffffffffffffffe <Address 0xfffffffffffffffe out of bounds>,
len = 0}, ttl_val = {s = 0x7ffffc00 <Address 0x7ffffc00 out of bounds>, len = 0}, user_param_val = {s = 0xffffffff7ec48084 "", len = 0}, maddr_val = {
s = 0x2400 <Address 0x2400 out of bounds>, len = 1}, method_val = {s = 0x100259768 "%2d(%d) %s: %send of header reached, state=%d\n", len = 0},
lr_val = {s = 0x18f3d0 <Address 0x18f3d0 out of bounds>, len = -1}, r2_val = {s = 0xffffffff7ec3c000 "", len = -1}, gr_val = {
s = 0x10018adbc "@\a}i\232\024?\230\020o?\225\202\024`\034\003", len = 1}}
u = <value optimized out>
port = <value optimized out>
dst_host = <value optimized out>
i = 2
---Type <return> to continue, or q <return> to quit---
flags = <value optimized out>
avp = <value optimized out>
st = {flags = 1, id = 137, name = {n = 1, s = {s = 0x10089c51a "", len = 1}, re = 0x10089c51a}, avp = 0x5}
sct = <value optimized out>
sjt = <value optimized out>
rve = <value optimized out>
mct = <value optimized out>
rv = 0x100420d30
rv1 = <value optimized out>
c1 = {cache_type = 4294967295, val_type = 2126757888, c = {avp_val = {n = -1, s = {s = 0xffffffff7fffe9e1 "", len = 1}, re = 0xffffffff7fffe9e1}, pval = {
rs = {s = 0xffffffff7fffe9e1 "", len = 1}, ri = 0, flags = 0}}, i2s = '\000' <repeats 15 times>, "\005\000\000\000\000\000\020"}
s = {s = 0x100478490 "", len = 1}
srevp = {0x100455728, 0x10047c698}
mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE,
u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0,
str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0},
data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0,
select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {
type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0,
string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}}
#16 0x000000010002df98 in run_actions (h=0xffffffff7ffff400, a=0x100447ee0, msg=0x10047c698) at action.c:1644
t = <value optimized out>
ret = <value optimized out>
mod = <value optimized out>
ms = 0
#17 0x000000010003823c in run_top_route (a=0x100447ee0, msg=0x10047c698, c=0x0) at action.c:1729
ctx = {rec_lev = 5, run_flags = 0, last_retcode = 1, jmp_env = {0, -2147489183, 4295157136, -2147488943, 4295197236, 4295153624, 7, 5689, 4297380792,
4297411808, 2, 4303994483}}
p = 0xffffffff7ffff400
ret = 4488928
sfbk = 0
#18 0x000000010002d1a8 in receive_msg (buf=<value optimized out>, len=<value optimized out>, rcv_info=<value optimized out>) at receive.c:209
msg = 0x10047c698
ctx = {rec_lev = 0, run_flags = 9504, last_retcode = 0, jmp_env = {77, 4297358768, 0, 1635280, 1049635, 77, -2147488351, 4296168208, 1049600, 103,
-2147488319, 4296149136}}
ret = <value optimized out>
inb = {
s = 0x10089be50 "INVITE sip:nkeeling3 at akanvoice.com SIP/2.0\r\nCall-ID: 709c8bdf3a590d1ff8707ff8a72bfb4e at 0.0.0.0\r\nCSeq: 2 INVITE\r\nFrom: \"N Keeling\" <sip:nkeeling at akanvoice.com>;tag=ed705cf4\r\nTo: <sip:nkeeling3 at akanvoice"..., len = 1738}
#19 0x0000000100125278 in receive_tcp_msg (con=0xffffffff766701c8, bytes_read=0xffffffff7ffff7e0, read_flags=0xffffffff7ffff7f0) at tcp_read.c:1044
buf = 0x10089be50 "INVITE sip:nkeeling3 at akanvoice.com SIP/2.0\r\nCall-ID: 709c8bdf3a590d1ff8707ff8a72bfb4e at 0.0.0.0\r\nCSeq: 2 INVITE\r\nFrom: \"N Keeling\" <sip:nkeeling at akanvoice.com>;tag=ed705cf4\r\nTo: <sip:nkeeling3 at akanvoice"...
bsize = 65535
#20 tcp_read_req (con=0xffffffff766701c8, bytes_read=0xffffffff7ffff7e0, read_flags=0xffffffff7ffff7f0) at tcp_read.c:1231
bytes = <value optimized out>
total_bytes = 1722
resp = 1
size = <value optimized out>
req = 0xffffffff76670250
dst = {send_sock = 0x1, to = {s = {sa_family = 65535, sa_data = "??\177???\000\000\000\004vgN\200"}, sin = {sin_family = 65535, sin_port = 65535,
sin_addr = {S_un = {S_un_b = {s_b1 = 127 '\177', s_b2 = 255 '?', s_b3 = 246 '?', s_b4 = 184 '?'}, S_un_w = {s_w1 = 32767, s_w2 = 63160},
S_addr = 2147481272}}, sin_zero = "\000\000\000\004vgN\200"}, sin6 = {sin6_family = 65535, sin6_port = 65535, sin6_flowinfo = 2147481272,
sin6_addr = {_S6_un = {_S6_u8 = "\000\000\000\004vgN\200????\177???", _S6_u32 = {4, 1986481792, 4294967295, 2147481560}, __S6_align = 4}},
sin6_scope_id = 0, __sin6_src_id = 8}}, id = 12, proto = 0 '\000', send_flags = {f = 1 '\001', blst_imask = 0 '\000'}}
c = 0 '\000'
ret = <value optimized out>
#21 0x000000010012613c in handle_io (fm=<value optimized out>, events=<value optimized out>, idx=0) at tcp_read.c:1461
ret = <value optimized out>
n = <value optimized out>
read_flags = 1
con = 0xffffffff766701c8
s = <value optimized out>
resp = <value optimized out>
t = <value optimized out>
#22 0x000000010012841c in io_wait_loop_devpoll (unix_sock=<value optimized out>) at io_wait.h:1405
dpoll = {dp_fds = 0x1004ba8b0, dp_nfds = 2, dp_timeout = 2000}
ret = 1
n = 1
---Type <return> to continue, or q <return> to quit---
r = <value optimized out>
fm = <value optimized out>
#23 tcp_receive_loop (unix_sock=<value optimized out>) at tcp_read.c:1594
No locals.
#24 0x00000001000bbe18 in tcp_init_children () at tcp_main.c:4952
r = <value optimized out>
i = <value optimized out>
reader_fd_1 = 20
pid = <value optimized out>
si_desc = "tcp receiver (generic)\000<\000\000\000\000\000\000\026\065\000\000\000\001\000A?\000????\177??a\000\000\000\001\000\006M\200\000\000\000\001\000\067h?\000\000\000\001\000C?p", '\000' <repeats 14 times>, "\026\062\000\000\000\001\000$??\000\000\000\001\000!??\000\000\000\000\000\000\000\000????xpiX\000\000\000\000\000\000\000"
si = <value optimized out>
#25 0x0000000100064db0 in main_loop () at main.c:1718
i = <value optimized out>
pid = <value optimized out>
si = <value optimized out>
si_desc = "udp receiver child=0 sock=209.252.110.38:5060\000??\000\000\000\001\000B9@\000\000\000\000\000\000\000\002????\177???\000\000\000\001\000\037z0\000\000\000\001\000$??\000\000\000\001\000#7H????????????????????????????????"
nrprocs = <value optimized out>
#26 0x00000001001f7b08 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:2546
cfg_stream = <value optimized out>
c = <value optimized out>
r = 1048576
tmp = 0x0
tmp_len = 0
options = 0x100221e60 ":f:cm:M:dVIhEb:l:L:n:vrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:"
seed = 253427269
rfd = <value optimized out>
debug_save = <value optimized out>
debug_flag = <value optimized out>
dont_fork_cnt = <value optimized out>
n_lst = 0x100000
p = <value optimized out>
(gdb)
From ushacked at gmail.com Thu Jul 12 10:48:12 2012
From: ushacked at gmail.com (Uri Shacked)
Date: Thu, 12 Jul 2012 11:48:12 +0300
Subject: [SR-Users] what exactly is "shmeme:fragments" ?
Message-ID: <CAMMbDhShwLO183UkTaYmZZ3CF_bzcS8CwzsOG90d+GN4rw1bvA@mail.gmail.com>
Hi,
can someone please explain a little about the "shmem" params that i see
when doing "kamctl fifo get_statistics shmeme:"
BR,
Uri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120712/6e6fa217/attachment.htm>
From aftnix at gmail.com Thu Jul 12 11:17:51 2012
From: aftnix at gmail.com (Aft nix)
Date: Thu, 12 Jul 2012 15:17:51 +0600
Subject: [SR-Users] sip over tls is not working
In-Reply-To: <a53dad8a511fa51269d81244f04cc5fd.squirrel@crocodile-rcs.com>
References: <a53dad8a511fa51269d81244f04cc5fd.squirrel@crocodile-rcs.com>
Message-ID: <CAGuaRCuK5bAxpuDxxDThdL7WwZkCmzJzdcKajq+Nxf0T=i0rBw@mail.gmail.com>
On Thu, Jul 12, 2012 at 1:33 AM, Peter Dunkley
<peter.dunkley at crocodile-rcs.com> wrote:
> Hi,
>
> I have just built Kamailio from Git master, configured TCP and TLS, and an
> HTTP event route. I was able to connect to Kamailio over TLS using Google
> Chrome (and saw the "SSL Error: The site's security certificate is not
> trusted!" page). After I clicked on "Proceed anyway" I saw the log
> message I put in the HTTP event route come out.
>
> I also logged in with Jitsi using TLS and that worked fine too.
>
> I tried this with both the WebSocket module loaded and without it, and it
> worked in both cases.
>
> I also tried the above with TCP and that worked fine as well.
>
> As far as I can tell TLS is working in Kamailio Git master.
>
> Regards,
>
> Peter
>
Thanks for the update. I've came to the same conclusion. I was going
to post my results
and saw your mail. Things are working for me right now. But i'm still
kind of puzzled why it didn't work earlier. Apart from a new "tcp"
listen directive i've not changed anything. i did a git pull though,
which showed some update in tcp_main. look at the diff of most recent
changes of tcp_main.c :(git diff $start $end -- tcp_main.c)
diff --git a/tcp_main.c b/tcp_main.c
index a6e3019..c5a2547 100644
--- a/tcp_main.c
+++ b/tcp_main.c
@@ -1427,7 +1427,7 @@ static inline void _tcpconn_free(struct tcp_connection* c)
#endif
lock_destroy(&c->write_lock);
#ifdef USE_TLS
- if (unlikely(c->type==PROTO_TLS || c->type==PROTO_WSS)) tls_tcpconn_clean(c);
+ if (unlikely(c->type==PROTO_TLS)) tls_tcpconn_clean(c);
#endif
shm_free(c);
}
@@ -1456,7 +1456,7 @@ void tcpconn_rm(struct tcp_connection* c)
TCPCONN_UNLOCK;
lock_destroy(&c->write_lock);
#ifdef USE_TLS
- if ((c->type==PROTO_TLS || c->type==PROTO_WSS)&&(c->extra_data))
tls_tcpconn_clean(c);
+ if ((c->type==PROTO_TLS)&&(c->extra_data)) tls_tcpconn_clean(c);
#endif
shm_free(c);
}
@@ -2270,7 +2270,7 @@ static int tcpconn_send_put(struct
tcp_connection* c, const char* buf,
{
do_close_fd=0;
#ifdef USE_TLS
- if (unlikely(c->type==PROTO_TLS || c->type==PROTO_WSS)) {
+ if (unlikely(c->type==PROTO_TLS)) {
t_buf = buf;
t_len = len;
do {
@@ -2372,7 +2372,7 @@ static int tcpconn_send_put(struct
tcp_connection* c, const char* buf,
}
#ifdef USE_TLS
- if (unlikely(c->type==PROTO_TLS || c->type==PROTO_WSS)) {
+ if (unlikely(c->type==PROTO_TLS)) {
/* for TLS the TLS processing and the send must happen
atomically w/ respect to other sends on the same connection
(otherwise reordering might occur which would break TLS) =>
@@ -2958,7 +2958,7 @@ inline static void tcpconn_close_main_fd(struct
tcp_connection* tcpconn)
fd=tcpconn->s;
#ifdef USE_TLS
- if (tcpconn->type==PROTO_TLS || tcpconn->type==PROTO_WSS)
+ if (tcpconn->type==PROTO_TLS)
tls_close(tcpconn, fd);
#endif
#ifdef TCP_FD_CACHE
@@ -3025,7 +3025,7 @@ inline static void tcpconn_destroy(struct
tcp_connection* tcpconn)
tcpconn_close_main_fd(tcpconn);
tcpconn->flags|=F_CONN_FD_CLOSED;
(*tcp_connections_no)--;
- if (unlikely(tcpconn->type==PROTO_TLS || tcpconn->type==PROTO_WSS))
+ if (unlikely(tcpconn->type==PROTO_TLS))
(*tls_connections_no)--;
}
_tcpconn_free(tcpconn); /* destroys also the wbuf_q if still present*/
@@ -3073,7 +3073,7 @@ inline static int tcpconn_put_destroy(struct
tcp_connection* tcpconn)
tcpconn_close_main_fd(tcpconn);
tcpconn->flags|=F_CONN_FD_CLOSED;
(*tcp_connections_no)--;
- if (unlikely(tcpconn->type==PROTO_TLS || tcpconn->type==PROTO_WSS))
+ if (unlikely(tcpconn->type==PROTO_TLS))
(*tls_connections_no)--;
}
/* all the flags / ops on the tcpconn must be done prior to decrementing
@@ -4509,7 +4509,7 @@ static inline void tcpconn_destroy_all(void)
fd=-1;
}
#ifdef USE_TLS
- if (fd>0 && (c->type==PROTO_TLS || c->type==PROTO_WSS))
+ if (fd>0 && c->type==PROTO_TLS)
tls_close(c, fd);
#endif
_tcpconn_rm(c);
@@ -4522,7 +4522,7 @@ static inline void tcpconn_destroy_all(void)
tcp_safe_close(fd);
}
(*tcp_connections_no)--;
- if (unlikely(c->type==PROTO_TLS || c->type==PROTO_WSS))
+ if (unlikely(c->type==PROTO_TLS))
(*tls_connections_no)--;
c=next;
}
I don't know if that changed anything.
Most likely i have done something silly which i am not finding at this moment.
Whatever, as things work so the thread should be marked SOLVED. Though
it irks me that i still dont know, what went wrong.
Cheers.
>
>> On Wed, Jul 11, 2012 at 9:37 PM, Peter Dunkley
>> <peter.dunkley at crocodile-rcs.com> wrote:
>>>
>>> Hi,
>>>
>>> WebSockets over TLS works which requires establishing a TLS connection
>>> and
>>> exchanging an HTTP request and response. It doesn't sound like this
>>> connection is even getting passed the TLS handshake part?
>>>
>>> Peter
>>>
>>
>> Hi,
>> That was my first guess. I will run some tests with plain tcp socket
>> and post update.
>>
>> cheers.
>>
>>>
>>> On Wed, 2012-07-11 at 17:14 +0200, Klaus Darilion wrote:
>>>
>>> Maybe there were some changes fore websocket support which cause
>>> problems. Do plain TCP connections work?
>>>
>>> klaus
>>>
>>> On 11.07.2012 16:20, Aft nix wrote:
>>> > On Wed, Jul 11, 2012 at 6:56 PM, Klaus Darilion
>>> > <klaus.mailinglists at pernau.at> wrote:
>>> >> I just tested TLS with Kamailio 3.3.0 and Eyebeam and it works. Make
>>> >> sure to
>>> >> specify "ca_list" if intermediate certificates are used.
>>> >>
>>> >
>>> > I was working with master branch, not 3.3 branch.
>>> >
>>> >>
>>> >> regards
>>> >> Klaus
>>> >>
>>> >> On 09.07.2012 13:27, Aft nix wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> I have enabled tls parameters as follows:
>>> >>>
>>> >>> in kamailio.cfg
>>> >>>
>>> >>> listen = tls:<IP>:<PORT>
>>> >>>
>>> >>> in tls.cfg
>>> >>>
>>> >>> [server:<IP>:<PORT>]
>>> >>> method = TLSv1
>>> >>> verify_certificate = no
>>> >>> require_certificate = no
>>> >>> private_key = /usr/local/etc/kamailio/kamailio-selfsigned.key
>>> >>> certificate = /usr/local/etc/kamailio/
>>> kamailio-selfsigned.pem
>>> >>>
>>> >>> Now if i try to connect to this interface using openssl s_client, it
>>> >>> does connects,
>>> >>> but now server certificate is sent from kamailio.
>>> >>>
>>> >>> kamailio log shows this :
>>> >>>
>>> >>> <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: <CLIENT
>>> >>> IP>
>>> >>> <core> [tcp_main.c:10
>
--
-aft
From jianjun365222 at gmail.com Fri Jul 13 04:37:07 2012
From: jianjun365222 at gmail.com (mike)
Date: Fri, 13 Jul 2012 10:37:07 +0800
Subject: [SR-Users] the 200 ok reply not include supported header
Message-ID: <CAOfBJcyVN_h=DY1q5ZXp7UBb3h2vMkiEV_ft9QSf3o4xk9XvCQ@mail.gmail.com>
Hi all:
i have the server loaded the path model , but the 200 ok didn't include
the "Supported" header filed .
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob at example.com>;tag=7F94778B653B
To: Bob <sip:bob at example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob at 192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
From: Bob <sip:bob at example.com>;tag=7F94778B653B
To: Bob <sip:bob at example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound (---------this line is not include-------------)
Require: outbound
Contact: <sip:bob at 192.0.2.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/
how could i fix it ?
thanks
mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120713/73b99f1c/attachment.htm>
From george at polarismail.com Fri Jul 13 05:46:49 2012
From: george at polarismail.com (George Breahna)
Date: Thu, 12 Jul 2012 23:46:49 -0400
Subject: [SR-Users] Kamailio + dialog + dispatcher (limiting calls)
Message-ID: <010d01cd60aa$2273e5a0$675bb0e0$@com>
I am trying to limit the total number of concurrent calls processed by
Kamailio and I'm having a world of trouble.
We are running Kamailio 3.2.3 on Debian Squeeze with the dispatcher module
and recently enabled the dialog module. The call flow is extremely simple.
We have two Asterisk servers to which we load balance the incoming calls to,
nothing more.
Our dialog configuration is the default kamailio config, with the following
additions:
modparam("dialog", "enable_stats", 1)
modparam("dialog", "dlg_flag", FLD_DLG)
modparam("dialog", "hash_size", 4096)
modparam("dialog", "profiles_with_value", "callquota")
modparam("dialog", "default_timeout", 300)
modparam("dialog", "dlg_match_mode",2)
modparam("dialog", "detect_spirals", 1)
modparam("dialog", "db_mode", 0)
in request_route we have:
if ( method=="INVITE" ) {
t_on_failure("FAIL_ONE");
ds_select_dst("1","4");
# sl_send_reply("100","Trying");
t_reply("100", "Trying");
dlg_manage();
setflag(FLT_ACC); # do accounting
$var(SIZE) = 0;
get_profile_size("callquota", "$rU", "$var(SIZE)");
if( $var(SIZE) >= MAX_NUMBER_OF_CALLS ){
xlog("DEBUG: Simultaneous calls limit reached for
$rU: $var(SIZE)\n");
sl_send_reply("503", "Simultaneous calls limit
reached");
exit;
}
set_dlg_profile("callquota","$rU");
if (get_profile_size("callquota","$var(SIZE)")) {
xlog("DEBUG: there are $var(SIZE) total calls for
$rU\n");
}
forward();#uri:host, uri:port);
exit();
}
We also added a dlg_manage() in WITHINDLG
if (is_method("BYE")) {
dlg_manage();
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
}
The problem is that some dialogs never get erased. Their total number always
increases and their state is always 1
kamctl fifo profile_list_dlgs callquota
dialog:: hash=2161:28334339
state:: 1
ref_count:: 1
timestart:: 0
timeout:: 0
In the debug logs I see these entries for the dialog module:
### Starting Call
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: ERROR: *** cfgtrace:
c=[/etc/kamailio/kamailio.cfg] l=515 a=25 n=dlg_manage
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:523]: no dialog callid='1560428909_26358995 at 4.55.13.227' found
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:523]: no dialog callid='1560428909_26358995 at 4.55.13.227' found
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:553]: no dialog callid='1560428909_26358995 at 4.55.13.227' found
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:309]: new dialog on hash 2161
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_handlers.c:271]: route_set <sip:1.2.3.4;lr=on>, contact
sip:+118884936245 at 4.55.13.227:5060, cseq 402 and bind_addr
udp:10.10.10.1:5060
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:583]: ref dlg 0x7feb80ef0ae8 with 1 -> 1
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:603]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: ERROR: *** cfgtrace:
c=[/etc/kamailio/kamailio.cfg] l=525 a=27 n=set_dlg_profile
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:459]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:461]: dialog id=28334339 found on entry 2161
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:514]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:517]: dialog callid='1560428909_26358995 at 4.55.13.227' found#012
on entry 2161, dir=1
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: CRITICAL: dialog
[dlg_hash.c:650]: bogus event 6 in state 1 for dlg 0x7feb80ef0ae8
[2161:28334339] with clid '1560428909_26358995 at 4.55.13.227' and tags
'gK0251b91f' ''
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:808]: dialog 0x7feb80ef0ae8 changed from state 1 to state 1, due
event 6 (ref 2)
Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
[dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
### Hanging up now
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25456]: DEBUG: tm [uac.c:182]:
DEBUG: dlg2hash: 29877
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25456]: DEBUG: tm [uac.c:182]:
DEBUG: dlg2hash: 29874
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
[dlg_hash.c:514]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
[dlg_hash.c:517]: dialog callid='1560428909_26358995 at 4.55.13.227' found#012
on entry 2161, dir=1
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: CRITICAL: dialog
[dlg_hash.c:650]: bogus event 7 in state 1 for dlg 0x7feb80ef0ae8
[2161:28334339] with clid '1560428909_26358995 at 4.55.13.227' and tags
'gK0251b91f' ''
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
[dlg_hash.c:808]: dialog 0x7feb80ef0ae8 changed from state 1 to state 1, due
event 7 (ref 2)
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
[dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: ERROR: *** cfgtrace:
c=[/etc/kamailio/kamailio.cfg] l=625 a=25 n=dlg_manage
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
[dlg_hash.c:459]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
[dlg_hash.c:461]: dialog id=28334339 found on entry 2161
Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
[dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
Is my config wrong ? Am I missing anything here ? Any advice would be much
appreciated
Thank you,
George
From klaus.mailinglists at pernau.at Fri Jul 13 09:11:14 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Fri, 13 Jul 2012 09:11:14 +0200
Subject: [SR-Users] the 200 ok reply not include supported header
In-Reply-To: <CAOfBJcyVN_h=DY1q5ZXp7UBb3h2vMkiEV_ft9QSf3o4xk9XvCQ@mail.gmail.com>
References: <CAOfBJcyVN_h=DY1q5ZXp7UBb3h2vMkiEV_ft9QSf3o4xk9XvCQ@mail.gmail.com>
Message-ID: <4FFFCA12.6070004@pernau.at>
Workaround:
http://kamailio.org/docs/modules/3.3.x/modules_k/textops.html#id2496649
append_to_reply("Supported: path, outbound\r\n");
regards
Klaus
On 13.07.2012 04:37, mike wrote:
> Hi all:
>
> i have the server loaded the path model , but the 200 ok didn't
> include the "Supported" header filed .
>
>
> REGISTER sip:example.com <http://example.com> SIP/2.0
>
> Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
>
> Max-Forwards: 70
>
> From: Bob <sip:bob at example.com
> <mailto:sip%3Abob at example.com>>;tag=7F94778B653B
>
> To: Bob <sip:bob at example.com <mailto:sip%3Abob at example.com>>
>
> Call-ID: 16CB75F21C70
>
> CSeq: 1 REGISTER
>
> Supported: path, outbound
>
> Route: <sip:ep1.example.com <http://ep1.example.com>;lr>
>
> Contact: <sip:bob at 192.0.2.2
> <mailto:sip%3Abob at 192.0.2.2>;transport=tcp>;reg-id=1
>
> ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
>
> Content-Length: 0
>
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi
>
> Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
>
> From: Bob <sip:bob at example.com
> <mailto:sip%3Abob at example.com>>;tag=7F94778B653B
>
> To: Bob <sip:bob at example.com
> <mailto:sip%3Abob at example.com>>;tag=6AF99445E44A
>
> Call-ID: 16CB75F21C70
>
> CSeq: 1 REGISTER
>
> Supported: path, outbound (---------this line is not include-------------)
>
> Require: outbound
>
> Contact: <sip:bob at 192.0.2.2
> <mailto:sip%3Abob at 192.0.2.2>;transport=tcp>;reg-id=1;expires=3600
>
> ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
>
> Path: <sip:VskztcQ/
>
>
> how could i fix it ?
>
>
> thanks
>
>
> mike
>
>
>
> _______________________________________________
> 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
>
From miconda at gmail.com Fri Jul 13 09:33:26 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Fri, 13 Jul 2012 09:33:26 +0200
Subject: [SR-Users] preparing release of v3.1.6
Message-ID: <4FFFCF46.2070508@gmail.com>
Hello,
later today I plan to package v3.1.6 as the last release in 3.1.x
series. Based on our release policy to work on latest two stable
branches, 3.1 got out of by release of 3.3.0.
The branch 3.1 may still get patches, it is not a closed branch, but it
is a matter of developers for willing to do that -- it is just not going
to be packaged again in a numbered release, so people will have to use
git branch.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Fri Jul 13 09:50:53 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Fri, 13 Jul 2012 09:50:53 +0200
Subject: [SR-Users] Kamailio + dialog + dispatcher (limiting calls)
In-Reply-To: <010d01cd60aa$2273e5a0$675bb0e0$@com>
References: <010d01cd60aa$2273e5a0$675bb0e0$@com>
Message-ID: <4FFFD35D.7000807@gmail.com>
Hello,
you have to use t_relay() instead of forward() -- some of the operations
are done on transaction callbacks for replies. Try this way and if still
troubles, let us know.
Cheers,
Daniel
On 7/13/12 5:46 AM, George Breahna wrote:
> I am trying to limit the total number of concurrent calls processed by
> Kamailio and I'm having a world of trouble.
>
> We are running Kamailio 3.2.3 on Debian Squeeze with the dispatcher module
> and recently enabled the dialog module. The call flow is extremely simple.
> We have two Asterisk servers to which we load balance the incoming calls to,
> nothing more.
>
> Our dialog configuration is the default kamailio config, with the following
> additions:
>
> modparam("dialog", "enable_stats", 1)
> modparam("dialog", "dlg_flag", FLD_DLG)
> modparam("dialog", "hash_size", 4096)
> modparam("dialog", "profiles_with_value", "callquota")
> modparam("dialog", "default_timeout", 300)
> modparam("dialog", "dlg_match_mode",2)
> modparam("dialog", "detect_spirals", 1)
> modparam("dialog", "db_mode", 0)
>
> in request_route we have:
>
> if ( method=="INVITE" ) {
> t_on_failure("FAIL_ONE");
> ds_select_dst("1","4");
> # sl_send_reply("100","Trying");
> t_reply("100", "Trying");
>
> dlg_manage();
> setflag(FLT_ACC); # do accounting
> $var(SIZE) = 0;
> get_profile_size("callquota", "$rU", "$var(SIZE)");
> if( $var(SIZE) >= MAX_NUMBER_OF_CALLS ){
> xlog("DEBUG: Simultaneous calls limit reached for
> $rU: $var(SIZE)\n");
> sl_send_reply("503", "Simultaneous calls limit
> reached");
> exit;
> }
>
> set_dlg_profile("callquota","$rU");
>
> if (get_profile_size("callquota","$var(SIZE)")) {
> xlog("DEBUG: there are $var(SIZE) total calls for
> $rU\n");
> }
>
>
> forward();#uri:host, uri:port);
> exit();
> }
>
> We also added a dlg_manage() in WITHINDLG
>
> if (is_method("BYE")) {
> dlg_manage();
> setflag(FLT_ACC); # do accounting ...
> setflag(FLT_ACCFAILED); # ... even if the transaction fails
> }
>
> The problem is that some dialogs never get erased. Their total number always
> increases and their state is always 1
>
> kamctl fifo profile_list_dlgs callquota
> dialog:: hash=2161:28334339
> state:: 1
> ref_count:: 1
> timestart:: 0
> timeout:: 0
> In the debug logs I see these entries for the dialog module:
>
> ### Starting Call
>
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: ERROR: *** cfgtrace:
> c=[/etc/kamailio/kamailio.cfg] l=515 a=25 n=dlg_manage
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:523]: no dialog callid='1560428909_26358995 at 4.55.13.227' found
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:523]: no dialog callid='1560428909_26358995 at 4.55.13.227' found
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:553]: no dialog callid='1560428909_26358995 at 4.55.13.227' found
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:309]: new dialog on hash 2161
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_handlers.c:271]: route_set <sip:1.2.3.4;lr=on>, contact
> sip:+118884936245 at 4.55.13.227:5060, cseq 402 and bind_addr
> udp:10.10.10.1:5060
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:583]: ref dlg 0x7feb80ef0ae8 with 1 -> 1
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:603]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: ERROR: *** cfgtrace:
> c=[/etc/kamailio/kamailio.cfg] l=525 a=27 n=set_dlg_profile
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:459]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:461]: dialog id=28334339 found on entry 2161
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:514]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:517]: dialog callid='1560428909_26358995 at 4.55.13.227' found#012
> on entry 2161, dir=1
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: CRITICAL: dialog
> [dlg_hash.c:650]: bogus event 6 in state 1 for dlg 0x7feb80ef0ae8
> [2161:28334339] with clid '1560428909_26358995 at 4.55.13.227' and tags
> 'gK0251b91f' ''
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:808]: dialog 0x7feb80ef0ae8 changed from state 1 to state 1, due
> event 6 (ref 2)
> Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
>
>
> ### Hanging up now
>
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25456]: DEBUG: tm [uac.c:182]:
> DEBUG: dlg2hash: 29877
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25456]: DEBUG: tm [uac.c:182]:
> DEBUG: dlg2hash: 29874
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> [dlg_hash.c:514]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> [dlg_hash.c:517]: dialog callid='1560428909_26358995 at 4.55.13.227' found#012
> on entry 2161, dir=1
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: CRITICAL: dialog
> [dlg_hash.c:650]: bogus event 7 in state 1 for dlg 0x7feb80ef0ae8
> [2161:28334339] with clid '1560428909_26358995 at 4.55.13.227' and tags
> 'gK0251b91f' ''
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> [dlg_hash.c:808]: dialog 0x7feb80ef0ae8 changed from state 1 to state 1, due
> event 7 (ref 2)
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: ERROR: *** cfgtrace:
> c=[/etc/kamailio/kamailio.cfg] l=625 a=25 n=dlg_manage
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> [dlg_hash.c:459]: ref dlg 0x7feb80ef0ae8 with 1 -> 2
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> [dlg_hash.c:461]: dialog id=28334339 found on entry 2161
> Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
>
>
> Is my config wrong ? Am I missing anything here ? Any advice would be much
> appreciated
>
> Thank you,
> George
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Fri Jul 13 10:05:13 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Fri, 13 Jul 2012 10:05:13 +0200
Subject: [SR-Users] failure route correct..?
In-Reply-To: <4FFDC8E1.9080902@online.nl>
References: <4FFDC8E1.9080902@online.nl>
Message-ID: <4FFFD6B9.2050709@gmail.com>
Hello,
one audio problem is due to nat issues -- be sure you engage rtpproxy
for this call in the failure route, if you didn't do it at all.
A ngrep trace of the call may help spotting if that is the case or not.
Cheers,
Daniel
On 7/11/12 8:41 PM, Gertjan Wolzak wrote:
> Hello All,
>
> I am trying to get a failure route to work, I have got it working
> partially.
>
> When a call comes in, first I check the db_alias, if that is positive
> I do a lookup location and relay if the location is valid.
>
> But sometimes the sip client is still registered in the location
> table, but not connected anymore, mainly with wifi connected clients.
>
> So, I have got the time out on 3 seconds (fr_timer). When that hits I
> have configured the following failure route:
>
>
> failure_route[NOTONLINE]
> {
>
> xlog("SCRIPT: Notonline failure route\n");
>
> t_on_failure("STOP");
>
> if (t_is_canceled())
> {
> exit;
> }
>
> if (t_check_status("408"))
> {
> xlog("SCRIPT: Status is time out");
> $rU = $avp(orig_called); /( called number and alias id
> not equal, so have to revert the rU back to the called number)/
> prefix("9993"); /( needed to get the right
> manipulation done within asterisk)/
> xlog("SCRIPT: uri is $ru");
> $ru = "sip:" + $rU + "@w.x.y.x:5060";
> xlog("SCRIPT: uri is $ru"); (w.x.y.z ip address of the
> asterisk box)
> append_branch();
> t_relay_to_udp("w.x.y.x","5060");
> break;
> }
> }
>
>
> I am not sure if the above is correct. I have based this on an old
> "voicemail" failure route I could find.
>
> It is working correct, the call is forwarded to an Asterisk box, where
> some manipulation is done and then send to an pstn gateway.
>
> The only problem I have is one way audio. RTP from the called number
> reaches the callee but not vice versa.
>
> Now I am wondering, can that be caused by the failure route, or should
> I be looking in another direction?
>
> Hope someone can give me a pointer.
>
> Thanks.
>
> Gertjan Wolzak
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120713/af839b35/attachment.htm>
From miconda at gmail.com Fri Jul 13 10:42:57 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Fri, 13 Jul 2012 10:42:57 +0200
Subject: [SR-Users] what exactly is "shmeme:fragments" ?
In-Reply-To: <CAMMbDhShwLO183UkTaYmZZ3CF_bzcS8CwzsOG90d+GN4rw1bvA@mail.gmail.com>
References: <CAMMbDhShwLO183UkTaYmZZ3CF_bzcS8CwzsOG90d+GN4rw1bvA@mail.gmail.com>
Message-ID: <4FFFDF91.90903@gmail.com>
Hello,
On 7/12/12 10:48 AM, Uri Shacked wrote:
> Hi,
> can someone please explain a little about the "shmem" params that i
> see when doing "kamctl fifo get_statistics shmeme:"
cannot remember all by hart at this moment, but you get there the value
of shared memory, how much is effectively used (data stored in memory),
how much is actually (real) used due to overhead of memory chunks (each
chunk has some extra fields, e.g., linking to next chunk, etc.) and the
number of fragments (how many structures are stored in shared memory,
e.g., if you do $shv(x) = "abc"; then "abc" will be stored in a memory
chunk, creating one fragment for it and the second will be with the
remaining free space).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From george at polarismail.com Fri Jul 13 15:14:14 2012
From: george at polarismail.com (George Breahna)
Date: Fri, 13 Jul 2012 09:14:14 -0400
Subject: [SR-Users] Kamailio + dialog + dispatcher (limiting calls)
In-Reply-To: <4FFFD35D.7000807@gmail.com>
References: <010d01cd60aa$2273e5a0$675bb0e0$@com> <4FFFD35D.7000807@gmail.com>
Message-ID: <005301cd60f9$66f83c40$34e8b4c0$@com>
Thank you very much... that did it!
George
> -----Original Message-----
> From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
> Sent: Friday, July 13, 2012 3:51 AM
> To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> Users Mailing List
> Cc: George Breahna
> Subject: Re: [SR-Users] Kamailio + dialog + dispatcher (limiting calls)
>
> Hello,
>
> you have to use t_relay() instead of forward() -- some of the
> operations are done on transaction callbacks for replies. Try this way
> and if still troubles, let us know.
>
> Cheers,
> Daniel
>
> On 7/13/12 5:46 AM, George Breahna wrote:
> > I am trying to limit the total number of concurrent calls processed
> by
> > Kamailio and I'm having a world of trouble.
> >
> > We are running Kamailio 3.2.3 on Debian Squeeze with the dispatcher
> > module and recently enabled the dialog module. The call flow is
> extremely simple.
> > We have two Asterisk servers to which we load balance the incoming
> > calls to, nothing more.
> >
> > Our dialog configuration is the default kamailio config, with the
> > following
> > additions:
> >
> > modparam("dialog", "enable_stats", 1)
> > modparam("dialog", "dlg_flag", FLD_DLG) modparam("dialog",
> > "hash_size", 4096) modparam("dialog", "profiles_with_value",
> > "callquota") modparam("dialog", "default_timeout", 300)
> > modparam("dialog", "dlg_match_mode",2) modparam("dialog",
> > "detect_spirals", 1) modparam("dialog", "db_mode", 0)
> >
> > in request_route we have:
> >
> > if ( method=="INVITE" ) {
> > t_on_failure("FAIL_ONE");
> > ds_select_dst("1","4");
> > # sl_send_reply("100","Trying");
> > t_reply("100", "Trying");
> >
> > dlg_manage();
> > setflag(FLT_ACC); # do accounting
> > $var(SIZE) = 0;
> > get_profile_size("callquota", "$rU", "$var(SIZE)");
> > if( $var(SIZE) >= MAX_NUMBER_OF_CALLS ){
> > xlog("DEBUG: Simultaneous calls limit
> reached
> > for
> > $rU: $var(SIZE)\n");
> > sl_send_reply("503", "Simultaneous calls
> > limit reached");
> > exit;
> > }
> >
> > set_dlg_profile("callquota","$rU");
> >
> > if (get_profile_size("callquota","$var(SIZE)")) {
> > xlog("DEBUG: there are $var(SIZE) total
> calls
> > for $rU\n");
> > }
> >
> >
> > forward();#uri:host, uri:port);
> > exit();
> > }
> >
> > We also added a dlg_manage() in WITHINDLG
> >
> > if (is_method("BYE")) {
> > dlg_manage();
> > setflag(FLT_ACC); # do accounting ...
> > setflag(FLT_ACCFAILED); # ... even if the transaction fails }
> >
> > The problem is that some dialogs never get erased. Their total number
> > always increases and their state is always 1
> >
> > kamctl fifo profile_list_dlgs callquota
> > dialog:: hash=2161:28334339
> > state:: 1
> > ref_count:: 1
> > timestart:: 0
> > timeout:: 0
> > In the debug logs I see these entries for the dialog module:
> >
> > ### Starting Call
> >
> > Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: ERROR: ***
> cfgtrace:
> > c=[/etc/kamailio/kamailio.cfg] l=515 a=25 n=dlg_manage Jul 12
> 22:38:34
> > debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:523]: no dialog callid='1560428909_26358995 at 4.55.13.227'
> > found Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG:
> dialog
> > [dlg_hash.c:523]: no dialog callid='1560428909_26358995 at 4.55.13.227'
> > found Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG:
> dialog
> > [dlg_hash.c:553]: no dialog callid='1560428909_26358995 at 4.55.13.227'
> > found Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG:
> dialog
> > [dlg_hash.c:309]: new dialog on hash 2161 Jul 12 22:38:34 debian1
> > /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_handlers.c:271]: route_set <sip:1.2.3.4;lr=on>, contact
> > sip:+118884936245 at 4.55.13.227:5060, cseq 402 and bind_addr
> > udp:10.10.10.1:5060
> > Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:583]: ref dlg 0x7feb80ef0ae8 with 1 -> 1 Jul 12 22:38:34
> > debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:603]: ref dlg 0x7feb80ef0ae8 with 1 -> 2 Jul 12 22:38:34
> > debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1 Jul 12
> 22:38:34
> > debian1 /usr/sbin/kamailio[25452]: ERROR: *** cfgtrace:
> > c=[/etc/kamailio/kamailio.cfg] l=525 a=27 n=set_dlg_profile Jul 12
> > 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:459]: ref dlg 0x7feb80ef0ae8 with 1 -> 2 Jul 12 22:38:34
> > debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:461]: dialog id=28334339 found on entry 2161 Jul 12
> > 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1 Jul 12
> 22:38:34
> > debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:514]: ref dlg 0x7feb80ef0ae8 with 1 -> 2 Jul 12 22:38:34
> > debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:517]: dialog callid='1560428909_26358995 at 4.55.13.227'
> > found#012 on entry 2161, dir=1 Jul 12 22:38:34 debian1
> > /usr/sbin/kamailio[25452]: CRITICAL: dialog
> > [dlg_hash.c:650]: bogus event 6 in state 1 for dlg 0x7feb80ef0ae8
> > [2161:28334339] with clid '1560428909_26358995 at 4.55.13.227' and tags
> > 'gK0251b91f' ''
> > Jul 12 22:38:34 debian1 /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:808]: dialog 0x7feb80ef0ae8 changed from state 1 to state
> > 1, due event 6 (ref 2) Jul 12 22:38:34 debian1
> > /usr/sbin/kamailio[25452]: DEBUG: dialog
> > [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
> >
> >
> > ### Hanging up now
> >
> > Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25456]: DEBUG: tm
> [uac.c:182]:
> > DEBUG: dlg2hash: 29877
> > Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25456]: DEBUG: tm
> [uac.c:182]:
> > DEBUG: dlg2hash: 29874
> > Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> > [dlg_hash.c:514]: ref dlg 0x7feb80ef0ae8 with 1 -> 2 Jul 12 22:38:46
> > debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> > [dlg_hash.c:517]: dialog callid='1560428909_26358995 at 4.55.13.227'
> > found#012 on entry 2161, dir=1 Jul 12 22:38:46 debian1
> > /usr/sbin/kamailio[25455]: CRITICAL: dialog
> > [dlg_hash.c:650]: bogus event 7 in state 1 for dlg 0x7feb80ef0ae8
> > [2161:28334339] with clid '1560428909_26358995 at 4.55.13.227' and tags
> > 'gK0251b91f' ''
> > Jul 12 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> > [dlg_hash.c:808]: dialog 0x7feb80ef0ae8 changed from state 1 to state
> > 1, due event 7 (ref 2) Jul 12 22:38:46 debian1
> > /usr/sbin/kamailio[25455]: DEBUG: dialog
> > [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1 Jul 12
> 22:38:46
> > debian1 /usr/sbin/kamailio[25455]: ERROR: *** cfgtrace:
> > c=[/etc/kamailio/kamailio.cfg] l=625 a=25 n=dlg_manage Jul 12
> 22:38:46
> > debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> > [dlg_hash.c:459]: ref dlg 0x7feb80ef0ae8 with 1 -> 2 Jul 12 22:38:46
> > debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> > [dlg_hash.c:461]: dialog id=28334339 found on entry 2161 Jul 12
> > 22:38:46 debian1 /usr/sbin/kamailio[25455]: DEBUG: dialog
> > [dlg_hash.c:621]: unref dlg 0x7feb80ef0ae8 with 1 -> 1
> >
> >
> > Is my config wrong ? Am I missing anything here ? Any advice would be
> > much appreciated
> >
> > Thank you,
> > George
> >
> >
> > _______________________________________________
> > 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
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep
> 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Sat Jul 14 19:21:31 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Sat, 14 Jul 2012 19:21:31 +0200
Subject: [SR-Users] Kamailio v3.1.6 released - the last packaging in 3.1.x
series
Message-ID: <5001AA9B.7060204@gmail.com>
Hello,
this morning I packaged the 3.1.6 to mark the last release in the 3.1.x
series. At this moment, the latest stable series are 3.2.x and 3.3.x, so
there is no intention of packing again a 3.1.x version -- although
patches may still go in branch 3.1.
Notes about v3.1.6 release were posted on the news section of the website:
* http://www.kamailio.org/w/2012/07/kamailio-v3-1-6-released/
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From aftnix at gmail.com Sat Jul 14 10:03:52 2012
From: aftnix at gmail.com (aft)
Date: Sat, 14 Jul 2012 04:03:52 -0400
Subject: [SR-Users] Adding "make menuconfig"
Message-ID: <1342253032.3106.11.camel@kruki>
Hi,
Kamailio is a modular stack. So inclusion or exclusion of a module is
very important. At this moment editing modules.lst is very *primitive*
way of doing things.
I like menuconfig style ncurses based interface. Which gives a very
clear view of "dependency" and "which and which" information about the
modules.
As number of modules increases, most of us just compile most of them, or
take the default modules.lst as granted.
If a menuconfig target is added, it should be easier to customize a
kamailio build.
Adding a menuconfig target seems a trivial task for anyone who know
kamailio build system well plus some intro to ncurses programming.
So i guess devs should look into it.
cheers
aft
From abalashov at evaristesys.com Sun Jul 15 00:08:44 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Sat, 14 Jul 2012 18:08:44 -0400
Subject: [SR-Users] Adding "make menuconfig"
In-Reply-To: <1342253032.3106.11.camel@kruki>
References: <1342253032.3106.11.camel@kruki>
Message-ID: <5001EDEC.3060205@evaristesys.com>
On 07/14/2012 04:03 AM, aft wrote:
> Adding a menuconfig target seems a trivial task for anyone who know
> kamailio build system well plus some intro to ncurses programming.
I would just do it using 'dialog' and skip the direct ncurses interfaces.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From anton.jugatsu at gmail.com Sun Jul 15 08:27:04 2012
From: anton.jugatsu at gmail.com (Anton Kvashenkin)
Date: Sun, 15 Jul 2012 10:27:04 +0400
Subject: [SR-Users] : Adding "make menuconfig"
Message-ID: <CANBhyPC-kfsuRsUH2OY-Zdk5TXvvUr54XxiMJJxrmkrGLxX7Vw@mail.gmail.com>
Or we can just "port" Opensips's "make menuconfig" :)
15.07.2012 2:05 ???????????? "aft" <aftnix at gmail.com> ???????:
> Hi,
>
> Kamailio is a modular stack. So inclusion or exclusion of a module is
> very important. At this moment editing modules.lst is very *primitive*
> way of doing things.
>
> I like menuconfig style ncurses based interface. Which gives a very
> clear view of "dependency" and "which and which" information about the
> modules.
>
> As number of modules increases, most of us just compile most of them, or
> take the default modules.lst as granted.
>
> If a menuconfig target is added, it should be easier to customize a
> kamailio build.
>
> Adding a menuconfig target seems a trivial task for anyone who know
> kamailio build system well plus some intro to ncurses programming.
>
> So i guess devs should look into it.
>
> cheers
> aft
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120715/c24af697/attachment.htm>
From tony at myipsolution.com Sun Jul 15 04:18:58 2012
From: tony at myipsolution.com (Tony Rosa)
Date: Sat, 14 Jul 2012 22:18:58 -0400
Subject: [SR-Users] Interested Sip Server
Message-ID: <CACqTXkbn23=1owkULPq6LHSU1+GvR=XsTh=EHTz3fK7ZfKM+Xg@mail.gmail.com>
I am interested sip server software for residential application
Tony Andrade
IP Solution
617-386-9186
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120714/8e202061/attachment.htm>
From govoiper at gmail.com Sun Jul 15 10:26:38 2012
From: govoiper at gmail.com (SamyGo)
Date: Sun, 15 Jul 2012 13:26:38 +0500
Subject: [SR-Users] Interested Sip Server
In-Reply-To: <CACqTXkbn23=1owkULPq6LHSU1+GvR=XsTh=EHTz3fK7ZfKM+Xg@mail.gmail.com>
References: <CACqTXkbn23=1owkULPq6LHSU1+GvR=XsTh=EHTz3fK7ZfKM+Xg@mail.gmail.com>
Message-ID: <CAJUJwtiPv-XcxsXxNYpf34+xEtX_L=x_CfL4EC+m3RXWkSPwKw@mail.gmail.com>
Hello,
What are your requirements ! What functionality are you specifically
looking for in SIP Server.?
Few details here would help us helping you in deciding something.
Regards,
Sammy
On Sun, Jul 15, 2012 at 7:18 AM, Tony Rosa <tony at myipsolution.com> wrote:
> I am interested sip server software for residential application
>
> Tony Andrade
> IP Solution
> 617-386-9186
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120715/7c3d5de2/attachment.htm>
From govoiper at gmail.com Sun Jul 15 10:26:38 2012
From: govoiper at gmail.com (SamyGo)
Date: Sun, 15 Jul 2012 13:26:38 +0500
Subject: [SR-Users] Interested Sip Server
In-Reply-To: <CACqTXkbn23=1owkULPq6LHSU1+GvR=XsTh=EHTz3fK7ZfKM+Xg@mail.gmail.com>
References: <CACqTXkbn23=1owkULPq6LHSU1+GvR=XsTh=EHTz3fK7ZfKM+Xg@mail.gmail.com>
Message-ID: <CAJUJwtiPv-XcxsXxNYpf34+xEtX_L=x_CfL4EC+m3RXWkSPwKw@mail.gmail.com>
Hello,
What are your requirements ! What functionality are you specifically
looking for in SIP Server.?
Few details here would help us helping you in deciding something.
Regards,
Sammy
On Sun, Jul 15, 2012 at 7:18 AM, Tony Rosa <tony at myipsolution.com> wrote:
> I am interested sip server software for residential application
>
> Tony Andrade
> IP Solution
> 617-386-9186
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120715/7c3d5de2/attachment-0001.htm>
From miconda at gmail.com Mon Jul 16 11:49:02 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 16 Jul 2012 11:49:02 +0200
Subject: [SR-Users] planning release of v3.2.4
Message-ID: <5003E38E.4030004@gmail.com>
Hello,
later this week (like Thursday) I am considering packaging v3.2.4 from
the latest git branch 3.2. If anyone has patches to push it there,
please do it asap in case you want them in this release.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From piyush.singhai at eng.knowlarity.com Mon Jul 16 13:07:53 2012
From: piyush.singhai at eng.knowlarity.com (piyush singhai)
Date: Mon, 16 Jul 2012 16:37:53 +0530
Subject: [SR-Users] How to use Kamailio
In-Reply-To: <CAHHSTJ4v2Sv-1n2aL1ztMKTqyU1o+sT7r8zKbTvMaBfpEEKUOg@mail.gmail.com>
References: <CAHHSTJ4v2Sv-1n2aL1ztMKTqyU1o+sT7r8zKbTvMaBfpEEKUOg@mail.gmail.com>
Message-ID: <CAHHSTJ6E5-C6FUGYtLAwB4pWRDiNYP5s81SrQ0Z_mZGVyezUNA@mail.gmail.com>
Hello
I am very new in opensip.
i am trying to install kamailio and freeswitch...kamailio is running
fine...but i donot know how kamailio will communicate to my local sip
server.
kamctl start and stop ...starting and stopping the kamailio.
i have installed kamalio from
http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git
--Piyush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120716/e1c5e3a2/attachment.htm>
From stoyan.v.mihaylov at gmail.com Mon Jul 16 14:18:49 2012
From: stoyan.v.mihaylov at gmail.com (Stoyan Mihaylov)
Date: Mon, 16 Jul 2012 15:18:49 +0300
Subject: [SR-Users] How to use Kamailio
In-Reply-To: <CAHHSTJ6E5-C6FUGYtLAwB4pWRDiNYP5s81SrQ0Z_mZGVyezUNA@mail.gmail.com>
References: <CAHHSTJ4v2Sv-1n2aL1ztMKTqyU1o+sT7r8zKbTvMaBfpEEKUOg@mail.gmail.com>
<CAHHSTJ6E5-C6FUGYtLAwB4pWRDiNYP5s81SrQ0Z_mZGVyezUNA@mail.gmail.com>
Message-ID: <CAPScudZ_5xmpiSp6Lv10_gtCWJ4wuHHrPbx3TJx7UfTFuEKsSw@mail.gmail.com>
It depends what you want. You can forward calls to your local sip server,
you can accept calls from your local sip server.
But you need to know what kind of "discussion" you expect between your
local sip server and Kamailio.
On Mon, Jul 16, 2012 at 2:07 PM, piyush singhai <
piyush.singhai at eng.knowlarity.com> wrote:
>
> Hello
>
> I am very new in opensip.
> i am trying to install kamailio and freeswitch...kamailio is running
> fine...but i donot know how kamailio will communicate to my local sip
> server.
>
> kamctl start and stop ...starting and stopping the kamailio.
>
> i have installed kamalio from
>
> http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git
>
> --Piyush
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120716/0d330553/attachment.htm>
From realjijo at gmail.com Mon Jul 16 16:27:42 2012
From: realjijo at gmail.com (Jijo)
Date: Mon, 16 Jul 2012 10:27:42 -0400
Subject: [SR-Users] kamailio core at qm_status
Message-ID: <CAOYmDE-ZAFWUNawKMRyPwSwgUe9XuYfVF7HS-o_Ggv5g0suR0g@mail.gmail.com>
Hi All,
I'm observing a core intermittently at "qm_status (qm=0x786cd000) at
mem/q_malloc.c:763" for kamailio version 3.1.0
looking at the backtrace this is occurring while doing a tcp buffer
overrun. Please have a look and let me know if anyone observed this issue
or how can we debug it.
Please find the backtrace and kamailio version
osbprod-V2R0:~ # /usr/sbin/kamailio -V
version: kamailio 3.1.0 (i386/linux) 21a375
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,
DBG_QM_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, PKG_SIZE 15MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 21a375
compiled on 12:38:44 Apr 26 2012 with gcc 4.5.0
#0 qm_status (qm=0x786cd000) at mem/q_malloc.c:763
#1 0x0819c0f3 in qm_debug_frag (qm=0x786cd000, f=<value optimized out>) at
mem/q_malloc.c:167
#2 0x0819c352 in qm_free (qm=0x786cd000, p=0x7a6cb6ac, file=0x821cce2
"<core>: tcp_main.c", func=0x822285f "wbufq_run", line=880) at
mem/q_malloc.c:457
#3 0x0815f686 in wbufq_run (tcpconn=0x7a1a7548, ev=4, fd_i=-1) at
tcp_main.c:880
#4 handle_tcpconn_ev (tcpconn=0x7a1a7548, ev=4, fd_i=-1) at tcp_main.c:4141
#5 0x08169bf2 in io_wait_loop_epoll () at io_wait.h:1092
#6 tcp_main_loop () at tcp_main.c:4606
#7 0x080b0404 in main_loop () at main.c:1655
#8 0x080b1f84 in main (argc=9, argv=0xbfb4c9f4) at main.c:2446
(gdb) l
758 LOG_(DEFAULT_FACILITY, memlog, "qm_status: ",
759 "dumping free list stats :\n");
760 for(h=0,i=0;h<QM_HASH_SIZE;h++){
761 unused=0;
762 for (f=qm->free_hash[h].head.u.nxt_free,j=0;
763 f!=&(qm->free_hash[h].head);
f=f->u.nxt_free, i++, j++){
764 if (!FRAG_WAS_USED(f)){
765 unused++;
766 #ifdef DBG_QM_MALLOC
767 LOG_(DEFAULT_FACILITY,
memlog, "qm_status: ",
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120716/4de66df4/attachment.htm>
From Gary.Chen at lightyear.net Mon Jul 16 16:32:44 2012
From: Gary.Chen at lightyear.net (Gary Chen)
Date: Mon, 16 Jul 2012 10:32:44 -0400
Subject: [SR-Users] How to use regular expression for $var ?
Message-ID: <A6C2711F9706AF4992FFEC48EA19CA90174144DF3D@lyepkyexc.LYEPLYEXC.local>
Kamailio 3.3.0
I have a variable $var(s:dst). It can store either a number or IP.
How do I check to determine whether it is a number of IP?
I tried the following and it did not work:
If ($var(s:dst) =~ "^\d+\.\d+\.\d+\.\d+$"){
It is a IP.
}else{
It is a Number
}
Thanks
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120716/e69651f4/attachment.htm>
From manwe at aholab.ehu.es Mon Jul 16 17:12:51 2012
From: manwe at aholab.ehu.es (Jon Bonilla (Manwe))
Date: Mon, 16 Jul 2012 17:12:51 +0200
Subject: [SR-Users] [sr-dev] kamailio core at qm_status
In-Reply-To: <CAOYmDE-ZAFWUNawKMRyPwSwgUe9XuYfVF7HS-o_Ggv5g0suR0g@mail.gmail.com>
References: <CAOYmDE-ZAFWUNawKMRyPwSwgUe9XuYfVF7HS-o_Ggv5g0suR0g@mail.gmail.com>
Message-ID: <20120716171251.1764894c@quenya>
El Mon, 16 Jul 2012 10:27:42 -0400
Jijo <realjijo at gmail.com> escribi?:
> Hi All,
>
> I'm observing a core intermittently at "qm_status (qm=0x786cd000) at
> mem/q_malloc.c:763" for kamailio version 3.1.0
>
I'd say that you're using a very old version. You should update your branch to
3.1.6 or upgrade to a newer branch.
From realjijo at gmail.com Mon Jul 16 17:28:13 2012
From: realjijo at gmail.com (Jijo)
Date: Mon, 16 Jul 2012 11:28:13 -0400
Subject: [SR-Users] [sr-dev] kamailio core at qm_status
In-Reply-To: <20120716171251.1764894c@quenya>
References: <CAOYmDE-ZAFWUNawKMRyPwSwgUe9XuYfVF7HS-o_Ggv5g0suR0g@mail.gmail.com>
<20120716171251.1764894c@quenya>
Message-ID: <CAOYmDE9+tpmvDRBEqD2Bqv879Xi+A+YLm9oQApsH+kMtiCV+tw@mail.gmail.com>
Thanks.. It is not easy to upgrade as it is happening at customer system.
Is there any change occurred for this issue.I looked at it, but didn't see
anything in q_malloc.c/qm_status()
On Mon, Jul 16, 2012 at 11:12 AM, Jon Bonilla <manwe at aholab.ehu.es> wrote:
> El Mon, 16 Jul 2012 10:27:42 -0400
> Jijo <realjijo at gmail.com> escribi?:
>
> > Hi All,
> >
> > I'm observing a core intermittently at "qm_status (qm=0x786cd000) at
> > mem/q_malloc.c:763" for kamailio version 3.1.0
> >
>
> I'd say that you're using a very old version. You should update your
> branch to
> 3.1.6 or upgrade to a newer branch.
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120716/0ee55824/attachment-0001.htm>
From brandon at cryy.com Mon Jul 16 19:11:15 2012
From: brandon at cryy.com (Brandon Armstead)
Date: Mon, 16 Jul 2012 10:11:15 -0700
Subject: [SR-Users] How to use regular expression for $var ?
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA90174144DF3D@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA90174144DF3D@lyepkyexc.LYEPLYEXC.local>
Message-ID: <54E33E0B-28FF-4A53-AD25-1250030B2561@cryy.com>
Gary,
Please elaborate on "did not work". Also have you logged the actual value of this var before the if/else statement?
Sent from my iPhone
On Jul 16, 2012, at 7:32 AM, Gary Chen <Gary.Chen at lightyear.net> wrote:
> Kamailio 3.3.0
>
> I have a variable $var(s:dst). It can store either a number or IP.
> How do I check to determine whether it is a number of IP?
> I tried the following and it did not work:
> If ($var(s:dst) =~ ?^\d+\.\d+\.\d+\.\d+$?){
> It is a IP.
> }else{
> It is a Number
> }
>
>
> Thanks
>
> Gary
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120716/0f578ae4/attachment.htm>
From evilzluk at gmail.com Mon Jul 16 20:19:22 2012
From: evilzluk at gmail.com (Konstantin M.)
Date: Mon, 16 Jul 2012 21:19:22 +0300
Subject: [SR-Users] Does kamailio has some headers optimizing mechanism ?
Message-ID: <CAEYtTze9gzL3S+GCMTyRHohws9L7LYYT2ZwH75nKMQVa-f9GGg@mail.gmail.com>
Hello,
I have a following part of code:
if (route(Test_TO_Dialer))
{
append_hf("P-hint: Loose Routing. Re-INVITE Detected: Uplink -->
Originator.\r\n");
xlog("********** loose_route(): Detected Re-INVITE from Uplink!
**********\n");
setflag(1); # do accounting
append_hf("P-hint: SDP was mangled\r\n");
python_exec("ParseSDP", $mb);
fix_nated_contact();
setbflag(6); # Mark as NATed
rtpproxy_manage();
dlg_manage();
}
But in a logs I see:
P-hint: Loose Routing. Re-INVITE Detected: Uplink --> Originator., SDP was
mangled
but it should be like this:
P-hint: Loose Routing. Re-INVITE Detected: Uplink --> Originator.
P-hint: SDP was mangled
Does kamailio has some headers optimizing mechanism ?
# ./kamailio -V
version: kamailio 3.2.3 (x86_64/linux)
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,
DBG_QM_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 15:37:11 Jun 9 2012 with gcc 4.4.3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120716/f951a499/attachment.htm>
From piyush.singhai at eng.knowlarity.com Mon Jul 16 12:59:12 2012
From: piyush.singhai at eng.knowlarity.com (piyush singhai)
Date: Mon, 16 Jul 2012 16:29:12 +0530
Subject: [SR-Users] How to use Kamailio
Message-ID: <CAHHSTJ4v2Sv-1n2aL1ztMKTqyU1o+sT7r8zKbTvMaBfpEEKUOg@mail.gmail.com>
Hello
I am very new in opensip.
i am trying to install kamailio and freeswitch...kamailio is running
fine...but i donot know how kamailio will communicate to my local sip
server.
kamctl start and stop ...starting and stopping the kamailio.
i have installed kamalio from
http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git
--Piyush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120716/4ccb02d4/attachment.htm>
From miconda at gmail.com Tue Jul 17 08:45:35 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 17 Jul 2012 08:45:35 +0200
Subject: [SR-Users] Does kamailio has some headers optimizing mechanism ?
In-Reply-To: <CAEYtTze9gzL3S+GCMTyRHohws9L7LYYT2ZwH75nKMQVa-f9GGg@mail.gmail.com>
References: <CAEYtTze9gzL3S+GCMTyRHohws9L7LYYT2ZwH75nKMQVa-f9GGg@mail.gmail.com>
Message-ID: <50050A0F.7040500@gmail.com>
Hello,
On 7/16/12 8:19 PM, Konstantin M. wrote:
> Hello,
>
> I have a following part of code:
>
>
> if (route(Test_TO_Dialer))
> {
> append_hf("P-hint: Loose Routing. Re-INVITE Detected: Uplink
> --> Originator.\r\n");
> xlog("********** loose_route(): Detected Re-INVITE from
> Uplink! **********\n");
>
> setflag(1); # do accounting
>
> append_hf("P-hint: SDP was mangled\r\n");
> python_exec("ParseSDP", $mb);
>
> fix_nated_contact();
> setbflag(6); # Mark as NATed
>
> rtpproxy_manage();
> dlg_manage();
> }
>
> But in a logs I see:
>
> P-hint: Loose Routing. Re-INVITE Detected: Uplink --> Originator., SDP
> was mangled
>
> but it should be like this:
> P-hint: Loose Routing. Re-INVITE Detected: Uplink --> Originator.
> P-hint: SDP was mangled
>
> Does kamailio has some headers optimizing mechanism ?
>
> # ./kamailio -V
> version: kamailio 3.2.3 (x86_64/linux)
> 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, DBG_QM_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 15:37:11 Jun 9 2012 with gcc 4.4.3
>
>
there is no such mechanism to join headers with same name added by
append_hf(). Can you provide a ngrep trace of such situation?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Tue Jul 17 08:50:04 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 17 Jul 2012 08:50:04 +0200
Subject: [SR-Users] How to use regular expression for $var ?
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA90174144DF3D@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA90174144DF3D@lyepkyexc.LYEPLYEXC.local>
Message-ID: <50050B1C.2070707@gmail.com>
Hello,
On 7/16/12 4:32 PM, Gary Chen wrote:
>
> Kamailio 3.3.0
>
> I have a variable $var(s:dst). It can store either a number or IP.
>
> How do I check to determine whether it is a number of IP?
>
> I tried the following and it did not work:
>
> If ($var(s:dst) =~ "^\d+\.\d+\.\d+\.\d+$"){
> It is a IP.
> }else{
> It is a Number
> }
for this particular case, you better use functions from ipops module:
http://kamailio.org/docs/modules/stable/modules/ipops.html#id2536192
Using regular expressions with variables is correct as you tried, not
sure the \d is taken on consideration, you may try \\d or what I usually
use is [0-9] instead of \d.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/778796e6/attachment-0001.htm>
From miconda at gmail.com Tue Jul 17 09:06:48 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 17 Jul 2012 09:06:48 +0200
Subject: [SR-Users] [sr-dev] kamailio core at qm_status
In-Reply-To: <CAOYmDE9+tpmvDRBEqD2Bqv879Xi+A+YLm9oQApsH+kMtiCV+tw@mail.gmail.com>
References: <CAOYmDE-ZAFWUNawKMRyPwSwgUe9XuYfVF7HS-o_Ggv5g0suR0g@mail.gmail.com>
<20120716171251.1764894c@quenya>
<CAOYmDE9+tpmvDRBEqD2Bqv879Xi+A+YLm9oQApsH+kMtiCV+tw@mail.gmail.com>
Message-ID: <50050F08.9060707@gmail.com>
Hello,
does it keep being or it is one time and that's it?
That is printed at shut down or if pkg_status() or shm_status() is
executed from some part of code or in config via cfgutils module functions.
You can get rid of them by setting memdbg and memlog to a value higher
than debug global parameter.
Cheers,
Daniel
On 7/16/12 5:28 PM, Jijo wrote:
> Thanks.. It is not easy to upgrade as it is happening at customer system.
> Is there any change occurred for this issue.I looked at it, but didn't
> see anything in q_malloc.c/qm_status()
>
>
> On Mon, Jul 16, 2012 at 11:12 AM, Jon Bonilla <manwe at aholab.ehu.es
> <mailto:manwe at aholab.ehu.es>> wrote:
>
> El Mon, 16 Jul 2012 10:27:42 -0400
> Jijo <realjijo at gmail.com <mailto:realjijo at gmail.com>> escribi?:
>
> > Hi All,
> >
> > I'm observing a core intermittently at "qm_status (qm=0x786cd000) at
> > mem/q_malloc.c:763" for kamailio version 3.1.0
> >
>
> I'd say that you're using a very old version. You should update
> your branch to
> 3.1.6 or upgrade to a newer branch.
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/5fec8a7c/attachment.htm>
From klaus.mailinglists at pernau.at Tue Jul 17 10:42:50 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Tue, 17 Jul 2012 10:42:50 +0200
Subject: [SR-Users] How to use regular expression for $var ?
In-Reply-To: <50050B1C.2070707@gmail.com>
References: <A6C2711F9706AF4992FFEC48EA19CA90174144DF3D@lyepkyexc.LYEPLYEXC.local>
<50050B1C.2070707@gmail.com>
Message-ID: <5005258A.7050107@pernau.at>
I remember that I once had to use the POSIX variant: [:digit:]
Klaus
On 17.07.2012 08:50, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 7/16/12 4:32 PM, Gary Chen wrote:
>>
>> Kamailio 3.3.0
>>
>> I have a variable $var(s:dst). It can store either a number or IP.
>>
>> How do I check to determine whether it is a number of IP?
>>
>> I tried the following and it did not work:
>>
>> If ($var(s:dst) =~ ?^\d+\.\d+\.\d+\.\d+$?){
>> It is a IP.
>> }else{
>> It is a Number
>> }
> for this particular case, you better use functions from ipops module:
>
> http://kamailio.org/docs/modules/stable/modules/ipops.html#id2536192
>
> Using regular expressions with variables is correct as you tried, not
> sure the \d is taken on consideration, you may try \\d or what I usually
> use is [0-9] instead of \d.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
>
> _______________________________________________
> 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
>
From ushacked at gmail.com Tue Jul 17 14:23:09 2012
From: ushacked at gmail.com (Uri Shacked)
Date: Tue, 17 Jul 2012 15:23:09 +0300
Subject: [SR-Users] Reply 503 was replaced to 500
In-Reply-To: <4FE81250.5070705@gmail.com>
References: <CAMMbDhR=rL=1rJPE5VABO7zE_oDbq7DieViHUtrhsdYv91n+Qg@mail.gmail.com>
<CAMMbDhQpvT-1_=njE2hq1EhVfX6MBTOTMs+dATbRojV5NNxhVA@mail.gmail.com>
<4FE81250.5070705@gmail.com>
Message-ID: <CAMMbDhT-zi0UZ3kRUzdLm1fTsutz+fk050TvAamMV=DNV5HdCg@mail.gmail.com>
Hi,
Here is the problem with the solution to sending different reply then the
once I receive:
I check if the reply is 603. If so, i did t_drop_replies and then t_reply
with the reply i wanted to send back. 500 with append_to_reply something....
The problem is that on the 500 that i send back, the to_tag is not the same
to_tag that i received with the 603.
That makes some problems on the sip and lots of problems on the CDR
creation (it is based on to_tag as well).
Any ideas?
How do i make it the same to_tag? Removing a header and recreating it seems
very dirty for it.....
BR,
Uri
On Mon, Jun 25, 2012 at 10:25 AM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:
> Hello,
>
> this 503 to 500 is a requirement from RFC, to prevent propagation of
> blacklisting/disabling destination hosts. I don't remember right now any
> configuration option for it, but you can try to enforce it from the failure
> route, like:
>
> t_reply("503", "...");
>
> Cheers,
> Daniel
>
>
> On 6/24/12 4:30 PM, Uri Shacked wrote:
>
> I just read the topic - "*Copy reason field from 503 to 500. * "
> Is there a way to change it if i want to send back the original leg 2 503
> reply?
>
> On Sun, Jun 24, 2012 at 4:17 PM, Uri Shacked <ushacked at gmail.com> wrote:
>
>> Hi,
>>
>> Kamailio server is behind our company's softswitch and acts as a sip
>> application server.
>> I notice that there are calls that the softswitch replied with 503
>> "service unavailable" and kamailio sent to the originator leg 500 "service
>> unavaileable".
>> When kamailio recieved 504 or 502 it sends them back as is. shouldn't it
>> be the same with 503?
>>
>> It also does not have a "to tag" in the CDR. And the "to tag" in the 503
>> that was recieved is not equal to the 500 reply "to tag" kamailio sent
>> back.
>>
>> any ideas?
>>
>> BR,
>> Uri
>>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/436d5c20/attachment.htm>
From abalashov at evaristesys.com Tue Jul 17 18:00:43 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 17 Jul 2012 12:00:43 -0400
Subject: [SR-Users] Topoh address
Message-ID: <6yux2hn76mag41ujonvrx76n.1342540737217@email.android.com>
A whole ago, it was mentioned on the list that there was some bug or issue in Topoh that precluded the use of the actual host IP of the proxy as the Topoh spoof address.?
Is that still true in 3.3? Or has that been fixed some time ago??
Thanks!
-- Alex
--
Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/42011140/attachment.htm>
From realjijo at gmail.com Tue Jul 17 18:03:49 2012
From: realjijo at gmail.com (Jijo)
Date: Tue, 17 Jul 2012 12:03:49 -0400
Subject: [SR-Users] [sr-dev] kamailio core at qm_status
In-Reply-To: <50050F08.9060707@gmail.com>
References: <CAOYmDE-ZAFWUNawKMRyPwSwgUe9XuYfVF7HS-o_Ggv5g0suR0g@mail.gmail.com>
<20120716171251.1764894c@quenya>
<CAOYmDE9+tpmvDRBEqD2Bqv879Xi+A+YLm9oQApsH+kMtiCV+tw@mail.gmail.com>
<50050F08.9060707@gmail.com>
Message-ID: <CAOYmDE9whUjcjy=8bFV0MpS45rmKdjacOw1CTDUkS1h9RYSGZg@mail.gmail.com>
Hi,
This is not happening at shutdown or status check. Its aborting when the
system is active.
Thanks
Jijo
On Tue, Jul 17, 2012 at 3:06 AM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:
> Hello,
>
> does it keep being or it is one time and that's it?
>
> That is printed at shut down or if pkg_status() or shm_status() is
> executed from some part of code or in config via cfgutils module functions.
>
> You can get rid of them by setting memdbg and memlog to a value higher
> than debug global parameter.
>
> Cheers,
> Daniel
>
>
> On 7/16/12 5:28 PM, Jijo wrote:
>
> Thanks.. It is not easy to upgrade as it is happening at customer system.
> Is there any change occurred for this issue.I looked at it, but didn't see
> anything in q_malloc.c/qm_status()
>
>
> On Mon, Jul 16, 2012 at 11:12 AM, Jon Bonilla <manwe at aholab.ehu.es> wrote:
>
>> El Mon, 16 Jul 2012 10:27:42 -0400
>> Jijo <realjijo at gmail.com> escribi?:
>>
>> > Hi All,
>> >
>> > I'm observing a core intermittently at "qm_status (qm=0x786cd000) at
>> > mem/q_malloc.c:763" for kamailio version 3.1.0
>> >
>>
>> I'd say that you're using a very old version. You should update your
>> branch to
>> 3.1.6 or upgrade to a newer branch.
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>
>
>
> _______________________________________________
> sr-dev mailing listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/2272c90e/attachment.htm>
From miconda at gmail.com Tue Jul 17 19:11:05 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 17 Jul 2012 19:11:05 +0200
Subject: [SR-Users] Topoh address
In-Reply-To: <6yux2hn76mag41ujonvrx76n.1342540737217@email.android.com>
References: <6yux2hn76mag41ujonvrx76n.1342540737217@email.android.com>
Message-ID: <50059CA9.6010801@gmail.com>
Hello,
On 7/17/12 6:00 PM, Alex Balashov wrote:
> A whole ago, it was mentioned on the list that there was some bug or
> issue in Topoh that precluded the use of the actual host IP of the
> proxy as the Topoh spoof address.
>
> Is that still true in 3.3? Or has that been fixed some time ago?
it's still there, I don't recall any commit changing that. But you can
use an IP address such as 127.0.0.2, it does not have to be a valid
routable ip address.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/ef5065da/attachment-0001.htm>
From bruno.bresciani at gmail.com Tue Jul 17 19:11:39 2012
From: bruno.bresciani at gmail.com (Bruno Bresciani)
Date: Tue, 17 Jul 2012 14:11:39 -0300
Subject: [SR-Users] Core fm_realloc function
Message-ID: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
Hi all,
I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0,
size=0) at mem/f_malloc.c:536.
I don't know exactly what may be caused this core because the debug of
kamailio is disabled, but looking at backtrace (gdb) and source code I
could notice a relationship with TLS connection establishment (handshake).
Other important fact is that core was generated by the kamalio itself with
signal 6 (abort) because it can't find the pointer to memory realloc.
I'd like to know if someone already observed this issue and if my analyse
above is correct?
Bellow is backtrace full with gdb:
Core was generated by `/home2/local/kamailio/sbin/kamailio -P
/var/run/kamailio.pid'.
Program terminated with signal 6, Aborted.
#0 0x00f30402 in __kernel_vsyscall ()
(gdb)
(gdb)
(gdb)
(gdb)
(gdb) bt full
#0 0x00f30402 in __kernel_vsyscall ()
No symbol table info available.
#1 0x009fec10 in raise () from /lib/libc.so.6
No symbol table info available.
#2 0x00a00521 in abort () from /lib/libc.so.6
No symbol table info available.
#3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
mem/f_malloc.c:536
f = (struct fm_frag *) 0xb61f0bb8
pf = <value optimized out>
orig_size = 18
L=?b???2n = (struct fm_frag *) 0xb61f0bd2
ptr = <value optimized out>
hash = 23548
#4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
../../mem/shm_mem.h:266
No locals.
#5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
No symbol table info available.
#6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
No symbol table info available.
#7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
No symbol table info available.
#8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
No symbol table info available.
#9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
No symbol table info available.
#10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
No symbol table info available.
#11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
No symbol table info available.
#12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
No symbol table info available.
#13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
tls_server.c:346
ret = <value optimized out>
ssl = (SSL *) 0xb61c1878
cert = <value optimized out>
tls_c = (struct tls_extra_data *) 0xb6208e58
tls_log = <value optimized out>
#14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
tls_server.c:1028
r = (struct tcp_req *) 0xb621affc
bytes_free = 4095
bytes_read = 70
read_size = 4095
ssl_error = 0
ssl_read = 0
ssl = (SSL *) 0xb61c1878
rd_buf = "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
202i<??<????\031??234?
\237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v??
??Ea\023x??J\206T\204C?
wr_buf =
"\027\003\001\003?
w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70, size =
65536}
wr = {
buf = 0xbf8fdfa4
"\027\003\001\003?
w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
pos = 0, used = 0,
size = 65536}
tls_c = (struct tls_extra_data *) 0xb6208e58
enc_rd_buf = (struct tls_rd_buf *) 0x0
n = 0
flush_flags = <value optimized out>
err_src = 0x541a83 "TLS read:"
x = <value optimized out>
#15 0x08158ade in tcp_read_headers (c=0xb621af88, read_flags=0xbf91e200) at
tcp_read.c:406
bytes = -1
remaining = <value optimized out>
p = <value optimized out>
r = (struct tcp_req *) 0xb621affc
#16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204,
read_flags=0xbf91e200) at tcp_read.c:871
bytes = <value optimized out>
total_bytes = 0
resp = <value optimized out>
size = <value optimized out>
req = (struct tcp_req *) 0xb621affc
dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data =
"\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family =
57540,
sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
"\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port =
49041,
sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
"\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 =
{0, 0, 16, 0, 1, 0,
1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}}, id =
-1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask = 0
'\0'}}
c = 10 '\n'
#17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
tcp_read.c:1150
ret = 4
n = 4
read_flags = 1
con = (struct tcp_connection *) 0xb621af88
s = 12
resp = <value optimized out>
t = <value optimized out>
#18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
No locals.
---Type <return> to continue, or q <return> to quit---
#19 0x0812885b in tcp_init_children () at tcp_main.c:4819
r = 3
reader_fd_1 = 35
pid = <value optimized out>
si = <value optimized out>
#20 0x080ad412 in main_loop () at main.c:1632
i = 4
pid = <value optimized out>
si = (struct socket_info *) 0x0
si_desc = "udp receiver child=3 sock=192.168.166.31:5060
\000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
#21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted DWARF
expression.
) at main.c:2398
cfg_stream = (FILE *) 0x8a2d008
c = <value optimized out>
r = 0
tmp = 0xbf91e674
"\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
tmp_len = 10492229
port = 136192361
proto = -1080957480
ret = <value optimized out>
seed = 21782655
rfd = 4
debug_save = <value optimized out>
debug_flag = 0
dont_fork_cnt = 0
n_lst = <value optimized out>
p = <value optimized out>
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/01162a5c/attachment.htm>
From miconda at gmail.com Tue Jul 17 19:18:48 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 17 Jul 2012 19:18:48 +0200
Subject: [SR-Users] Reply 503 was replaced to 500
In-Reply-To: <CAMMbDhT-zi0UZ3kRUzdLm1fTsutz+fk050TvAamMV=DNV5HdCg@mail.gmail.com>
References: <CAMMbDhR=rL=1rJPE5VABO7zE_oDbq7DieViHUtrhsdYv91n+Qg@mail.gmail.com>
<CAMMbDhQpvT-1_=njE2hq1EhVfX6MBTOTMs+dATbRojV5NNxhVA@mail.gmail.com>
<4FE81250.5070705@gmail.com>
<CAMMbDhT-zi0UZ3kRUzdLm1fTsutz+fk050TvAamMV=DNV5HdCg@mail.gmail.com>
Message-ID: <50059E78.2090809@gmail.com>
Hello,
sending a >=300 reply is for an not-established dialog, which eventually
can be forked by proxy, meaning many 1xx replies can get to caller, then
many >=300 replies can get to the proxy which will chose which one to
use for sending back to the caller.
Doing a t_reply(...) with a different code than the received one is like
having two branch, one locally and one from where the reply is received,
but you decide to reply from the local one. So if the caller device has
problems with this case, the it will have problems with serial/parallel
forking.
For accounting you can save incoming to-tag in an avp and store it in a
separate column in acc table. But setting the to-tag for t_reply() is
not possible at this time.
Btw, have you tried instead the change_reply_status() function?
http://kamailio.org/docs/modules/stable/modules/textopsx.html#textopsx.change_reply_status
Cheers,
Daniel
On 7/17/12 2:23 PM, Uri Shacked wrote:
>
> Hi,
>
> Here is the problem with the solution to sending different reply then
> the once I receive:
>
> I check if the reply is 603. If so, i did t_drop_replies and then
> t_reply with the reply i wanted to send back. 500 with append_to_reply
> something....
>
> The problem is that on the 500 that i send back, the to_tag is not the
> same to_tag that i received with the 603.
>
> That makes some problems on the sip and lots of problems on the CDR
> creation (it is based on to_tag as well).
>
> Any ideas?
>
> How do i make it the same to_tag? Removing a header and recreating it
> seems very dirty for it.....
>
> BR,
>
> Uri
>
> On Mon, Jun 25, 2012 at 10:25 AM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
> Hello,
>
> this 503 to 500 is a requirement from RFC, to prevent propagation
> of blacklisting/disabling destination hosts. I don't remember
> right now any configuration option for it, but you can try to
> enforce it from the failure route, like:
>
> t_reply("503", "...");
>
> Cheers,
> Daniel
>
>
> On 6/24/12 4:30 PM, Uri Shacked wrote:
>> I just read the topic - "_Copy reason field from 503 to 500. _"
>> Is there a way to change it if i want to send back the original
>> leg 2 503 reply?
>>
>> On Sun, Jun 24, 2012 at 4:17 PM, Uri Shacked <ushacked at gmail.com
>> <mailto:ushacked at gmail.com>> wrote:
>>
>> Hi,
>> Kamailio server is behind our company's softswitch and acts
>> as a sip application server.
>> I notice that there are calls that the softswitch replied
>> with 503 "service unavailable" and kamailio sent to the
>> originator leg 500 "service unavaileable".
>> When kamailio recieved 504 or 502 it sends them back as is.
>> shouldn't it be the same with 503?
>> It also does not have a "to tag" in the CDR. And the "to tag"
>> in the 503 that was recieved is not equal to the 500 reply
>> "to tag" kamailio sent back.
>> any ideas?
>> BR,
>> Uri
>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com <http://www.asipto.com/>
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/428b60ca/attachment-0001.htm>
From miconda at gmail.com Tue Jul 17 19:20:02 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 17 Jul 2012 19:20:02 +0200
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
Message-ID: <50059EC2.6060409@gmail.com>
Hello,
send also the version 'kamailio -V' to match the proper sources.
Cheers,
Daniel
On 7/17/12 7:11 PM, Bruno Bresciani wrote:
> Hi all,
>
> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536.
>
> I don't know exactly what may be caused this core because the debug of
> kamailio is disabled, but looking at backtrace (gdb) and source code I
> could notice a relationship with TLS connection establishment
> (handshake). Other important fact is that core was generated by the
> kamalio itself with signal 6 (abort) because it can't find the pointer
> to memory realloc.
> I'd like to know if someone already observed this issue and if my
> analyse above is correct?
>
> Bellow is backtrace full with gdb:
>
> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
> /var/run/kamailio.pid'.
> Program terminated with signal 6, Aborted.
> #0 0x00f30402 in __kernel_vsyscall ()
> (gdb)
> (gdb)
> (gdb)
> (gdb)
> (gdb) bt full
> #0 0x00f30402 in __kernel_vsyscall ()
> No symbol table info available.
> #1 0x009fec10 in raise () from /lib/libc.so.6
> No symbol table info available.
> #2 0x00a00521 in abort () from /lib/libc.so.6
> No symbol table info available.
> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
> mem/f_malloc.c:536
> f = (struct fm_frag *) 0xb61f0bb8
> pf = <value optimized out>
> orig_size = 18
> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
> ptr = <value optimized out>
> hash = 23548
> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
> ../../mem/shm_mem.h:266
> No locals.
> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
> No symbol table info available.
> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
> No symbol table info available.
> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
> No symbol table info available.
> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
> No symbol table info available.
> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
> No symbol table info available.
> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
> No symbol table info available.
> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
> No symbol table info available.
> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
> No symbol table info available.
> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
> tls_server.c:346
> ret = <value optimized out>
> ssl = (SSL *) 0xb61c1878
> cert = <value optimized out>
> tls_c = (struct tls_extra_data *) 0xb6208e58
> tls_log = <value optimized out>
> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
> tls_server.c:1028
> r = (struct tcp_req *) 0xb621affc
> bytes_free = 4095
> bytes_read = 70
> read_size = 4095
> ssl_error = 0
> ssl_read = 0
> ssl = (SSL *) 0xb61c1878
> rd_buf = "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
> wr_buf =
> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70,
> size = 65536}
> wr = {
> buf = 0xbf8fdfa4
> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
> pos = 0, used = 0,
> size = 65536}
> tls_c = (struct tls_extra_data *) 0xb6208e58
> enc_rd_buf = (struct tls_rd_buf *) 0x0
> n = 0
> flush_flags = <value optimized out>
> err_src = 0x541a83 "TLS read:"
> x = <value optimized out>
> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
> read_flags=0xbf91e200) at tcp_read.c:406
> bytes = -1
> remaining = <value optimized out>
> p = <value optimized out>
> r = (struct tcp_req *) 0xb621affc
> #16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204,
> read_flags=0xbf91e200) at tcp_read.c:871
> bytes = <value optimized out>
> total_bytes = 0
> resp = <value optimized out>
> size = <value optimized out>
> req = (struct tcp_req *) 0xb621affc
> dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data
> = "\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin =
> {sin_family = 57540,
> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540,
> sin6_port = 49041,
> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000",
> u6_addr16 = {0, 0, 16, 0, 1, 0,
> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}},
> id = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0',
> blst_imask = 0 '\0'}}
> c = 10 '\n'
> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
> tcp_read.c:1150
> ret = 4
> n = 4
> read_flags = 1
> con = (struct tcp_connection *) 0xb621af88
> s = 12
> resp = <value optimized out>
> t = <value optimized out>
> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
> No locals.
> ---Type <return> to continue, or q <return> to quit---
> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
> r = 3
> reader_fd_1 = 35
> pid = <value optimized out>
> si = <value optimized out>
> #20 0x080ad412 in main_loop () at main.c:1632
> i = 4
> pid = <value optimized out>
> si = (struct socket_info *) 0x0
> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
> <http://192.168.166.31:5060>\000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted
> DWARF expression.
> ) at main.c:2398
> cfg_stream = (FILE *) 0x8a2d008
> c = <value optimized out>
> r = 0
> tmp = 0xbf91e674
> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
> tmp_len = 10492229
> port = 136192361
> proto = -1080957480
> ret = <value optimized out>
> seed = 21782655
> rfd = 4
> debug_save = <value optimized out>
> debug_flag = 0
> dont_fork_cnt = 0
> n_lst = <value optimized out>
> p = <value optimized out>
>
>
> Best Regards
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/3ab44c46/attachment.htm>
From bruno.bresciani at gmail.com Tue Jul 17 19:26:17 2012
From: bruno.bresciani at gmail.com (Bruno Bresciani)
Date: Tue, 17 Jul 2012 14:26:17 -0300
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <50059EC2.6060409@gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
Message-ID: <CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
Best Regards
2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> send also the version 'kamailio -V' to match the proper sources.
>
> Cheers,
> Daniel
>
>
> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>
> Hi all,
>
> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0,
> size=0) at mem/f_malloc.c:536.
>
> I don't know exactly what may be caused this core because the debug of
> kamailio is disabled, but looking at backtrace (gdb) and source code I
> could notice a relationship with TLS connection establishment (handshake).
> Other important fact is that core was generated by the kamalio itself with
> signal 6 (abort) because it can't find the pointer to memory realloc.
> I'd like to know if someone already observed this issue and if my analyse
> above is correct?
>
> Bellow is backtrace full with gdb:
>
> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
> /var/run/kamailio.pid'.
> Program terminated with signal 6, Aborted.
> #0 0x00f30402 in __kernel_vsyscall ()
> (gdb)
> (gdb)
> (gdb)
> (gdb)
> (gdb) bt full
> #0 0x00f30402 in __kernel_vsyscall ()
> No symbol table info available.
> #1 0x009fec10 in raise () from /lib/libc.so.6
> No symbol table info available.
> #2 0x00a00521 in abort () from /lib/libc.so.6
> No symbol table info available.
> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
> mem/f_malloc.c:536
> f = (struct fm_frag *) 0xb61f0bb8
> pf = <value optimized out>
> orig_size = 18
> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
> ptr = <value optimized out>
> hash = 23548
> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
> ../../mem/shm_mem.h:266
> No locals.
> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
> No symbol table info available.
> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
> No symbol table info available.
> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
> No symbol table info available.
> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
> No symbol table info available.
> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
> No symbol table info available.
> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
> No symbol table info available.
> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
> No symbol table info available.
> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
> No symbol table info available.
> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
> tls_server.c:346
> ret = <value optimized out>
> ssl = (SSL *) 0xb61c1878
> cert = <value optimized out>
> tls_c = (struct tls_extra_data *) 0xb6208e58
> tls_log = <value optimized out>
> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
> tls_server.c:1028
> r = (struct tcp_req *) 0xb621affc
> bytes_free = 4095
> bytes_read = 70
> read_size = 4095
> ssl_error = 0
> ssl_read = 0
> ssl = (SSL *) 0xb61c1878
> rd_buf = "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>
> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
> wr_buf =
> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>
> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70, size =
> 65536}
> wr = {
> buf = 0xbf8fdfa4
> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
> pos = 0, used = 0,
> size = 65536}
> tls_c = (struct tls_extra_data *) 0xb6208e58
> enc_rd_buf = (struct tls_rd_buf *) 0x0
> n = 0
> flush_flags = <value optimized out>
> err_src = 0x541a83 "TLS read:"
> x = <value optimized out>
> #15 0x08158ade in tcp_read_headers (c=0xb621af88, read_flags=0xbf91e200)
> at tcp_read.c:406
> bytes = -1
> remaining = <value optimized out>
> p = <value optimized out>
> r = (struct tcp_req *) 0xb621affc
> #16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204,
> read_flags=0xbf91e200) at tcp_read.c:871
> bytes = <value optimized out>
> total_bytes = 0
> resp = <value optimized out>
> size = <value optimized out>
> req = (struct tcp_req *) 0xb621affc
> dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data =
> "\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family =
> 57540,
> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port =
> 49041,
> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 =
> {0, 0, 16, 0, 1, 0,
> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}}, id =
> -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask = 0
> '\0'}}
> c = 10 '\n'
> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
> tcp_read.c:1150
> ret = 4
> n = 4
> read_flags = 1
> con = (struct tcp_connection *) 0xb621af88
> s = 12
> resp = <value optimized out>
> t = <value optimized out>
> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
> No locals.
> ---Type <return> to continue, or q <return> to quit---
> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
> r = 3
> reader_fd_1 = 35
> pid = <value optimized out>
> si = <value optimized out>
> #20 0x080ad412 in main_loop () at main.c:1632
> i = 4
> pid = <value optimized out>
> si = (struct socket_info *) 0x0
> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
> \000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted DWARF
> expression.
> ) at main.c:2398
> cfg_stream = (FILE *) 0x8a2d008
> c = <value optimized out>
> r = 0
> tmp = 0xbf91e674
> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
> tmp_len = 10492229
> port = 136192361
> proto = -1080957480
> ret = <value optimized out>
> seed = 21782655
> rfd = 4
> debug_save = <value optimized out>
> debug_flag = 0
> dont_fork_cnt = 0
> n_lst = <value optimized out>
> p = <value optimized out>
>
>
> Best Regards
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120717/7b0376d1/attachment-0001.htm>
From ushacked at gmail.com Wed Jul 18 07:20:47 2012
From: ushacked at gmail.com (Uri Shacked)
Date: Wed, 18 Jul 2012 08:20:47 +0300
Subject: [SR-Users] Reply 503 was replaced to 500
In-Reply-To: <50059E78.2090809@gmail.com>
References: <CAMMbDhR=rL=1rJPE5VABO7zE_oDbq7DieViHUtrhsdYv91n+Qg@mail.gmail.com>
<CAMMbDhQpvT-1_=njE2hq1EhVfX6MBTOTMs+dATbRojV5NNxhVA@mail.gmail.com>
<4FE81250.5070705@gmail.com>
<CAMMbDhT-zi0UZ3kRUzdLm1fTsutz+fk050TvAamMV=DNV5HdCg@mail.gmail.com>
<50059E78.2090809@gmail.com>
Message-ID: <CAMMbDhTUZVS_quLqQVD3dVk0nb0bS4xuMKyCUs97LDPeXPiRSQ@mail.gmail.com>
Hi
I tried the "change_reply_status".
The problem with it is that i need to do "append_to_reply" as well. The
first one can be called only on the "on reply" route, and the second on the
"on failure" route.
And as i notice, doing "append_to_reply" with no "t_reply" does not really
append anything... so it looks like I will have to do "t_reply" and deal
with the to_tag later.
Thanks,
Uri
On Tue, Jul 17, 2012 at 8:18 PM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:
> Hello,
>
> sending a >=300 reply is for an not-established dialog, which eventually
> can be forked by proxy, meaning many 1xx replies can get to caller, then
> many >=300 replies can get to the proxy which will chose which one to use
> for sending back to the caller.
>
> Doing a t_reply(...) with a different code than the received one is like
> having two branch, one locally and one from where the reply is received,
> but you decide to reply from the local one. So if the caller device has
> problems with this case, the it will have problems with serial/parallel
> forking.
>
> For accounting you can save incoming to-tag in an avp and store it in a
> separate column in acc table. But setting the to-tag for t_reply() is not
> possible at this time.
>
> Btw, have you tried instead the change_reply_status() function?
>
>
> http://kamailio.org/docs/modules/stable/modules/textopsx.html#textopsx.change_reply_status
>
> Cheers,
> Daniel
>
>
> On 7/17/12 2:23 PM, Uri Shacked wrote:
>
> Hi,
>
> Here is the problem with the solution to sending different reply then the
> once I receive:
>
>
>
> I check if the reply is 603. If so, i did t_drop_replies and then t_reply
> with the reply i wanted to send back. 500 with append_to_reply something....
>
>
>
> The problem is that on the 500 that i send back, the to_tag is not the
> same to_tag that i received with the 603.
>
> That makes some problems on the sip and lots of problems on the CDR
> creation (it is based on to_tag as well).
>
>
>
> Any ideas?
>
> How do i make it the same to_tag? Removing a header and recreating it
> seems very dirty for it.....
>
>
>
> BR,
>
> Uri
> On Mon, Jun 25, 2012 at 10:25 AM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Hello,
>>
>> this 503 to 500 is a requirement from RFC, to prevent propagation of
>> blacklisting/disabling destination hosts. I don't remember right now any
>> configuration option for it, but you can try to enforce it from the failure
>> route, like:
>>
>> t_reply("503", "...");
>>
>> Cheers,
>> Daniel
>>
>>
>> On 6/24/12 4:30 PM, Uri Shacked wrote:
>>
>> I just read the topic - "*Copy reason field from 503 to 500. * "
>> Is there a way to change it if i want to send back the original leg 2 503
>> reply?
>>
>> On Sun, Jun 24, 2012 at 4:17 PM, Uri Shacked <ushacked at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Kamailio server is behind our company's softswitch and acts as a sip
>>> application server.
>>> I notice that there are calls that the softswitch replied with 503
>>> "service unavailable" and kamailio sent to the originator leg 500 "service
>>> unavaileable".
>>> When kamailio recieved 504 or 502 it sends them back as is. shouldn't it
>>> be the same with 503?
>>>
>>> It also does not have a "to tag" in the CDR. And the "to tag" in the 503
>>> that was recieved is not equal to the 500 reply "to tag" kamailio sent
>>> back.
>>>
>>> any ideas?
>>>
>>> BR,
>>> Uri
>>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/12fd981e/attachment.htm>
From miconda at gmail.com Wed Jul 18 07:54:34 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 18 Jul 2012 07:54:34 +0200
Subject: [SR-Users] Reply 503 was replaced to 500
In-Reply-To: <CAMMbDhTUZVS_quLqQVD3dVk0nb0bS4xuMKyCUs97LDPeXPiRSQ@mail.gmail.com>
References: <CAMMbDhR=rL=1rJPE5VABO7zE_oDbq7DieViHUtrhsdYv91n+Qg@mail.gmail.com>
<CAMMbDhQpvT-1_=njE2hq1EhVfX6MBTOTMs+dATbRojV5NNxhVA@mail.gmail.com>
<4FE81250.5070705@gmail.com>
<CAMMbDhT-zi0UZ3kRUzdLm1fTsutz+fk050TvAamMV=DNV5HdCg@mail.gmail.com>
<50059E78.2090809@gmail.com>
<CAMMbDhTUZVS_quLqQVD3dVk0nb0bS4xuMKyCUs97LDPeXPiRSQ@mail.gmail.com>
Message-ID: <50064F9A.7020405@gmail.com>
Hello,
you have to use append_hf() in the onreply route.
Cheers,
Daniel
On 7/18/12 7:20 AM, Uri Shacked wrote:
>
> Hi
>
> I tried the "change_reply_status".
>
> The problem with it is that i need to do "append_to_reply" as well.
> The first one can be called only on the "on reply" route, and the
> second on the "on failure" route.
>
> And as i notice, doing "append_to_reply" with no "t_reply" does not
> really append anything... so it looks like I will have to do "t_reply"
> and deal with the to_tag later.
>
> Thanks,
>
> Uri
>
> On Tue, Jul 17, 2012 at 8:18 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
> Hello,
>
> sending a >=300 reply is for an not-established dialog, which
> eventually can be forked by proxy, meaning many 1xx replies can
> get to caller, then many >=300 replies can get to the proxy which
> will chose which one to use for sending back to the caller.
>
> Doing a t_reply(...) with a different code than the received one
> is like having two branch, one locally and one from where the
> reply is received, but you decide to reply from the local one. So
> if the caller device has problems with this case, the it will have
> problems with serial/parallel forking.
>
> For accounting you can save incoming to-tag in an avp and store it
> in a separate column in acc table. But setting the to-tag for
> t_reply() is not possible at this time.
>
> Btw, have you tried instead the change_reply_status() function?
>
> http://kamailio.org/docs/modules/stable/modules/textopsx.html#textopsx.change_reply_status
>
> Cheers,
> Daniel
>
>
> On 7/17/12 2:23 PM, Uri Shacked wrote:
>>
>> Hi,
>>
>> Here is the problem with the solution to sending different reply
>> then the once I receive:
>>
>> I check if the reply is 603. If so, i did t_drop_replies and then
>> t_reply with the reply i wanted to send back. 500 with
>> append_to_reply something....
>>
>> The problem is that on the 500 that i send back, the to_tag is
>> not the same to_tag that i received with the 603.
>>
>> That makes some problems on the sip and lots of problems on the
>> CDR creation (it is based on to_tag as well).
>>
>> Any ideas?
>>
>> How do i make it the same to_tag? Removing a header and
>> recreating it seems very dirty for it.....
>>
>> BR,
>>
>> Uri
>>
>> On Mon, Jun 25, 2012 at 10:25 AM, Daniel-Constantin Mierla
>> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>> Hello,
>>
>> this 503 to 500 is a requirement from RFC, to prevent
>> propagation of blacklisting/disabling destination hosts. I
>> don't remember right now any configuration option for it, but
>> you can try to enforce it from the failure route, like:
>>
>> t_reply("503", "...");
>>
>> Cheers,
>> Daniel
>>
>>
>> On 6/24/12 4:30 PM, Uri Shacked wrote:
>>> I just read the topic - "_Copy reason field from 503 to 500. _"
>>> Is there a way to change it if i want to send back the
>>> original leg 2 503 reply?
>>>
>>> On Sun, Jun 24, 2012 at 4:17 PM, Uri Shacked
>>> <ushacked at gmail.com <mailto:ushacked at gmail.com>> wrote:
>>>
>>> Hi,
>>> Kamailio server is behind our company's softswitch and
>>> acts as a sip application server.
>>> I notice that there are calls that the softswitch
>>> replied with 503 "service unavailable" and kamailio sent
>>> to the originator leg 500 "service unavaileable".
>>> When kamailio recieved 504 or 502 it sends them back as
>>> is. shouldn't it be the same with 503?
>>> It also does not have a "to tag" in the CDR. And the "to
>>> tag" in the 503 that was recieved is not equal to the
>>> 500 reply "to tag" kamailio sent back.
>>> any ideas?
>>> BR,
>>> Uri
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla -http://www.asipto.com <http://www.asipto.com/>
>> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com <http://www.asipto.com/>
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/15a5c771/attachment-0001.htm>
From ali.stgt at gmail.com Wed Jul 18 09:29:19 2012
From: ali.stgt at gmail.com (=?UTF-8?B?RHVybXXFnyBBbGkgw5Z6dMO8cms=?=)
Date: Wed, 18 Jul 2012 10:29:19 +0300
Subject: [SR-Users] Presence Subscription / Subscription-State: pending
Message-ID: <CAFNHZwerMerJRJKhrEYL6dA4B1gacCF2B80xSqfb6B83RUXBxw@mail.gmail.com>
Hi All,
I am trying to subscribe to the presence event but unfortunaly I am getting
following Notify with the "Subscription-State: pending" status.
NOTIFY sip:5000 at 192.168.127.138:55583 SIP/2.0
Via: SIP/2.0/UDP 192.168.127.230;branch=z9hG4bK6a8e.19cd7bb7.0
To: sip:5000 at 192.168.127.230;tag=2786be25cb234561b8dea2e067fd769c-5000
From: sip:5000 at 192.168.127.230;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6a8e
CSeq: 2 NOTIFY
Call-ID: e4ec6031-99e1-de11-8845-5000 at vvt-laptop
Content-Length: 0
User-Agent: kamailio (3.2.3 (i386/linux))
Max-Forwards: 70
Event: presence
Contact: <sip:192.168.127.230:5060;transport=udp>
Subscription-State: pending;expires=3670
For the implemantation I followed the guide from
http://kb.asipto.com/kamailio:presence:k31-made-simple
The xcap table has already the needed resource-lists and pres-rules record.
Is there another guide exists for the presence module which can be
helpfully for me?
Thank you in advance
ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/ac614725/attachment.htm>
From vijay.thakur at loopmethods.com Wed Jul 18 13:38:28 2012
From: vijay.thakur at loopmethods.com (Vijay Thakur)
Date: Wed, 18 Jul 2012 17:08:28 +0530
Subject: [SR-Users] Compile Kamailio from Source with STUN
Message-ID: <5006A034.3@loopmethods.com>
Dear All Experts,
I am following the steps given at
http://kb.asipto.com/kamailio:presence:k31-made-simple. I want to
compile kamailio with stun support. So guide me that what will be the
command to do it. As per the
given command :
*make PREFIX=/usr/local/kamailio-3.1-xcap FLAVOUR=kamailio \
include_modules="db_mysql presence presence_xml xhttp xcap_server" cfg
what text should i use to make stun module.
*
--
Best Regards,
Vijay Thakur
(Assistant Manager - Networks)
Mobile : +91 8744018065
Mail : vijay.thakur at loopmethods.com
Loop IT Methods Private Limited
1st Floor, B-10, Sector-7, Noida, (U.P) India
Ph: +91 120 305 3481,82 (INDIA), +1 347 468 8631 (USA), +61 390 011 178 (AUS)
Fax: +91 971 728 330
Web: www.loopmethods.com
LOOP Disclaimer -------------------------------------------------------------------------------------------------
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.
-----------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/b021a344/attachment.htm>
From miconda at gmail.com Wed Jul 18 18:34:58 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 18 Jul 2012 18:34:58 +0200
Subject: [SR-Users] Compile Kamailio from Source with STUN
In-Reply-To: <5006A034.3@loopmethods.com>
References: <5006A034.3@loopmethods.com>
Message-ID: <5006E5B2.3070505@gmail.com>
Hello,
if you want to enable the STUN code from the core, you have to add
STUN=1 to make command.
If you look to deploy a stun server, then there are several options out
there, one being part of baresip project, then mystun, etc ...
Cheers,
Daniel
On 7/18/12 1:38 PM, Vijay Thakur wrote:
> Dear All Experts,
>
> I am following the steps given at
> http://kb.asipto.com/kamailio:presence:k31-made-simple. I want to
> compile kamailio with stun support. So guide me that what will be the
> command to do it. As per the
> given command :
>
> *make PREFIX=/usr/local/kamailio-3.1-xcap FLAVOUR=kamailio \
> include_modules="db_mysql presence presence_xml xhttp xcap_server" cfg
>
> what text should i use to make stun module.
> *
>
> --
> Best Regards,
>
> Vijay Thakur
> (Assistant Manager - Networks)
> Mobile : +91 8744018065
> Mail :vijay.thakur at loopmethods.com
>
> Loop IT Methods Private Limited
> 1st Floor, B-10, Sector-7, Noida, (U.P) India
> Ph: +91 120 305 3481,82 (INDIA), +1 347 468 8631 (USA), +61 390 011 178 (AUS)
> Fax: +91 971 728 330
> Web:www.loopmethods.com
>
> LOOP Disclaimer -------------------------------------------------------------------------------------------------
> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.
> -----------------------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/b213b4b1/attachment.htm>
From miconda at gmail.com Wed Jul 18 18:38:10 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 18 Jul 2012 18:38:10 +0200
Subject: [SR-Users] Presence Subscription / Subscription-State: pending
In-Reply-To: <CAFNHZwerMerJRJKhrEYL6dA4B1gacCF2B80xSqfb6B83RUXBxw@mail.gmail.com>
References: <CAFNHZwerMerJRJKhrEYL6dA4B1gacCF2B80xSqfb6B83RUXBxw@mail.gmail.com>
Message-ID: <5006E672.10707@gmail.com>
Hello,
when you updated the presence rules via xcap, did you executed the
function to update the notifiers as well? I mean the two function at:
http://kamailio.org/docs/modules/stable/modules_k/presence.html#id2496049
Cheers,
Daniel
On 7/18/12 9:29 AM, Durmu? Ali ?zt?rk wrote:
> Hi All,
>
> I am trying to subscribe to the presence event but unfortunaly I am
> getting following Notify with the "Subscription-State: pending" status.
>
> NOTIFY sip:5000 at 192.168.127.138:55583
> <http://sip:5000 at 192.168.127.138:55583> SIP/2.0
> Via: SIP/2.0/UDP 192.168.127.230;branch=z9hG4bK6a8e.19cd7bb7.0
> To: sip:5000 at 192.168.127.230
> <mailto:sip%3A5000 at 192.168.127.230>;tag=2786be25cb234561b8dea2e067fd769c-5000
> From: sip:5000 at 192.168.127.230
> <mailto:sip%3A5000 at 192.168.127.230>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6a8e
> CSeq: 2 NOTIFY
> Call-ID: e4ec6031-99e1-de11-8845-5000 at vvt-laptop
> Content-Length: 0
> User-Agent: kamailio (3.2.3 (i386/linux))
> Max-Forwards: 70
> Event: presence
> Contact: <sip:192.168.127.230:5060;transport=udp>
> Subscription-State: pending;expires=3670
>
>
> For the implemantation I followed the guide from
> http://kb.asipto.com/kamailio:presence:k31-made-simple
>
> The xcap table has already the needed resource-lists and pres-rules
> record.
>
> Is there another guide exists for the presence module which can be
> helpfully for me?
>
> Thank you in advance
> ali
>
>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/5ad4929c/attachment.htm>
From miconda at gmail.com Wed Jul 18 18:42:23 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 18 Jul 2012 18:42:23 +0200
Subject: [SR-Users] [sr-dev] kamailio core at qm_status
In-Reply-To: <CAOYmDE9whUjcjy=8bFV0MpS45rmKdjacOw1CTDUkS1h9RYSGZg@mail.gmail.com>
References: <CAOYmDE-ZAFWUNawKMRyPwSwgUe9XuYfVF7HS-o_Ggv5g0suR0g@mail.gmail.com>
<20120716171251.1764894c@quenya>
<CAOYmDE9+tpmvDRBEqD2Bqv879Xi+A+YLm9oQApsH+kMtiCV+tw@mail.gmail.com>
<50050F08.9060707@gmail.com>
<CAOYmDE9whUjcjy=8bFV0MpS45rmKdjacOw1CTDUkS1h9RYSGZg@mail.gmail.com>
Message-ID: <5006E76F.9030300@gmail.com>
Hello,
sorry, I just read the last messages in the thread and I didn't noticed
it is about a crash, but thought it is about an annoying log message.
The backtrace is no longer matching the latest sources of the 3.1
branch, but I expect it is due to a double free issue, so you have to
update to latest 3.1.6, as suggested by other users here. There were
many fixes from 3.1.0 to 3.1.6.
Cheers,
Daniel
On 7/17/12 6:03 PM, Jijo wrote:
> Hi,
>
> This is not happening at shutdown or status check. Its aborting when
> the system is active.
>
> Thanks
> Jijo
> On Tue, Jul 17, 2012 at 3:06 AM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
> Hello,
>
> does it keep being or it is one time and that's it?
>
> That is printed at shut down or if pkg_status() or shm_status() is
> executed from some part of code or in config via cfgutils module
> functions.
>
> You can get rid of them by setting memdbg and memlog to a value
> higher than debug global parameter.
>
> Cheers,
> Daniel
>
>
> On 7/16/12 5:28 PM, Jijo wrote:
>> Thanks.. It is not easy to upgrade as it is happening at customer
>> system.
>> Is there any change occurred for this issue.I looked at it, but
>> didn't see anything in q_malloc.c/qm_status()
>>
>>
>> On Mon, Jul 16, 2012 at 11:12 AM, Jon Bonilla
>> <manwe at aholab.ehu.es <mailto:manwe at aholab.ehu.es>> wrote:
>>
>> El Mon, 16 Jul 2012 10:27:42 -0400
>> Jijo <realjijo at gmail.com <mailto:realjijo at gmail.com>> escribi?:
>>
>> > Hi All,
>> >
>> > I'm observing a core intermittently at "qm_status
>> (qm=0x786cd000) at
>> > mem/q_malloc.c:763" for kamailio version 3.1.0
>> >
>>
>> I'd say that you're using a very old version. You should
>> update your branch to
>> 3.1.6 or upgrade to a newer branch.
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/f9266fb6/attachment-0001.htm>
From renan.capaverde at digitro.com.br Wed Jul 18 21:03:59 2012
From: renan.capaverde at digitro.com.br (Renan Capaverde)
Date: Wed, 18 Jul 2012 16:03:59 -0300
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
Message-ID: <5007089F.708@digitro.com.br>
I am having the same problem on kamailio 3.1.6. Someone please help.
Cheers,
Renan
Em 17/7/2012 14:26, Bruno Bresciani escreveu:
> Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
>
> Best Regards
>
>
> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> send also the version 'kamailio -V' to match the proper sources.
>
> Cheers,
> Daniel
>
>
> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>> Hi all,
>>
>> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536.
>>
>> I don't know exactly what may be caused this core because the
>> debug of kamailio is disabled, but looking at backtrace (gdb) and
>> source code I could notice a relationship with TLS connection
>> establishment (handshake). Other important fact is that core was
>> generated by the kamalio itself with signal 6 (abort) because it
>> can't find the pointer to memory realloc.
>> I'd like to know if someone already observed this issue and if my
>> analyse above is correct?
>>
>> Bellow is backtrace full with gdb:
>>
>> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>> /var/run/kamailio.pid'.
>> Program terminated with signal 6, Aborted.
>> #0 0x00f30402 in __kernel_vsyscall ()
>> (gdb)
>> (gdb)
>> (gdb)
>> (gdb)
>> (gdb) bt full
>> #0 0x00f30402 in __kernel_vsyscall ()
>> No symbol table info available.
>> #1 0x009fec10 in raise () from /lib/libc.so.6
>> No symbol table info available.
>> #2 0x00a00521 in abort () from /lib/libc.so.6
>> No symbol table info available.
>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0,
>> size=0) at mem/f_malloc.c:536
>> f = (struct fm_frag *) 0xb61f0bb8
>> pf = <value optimized out>
>> orig_size = 18
>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>> ptr = <value optimized out>
>> hash = 23548
>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
>> ../../mem/shm_mem.h:266
>> No locals.
>> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
>> No symbol table info available.
>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>> No symbol table info available.
>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>> No symbol table info available.
>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>> No symbol table info available.
>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
>> No symbol table info available.
>> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
>> No symbol table info available.
>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>> No symbol table info available.
>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>> No symbol table info available.
>> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
>> tls_server.c:346
>> ret = <value optimized out>
>> ssl = (SSL *) 0xb61c1878
>> cert = <value optimized out>
>> tls_c = (struct tls_extra_data *) 0xb6208e58
>> tls_log = <value optimized out>
>> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
>> tls_server.c:1028
>> r = (struct tcp_req *) 0xb621affc
>> bytes_free = 4095
>> bytes_read = 70
>> read_size = 4095
>> ssl_error = 0
>> ssl_read = 0
>> ssl = (SSL *) 0xb61c1878
>> rd_buf =
>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>> wr_buf =
>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used =
>> 70, size = 65536}
>> wr = {
>> buf = 0xbf8fdfa4
>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>> pos = 0, used = 0,
>> size = 65536}
>> tls_c = (struct tls_extra_data *) 0xb6208e58
>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>> n = 0
>> flush_flags = <value optimized out>
>> err_src = 0x541a83 "TLS read:"
>> x = <value optimized out>
>> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
>> read_flags=0xbf91e200) at tcp_read.c:406
>> bytes = -1
>> remaining = <value optimized out>
>> p = <value optimized out>
>> r = (struct tcp_req *) 0xb621affc
>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88,
>> bytes_read=0xbf91e204, read_flags=0xbf91e200) at tcp_read.c:871
>> bytes = <value optimized out>
>> total_bytes = 0
>> resp = <value optimized out>
>> size = <value optimized out>
>> req = (struct tcp_req *) 0xb621affc
>> dst = {send_sock = 0x1, to = {s = {sa_family = 57540,
>> sa_data = "\221??\020\000\000\000\000\000\000\000\020\000\000"},
>> sin = {sin_family = 57540,
>> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
>> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540,
>> sin6_port = 49041,
>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000",
>> u6_addr16 = {0, 0, 16, 0, 1, 0,
>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id =
>> 12}}, id = -1080958468, proto = 4 '\004', send_flags = {f = 0
>> '\0', blst_imask = 0 '\0'}}
>> c = 10 '\n'
>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
>> tcp_read.c:1150
>> ret = 4
>> n = 4
>> read_flags = 1
>> con = (struct tcp_connection *) 0xb621af88
>> s = 12
>> resp = <value optimized out>
>> t = <value optimized out>
>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
>> No locals.
>> ---Type <return> to continue, or q <return> to quit---
>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>> r = 3
>> reader_fd_1 = 35
>> pid = <value optimized out>
>> si = <value optimized out>
>> #20 0x080ad412 in main_loop () at main.c:1632
>> i = 4
>> pid = <value optimized out>
>> si = (struct socket_info *) 0x0
>> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
>> <http://192.168.166.31:5060>\000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address:
>> Corrupted DWARF expression.
>> ) at main.c:2398
>> cfg_stream = (FILE *) 0x8a2d008
>> c = <value optimized out>
>> r = 0
>> tmp = 0xbf91e674
>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>> tmp_len = 10492229
>> port = 136192361
>> proto = -1080957480
>> ret = <value optimized out>
>> seed = 21782655
>> rfd = 4
>> debug_save = <value optimized out>
>> debug_flag = 0
>> dont_fork_cnt = 0
>> n_lst = <value optimized out>
>> p = <value optimized out>
>>
>>
>> Best Regards
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/99cc519d/attachment-0001.htm>
From miconda at gmail.com Thu Jul 19 09:15:58 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 19 Jul 2012 09:15:58 +0200
Subject: [SR-Users] Presence Subscription / Subscription-State: pending
In-Reply-To: <CAFNHZwfKWTWv2T4XDurHvy3y3PL_m=A2HLraNs2h1tMQX3aK5Q@mail.gmail.com>
References: <CAFNHZwerMerJRJKhrEYL6dA4B1gacCF2B80xSqfb6B83RUXBxw@mail.gmail.com>
<5006E672.10707@gmail.com>
<CAFNHZwfKWTWv2T4XDurHvy3y3PL_m=A2HLraNs2h1tMQX3aK5Q@mail.gmail.com>
Message-ID: <5007B42E.6060101@gmail.com>
Hello,
please keep the mailing list cc-ed, private emails from mailing list
discussions will be ignored.
On 7/19/12 8:28 AM, Durmu? Ali ?zt?rk wrote:
> Hi Daniel,
>
> Thank you for your advise. I have found the problem, I thought it is
> enough to subscribe with my own ID but fact is I have to subscribe to
> the buddies of my contact list.This was not clear for me at the beginning.
ok, great you found it.
>
> It is better to subscribe only to the presence.wmi? Or should I
> susbcribe to presence and presence.wmi?
Do you mean presence mwi? mwi is for message waiting indication, like
voicemail, so you get notifications when someone leaves you a message on
the media server.
Cheers,
Daniel
>
> Best Regards,
> Ali
>
> 2012/7/18 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> when you updated the presence rules via xcap, did you executed the
> function to update the notifiers as well? I mean the two function at:
>
> http://kamailio.org/docs/modules/stable/modules_k/presence.html#id2496049
>
> Cheers,
> Daniel
>
>
>
> On 7/18/12 9:29 AM, Durmu? Ali ?zt?rk wrote:
>> Hi All,
>>
>> I am trying to subscribe to the presence event but unfortunaly I
>> am getting following Notify with the "Subscription-State:
>> pending" status.
>>
>> NOTIFY sip:5000 at 192.168.127.138:55583
>> <http://sip:5000 at 192.168.127.138:55583> SIP/2.0
>> Via: SIP/2.0/UDP 192.168.127.230;branch=z9hG4bK6a8e.19cd7bb7.0
>> To: sip:5000 at 192.168.127.230
>> <mailto:sip%3A5000 at 192.168.127.230>;tag=2786be25cb234561b8dea2e067fd769c-5000
>> From: sip:5000 at 192.168.127.230
>> <mailto:sip%3A5000 at 192.168.127.230>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6a8e
>> CSeq: 2 NOTIFY
>> Call-ID: e4ec6031-99e1-de11-8845-5000 at vvt-laptop
>> Content-Length: 0
>> User-Agent: kamailio (3.2.3 (i386/linux))
>> Max-Forwards: 70
>> Event: presence
>> Contact: <sip:192.168.127.230:5060;transport=udp>
>> Subscription-State: pending;expires=3670
>>
>>
>> For the implemantation I followed the guide from
>> http://kb.asipto.com/kamailio:presence:k31-made-simple
>>
>> The xcap table has already the needed resource-lists
>> and pres-rules record.
>>
>> Is there another guide exists for the presence module which can
>> be helpfully for me?
>>
>> Thank you in advance
>> ali
>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120719/efc0190d/attachment.htm>
From miconda at gmail.com Thu Jul 19 09:18:35 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 19 Jul 2012 09:18:35 +0200
Subject: [SR-Users] planning release of v3.2.4
In-Reply-To: <5003E38E.4030004@gmail.com>
References: <5003E38E.4030004@gmail.com>
Message-ID: <5007B4CB.20405@gmail.com>
Hello,
quick note to remind about the release of v3.2.4 later today. After
12:00GMT till the release is done, please write a short note on sr-dev
if you have to commit in branch 3.2.
Cheers,
Daniel
On 7/16/12 11:49 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> later this week (like Thursday) I am considering packaging v3.2.4 from
> the latest git branch 3.2. If anyone has patches to push it there,
> please do it asap in case you want them in this release.
>
> Cheers,
> Daniel
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From jason.penton at smilecoms.com Thu Jul 19 09:34:14 2012
From: jason.penton at smilecoms.com (Jason Penton)
Date: Thu, 19 Jul 2012 09:34:14 +0200
Subject: [SR-Users] Presence Subscription / Subscription-State: pending
In-Reply-To: <5007B42E.6060101@gmail.com>
References: <CAFNHZwerMerJRJKhrEYL6dA4B1gacCF2B80xSqfb6B83RUXBxw@mail.gmail.com>
<5006E672.10707@gmail.com>
<CAFNHZwfKWTWv2T4XDurHvy3y3PL_m=A2HLraNs2h1tMQX3aK5Q@mail.gmail.com>
<5007B42E.6060101@gmail.com>
Message-ID: <CAE=Kcriv=YFSKsx2sicVazv3vH_HDgDyT_bHZ7iLq98mtBz=dg@mail.gmail.com>
ok cool
On Thu, Jul 19, 2012 at 9:15 AM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:
> Hello,
>
> please keep the mailing list cc-ed, private emails from mailing list
> discussions will be ignored.
>
> On 7/19/12 8:28 AM, Durmu? Ali ?zt?rk wrote:
>
> Hi Daniel,
>
> Thank you for your advise. I have found the problem, I thought it is
> enough to subscribe with my own ID but fact is I have to subscribe to the
> buddies of my contact list.This was not clear for me at the beginning.
>
> ok, great you found it.
>
>
> It is better to subscribe only to the presence.wmi? Or should I
> susbcribe to presence and presence.wmi?
>
>
> Do you mean presence mwi? mwi is for message waiting indication, like
> voicemail, so you get notifications when someone leaves you a message on
> the media server.
>
> Cheers,
> Daniel
>
>
> Best Regards,
> Ali
>
>
> 2012/7/18 Daniel-Constantin Mierla <miconda at gmail.com>
>
>> Hello,
>>
>> when you updated the presence rules via xcap, did you executed the
>> function to update the notifiers as well? I mean the two function at:
>>
>> http://kamailio.org/docs/modules/stable/modules_k/presence.html#id2496049
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> On 7/18/12 9:29 AM, Durmu? Ali ?zt?rk wrote:
>>
>> Hi All,
>>
>> I am trying to subscribe to the presence event but unfortunaly I am
>> getting following Notify with the "Subscription-State: pending" status.
>>
>> NOTIFY sip:5000 at 192.168.127.138:55583 SIP/2.0
>> Via: SIP/2.0/UDP 192.168.127.230;branch=z9hG4bK6a8e.19cd7bb7.0
>> To: sip:5000 at 192.168.127.230;tag=2786be25cb234561b8dea2e067fd769c-5000
>> From: sip:5000 at 192.168.127.230;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6a8e
>> CSeq: 2 NOTIFY
>> Call-ID: e4ec6031-99e1-de11-8845-5000 at vvt-laptop
>> Content-Length: 0
>> User-Agent: kamailio (3.2.3 (i386/linux))
>> Max-Forwards: 70
>> Event: presence
>> Contact: <sip:192.168.127.230:5060;transport=udp>
>> Subscription-State: pending;expires=3670
>>
>>
>> For the implemantation I followed the guide from
>> http://kb.asipto.com/kamailio:presence:k31-made-simple
>>
>> The xcap table has already the needed resource-lists and pres-rules
>> record.
>>
>> Is there another guide exists for the presence module which can be
>> helpfully for me?
>>
>> Thank you in advance
>> ali
>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
> _______________________________________________
> 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
>
>
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120719/ea04f656/attachment-0001.htm>
From ali.stgt at gmail.com Thu Jul 19 13:01:48 2012
From: ali.stgt at gmail.com (=?UTF-8?B?RHVybXXFnyBBbGkgw5Z6dMO8cms=?=)
Date: Thu, 19 Jul 2012 14:01:48 +0300
Subject: [SR-Users] Presence Subscription / Subscription-State: pending
In-Reply-To: <CAE=Kcriv=YFSKsx2sicVazv3vH_HDgDyT_bHZ7iLq98mtBz=dg@mail.gmail.com>
References: <CAFNHZwerMerJRJKhrEYL6dA4B1gacCF2B80xSqfb6B83RUXBxw@mail.gmail.com>
<5006E672.10707@gmail.com>
<CAFNHZwfKWTWv2T4XDurHvy3y3PL_m=A2HLraNs2h1tMQX3aK5Q@mail.gmail.com>
<5007B42E.6060101@gmail.com>
<CAE=Kcriv=YFSKsx2sicVazv3vH_HDgDyT_bHZ7iLq98mtBz=dg@mail.gmail.com>
Message-ID: <CAFNHZweGXr+-oL-cmOYSmjrigAQMy36Tt5moq1JAkue=nzp6hg@mail.gmail.com>
Hi Daniel,
Not mwi, presence.winfo I have mean.
Thank you.
2012/7/19 Jason Penton <jason.penton at smilecoms.com>
> ok cool
>
>
> On Thu, Jul 19, 2012 at 9:15 AM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Hello,
>>
>> please keep the mailing list cc-ed, private emails from mailing list
>> discussions will be ignored.
>>
>> On 7/19/12 8:28 AM, Durmu? Ali ?zt?rk wrote:
>>
>> Hi Daniel,
>>
>> Thank you for your advise. I have found the problem, I thought it is
>> enough to subscribe with my own ID but fact is I have to subscribe to the
>> buddies of my contact list.This was not clear for me at the beginning.
>>
>> ok, great you found it.
>>
>>
>> It is better to subscribe only to the presence.wmi? Or should I
>> susbcribe to presence and presence.wmi?
>>
>>
>> Do you mean presence mwi? mwi is for message waiting indication, like
>> voicemail, so you get notifications when someone leaves you a message on
>> the media server.
>>
>> Cheers,
>> Daniel
>>
>>
>> Best Regards,
>> Ali
>>
>>
>> 2012/7/18 Daniel-Constantin Mierla <miconda at gmail.com>
>>
>>> Hello,
>>>
>>> when you updated the presence rules via xcap, did you executed the
>>> function to update the notifiers as well? I mean the two function at:
>>>
>>> http://kamailio.org/docs/modules/stable/modules_k/presence.html#id2496049
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>>
>>> On 7/18/12 9:29 AM, Durmu? Ali ?zt?rk wrote:
>>>
>>> Hi All,
>>>
>>> I am trying to subscribe to the presence event but unfortunaly I am
>>> getting following Notify with the "Subscription-State: pending" status.
>>>
>>> NOTIFY sip:5000 at 192.168.127.138:55583 SIP/2.0
>>> Via: SIP/2.0/UDP 192.168.127.230;branch=z9hG4bK6a8e.19cd7bb7.0
>>> To: sip:5000 at 192.168.127.230;tag=2786be25cb234561b8dea2e067fd769c-5000
>>> From: sip:5000 at 192.168.127.230
>>> ;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6a8e
>>> CSeq: 2 NOTIFY
>>> Call-ID: e4ec6031-99e1-de11-8845-5000 at vvt-laptop
>>> Content-Length: 0
>>> User-Agent: kamailio (3.2.3 (i386/linux))
>>> Max-Forwards: 70
>>> Event: presence
>>> Contact: <sip:192.168.127.230:5060;transport=udp>
>>> Subscription-State: pending;expires=3670
>>>
>>>
>>> For the implemantation I followed the guide from
>>> http://kb.asipto.com/kamailio:presence:k31-made-simple
>>>
>>> The xcap table has already the needed resource-lists and pres-rules
>>> record.
>>>
>>> Is there another guide exists for the presence module which can be
>>> helpfully for me?
>>>
>>> Thank you in advance
>>> ali
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>> _______________________________________________
>> 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
>>
>>
> This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120719/48b22e6d/attachment.htm>
From malinux at gmail.com Thu Jul 19 13:12:02 2012
From: malinux at gmail.com (=?ISO-8859-1?Q?Martin_Schi=F8tz?=)
Date: Thu, 19 Jul 2012 13:12:02 +0200
Subject: [SR-Users] Kamailio as SBC and far end nat
Message-ID: <CAL6+JgLpdBrGWaGUh5K7y5GWMxakP25K76T7qJXA-Pye+rrE8Q@mail.gmail.com>
Hi
I'm trying to configure kamailio version 3.3.0 to be a Session Border
Controller which only purpose is to handle far-end-nat.
On the far end site I have a SIP client with IP '192.168.1.2' which is
NAT'ed to IP 'zz.zz.85.230'. The SIP ALG is disabled on the NAT
firewall. The SIP client is communicating with the kamailio server and
the Kamailio server is forwarding every thing to an Avaya SIP server
'xx.xx.173.15' and vice versa. The kamilio is konfigured to do this
stateless.
The REGISTER and SUBSCRIBE part works fine. The kamailio is using the
'Via:' field and I also needed to do subst on the 'Contact:' field in
order for our SIP server to communicate back to the kamailio. But when
I get to the NOTIFY packet from the SIP server to the kamailio there
is no 'Via:' field or any other information about the SIP clients
IP/port and the Kamailio just sends back 'SIP/2.0 404 Not here.' to
the SIP server.
I guess that this can not be solved with a statless kamailio?
I guess that I need some kind of state table in the kamailio - is that
possible without doing REGISTER directly with the kamailio?
Any other good ideas are welcome?
Cheers,
Martin
Tell me if need more info the issue?
-----
#
T xx.xx.173.15:38059 -> yy.yy.159.211:5060 [AP]
NOTIFY sip:2001012 at yy.yy.159.211:5060;transport=TCP SIP/2.0.
Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
From: "2001012"
<sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
CSeq: 3 NOTIFY.
Contact: <sip:xx.xx.173.14:15060>.
Via: SIP/2.0/TCP
xx.xx.173.15;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4.
Via: SIP/2.0/UDP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
Via: SIP/2.0/TCP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
Event: message-summary.
Content-Type: application/simple-message-summary.
Content-Length: 69.
Subscription-State: active;expires=299.
Max-Forwards: 68.
User-Agent: AVAYA-SM-6.1.4.0.614005.
.
Messages-Waiting: no.
Message-Account: sip:2001012 at bsosip.domain.dk.
##
T yy.yy.159.211:5060 -> xx.xx.173.15:38059 [AP]
SIP/2.0 404 Not here.
Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
From: "2001012"
<sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
CSeq: 3 NOTIFY.
Via: SIP/2.0/TCP
xx.xx.173.15;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4;rport=38059.
Via: SIP/2.0/UDP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
Via: SIP/2.0/TCP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
Server: kamailio (3.3.0 (i386/linux)).
Content-Length: 0.
.
#
T xx.xx.173.15:38059 -> yy.yy.159.211:5060 [A]
......
#
T yy.yy.159.211:5060 -> xx.xx.173.15:38059 [AP]
SIP/2.0 404 Not here.
Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
From: "2001012"
<sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
CSeq: 3 NOTIFY.
Via: SIP/2.0/TCP
xx.xx.173.15;rport=38059;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4.
Via: SIP/2.0/UDP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
Via: SIP/2.0/TCP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
Server: kamailio (3.3.0 (i386/linux)).
Content-Length: 0.
-----
From miconda at gmail.com Thu Jul 19 15:34:04 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 19 Jul 2012 15:34:04 +0200
Subject: [SR-Users] Presence Subscription / Subscription-State: pending
In-Reply-To: <CAFNHZweGXr+-oL-cmOYSmjrigAQMy36Tt5moq1JAkue=nzp6hg@mail.gmail.com>
References: <CAFNHZwerMerJRJKhrEYL6dA4B1gacCF2B80xSqfb6B83RUXBxw@mail.gmail.com>
<5006E672.10707@gmail.com>
<CAFNHZwfKWTWv2T4XDurHvy3y3PL_m=A2HLraNs2h1tMQX3aK5Q@mail.gmail.com>
<5007B42E.6060101@gmail.com>
<CAE=Kcriv=YFSKsx2sicVazv3vH_HDgDyT_bHZ7iLq98mtBz=dg@mail.gmail.com>
<CAFNHZweGXr+-oL-cmOYSmjrigAQMy36Tt5moq1JAkue=nzp6hg@mail.gmail.com>
Message-ID: <50080CCC.8010808@gmail.com>
Hello,
On 7/19/12 1:01 PM, Durmu? Ali ?zt?rk wrote:
> Hi Daniel,
>
> Not mwi, presence.winfo I have mean.
winfo is to watch the state of your watchers in regard to the relation
with you as presentity. presence event is to watch the states of your
buddy list contacts.
Usually, you have to watch both, first to know when someone wants to
watch you, second to see what your contacts are doing.
Cheers,
Daniel
>
> Thank you.
>
> 2012/7/19 Jason Penton <jason.penton at smilecoms.com
> <mailto:jason.penton at smilecoms.com>>
>
> ok cool
>
>
> On Thu, Jul 19, 2012 at 9:15 AM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
> Hello,
>
> please keep the mailing list cc-ed, private emails from
> mailing list discussions will be ignored.
>
> On 7/19/12 8:28 AM, Durmu? Ali ?zt?rk wrote:
>> Hi Daniel,
>>
>> Thank you for your advise. I have found the problem, I
>> thought it is enough to subscribe with my own ID but fact is
>> I have to subscribe to the buddies of my contact list.This
>> was not clear for me at the beginning.
> ok, great you found it.
>
>>
>> It is better to subscribe only to the presence.wmi? Or should
>> I susbcribe to presence and presence.wmi?
>
> Do you mean presence mwi? mwi is for message waiting
> indication, like voicemail, so you get notifications when
> someone leaves you a message on the media server.
>
> Cheers,
> Daniel
>>
>> Best Regards,
>> Ali
>>
>>
>> 2012/7/18 Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>>
>>
>> Hello,
>>
>> when you updated the presence rules via xcap, did you
>> executed the function to update the notifiers as well? I
>> mean the two function at:
>>
>> http://kamailio.org/docs/modules/stable/modules_k/presence.html#id2496049
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> On 7/18/12 9:29 AM, Durmu? Ali ?zt?rk wrote:
>>> Hi All,
>>>
>>> I am trying to subscribe to the presence event but
>>> unfortunaly I am getting following Notify with the
>>> "Subscription-State: pending" status.
>>>
>>> NOTIFY sip:5000 at 192.168.127.138:55583
>>> <http://sip:5000 at 192.168.127.138:55583> SIP/2.0
>>> Via: SIP/2.0/UDP
>>> 192.168.127.230;branch=z9hG4bK6a8e.19cd7bb7.0
>>> To: sip:5000 at 192.168.127.230
>>> <mailto:sip%3A5000 at 192.168.127.230>;tag=2786be25cb234561b8dea2e067fd769c-5000
>>> From: sip:5000 at 192.168.127.230
>>> <mailto:sip%3A5000 at 192.168.127.230>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6a8e
>>> CSeq: 2 NOTIFY
>>> Call-ID: e4ec6031-99e1-de11-8845-5000 at vvt-laptop
>>> Content-Length: 0
>>> User-Agent: kamailio (3.2.3 (i386/linux))
>>> Max-Forwards: 70
>>> Event: presence
>>> Contact: <sip:192.168.127.230:5060;transport=udp>
>>> Subscription-State: pending;expires=3670
>>>
>>>
>>> For the implemantation I followed the guide from
>>> http://kb.asipto.com/kamailio:presence:k31-made-simple
>>>
>>> The xcap table has already the needed resource-lists
>>> and pres-rules record.
>>>
>>> Is there another guide exists for the presence module
>>> which can be helpfully for me?
>>>
>>> Thank you in advance
>>> ali
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> mailing list
> sr-users at lists.sip-router.org
> <mailto:sr-users at lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> This email is subject to the disclaimer of Smile Communications (PTY) Ltd. athttp://www.smilecoms.com/disclaimer
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> sr-users at lists.sip-router.org <mailto:sr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120719/a60b0d64/attachment-0001.htm>
From miconda at gmail.com Thu Jul 19 15:40:58 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 19 Jul 2012 15:40:58 +0200
Subject: [SR-Users] Kamailio as SBC and far end nat
In-Reply-To: <CAL6+JgLpdBrGWaGUh5K7y5GWMxakP25K76T7qJXA-Pye+rrE8Q@mail.gmail.com>
References: <CAL6+JgLpdBrGWaGUh5K7y5GWMxakP25K76T7qJXA-Pye+rrE8Q@mail.gmail.com>
Message-ID: <50080E6A.2040102@gmail.com>
Hello,
for dialogs (like subscriptions or invites), you have to use record
routing (see rr module) -- so for initial subscribe/invite you have to
add record-route header in kamailio, then do loose routing for requests
within the dialog (like notify) -- the default config file coming with
kamailio has such logic there.
For registrations, I would suggest the usage of Path extensions, which
is an ietf rfc, but the registrar server has to support that (avaya sip
server in your case). Alternative will be to replace the contact in
register (you can do it for subscribe as well) requests with ip of
kamailio and a parameter that encodes the nat box ip/port.
A similar mechanism is used by add_contact_alias() function from
nathelper module to help going through nat -- you can actually use it in
conjunction with record routing for invites/subscriptions.
Cheers,
Daniel
On 7/19/12 1:12 PM, Martin Schi?tz wrote:
> Hi
>
> I'm trying to configure kamailio version 3.3.0 to be a Session Border
> Controller which only purpose is to handle far-end-nat.
>
> On the far end site I have a SIP client with IP '192.168.1.2' which is
> NAT'ed to IP 'zz.zz.85.230'. The SIP ALG is disabled on the NAT
> firewall. The SIP client is communicating with the kamailio server and
> the Kamailio server is forwarding every thing to an Avaya SIP server
> 'xx.xx.173.15' and vice versa. The kamilio is konfigured to do this
> stateless.
>
> The REGISTER and SUBSCRIBE part works fine. The kamailio is using the
> 'Via:' field and I also needed to do subst on the 'Contact:' field in
> order for our SIP server to communicate back to the kamailio. But when
> I get to the NOTIFY packet from the SIP server to the kamailio there
> is no 'Via:' field or any other information about the SIP clients
> IP/port and the Kamailio just sends back 'SIP/2.0 404 Not here.' to
> the SIP server.
>
> I guess that this can not be solved with a statless kamailio?
> I guess that I need some kind of state table in the kamailio - is that
> possible without doing REGISTER directly with the kamailio?
> Any other good ideas are welcome?
>
> Cheers,
> Martin
>
>
> Tell me if need more info the issue?
> -----
> #
> T xx.xx.173.15:38059 -> yy.yy.159.211:5060 [AP]
> NOTIFY sip:2001012 at yy.yy.159.211:5060;transport=TCP SIP/2.0.
> Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
> From: "2001012"
> <sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
> To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
> CSeq: 3 NOTIFY.
> Contact: <sip:xx.xx.173.14:15060>.
> Via: SIP/2.0/TCP
> xx.xx.173.15;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4.
> Via: SIP/2.0/UDP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
> Via: SIP/2.0/TCP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
> Event: message-summary.
> Content-Type: application/simple-message-summary.
> Content-Length: 69.
> Subscription-State: active;expires=299.
> Max-Forwards: 68.
> User-Agent: AVAYA-SM-6.1.4.0.614005.
> .
> Messages-Waiting: no.
> Message-Account: sip:2001012 at bsosip.domain.dk.
>
> ##
> T yy.yy.159.211:5060 -> xx.xx.173.15:38059 [AP]
> SIP/2.0 404 Not here.
> Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
> From: "2001012"
> <sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
> To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
> CSeq: 3 NOTIFY.
> Via: SIP/2.0/TCP
> xx.xx.173.15;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4;rport=38059.
> Via: SIP/2.0/UDP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
> Via: SIP/2.0/TCP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
> Server: kamailio (3.3.0 (i386/linux)).
> Content-Length: 0.
> .
>
> #
> T xx.xx.173.15:38059 -> yy.yy.159.211:5060 [A]
> ......
> #
> T yy.yy.159.211:5060 -> xx.xx.173.15:38059 [AP]
> SIP/2.0 404 Not here.
> Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
> From: "2001012"
> <sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
> To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
> CSeq: 3 NOTIFY.
> Via: SIP/2.0/TCP
> xx.xx.173.15;rport=38059;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4.
> Via: SIP/2.0/UDP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
> Via: SIP/2.0/TCP xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
> Server: kamailio (3.3.0 (i386/linux)).
> Content-Length: 0.
> -----
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Thu Jul 19 15:57:53 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 19 Jul 2012 15:57:53 +0200
Subject: [SR-Users] Kamailio v3.2.4 Released
Message-ID: <50081261.4070603@gmail.com>
Hello,
Kamailio v3.2.4 is out -- this is a minor release packaged from previous
stable branch, GIT 3.2. Anyone running 3.2.x should update to it in
order to benefit of latest fixes, there is no change required to be done
in database structure or configuration file, just re-install over the
old deployment. As usual, a backup is recommended to be in the safe side.
More details about this release at:
* http://www.kamailio.org/w/2012/07/kamailio-v3-2-4-released/
New installations should start with latest stable series 3.3.x, at this
time latest Kamailio version being v3.3.0.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From klaus.mailinglists at pernau.at Thu Jul 19 16:23:21 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Thu, 19 Jul 2012 16:23:21 +0200
Subject: [SR-Users] Compile Kamailio from Source with STUN
In-Reply-To: <5006A034.3@loopmethods.com>
References: <5006A034.3@loopmethods.com>
Message-ID: <50081859.5020906@pernau.at>
If you want to build Debian packages see
http://www.kamailio.org/wiki/install/3.2.x/debian (expecially step 3)
regards
Klaus
On 18.07.2012 13:38, Vijay Thakur wrote:
> Dear All Experts,
>
> I am following the steps given at
> http://kb.asipto.com/kamailio:presence:k31-made-simple. I want to
> compile kamailio with stun support. So guide me that what will be the
> command to do it. As per the
> given command :
>
> *make PREFIX=/usr/local/kamailio-3.1-xcap FLAVOUR=kamailio \
> include_modules="db_mysql presence presence_xml xhttp xcap_server" cfg
>
> what text should i use to make stun module.
> *
>
>
> --
> Best Regards,
>
> Vijay Thakur
> (Assistant Manager - Networks)
> Mobile : +91 8744018065
> Mail :vijay.thakur at loopmethods.com
>
> Loop IT Methods Private Limited
> 1st Floor, B-10, Sector-7, Noida, (U.P) India
> Ph: +91 120 305 3481,82 (INDIA), +1 347 468 8631 (USA), +61 390 011 178 (AUS)
> Fax: +91 971 728 330
> Web:www.loopmethods.com
>
> LOOP Disclaimer -------------------------------------------------------------------------------------------------
> This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.
> -----------------------------------------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> 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
>
From klaus.mailinglists at pernau.at Thu Jul 19 16:27:53 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Thu, 19 Jul 2012 16:27:53 +0200
Subject: [SR-Users] Kamailio as SBC and far end nat
In-Reply-To: <50080E6A.2040102@gmail.com>
References: <CAL6+JgLpdBrGWaGUh5K7y5GWMxakP25K76T7qJXA-Pye+rrE8Q@mail.gmail.com>
<50080E6A.2040102@gmail.com>
Message-ID: <50081969.5000008@pernau.at>
There is only one thing left: keep-alive. To keep the NAT pinhole open
you need periodic traffic from/to the client. Either enable NAT keep
alive on the SIP client, or on Kamailio (nathelper module and save() the
contacts just for the purpose of nathelper keep-alive) or on Avaya (e.g.
if Avaya can send periodic OPTIONS that could help). A dirty workaround
would be to set registration expiration to a small value, e.g. 45 seconds.
regards
Klaus
On 19.07.2012 15:40, Daniel-Constantin Mierla wrote:
> Hello,
>
> for dialogs (like subscriptions or invites), you have to use record
> routing (see rr module) -- so for initial subscribe/invite you have to
> add record-route header in kamailio, then do loose routing for requests
> within the dialog (like notify) -- the default config file coming with
> kamailio has such logic there.
>
> For registrations, I would suggest the usage of Path extensions, which
> is an ietf rfc, but the registrar server has to support that (avaya sip
> server in your case). Alternative will be to replace the contact in
> register (you can do it for subscribe as well) requests with ip of
> kamailio and a parameter that encodes the nat box ip/port.
>
> A similar mechanism is used by add_contact_alias() function from
> nathelper module to help going through nat -- you can actually use it in
> conjunction with record routing for invites/subscriptions.
>
> Cheers,
> Daniel
>
>
> On 7/19/12 1:12 PM, Martin Schi?tz wrote:
>> Hi
>>
>> I'm trying to configure kamailio version 3.3.0 to be a Session Border
>> Controller which only purpose is to handle far-end-nat.
>>
>> On the far end site I have a SIP client with IP '192.168.1.2' which is
>> NAT'ed to IP 'zz.zz.85.230'. The SIP ALG is disabled on the NAT
>> firewall. The SIP client is communicating with the kamailio server and
>> the Kamailio server is forwarding every thing to an Avaya SIP server
>> 'xx.xx.173.15' and vice versa. The kamilio is konfigured to do this
>> stateless.
>>
>> The REGISTER and SUBSCRIBE part works fine. The kamailio is using the
>> 'Via:' field and I also needed to do subst on the 'Contact:' field in
>> order for our SIP server to communicate back to the kamailio. But when
>> I get to the NOTIFY packet from the SIP server to the kamailio there
>> is no 'Via:' field or any other information about the SIP clients
>> IP/port and the Kamailio just sends back 'SIP/2.0 404 Not here.' to
>> the SIP server.
>>
>> I guess that this can not be solved with a statless kamailio?
>> I guess that I need some kind of state table in the kamailio - is that
>> possible without doing REGISTER directly with the kamailio?
>> Any other good ideas are welcome?
>>
>> Cheers,
>> Martin
>>
>>
>> Tell me if need more info the issue?
>> -----
>> #
>> T xx.xx.173.15:38059 -> yy.yy.159.211:5060 [AP]
>> NOTIFY sip:2001012 at yy.yy.159.211:5060;transport=TCP SIP/2.0.
>> Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
>> From: "2001012"
>> <sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
>>
>> To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
>> CSeq: 3 NOTIFY.
>> Contact: <sip:xx.xx.173.14:15060>.
>> Via: SIP/2.0/TCP
>> xx.xx.173.15;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4.
>>
>> Via: SIP/2.0/UDP
>> xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
>> Via: SIP/2.0/TCP
>> xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
>> Event: message-summary.
>> Content-Type: application/simple-message-summary.
>> Content-Length: 69.
>> Subscription-State: active;expires=299.
>> Max-Forwards: 68.
>> User-Agent: AVAYA-SM-6.1.4.0.614005.
>> .
>> Messages-Waiting: no.
>> Message-Account: sip:2001012 at bsosip.domain.dk.
>>
>> ##
>> T yy.yy.159.211:5060 -> xx.xx.173.15:38059 [AP]
>> SIP/2.0 404 Not here.
>> Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
>> From: "2001012"
>> <sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
>>
>> To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
>> CSeq: 3 NOTIFY.
>> Via: SIP/2.0/TCP
>> xx.xx.173.15;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4;rport=38059.
>>
>> Via: SIP/2.0/UDP
>> xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
>> Via: SIP/2.0/TCP
>> xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
>> Server: kamailio (3.3.0 (i386/linux)).
>> Content-Length: 0.
>> .
>>
>> #
>> T xx.xx.173.15:38059 -> yy.yy.159.211:5060 [A]
>> ......
>> #
>> T yy.yy.159.211:5060 -> xx.xx.173.15:38059 [AP]
>> SIP/2.0 404 Not here.
>> Call-ID: NjQ5ZDNlYzRjOWFjMzMzN2JlYzAwMTg4ODYwZTJlYWY..
>> From: "2001012"
>> <sip:2001012 at bsosip.domain.dk>;tag=-667195155*1*016asm-callprocessing.sar229435981~1342570131099~1170998434~1.
>>
>> To: "2001012" <sip:2001012 at bsosip.domain.dk>;tag=7ca0af7d.
>> CSeq: 3 NOTIFY.
>> Via: SIP/2.0/TCP
>> xx.xx.173.15;rport=38059;branch=z9hG4bK4DEAAD0E478B838008189457-AP;ft=xx.xx.173.15~13c4.
>>
>> Via: SIP/2.0/UDP
>> xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838008189457.
>> Via: SIP/2.0/TCP
>> xx.xx.173.14:15070;branch=z9hG4bK4DEAAD0E478B838018189455.
>> Server: kamailio (3.3.0 (i386/linux)).
>> Content-Length: 0.
>> -----
>>
>> _______________________________________________
>> 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
>
From anca.vamanu at 1and1.ro Thu Jul 19 17:00:24 2012
From: anca.vamanu at 1and1.ro (Anca Vamanu)
Date: Thu, 19 Jul 2012 18:00:24 +0300
Subject: [SR-Users] uac module From header rewriting problems
In-Reply-To: <20120703090234.3937cb50@vostro>
References: <20120703090234.3937cb50@vostro>
Message-ID: <50082108.9080208@1and1.ro>
Hi Timo,
You might be interested in checking out the commit
0f702f6e236eb0cbb238bf83a0c4ae94d7b3cad8 .
It adds an alternative implementation to the AUTO mode for
uac_replace_from/to() by using the dialog module to store the URIs.
Here is the excerpt from the README file explaining this:
If you set restore_mode to AUTO, the URI will be modified automatically
in all subsequent requests and replies in that dialog.
There are two ways in which the AUTO mode can be achieved.
One uses the rr module and appends to the Record-Route header a
parameter containing some strings from which the original and new URI
can be computed. The problem with this mode is that it relies on the
fact the parties will send the Route exactly as it was received. In
case there is a change, the resulting URIs will not be correct.
The other one uses the dialog module to store the original and new URI.
If you already use dialog module in your configuration, this is the
advisable mode. All you need to do to use this is to call dlg_manage()
before calling uac_replace_to(). It works by storing the URIs as dialog
variables and registering callbacks in dialog module for in dialog
requests.
Regards,
Anca
On 07/03/2012 09:02 AM, Timo Teras wrote:
> Hi,
>
> I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
> however even with the latest versions I'm still seeing corruption in
> From headers when they are rewritten for the whole dialogue
> (from_restore_mode=auto, the default).
>
> I spent some time analyzing the problem and the problem seems to be
> connected with the fact that only the bitwise difference of the
> original and modified URI are stored (XOR). The only purpose for this
> appears to be the idea to save only the difference in the rr params
> instead of two full URIs.
>
> However, it appears that in many cases (especially call transfer) the
> From header will be altered during dialogue. This is explicitly allowed
> in RFC 3261 ? 20.20:
> The From header field indicates the initiator of the request. This
> may be different from the initiator of the dialog.
>
> I've seen this in practise with few commercial SIP stacks. Sometimes
> the changes are minor, or even trivial - but with the difference
> encoding having even one character changed (e.g. case), being deleted or
> added will result in the whole header being corrupted.
>
> I'm now wondering if we should just store both URIs in the rr params.
> While taking little more space, it should fix us sending garbage to the
> wire (which usually results in dropped call as the remote will reject
> the garbage messages).
>
> Any better ideas?
>
> Cheers,
> Timo
>
> _______________________________________________
> 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
From khareapoorv at gmail.com Fri Jul 20 05:06:58 2012
From: khareapoorv at gmail.com (Apoorv Khare)
Date: Thu, 19 Jul 2012 20:06:58 -0700
Subject: [SR-Users] Kamailio and IMS
Message-ID: <CAOfMT3O7m=xMt02ZU3DM9t01Pk1u3Dbq96-RAOuZiMn4viB6Hg@mail.gmail.com>
Hi Everyone,
I am trying to integrate IMS(*carstenbock/ims*) patch in Kamailio. But so
far I could not find any proper documentation to load configuration files -
pcscf, icscf, scscf, mgcf etc? Please let me know if there is anything
available!
Only relevant link I found -
http://www.kamailio.org/w/2011/01/ims-extensions-available-for-testing/ AND
this link does not seems to be update -
http://www.ng-voice.com/our-solution/installation/
BR, Apoorv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120719/1f9ab5cd/attachment-0001.htm>
From timo.teras at iki.fi Fri Jul 20 07:38:21 2012
From: timo.teras at iki.fi (Timo Teras)
Date: Fri, 20 Jul 2012 08:38:21 +0300
Subject: [SR-Users] uac module From header rewriting problems
In-Reply-To: <50082108.9080208@1and1.ro>
References: <20120703090234.3937cb50@vostro>
<50082108.9080208@1and1.ro>
Message-ID: <20120720083821.6183b86d@vostro>
On Thu, 19 Jul 2012 18:00:24 +0300 Anca Vamanu <anca.vamanu at 1and1.ro>
wrote:
> You might be interested in checking out the commit
>
> 0f702f6e236eb0cbb238bf83a0c4ae94d7b3cad8 .
>
> It adds an alternative implementation to the AUTO mode for
> uac_replace_from/to() by using the dialog module to store the URIs.
Thanks for the heads up. Looks like it would fix my issue. And yes, I'm
using dlg_manage() already. So this'd be just drop-in change.
Will test. But might be that not until next week.
Thanks!
From edesibe at googlemail.com Fri Jul 20 07:51:06 2012
From: edesibe at googlemail.com (Ivan Milivojevic)
Date: Fri, 20 Jul 2012 07:51:06 +0200
Subject: [SR-Users] Kamailio and IMS
In-Reply-To: <CAOfMT3O7m=xMt02ZU3DM9t01Pk1u3Dbq96-RAOuZiMn4viB6Hg@mail.gmail.com>
References: <CAOfMT3O7m=xMt02ZU3DM9t01Pk1u3Dbq96-RAOuZiMn4viB6Hg@mail.gmail.com>
Message-ID: <CAOGEeza4Gzb9p+2wjZ653C+esntGCsL8iPm1GBu3-pS3rQ954w@mail.gmail.com>
http://nil.uniza.sk/ngnims/kamailio-ims/installing-base-kamailio-ims-platform-debian-squeeze-32bit
Best Regards
Ivan
On Fri, Jul 20, 2012 at 5:06 AM, Apoorv Khare <khareapoorv at gmail.com> wrote:
> Hi Everyone,
>
> I am trying to integrate IMS(carstenbock/ims) patch in Kamailio. But so far
> I could not find any proper documentation to load configuration files -
> pcscf, icscf, scscf, mgcf etc? Please let me know if there is anything
> available!
>
> Only relevant link I found -
> http://www.kamailio.org/w/2011/01/ims-extensions-available-for-testing/ AND
> this link does not seems to be update -
> http://www.ng-voice.com/our-solution/installation/
>
> BR, Apoorv
>
> _______________________________________________
> 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
>
From jason.penton at smilecoms.com Fri Jul 20 08:44:46 2012
From: jason.penton at smilecoms.com (Jason Penton)
Date: Fri, 20 Jul 2012 08:44:46 +0200
Subject: [SR-Users] Kamailio and IMS
In-Reply-To: <CAOGEeza4Gzb9p+2wjZ653C+esntGCsL8iPm1GBu3-pS3rQ954w@mail.gmail.com>
References: <CAOfMT3O7m=xMt02ZU3DM9t01Pk1u3Dbq96-RAOuZiMn4viB6Hg@mail.gmail.com>
<CAOGEeza4Gzb9p+2wjZ653C+esntGCsL8iPm1GBu3-pS3rQ954w@mail.gmail.com>
Message-ID: <CAE=KcriVLqFkYMNXXXOHtEZ3NRHmZ8wnKCXLUVubFO77H5x0RA@mail.gmail.com>
Hi Apoorv,
We, along with Carsten and some other guys are working on IMS extensions
for Kamailio. Right now the code sits in a staging area while we test and
improve before re-integrating it into Kamailio master. You can find the
extensions here:
http://code.google.com/p/smile-ims-extensions/
Please feel free to ask if you have any questions.
Cheers
Jason
On Fri, Jul 20, 2012 at 7:51 AM, Ivan Milivojevic <edesibe at googlemail.com>wrote:
>
> http://nil.uniza.sk/ngnims/kamailio-ims/installing-base-kamailio-ims-platform-debian-squeeze-32bit
>
> Best Regards
> Ivan
>
> On Fri, Jul 20, 2012 at 5:06 AM, Apoorv Khare <khareapoorv at gmail.com>
> wrote:
> > Hi Everyone,
> >
> > I am trying to integrate IMS(carstenbock/ims) patch in Kamailio. But so
> far
> > I could not find any proper documentation to load configuration files -
> > pcscf, icscf, scscf, mgcf etc? Please let me know if there is anything
> > available!
> >
> > Only relevant link I found -
> > http://www.kamailio.org/w/2011/01/ims-extensions-available-for-testing/AND
> > this link does not seems to be update -
> > http://www.ng-voice.com/our-solution/installation/
> >
> > BR, Apoorv
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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
>
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120720/c4f3fe55/attachment.htm>
From khareapoorv at gmail.com Fri Jul 20 08:45:05 2012
From: khareapoorv at gmail.com (Apoorv Khare)
Date: Thu, 19 Jul 2012 23:45:05 -0700
Subject: [SR-Users] Kamailio and IMS
In-Reply-To: <CAOGEeza4Gzb9p+2wjZ653C+esntGCsL8iPm1GBu3-pS3rQ954w@mail.gmail.com>
References: <CAOfMT3O7m=xMt02ZU3DM9t01Pk1u3Dbq96-RAOuZiMn4viB6Hg@mail.gmail.com>
<CAOGEeza4Gzb9p+2wjZ653C+esntGCsL8iPm1GBu3-pS3rQ954w@mail.gmail.com>
Message-ID: <CAOfMT3PHzMMfZFC1ZtUQt_1uucuc_KExL==_B9-b7texcvVm_A@mail.gmail.com>
Thanks Ivan,
Earlier today I actually tried this option, but following mentioned thing
does not make sense. How can we create "kamailio.cfg" as a soft link for
two different files i.e. pcscf and scscf. Also what will happen to original
kamailio.cfg file?
Installing P-CSCF
from the guide "Copy the required config to kamailio.cfg (e.g. pcscf.cfg)",
but I'll backup the old kamailio file and make symlink
cd /etc/kamailio
mv kamailio.cfg kamailio.cfg.dist
ln -s pcscf.cfg kamailio.cfg
Installing S-CSCF
the same for P-CSCSF
cd /etc/kamailio
mv kamailio.cfg kamailio.cfg.dist
ln -s scscf.cfg kamailio.cfg
BR, Apoorv
On Thu, Jul 19, 2012 at 10:51 PM, Ivan Milivojevic
<edesibe at googlemail.com>wrote:
>
> http://nil.uniza.sk/ngnims/kamailio-ims/installing-base-kamailio-ims-platform-debian-squeeze-32bit
>
> Best Regards
> Ivan
>
> On Fri, Jul 20, 2012 at 5:06 AM, Apoorv Khare <khareapoorv at gmail.com>
> wrote:
> > Hi Everyone,
> >
> > I am trying to integrate IMS(carstenbock/ims) patch in Kamailio. But so
> far
> > I could not find any proper documentation to load configuration files -
> > pcscf, icscf, scscf, mgcf etc? Please let me know if there is anything
> > available!
> >
> > Only relevant link I found -
> > http://www.kamailio.org/w/2011/01/ims-extensions-available-for-testing/AND
> > this link does not seems to be update -
> > http://www.ng-voice.com/our-solution/installation/
> >
> > BR, Apoorv
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120719/6c9cbca9/attachment.htm>
From khareapoorv at gmail.com Fri Jul 20 08:54:03 2012
From: khareapoorv at gmail.com (Apoorv Khare)
Date: Thu, 19 Jul 2012 23:54:03 -0700
Subject: [SR-Users] Kamailio and IMS
In-Reply-To: <CAE=KcriVLqFkYMNXXXOHtEZ3NRHmZ8wnKCXLUVubFO77H5x0RA@mail.gmail.com>
References: <CAOfMT3O7m=xMt02ZU3DM9t01Pk1u3Dbq96-RAOuZiMn4viB6Hg@mail.gmail.com>
<CAOGEeza4Gzb9p+2wjZ653C+esntGCsL8iPm1GBu3-pS3rQ954w@mail.gmail.com>
<CAE=KcriVLqFkYMNXXXOHtEZ3NRHmZ8wnKCXLUVubFO77H5x0RA@mail.gmail.com>
Message-ID: <CAOfMT3Pui4vEp=Yw0CF1e3FUsGWXJ1=BKhQudfJawzhSULjFqQ@mail.gmail.com>
Thanks Jason,
Really looking forward towards this when can we expect it? Currently I have
downloaded following way, is this correct? Is there any way I can load all
the config files simultaneously like we do in Open-IMS or if not can we add
some paths in kamilio.cfg to load pcscf.cfg and others...
git clone --depth 1 git://git.sip-router.org/sip-router kamailio
checkout carstenbock/ims
Great work folks!!!!!!
BR, Apoorv
On Thu, Jul 19, 2012 at 11:44 PM, Jason Penton
<jason.penton at smilecoms.com>wrote:
> Hi Apoorv,
>
> We, along with Carsten and some other guys are working on IMS extensions
> for Kamailio. Right now the code sits in a staging area while we test and
> improve before re-integrating it into Kamailio master. You can find the
> extensions here:
>
> http://code.google.com/p/smile-ims-extensions/
>
> Please feel free to ask if you have any questions.
>
> Cheers
> Jason
>
>
> On Fri, Jul 20, 2012 at 7:51 AM, Ivan Milivojevic <edesibe at googlemail.com>wrote:
>
>>
>> http://nil.uniza.sk/ngnims/kamailio-ims/installing-base-kamailio-ims-platform-debian-squeeze-32bit
>>
>> Best Regards
>> Ivan
>>
>> On Fri, Jul 20, 2012 at 5:06 AM, Apoorv Khare <khareapoorv at gmail.com>
>> wrote:
>> > Hi Everyone,
>> >
>> > I am trying to integrate IMS(carstenbock/ims) patch in Kamailio. But so
>> far
>> > I could not find any proper documentation to load configuration files -
>> > pcscf, icscf, scscf, mgcf etc? Please let me know if there is anything
>> > available!
>> >
>> > Only relevant link I found -
>> > http://www.kamailio.org/w/2011/01/ims-extensions-available-for-testing/AND
>> > this link does not seems to be update -
>> > http://www.ng-voice.com/our-solution/installation/
>> >
>> > BR, Apoorv
>> >
>> > _______________________________________________
>> > 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
>> >
>>
>> _______________________________________________
>> 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
>>
>
> This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120719/496dd586/attachment-0001.htm>
From jason.penton at smilecoms.com Fri Jul 20 08:59:56 2012
From: jason.penton at smilecoms.com (Jason Penton)
Date: Fri, 20 Jul 2012 08:59:56 +0200
Subject: [SR-Users] Kamailio and IMS
In-Reply-To: <CAOfMT3Pui4vEp=Yw0CF1e3FUsGWXJ1=BKhQudfJawzhSULjFqQ@mail.gmail.com>
References: <CAOfMT3O7m=xMt02ZU3DM9t01Pk1u3Dbq96-RAOuZiMn4viB6Hg@mail.gmail.com>
<CAOGEeza4Gzb9p+2wjZ653C+esntGCsL8iPm1GBu3-pS3rQ954w@mail.gmail.com>
<CAE=KcriVLqFkYMNXXXOHtEZ3NRHmZ8wnKCXLUVubFO77H5x0RA@mail.gmail.com>
<CAOfMT3Pui4vEp=Yw0CF1e3FUsGWXJ1=BKhQudfJawzhSULjFqQ@mail.gmail.com>
Message-ID: <CAE=KcriYyQKxytMEVdExTS9hKOZX-oyRWD78kRkebmySJCTrMA@mail.gmail.com>
Hi Apoorv,
No this is different to Carsten's branch. You will have to check it out
using - http://code.google.com/p/smile-ims-extensions/source/checkout
I think for now until we get the code into Kamailio master (with all docs)
it may be better for you to use Carsten's branch as it has documentation to
use it ;) - ours doesn't just yet and I, nor the others, will have too much
time to help you out too much
The code will be in Kamailio master soon (with docs). I promise! ;)
Cheers
Jason
On Fri, Jul 20, 2012 at 8:54 AM, Apoorv Khare <khareapoorv at gmail.com> wrote:
> Thanks Jason,
>
> Really looking forward towards this when can we expect it? Currently I
> have downloaded following way, is this correct? Is there any way I can load
> all the config files simultaneously like we do in Open-IMS or if not can we
> add some paths in kamilio.cfg to load pcscf.cfg and others...
>
> git clone --depth 1 git://git.sip-router.org/sip-router kamailio
> checkout carstenbock/ims
>
> Great work folks!!!!!!
>
> BR, Apoorv
>
> On Thu, Jul 19, 2012 at 11:44 PM, Jason Penton <jason.penton at smilecoms.com
> > wrote:
>
>> Hi Apoorv,
>>
>> We, along with Carsten and some other guys are working on IMS extensions
>> for Kamailio. Right now the code sits in a staging area while we test and
>> improve before re-integrating it into Kamailio master. You can find the
>> extensions here:
>>
>> http://code.google.com/p/smile-ims-extensions/
>>
>> Please feel free to ask if you have any questions.
>>
>> Cheers
>> Jason
>>
>>
>> On Fri, Jul 20, 2012 at 7:51 AM, Ivan Milivojevic <edesibe at googlemail.com
>> > wrote:
>>
>>>
>>> http://nil.uniza.sk/ngnims/kamailio-ims/installing-base-kamailio-ims-platform-debian-squeeze-32bit
>>>
>>> Best Regards
>>> Ivan
>>>
>>> On Fri, Jul 20, 2012 at 5:06 AM, Apoorv Khare <khareapoorv at gmail.com>
>>> wrote:
>>> > Hi Everyone,
>>> >
>>> > I am trying to integrate IMS(carstenbock/ims) patch in Kamailio. But
>>> so far
>>> > I could not find any proper documentation to load configuration files -
>>> > pcscf, icscf, scscf, mgcf etc? Please let me know if there is anything
>>> > available!
>>> >
>>> > Only relevant link I found -
>>> >
>>> http://www.kamailio.org/w/2011/01/ims-extensions-available-for-testing/AND
>>> > this link does not seems to be update -
>>> > http://www.ng-voice.com/our-solution/installation/
>>> >
>>> > BR, Apoorv
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>> This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
>
>
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120720/b5173f16/attachment.htm>
From intel at intrans.baku.az Fri Jul 20 13:24:45 2012
From: intel at intrans.baku.az (intel at intrans.baku.az)
Date: Fri, 20 Jul 2012 16:24:45 +0500 (AZST)
Subject: [SR-Users] How to rewritehostport() dynamically?
Message-ID: <29225.85.132.76.4.1342783485.squirrel@mail.az>
Can I use rewritehostport() function with argument selected at time of
call processing?
I have a lua script, which gets address/port of next hop(from base)
But how to call rewritehostport() with it?
I can't find, how to call this function from lua script directly
(I've tried sr.tm.rewritehostport() and rewritehostport() - no success)
If i set pseudovariable (f.e $avp(relay)) and call
rewritehostport("$avp(relay)") from kamailio.cfg later, i can see in logs
such message:
ERROR: tm [ut.h:327]: failed to resolve "$avp(relay)"
Seems it use name of pv, not value?
What should I do to call this function with correct parameter?
--
From abalashov at evaristesys.com Fri Jul 20 14:02:47 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 20 Jul 2012 08:02:47 -0400
Subject: [SR-Users] How to rewritehostport() dynamically?
Message-ID: <fw2u3dtx21ov87pgtf01hm8r.1342785767716@email.android.com>
Try modifying the request URI with $ru/$rU/$rd/$rp instead. See the pseudovariables page on the dokuwiki for more information.?
rewritehostport() is a legacy function that does not deal with variables.?
-- Alex
--
Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/intel at intrans.baku.az wrote:Can I use rewritehostport() function with argument selected at time of
call processing?
I have a lua script, which gets address/port of next hop(from base)
But how to call rewritehostport() with it?
I can't find, how to call this function from lua script directly
(I've tried sr.tm.rewritehostport() and rewritehostport() - no success)
If i set pseudovariable (f.e $avp(relay)) and call
rewritehostport("$avp(relay)") from kamailio.cfg later, i can see in logs
such message:
ERROR: tm [ut.h:327]: failed to resolve "$avp(relay)"
Seems it use name of pv, not value?
What should I do to call this function with correct parameter?
--
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120720/59b9386f/attachment.htm>
From ushacked at gmail.com Sun Jul 22 16:09:02 2012
From: ushacked at gmail.com (Uri Shacked)
Date: Sun, 22 Jul 2012 17:09:02 +0300
Subject: [SR-Users] Can't initialize shared memory
Message-ID: <CAMMbDhQUjp+rshWUHh8W0wt3cJPPKLK+316ZjMSZ_=_Q3nPanw@mail.gmail.com>
Hi,
Anyone got this message " Can't initialize shared memory" ?
When i run kamailio using "kamailio -m 512" it works OK
When i run "/etc/init.d/kamailio start" i get the message above. my init
script anf defaults are set with memory = 512.
I played a little with 3.3.0 and now i am back to 3.2.4 can it be something
to do with it?
BR,
Uri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120722/8788ba2e/attachment.htm>
From miconda at gmail.com Mon Jul 23 11:31:20 2012
From: miconda at gmail.com (Daniel-Constantine Mierla)
Date: Mon, 23 Jul 2012 11:31:20 +0200
Subject: [SR-Users] Can't initialize shared memory
In-Reply-To: <CAMMbDhQUjp+rshWUHh8W0wt3cJPPKLK+316ZjMSZ_=_Q3nPanw@mail.gmail.com>
References: <CAMMbDhQUjp+rshWUHh8W0wt3cJPPKLK+316ZjMSZ_=_Q3nPanw@mail.gmail.com>
Message-ID: <AC361084-1E9A-440F-AC76-EED73CDE8FF0@gmail.com>
Hello,
Set debug=4 in config file and look over detailed log messages, maybe you get proper hint. If not, send them here so we can analyze them.
Cheers,
Daniel
On Jul 22, 2012, at 4:09 PM, Uri Shacked <ushacked at gmail.com> wrote:
> Hi,
>
> Anyone got this message " Can't initialize shared memory" ?
>
> When i run kamailio using "kamailio -m 512" it works OK
> When i run "/etc/init.d/kamailio start" i get the message above. my init script anf defaults are set with memory = 512.
>
> I played a little with 3.3.0 and now i am back to 3.2.4 can it be something to do with it?
>
> 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
From vijay.thakur at loopmethods.com Mon Jul 23 13:53:29 2012
From: vijay.thakur at loopmethods.com (Vijay Thakur)
Date: Mon, 23 Jul 2012 17:23:29 +0530
Subject: [SR-Users] Kamailio setup problem
Message-ID: <500D3B39.2090104@loopmethods.com>
All Experts,
I have installed Kamailio Server on Linode Cloud. I have followed the
following URL for Setup:
http://kb.asipto.com/kamailio:presence:k31-made-simple
This is done in ubuntu 10.04. I am only able to make chat. Video chat,
conference, Presence, Call, Screen Sharing is not working. But followed
the same how to install kamailio in my local system and
all features are working fine. Does there anyone who can point out the
flaw in setup.
Thanks and regards,
Vijay Thakur
From stoyan.v.mihaylov at gmail.com Mon Jul 23 14:29:00 2012
From: stoyan.v.mihaylov at gmail.com (Stoyan Mihaylov)
Date: Mon, 23 Jul 2012 15:29:00 +0300
Subject: [SR-Users] Kamailio setup problem
In-Reply-To: <500D3B39.2090104@loopmethods.com>
References: <500D3B39.2090104@loopmethods.com>
Message-ID: <CAPScudbNPTtpwUvQejPrxRnYWxj2h2iHXZvu0QKAy+S+-i1K5g@mail.gmail.com>
Check your firewall. This is from our iptables:
ACCEPT udp -- anywhere anywhere udp
dpts:10000:60000
It solved problems with video - when it had - 10000:20000 - then we had
sound but no video.
On Mon, Jul 23, 2012 at 2:53 PM, Vijay Thakur
<vijay.thakur at loopmethods.com>wrote:
> All Experts,
>
> I have installed Kamailio Server on Linode Cloud. I have followed the
> following URL for Setup:
> http://kb.asipto.com/kamailio:**presence:k31-made-simple<http://kb.asipto.com/kamailio:presence:k31-made-simple>
>
> This is done in ubuntu 10.04. I am only able to make chat. Video chat,
> conference, Presence, Call, Screen Sharing is not working. But followed the
> same how to install kamailio in my local system and
> all features are working fine. Does there anyone who can point out the
> flaw in setup.
>
> Thanks and regards,
>
>
> Vijay Thakur
>
>
>
>
>
> ______________________________**_________________
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120723/e587462c/attachment.htm>
From bruno.bresciani at gmail.com Mon Jul 23 14:37:06 2012
From: bruno.bresciani at gmail.com (Bruno Bresciani)
Date: Mon, 23 Jul 2012 09:37:06 -0300
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <5007089F.708@digitro.com.br>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
Message-ID: <CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
Hi All,
I imagine that this core doesn't easy to replicate but somebody can help
me to understand why it was generated? There is some way to prevent it?
Best Regards
2012/7/18 Renan Capaverde <renan.capaverde at digitro.com.br>
> I am having the same problem on kamailio 3.1.6. Someone please help.
>
> Cheers,
> Renan
>
> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>
> Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
>
> Best Regards
>
>
> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com>
>
>> Hello,
>>
>> send also the version 'kamailio -V' to match the proper sources.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>
>> Hi all,
>>
>> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0,
>> size=0) at mem/f_malloc.c:536.
>>
>> I don't know exactly what may be caused this core because the debug of
>> kamailio is disabled, but looking at backtrace (gdb) and source code I
>> could notice a relationship with TLS connection establishment (handshake).
>> Other important fact is that core was generated by the kamalio itself with
>> signal 6 (abort) because it can't find the pointer to memory realloc.
>> I'd like to know if someone already observed this issue and if my analyse
>> above is correct?
>>
>> Bellow is backtrace full with gdb:
>>
>> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>> /var/run/kamailio.pid'.
>> Program terminated with signal 6, Aborted.
>> #0 0x00f30402 in __kernel_vsyscall ()
>> (gdb)
>> (gdb)
>> (gdb)
>> (gdb)
>> (gdb) bt full
>> #0 0x00f30402 in __kernel_vsyscall ()
>> No symbol table info available.
>> #1 0x009fec10 in raise () from /lib/libc.so.6
>> No symbol table info available.
>> #2 0x00a00521 in abort () from /lib/libc.so.6
>> No symbol table info available.
>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
>> mem/f_malloc.c:536
>> f = (struct fm_frag *) 0xb61f0bb8
>> pf = <value optimized out>
>> orig_size = 18
>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>> ptr = <value optimized out>
>> hash = 23548
>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
>> ../../mem/shm_mem.h:266
>> No locals.
>> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
>> No symbol table info available.
>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>> No symbol table info available.
>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>> No symbol table info available.
>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>> No symbol table info available.
>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
>> No symbol table info available.
>> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
>> No symbol table info available.
>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>> No symbol table info available.
>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>> No symbol table info available.
>> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
>> tls_server.c:346
>> ret = <value optimized out>
>> ssl = (SSL *) 0xb61c1878
>> cert = <value optimized out>
>> tls_c = (struct tls_extra_data *) 0xb6208e58
>> tls_log = <value optimized out>
>> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
>> tls_server.c:1028
>> r = (struct tcp_req *) 0xb621affc
>> bytes_free = 4095
>> bytes_read = 70
>> read_size = 4095
>> ssl_error = 0
>> ssl_read = 0
>> ssl = (SSL *) 0xb61c1878
>> rd_buf = "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>
>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>> wr_buf =
>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>
>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70, size
>> = 65536}
>> wr = {
>> buf = 0xbf8fdfa4
>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>> pos = 0, used = 0,
>> size = 65536}
>> tls_c = (struct tls_extra_data *) 0xb6208e58
>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>> n = 0
>> flush_flags = <value optimized out>
>> err_src = 0x541a83 "TLS read:"
>> x = <value optimized out>
>> #15 0x08158ade in tcp_read_headers (c=0xb621af88, read_flags=0xbf91e200)
>> at tcp_read.c:406
>> bytes = -1
>> remaining = <value optimized out>
>> p = <value optimized out>
>> r = (struct tcp_req *) 0xb621affc
>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204,
>> read_flags=0xbf91e200) at tcp_read.c:871
>> bytes = <value optimized out>
>> total_bytes = 0
>> resp = <value optimized out>
>> size = <value optimized out>
>> req = (struct tcp_req *) 0xb621affc
>> dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data =
>> "\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family =
>> 57540,
>> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
>> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port =
>> 49041,
>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 =
>> {0, 0, 16, 0, 1, 0,
>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}}, id
>> = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask = 0
>> '\0'}}
>> c = 10 '\n'
>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
>> tcp_read.c:1150
>> ret = 4
>> n = 4
>> read_flags = 1
>> con = (struct tcp_connection *) 0xb621af88
>> s = 12
>> resp = <value optimized out>
>> t = <value optimized out>
>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
>> No locals.
>> ---Type <return> to continue, or q <return> to quit---
>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>> r = 3
>> reader_fd_1 = 35
>> pid = <value optimized out>
>> si = <value optimized out>
>> #20 0x080ad412 in main_loop () at main.c:1632
>> i = 4
>> pid = <value optimized out>
>> si = (struct socket_info *) 0x0
>> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
>> \000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted DWARF
>> expression.
>> ) at main.c:2398
>> cfg_stream = (FILE *) 0x8a2d008
>> c = <value optimized out>
>> r = 0
>> tmp = 0xbf91e674
>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>> tmp_len = 10492229
>> port = 136192361
>> proto = -1080957480
>> ret = <value optimized out>
>> seed = 21782655
>> rfd = 4
>> debug_save = <value optimized out>
>> debug_flag = 0
>> dont_fork_cnt = 0
>> n_lst = <value optimized out>
>> p = <value optimized out>
>>
>>
>> Best Regards
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120723/30946c59/attachment-0001.htm>
From adam.fyfe1 at gmail.com Mon Jul 23 17:14:24 2012
From: adam.fyfe1 at gmail.com (Adam Fyfe)
Date: Mon, 23 Jul 2012 16:14:24 +0100
Subject: [SR-Users] SIREMIS
Message-ID: <CAC5mzB71k61BgkRm1gV1SrBAszoHpRx15ZOT8hBW1pWyAD777w@mail.gmail.com>
Hi,
I am testing Siremis, and have become stuck.
How does one add an outbound SIP trunk for calls ?
thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120723/4a3b603e/attachment.htm>
From abalashov at evaristesys.com Tue Jul 24 02:38:26 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 23 Jul 2012 20:38:26 -0400
Subject: [SR-Users] rtimer execution period - round two
Message-ID: <500DEE82.2060304@evaristesys.com>
Hi Daniel,
I wanted to go back to this thread for a minute:
http://lists.sip-router.org/pipermail/sr-users/2012-June/073663.html
Sorry that I didn't reply to the thread; I no longer have the last message.
In your reply, you said:
> there is no timeout on the execution of that task. Of course, you
> can start many rtimer processes to do same task, up to you,
> via configuration parameters. A matter of how rtimer executed
> route is built, a rtimer process may not rest (e.g., sleep) and
> keep consuming mqueue items as long as the queue is not empty."
However, I am seeing some behaviour that is rather different.
Roughly, I have a single rtimer task that runs every 3 seconds and
consumes an mqueue full of accounting events. The rtimer request route
looks like something this:
route[ACCT_WRITER] {
while(mq_fetch("acct_write")) {
# Some stuff to write $mqv(...) values to PostgreSQL.
...
sql_query("ca", "SELECT * FROM acct_event_proc(...)");
...
mq_pv_free("account_write");
}
}
And the rtimer task is parameterised thusly:
modparam("rtimer", "timer", "name=acct_write;interval=3;mode=1")
modparam("rtimer", "exec", "timer=acct_write;route=ACCT_WRITER")
And the mqueue:
modparam("mqueue", "mqueue", "name=acct_write")
I have a stored procedure - let's call it acct_event_proc() - that is
invoked from within the rtimer task. When I looked at the live query
activity from Kamailio to Postgres by doing a packet capture on
loopback, like this:
tcpdump -i any -A -s 0 -tttt -n 'tcp port 5432' | grep acct_event_proc
What I saw was some events being written for about ~3 seconds and then
the process would stop. Then, after about half a second, it would burst
again for 3 seconds, then stop again. And so on and so forth.
When I lowered the interval to 1 second, it got faster and more
responsive, and would push more events through in one interval. But
still, it appeared to be a limited "burst" of SELECT calls punctuated by
1 second of silence.
When I checked out branch 3.3 and lowered the interval to 50000u, it got
even faster, almost real-time enough to keep up. Still, I did not
really know what was happening, so I added an MI command to HEAD to
check mqueue size live:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commit;h=41f77159c5851bb36ad12abecc2faf58602d6935
(I think it would be quite useful anyhow, as there is no runtime mqueue
info available right now.)
Using it, I confirmed my impression: the bigger the rtimer interval, the
larger the queue grows, and the slower the events seem to be written
overall. The shorter the rtimer interval, the faster they are dequeued,
and the smaller the mqueue is overall, in the course of normal call
processing.
Thus, my impression is that the execution time of the rtimer task is
bounded by the interval, and that the core kills the forked rtimer task
currently running prior to starting another one.
Can you shed some light?
Thanks!
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Tue Jul 24 02:44:25 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 23 Jul 2012 20:44:25 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500DEE82.2060304@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
Message-ID: <500DEFE9.9020607@evaristesys.com>
I am wondering if the execution time of a route is somehow bounded in
action.c/run_actions(). Unfortunately, I don't enough about how it
works to figure it out.
On 07/23/2012 08:38 PM, Alex Balashov wrote:
> Hi Daniel,
>
> I wanted to go back to this thread for a minute:
>
> http://lists.sip-router.org/pipermail/sr-users/2012-June/073663.html
>
> Sorry that I didn't reply to the thread; I no longer have the last
> message.
>
> In your reply, you said:
>
> > there is no timeout on the execution of that task. Of course, you
> > can start many rtimer processes to do same task, up to you,
> > via configuration parameters. A matter of how rtimer executed
> > route is built, a rtimer process may not rest (e.g., sleep) and
> > keep consuming mqueue items as long as the queue is not empty."
>
> However, I am seeing some behaviour that is rather different.
>
> Roughly, I have a single rtimer task that runs every 3 seconds and
> consumes an mqueue full of accounting events. The rtimer request route
> looks like something this:
>
> route[ACCT_WRITER] {
> while(mq_fetch("acct_write")) {
> # Some stuff to write $mqv(...) values to PostgreSQL.
>
> ...
>
> sql_query("ca", "SELECT * FROM acct_event_proc(...)");
> ...
>
> mq_pv_free("account_write");
> }
> }
>
> And the rtimer task is parameterised thusly:
>
> modparam("rtimer", "timer", "name=acct_write;interval=3;mode=1")
> modparam("rtimer", "exec", "timer=acct_write;route=ACCT_WRITER")
>
> And the mqueue:
>
> modparam("mqueue", "mqueue", "name=acct_write")
>
> I have a stored procedure - let's call it acct_event_proc() - that is
> invoked from within the rtimer task. When I looked at the live query
> activity from Kamailio to Postgres by doing a packet capture on
> loopback, like this:
>
> tcpdump -i any -A -s 0 -tttt -n 'tcp port 5432' | grep acct_event_proc
>
> What I saw was some events being written for about ~3 seconds and then
> the process would stop. Then, after about half a second, it would burst
> again for 3 seconds, then stop again. And so on and so forth.
>
> When I lowered the interval to 1 second, it got faster and more
> responsive, and would push more events through in one interval. But
> still, it appeared to be a limited "burst" of SELECT calls punctuated by
> 1 second of silence.
>
> When I checked out branch 3.3 and lowered the interval to 50000u, it got
> even faster, almost real-time enough to keep up. Still, I did not
> really know what was happening, so I added an MI command to HEAD to
> check mqueue size live:
>
>
> http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commit;h=41f77159c5851bb36ad12abecc2faf58602d6935
>
>
> (I think it would be quite useful anyhow, as there is no runtime mqueue
> info available right now.)
>
> Using it, I confirmed my impression: the bigger the rtimer interval, the
> larger the queue grows, and the slower the events seem to be written
> overall. The shorter the rtimer interval, the faster they are dequeued,
> and the smaller the mqueue is overall, in the course of normal call
> processing.
>
> Thus, my impression is that the execution time of the rtimer task is
> bounded by the interval, and that the core kills the forked rtimer task
> currently running prior to starting another one.
>
> Can you shed some light?
>
> Thanks!
>
> -- Alex
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Tue Jul 24 02:49:36 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 23 Jul 2012 20:49:36 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500DEE82.2060304@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
Message-ID: <500DF120.1050604@evaristesys.com>
On 07/23/2012 08:38 PM, Alex Balashov wrote:
> mq_pv_free("account_write");
This is a typo, btw.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Tue Jul 24 03:12:26 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 23 Jul 2012 21:12:26 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500DF120.1050604@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
<500DF120.1050604@evaristesys.com>
Message-ID: <500DF67A.5000108@evaristesys.com>
I did an experiment to try to simplify the problem, and rule out mqueue
concurrency/locking issues:
modparam("pv", "shvset", "lasttm=i:-1")
modparam("rtimer", "timer", "name=test;interval=1;mode=1")
modparam("rtimer", "exec", "timer=test;route=TEST_ROUTE")
route[TEST_ROUTE] {
while(1) {
if($shv(lasttm) < 0)
$shv(lasttm) = $TV(sn);
else {
$var(gap) = $TV(sn) - $shv(lasttm);
if($var(gap) >= 1) {
xlog("L_INFO", "Presented time gap:
$var(gap)\n");
}
}
$shv(lasttm) = $TV(sn);
}
}
And here's what I saw in the log:
Jul 23 21:10:07 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:12 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:13 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:16 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:18 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:21 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:23 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:29 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:30 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:34 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:36 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:38 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:39 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:40 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
Jul 23 21:10:43 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
Presented time gap: 1
When I repeated the experiment with interval=3:
Jul 23 21:11:51 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
Presented time gap: 1
Jul 23 21:11:52 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
Presented time gap: 1
Jul 23 21:11:54 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
Presented time gap: 1
Jul 23 21:11:55 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
Presented time gap: 1
Jul 23 21:11:56 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
Presented time gap: 1
Jul 23 21:11:59 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
Presented time gap: 1
Jul 23 21:12:03 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
Presented time gap: 1
Jul 23 21:12:04 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
Presented time gap: 1
So, something is definitely interrupting the possibility of continuous
execution of these rtimer tasks.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Tue Jul 24 03:23:27 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 23 Jul 2012 21:23:27 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500DF67A.5000108@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
<500DF120.1050604@evaristesys.com>
<500DF67A.5000108@evaristesys.com>
Message-ID: <500DF90F.10906@evaristesys.com>
I think some sort of execution time governor in the actions
infrastructure is probably the right angle here.
I added a log statement to modules_k/rtimer/rtimer_mod.c:stm_timer_exec():
for(rt=it->rt; rt; rt=rt->next)
{
fmsg = faked_msg_next();
if (exec_pre_script_cb(fmsg, REQUEST_CB_TYPE)==0 )
continue; /* drop the request */
set_route_type(REQUEST_ROUTE);
run_top_route(main_rt.rlist[rt->route], fmsg, 0);
LM_ERR("Fell out of route execution: %u\n", time(NULL));
exec_post_script_cb(fmsg, REQUEST_CB_TYPE);
}
And here's what I saw, with the previous test task (quoted in the
message above which I am posting):
Jul 23 21:20:15 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092815
Jul 23 21:20:19 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:20 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092820
Jul 23 21:20:22 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:24 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:25 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:25 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092825
Jul 23 21:20:28 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:29 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:30 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092830
Jul 23 21:20:31 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:35 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:35 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092835
Jul 23 21:20:36 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:37 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Jul 23 21:20:38 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
Presented time gap: 1
Shouldn't that while() loop in the script run to infinity?
(max_while_loops is set to 0)
On 07/23/2012 09:12 PM, Alex Balashov wrote:
> I did an experiment to try to simplify the problem, and rule out mqueue
> concurrency/locking issues:
>
> modparam("pv", "shvset", "lasttm=i:-1")
>
> modparam("rtimer", "timer", "name=test;interval=1;mode=1")
> modparam("rtimer", "exec", "timer=test;route=TEST_ROUTE")
>
> route[TEST_ROUTE] {
> while(1) {
> if($shv(lasttm) < 0)
> $shv(lasttm) = $TV(sn);
> else {
> $var(gap) = $TV(sn) - $shv(lasttm);
>
> if($var(gap) >= 1) {
> xlog("L_INFO", "Presented time gap:
> $var(gap)\n");
> }
> }
>
> $shv(lasttm) = $TV(sn);
> }
> }
>
> And here's what I saw in the log:
>
> Jul 23 21:10:07 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:12 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:13 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:16 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:18 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:21 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:23 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:29 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:30 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:34 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:36 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:38 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:39 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:40 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
> Jul 23 21:10:43 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
> Presented time gap: 1
>
> When I repeated the experiment with interval=3:
>
> Jul 23 21:11:51 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
> Presented time gap: 1
> Jul 23 21:11:52 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
> Presented time gap: 1
> Jul 23 21:11:54 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
> Presented time gap: 1
> Jul 23 21:11:55 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
> Presented time gap: 1
> Jul 23 21:11:56 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
> Presented time gap: 1
> Jul 23 21:11:59 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
> Presented time gap: 1
> Jul 23 21:12:03 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
> Presented time gap: 1
> Jul 23 21:12:04 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
> Presented time gap: 1
>
> So, something is definitely interrupting the possibility of continuous
> execution of these rtimer tasks.
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Tue Jul 24 04:02:12 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 23 Jul 2012 22:02:12 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500DF90F.10906@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
<500DF120.1050604@evaristesys.com>
<500DF67A.5000108@evaristesys.com> <500DF90F.10906@evaristesys.com>
Message-ID: <500E0224.2090307@evaristesys.com>
Yeah, something's going on interrupting the execution of the route. I
set the interval to 1:
modparam("rtimer", "timer", "name=test;interval=1;mode=1")
And then added this to the infinite for() loop in
timer_proc.c:fork_basic_timer(), after the call to the timer_function:
LM_ERR("Bottomed out of timer loop\n");
if(tm_last > 0) {
tm = time(NULL);
LM_ERR("Execution gap: %d\n",
tm - tm_last);
}
tm_last = time(0);
}
And here's what I got:
Jul 23 21:59:19 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
Presented time gap: 1
Jul 23 21:59:20 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
Presented time gap: 1
Jul 23 21:59:22 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
Presented time gap: 1
Jul 23 21:59:22 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
rtimer [rtimer_mod.c:194]: Bottomed out of top route execution
Jul 23 21:59:22 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
<core> [timer_proc.c:94]: Bottomed out of timer loop
Jul 23 21:59:23 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
Presented time gap: 1
Jul 23 21:59:25 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
Presented time gap: 1
Jul 23 21:59:26 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
Presented time gap: 1
Jul 23 21:59:27 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
rtimer [rtimer_mod.c:194]: Bottomed out of top route execution
Jul 23 21:59:27 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
<core> [timer_proc.c:94]: Bottomed out of timer loop
Jul 23 21:59:27 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
<core> [timer_proc.c:99]: Execution gap: 5
Jul 23 21:59:32 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
rtimer [rtimer_mod.c:194]: Bottomed out of top route execution
Jul 23 21:59:32 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
<core> [timer_proc.c:94]: Bottomed out of timer loop
Jul 23 21:59:32 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
<core> [timer_proc.c:99]: Execution gap: 5
There is definitely something dependably interrupting the execution once
in a while (every 5 sec).
On 07/23/2012 09:23 PM, Alex Balashov wrote:
> I think some sort of execution time governor in the actions
> infrastructure is probably the right angle here.
>
> I added a log statement to modules_k/rtimer/rtimer_mod.c:stm_timer_exec():
>
> for(rt=it->rt; rt; rt=rt->next)
> {
> fmsg = faked_msg_next();
> if (exec_pre_script_cb(fmsg, REQUEST_CB_TYPE)==0 )
> continue; /* drop the request */
> set_route_type(REQUEST_ROUTE);
> run_top_route(main_rt.rlist[rt->route], fmsg, 0);
> LM_ERR("Fell out of route execution: %u\n", time(NULL));
> exec_post_script_cb(fmsg, REQUEST_CB_TYPE);
> }
>
> And here's what I saw, with the previous test task (quoted in the
> message above which I am posting):
>
> Jul 23 21:20:15 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092815
> Jul 23 21:20:19 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:20 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092820
> Jul 23 21:20:22 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:24 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:25 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:25 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092825
> Jul 23 21:20:28 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:29 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:30 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092830
> Jul 23 21:20:31 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:35 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:35 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092835
> Jul 23 21:20:36 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:37 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
> Jul 23 21:20:38 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
> Presented time gap: 1
>
> Shouldn't that while() loop in the script run to infinity?
> (max_while_loops is set to 0)
>
> On 07/23/2012 09:12 PM, Alex Balashov wrote:
>
>> I did an experiment to try to simplify the problem, and rule out mqueue
>> concurrency/locking issues:
>>
>> modparam("pv", "shvset", "lasttm=i:-1")
>>
>> modparam("rtimer", "timer", "name=test;interval=1;mode=1")
>> modparam("rtimer", "exec", "timer=test;route=TEST_ROUTE")
>>
>> route[TEST_ROUTE] {
>> while(1) {
>> if($shv(lasttm) < 0)
>> $shv(lasttm) = $TV(sn);
>> else {
>> $var(gap) = $TV(sn) - $shv(lasttm);
>>
>> if($var(gap) >= 1) {
>> xlog("L_INFO", "Presented time gap:
>> $var(gap)\n");
>> }
>> }
>>
>> $shv(lasttm) = $TV(sn);
>> }
>> }
>>
>> And here's what I saw in the log:
>>
>> Jul 23 21:10:07 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:12 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:13 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:16 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:18 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:21 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:23 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:29 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:30 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:34 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:36 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:38 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:39 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:40 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>> Jul 23 21:10:43 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>> Presented time gap: 1
>>
>> When I repeated the experiment with interval=3:
>>
>> Jul 23 21:11:51 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>> Presented time gap: 1
>> Jul 23 21:11:52 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>> Presented time gap: 1
>> Jul 23 21:11:54 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>> Presented time gap: 1
>> Jul 23 21:11:55 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>> Presented time gap: 1
>> Jul 23 21:11:56 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>> Presented time gap: 1
>> Jul 23 21:11:59 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>> Presented time gap: 1
>> Jul 23 21:12:03 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>> Presented time gap: 1
>> Jul 23 21:12:04 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>> Presented time gap: 1
>>
>> So, something is definitely interrupting the possibility of continuous
>> execution of these rtimer tasks.
>>
>
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Tue Jul 24 04:26:38 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 23 Jul 2012 22:26:38 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500E0224.2090307@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
<500DF120.1050604@evaristesys.com>
<500DF67A.5000108@evaristesys.com> <500DF90F.10906@evaristesys.com>
<500E0224.2090307@evaristesys.com>
Message-ID: <500E07DE.1030201@evaristesys.com>
Okay, ignore this bit. I had a conflicting timer that I forgot about
that was engaged at a 5 sec interval, thus polluting the results. When
I run my pure while() loop test routine and only it, it does not
demonstrate this loop-breaking behaviour.
It still doesn't explain what is going on with my mqueue-consuming DB
loop, though. One easy explanation would be that mq_fetch() returns 0
at some point, and the while() loop bottoms out, and doesn't run again
for 'interval' (u)sec. But then, why would I be showing the mqueue as
growing and growing, not at 0 elements?
On 07/23/2012 10:02 PM, Alex Balashov wrote:
> Yeah, something's going on interrupting the execution of the route. I
> set the interval to 1:
>
> modparam("rtimer", "timer", "name=test;interval=1;mode=1")
>
> And then added this to the infinite for() loop in
> timer_proc.c:fork_basic_timer(), after the call to the timer_function:
>
> LM_ERR("Bottomed out of timer loop\n");
>
> if(tm_last > 0) {
> tm = time(NULL);
> LM_ERR("Execution gap: %d\n",
> tm - tm_last);
> }
>
> tm_last = time(0);
> }
>
> And here's what I got:
>
> Jul 23 21:59:19 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
> Presented time gap: 1
> Jul 23 21:59:20 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
> Presented time gap: 1
> Jul 23 21:59:22 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
> Presented time gap: 1
> Jul 23 21:59:22 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
> rtimer [rtimer_mod.c:194]: Bottomed out of top route execution
> Jul 23 21:59:22 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
> <core> [timer_proc.c:94]: Bottomed out of timer loop
> Jul 23 21:59:23 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
> Presented time gap: 1
> Jul 23 21:59:25 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
> Presented time gap: 1
> Jul 23 21:59:26 diminuendo-1 /usr/local/sbin/kamailio[2686]: INFO:
> Presented time gap: 1
> Jul 23 21:59:27 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
> rtimer [rtimer_mod.c:194]: Bottomed out of top route execution
> Jul 23 21:59:27 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
> <core> [timer_proc.c:94]: Bottomed out of timer loop
> Jul 23 21:59:27 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
> <core> [timer_proc.c:99]: Execution gap: 5
> Jul 23 21:59:32 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
> rtimer [rtimer_mod.c:194]: Bottomed out of top route execution
> Jul 23 21:59:32 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
> <core> [timer_proc.c:94]: Bottomed out of timer loop
> Jul 23 21:59:32 diminuendo-1 /usr/local/sbin/kamailio[2687]: ERROR:
> <core> [timer_proc.c:99]: Execution gap: 5
>
> There is definitely something dependably interrupting the execution once
> in a while (every 5 sec).
>
>
> On 07/23/2012 09:23 PM, Alex Balashov wrote:
>
>> I think some sort of execution time governor in the actions
>> infrastructure is probably the right angle here.
>>
>> I added a log statement to
>> modules_k/rtimer/rtimer_mod.c:stm_timer_exec():
>>
>> for(rt=it->rt; rt; rt=rt->next)
>> {
>> fmsg = faked_msg_next();
>> if (exec_pre_script_cb(fmsg, REQUEST_CB_TYPE)==0 )
>> continue; /* drop the request */
>> set_route_type(REQUEST_ROUTE);
>> run_top_route(main_rt.rlist[rt->route], fmsg, 0);
>> LM_ERR("Fell out of route execution: %u\n", time(NULL));
>> exec_post_script_cb(fmsg, REQUEST_CB_TYPE);
>> }
>>
>> And here's what I saw, with the previous test task (quoted in the
>> message above which I am posting):
>>
>> Jul 23 21:20:15 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
>> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092815
>> Jul 23 21:20:19 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:20 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
>> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092820
>> Jul 23 21:20:22 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:24 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:25 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:25 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
>> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092825
>> Jul 23 21:20:28 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:29 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:30 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
>> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092830
>> Jul 23 21:20:31 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:35 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:35 diminuendo-1 /usr/local/sbin/kamailio[26255]: ERROR:
>> rtimer [rtimer_mod.c:192]: Fell out of route execution: 1343092835
>> Jul 23 21:20:36 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:37 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>> Jul 23 21:20:38 diminuendo-1 /usr/local/sbin/kamailio[26254]: INFO:
>> Presented time gap: 1
>>
>> Shouldn't that while() loop in the script run to infinity?
>> (max_while_loops is set to 0)
>>
>> On 07/23/2012 09:12 PM, Alex Balashov wrote:
>>
>>> I did an experiment to try to simplify the problem, and rule out mqueue
>>> concurrency/locking issues:
>>>
>>> modparam("pv", "shvset", "lasttm=i:-1")
>>>
>>> modparam("rtimer", "timer", "name=test;interval=1;mode=1")
>>> modparam("rtimer", "exec", "timer=test;route=TEST_ROUTE")
>>>
>>> route[TEST_ROUTE] {
>>> while(1) {
>>> if($shv(lasttm) < 0)
>>> $shv(lasttm) = $TV(sn);
>>> else {
>>> $var(gap) = $TV(sn) - $shv(lasttm);
>>>
>>> if($var(gap) >= 1) {
>>> xlog("L_INFO", "Presented time gap:
>>> $var(gap)\n");
>>> }
>>> }
>>>
>>> $shv(lasttm) = $TV(sn);
>>> }
>>> }
>>>
>>> And here's what I saw in the log:
>>>
>>> Jul 23 21:10:07 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:12 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:13 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:16 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:18 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:21 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:23 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:29 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:30 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:34 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:36 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:38 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:39 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:40 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:10:43 diminuendo-1 /usr/local/sbin/kamailio[26073]: INFO:
>>> Presented time gap: 1
>>>
>>> When I repeated the experiment with interval=3:
>>>
>>> Jul 23 21:11:51 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:11:52 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:11:54 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:11:55 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:11:56 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:11:59 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:12:03 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>>> Presented time gap: 1
>>> Jul 23 21:12:04 diminuendo-1 /usr/local/sbin/kamailio[26132]: INFO:
>>> Presented time gap: 1
>>>
>>> So, something is definitely interrupting the possibility of continuous
>>> execution of these rtimer tasks.
>>>
>>
>>
>
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Tue Jul 24 04:46:43 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 23 Jul 2012 22:46:43 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500DEE82.2060304@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
Message-ID: <500E0C93.6000806@evaristesys.com>
On 07/23/2012 08:38 PM, Alex Balashov wrote:
> route[ACCT_WRITER] {
> while(mq_fetch("acct_write")) {
> # Some stuff to write $mqv(...) values to PostgreSQL.
>
> ...
>
> sql_query("ca", "SELECT * FROM acct_event_proc(...)");
> ...
>
> mq_pv_free("acct_write");
> }
> }
I added the mq_size() function in script:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commit;h=f492b41bd12904e3132260562073e79d76a003a5
Then, added this to the bottom of this route:
$var(sz) = mq_size("acct_write");
if($var(sz) > 0)
xlog("L_INFO", "Exiting request route with mq size:
$var(sz)\n");
And, I'm seeing this in the log, running at a 1-second interval:
Jul 24 22:41:59 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 229
Jul 24 22:42:00 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 82
Jul 24 22:42:05 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 328
Jul 24 22:42:11 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 689
Jul 24 22:42:15 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 946
Jul 24 22:42:22 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1586
Jul 24 22:42:27 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1783
Jul 24 22:42:32 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1964
Jul 24 22:42:37 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2346
Jul 24 22:42:39 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2323
Jul 24 22:42:41 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2210
Jul 24 22:42:45 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2224
Jul 24 22:42:46 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2056
Jul 24 22:42:47 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1904
Jul 24 22:42:48 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1798
Jul 24 22:42:49 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1619
Jul 24 22:42:53 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1651
Jul 24 22:42:54 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1467
Jul 24 22:42:55 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1378
Jul 24 22:42:56 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1206
Jul 24 22:42:59 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1220
Jul 24 22:43:04 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1542
Jul 24 22:43:08 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1733
Jul 24 22:43:13 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1846
Jul 24 22:43:21 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2437
Jul 24 22:43:26 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2751
Jul 24 22:43:29 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2734
Jul 24 22:43:33 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2778
Jul 24 22:43:35 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2742
Jul 24 22:43:37 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2582
Jul 24 22:43:42 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2828
Jul 24 22:43:44 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2663
Jul 24 22:43:45 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2490
Jul 24 22:43:46 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2339
Jul 24 22:43:47 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2153
Jul 24 22:43:49 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2022
Jul 24 22:43:53 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2182
Jul 24 22:43:54 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2002
Jul 24 22:43:55 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1813
Jul 24 22:43:57 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1638
Jul 24 22:43:58 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1439
Jul 24 22:44:02 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1452
Jul 24 22:44:06 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1640
Jul 24 22:44:11 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 1836
Jul 24 22:44:17 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2120
Jul 24 22:44:22 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2156
Jul 24 22:44:27 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
Executing request route with mq size: 2495
So, perhaps my issue comes down to the while() loop breaking before the
queue is truly empty. That is, unless those thousands of records are
somehow showing up between the while() condition evaluation and my log
statement, which seems quite unlikely. Any way to fix that?
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From ngoahotanglongbk at gmail.com Tue Jul 24 05:55:02 2012
From: ngoahotanglongbk at gmail.com (Duong Manh Truong)
Date: Tue, 24 Jul 2012 10:55:02 +0700
Subject: [SR-Users] Kamailio with APNS
Message-ID: <CADNPFHQX7PWzpLM9+oWQfwnQNVE-oLPpJtbr_-C_-66r9XaB_Q@mail.gmail.com>
Hi list,
My team are developing a SIP client for mobile running iOS ,
then having to deal with the "back ground mode" problem while this soft is
installed on mobiles
One of the solutions is using APNS. (Apple Push Notification Service)
I wanna to use Kamailio as SIP Redirect / Proxy for my current SIP server
The model is like that:
User A <---------> Kamailio <---------> SIP server <--------> User B
IF UserA call UserB, UserB is not available now (not registered yet),
normally, SIP server will reply Kamailio with "404 Not found"
In that case, i want to set up Kamailio do the communication with APNS and
waiting for UserB "Wake up" then RESEND the Invite message ......
(instead of forwarding this 404 message to UserA)
I am getting stuck at how Kamailio can control "404 Not found" message
which it receives from SIP server .
I do searching around several days but still can not get any clearer
points.
Please help me with some instruction/ configuration of Kamailio for this
case !
Thank you very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/a6cbe404/attachment.htm>
From ngoahotanglongbk at gmail.com Tue Jul 24 06:02:27 2012
From: ngoahotanglongbk at gmail.com (Duong Manh Truong)
Date: Tue, 24 Jul 2012 11:02:27 +0700
Subject: [SR-Users] Kamailio with APNS
Message-ID: <CADNPFHQgNHdOXPt82xK4N=-5DNUeNREpdY69-SfM+NJ5q2LOJg@mail.gmail.com>
Hi list,
My team are developing a SIP client for mobile running iOS ,
then having to deal with the "back ground mode" problem while this soft is
installed on mobiles
One of the solutions is using APNS. (Apple Push Notification Service)
I wanna to use Kamailio as SIP Redirect / Proxy for my current SIP server
The model is like that:
User A <---------> Kamailio <---------> SIP server <--------> User B
IF UserA call UserB, UserB is not available now (not registered yet),
normally, SIP server will reply Kamailio with "404 Not found"
In that case, i want to set up Kamailio do the communication with APNS and
waiting for UserB "Wake up" then RESEND the Invite message ......
(instead of forwarding this 404 message to UserA)
I am getting stuck at how Kamailio can control "404 Not found" message
which it receives from SIP server .
I do searching around several days but still can not get any clearer
points.
Please help me with some instruction/ configuration of Kamailio for this
case !
Thank you very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/bde2340c/attachment.htm>
From miconda at gmail.com Tue Jul 24 08:59:31 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 24 Jul 2012 08:59:31 +0200
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500E0C93.6000806@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
<500E0C93.6000806@evaristesys.com>
Message-ID: <500E47D3.2010205@gmail.com>
Hello,
On 7/24/12 4:46 AM, Alex Balashov wrote:
> On 07/23/2012 08:38 PM, Alex Balashov wrote:
>
>> route[ACCT_WRITER] {
>> while(mq_fetch("acct_write")) {
>> # Some stuff to write $mqv(...) values to PostgreSQL.
>>
>> ...
>>
>> sql_query("ca", "SELECT * FROM acct_event_proc(...)");
>> ...
>>
>> mq_pv_free("acct_write");
>> }
>> }
>
> I added the mq_size() function in script:
>
> http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commit;h=f492b41bd12904e3132260562073e79d76a003a5
>
>
> Then, added this to the bottom of this route:
>
> $var(sz) = mq_size("acct_write");
>
> if($var(sz) > 0)
> xlog("L_INFO", "Exiting request route with mq size:
> $var(sz)\n");
I assume the xlog message above is starting ' Executing ...' as showed
in next logs.
Have you tried it with the log message in the sources to see if it goes
after the C code line:
run_top_route(main_rt.rlist[rt->route], fmsg, 0);
?
The way mqueue is consuming items from queue does not ensure queue
locking until all items are consumed. So the first item there is removed
from queue and cloned in private memory where is accessible via PV, then
the queue is unlocked so others can consume or add to it.
Not being in office for few days, I cannot run tests myself ... do you
have heavy writers? Can you add few more timer processes to consume from
queue and see what happens?
Cheers,
Daniel
>
> And, I'm seeing this in the log, running at a 1-second interval:
>
> Jul 24 22:41:59 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 229
> Jul 24 22:42:00 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 82
> Jul 24 22:42:05 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 328
> Jul 24 22:42:11 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 689
> Jul 24 22:42:15 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 946
> Jul 24 22:42:22 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1586
> Jul 24 22:42:27 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1783
> Jul 24 22:42:32 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1964
> Jul 24 22:42:37 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2346
> Jul 24 22:42:39 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2323
> Jul 24 22:42:41 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2210
> Jul 24 22:42:45 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2224
> Jul 24 22:42:46 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2056
> Jul 24 22:42:47 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1904
> Jul 24 22:42:48 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1798
> Jul 24 22:42:49 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1619
> Jul 24 22:42:53 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1651
> Jul 24 22:42:54 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1467
> Jul 24 22:42:55 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1378
> Jul 24 22:42:56 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1206
> Jul 24 22:42:59 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1220
> Jul 24 22:43:04 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1542
> Jul 24 22:43:08 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1733
> Jul 24 22:43:13 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1846
> Jul 24 22:43:21 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2437
> Jul 24 22:43:26 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2751
> Jul 24 22:43:29 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2734
> Jul 24 22:43:33 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2778
> Jul 24 22:43:35 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2742
> Jul 24 22:43:37 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2582
> Jul 24 22:43:42 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2828
> Jul 24 22:43:44 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2663
> Jul 24 22:43:45 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2490
> Jul 24 22:43:46 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2339
> Jul 24 22:43:47 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2153
> Jul 24 22:43:49 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2022
> Jul 24 22:43:53 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2182
> Jul 24 22:43:54 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2002
> Jul 24 22:43:55 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1813
> Jul 24 22:43:57 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1638
> Jul 24 22:43:58 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1439
> Jul 24 22:44:02 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1452
> Jul 24 22:44:06 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1640
> Jul 24 22:44:11 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 1836
> Jul 24 22:44:17 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2120
> Jul 24 22:44:22 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2156
> Jul 24 22:44:27 diminuendo-1 /usr/local/sbin/kamailio[31118]: INFO:
> Executing request route with mq size: 2495
>
> So, perhaps my issue comes down to the while() loop breaking before
> the queue is truly empty. That is, unless those thousands of records
> are somehow showing up between the while() condition evaluation and my
> log statement, which seems quite unlikely. Any way to fix that?
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Tue Jul 24 09:01:21 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 24 Jul 2012 09:01:21 +0200
Subject: [SR-Users] SIREMIS
In-Reply-To: <CAC5mzB71k61BgkRm1gV1SrBAszoHpRx15ZOT8hBW1pWyAD777w@mail.gmail.com>
References: <CAC5mzB71k61BgkRm1gV1SrBAszoHpRx15ZOT8hBW1pWyAD777w@mail.gmail.com>
Message-ID: <500E4841.5080708@gmail.com>
Hello,
On 7/23/12 5:14 PM, Adam Fyfe wrote:
> Hi,
>
> I am testing Siremis, and have become stuck.
>
> How does one add an outbound SIP trunk for calls ?
trunking is more like forwarding traffic, do you look for kind of least
cost routing engine? If yes, then check lcr, carrierroute or drouting
modules.
If you look for something else, reply with a bit more details here on
the mailing list.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From ushacked at gmail.com Tue Jul 24 09:30:07 2012
From: ushacked at gmail.com (Uri Shacked)
Date: Tue, 24 Jul 2012 10:30:07 +0300
Subject: [SR-Users] Can't initialize shared memory
In-Reply-To: <CAMMbDhT73TGdwP=ofMdp+fv2cq_nEwC2hnkFcy8XMxS074O3ZQ@mail.gmail.com>
References: <CAMMbDhT73TGdwP=ofMdp+fv2cq_nEwC2hnkFcy8XMxS074O3ZQ@mail.gmail.com>
Message-ID: <CAMMbDhTmH6XaCaH0anAOqqOJhZmv=gzuTJsNGvj94A4mh=qrFQ@mail.gmail.com>
>
> this is the log when debug is 4...
>
> Jul 24 10:19:37 RNDSRV kamailio: : <core> [cfg.y:3532]: parse error in
> config file /usr/local/etc/kamailio/global_params.cfg, line 121, column 54:
> Can't initialize shared memory
> Jul 24 10:19:37 RNDSRV kamailio: ERROR: mi_fifo [mi_fifo.c:271]: FIFO stat
> failed: Bad address
>
>
> not much.
> line 121 on the file is the modparam for mi_fifo indication the
> /tmp/kamailio_fifo file.
>
> # ----- mi_fifo params -----
> modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")
> any ideas?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/aea0d2fb/attachment-0001.htm>
From antanas.masevicius at ntt.lt Tue Jul 24 09:49:47 2012
From: antanas.masevicius at ntt.lt (Antanas Masevicius)
Date: Tue, 24 Jul 2012 10:49:47 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
Message-ID: <500E539B.9030300@ntt.lt>
Hello,
having trouble running LCR in kamailio 3.3 (head).
Here is my DB excerpt which i use to reproduce the problem:
INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
INSERT INTO `lcr_gw` VALUES
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
I stripped all other LCR data from my DB and only this rule with
from_uri and request_uri seems to bother me.
Tried this version on debian lenny and debian squeeze. On Lenny i am not
able to load lcr tables at all, get a segfault.
On squeeze, lcr tables loads up, but this rule gets marked as disabled.
Here is config part which i use to load a rule:
if (load_gws(90, $rU, $fu)) {
if (next_gw()) {
t_on_failure("FAIL_GW");
} else {
route(NO_ROUTE);
}
On squeeze, if i add following code to lcr_mod.c:1249 :
LM_INFO("LOADING lcr rule <%u> \n", rule_id);
right after:
rule_id = (unsigned int)VAL_INT(ROW_VALUES(row));
rule_id is still printed, but i get segfault like this:
Jul 24 10:17:43 sp1 kernel: [23482626.105865] kamailio[15136]: segfault
at a4 ip 00007fde15cb8802 sp 00007fff39d68320 error 4 in
lcr.so[7fde15ca8000+23000]
Not sure what i do terribly wrong. Setting from_uri and request_uri to
anythig but NULL makes the code to segfault with that print line added.
Without print line, kamailio starts, but never loads that rule.
Any help would be appreciated.
best regards,
Antanas Masevicius
NTT
From abalashov at evaristesys.com Tue Jul 24 09:53:46 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 24 Jul 2012 03:53:46 -0400
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
Message-ID: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
When calling load_gws(), try putting $rU and $fu in double quotes, e.g. "$rU" rather than $rU bare.?
-- Alex
--
Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/Antanas Masevicius <antanas.masevicius at ntt.lt> wrote:Hello,
having trouble running LCR in kamailio 3.3 (head).
Here is my DB excerpt which i use to reproduce the problem:
INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
INSERT INTO `lcr_gw` VALUES
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
I stripped all other LCR data from my DB and only this rule with
from_uri and request_uri? seems to bother me.
Tried this version on debian lenny and debian squeeze. On Lenny i am not
able to load lcr tables at all, get a segfault.
On squeeze, lcr tables loads up, but this rule gets marked as disabled.
Here is config part which i use to load a rule:
??????? if (load_gws(90, $rU, $fu)) {
??????????? if (next_gw()) {
??????????????? t_on_failure("FAIL_GW");
??????????? } else {
??????????????? route(NO_ROUTE);
??????????? }
On squeeze, if i add following code to lcr_mod.c:1249 :
? LM_INFO("LOADING lcr rule <%u> \n", rule_id);
right after:
? rule_id = (unsigned int)VAL_INT(ROW_VALUES(row));
rule_id is still printed, but i get segfault like this:
Jul 24 10:17:43 sp1 kernel: [23482626.105865] kamailio[15136]: segfault
at a4 ip 00007fde15cb8802 sp 00007fff39d68320 error 4 in
lcr.so[7fde15ca8000+23000]
Not sure what i do terribly wrong. Setting from_uri and request_uri to
anythig but NULL makes the code to segfault with that print line added.
Without print line, kamailio starts, but never loads that rule.
Any help would be appreciated.
best regards,
Antanas Masevicius
NTT
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/0cb22e95/attachment.htm>
From nguyenthanhtien at ansv.vn Tue Jul 24 10:07:06 2012
From: nguyenthanhtien at ansv.vn (Nguyen Thanh Tien)
Date: Tue, 24 Jul 2012 15:07:06 +0700
Subject: [SR-Users] Kamailio with APNS
Message-ID: <000c01cd6973$5455d840$fd0188c0$@ansv.vn>
I think you can find the 404 message at the onreply_route[].
I tried and found the 200 OK here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/eaa5066c/attachment.htm>
From antanas.masevicius at ntt.lt Tue Jul 24 10:17:23 2012
From: antanas.masevicius at ntt.lt (Antanas Masevicius)
Date: Tue, 24 Jul 2012 11:17:23 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
References: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
Message-ID: <500E5A13.4070801@ntt.lt>
Hello,
thanks for the tip Alex, but still getting the same error:
lcr [hash.c:166]: could not find (disabled) rule with id <2617960>
if it helps, here is my ldd output for lcr.so:
linux-vdso.so.1 => (0x00007ffffe7ff000)
libpcre.so.3 => /lib/libpcre.so.3 (0x00007faf0cfd1000)
libsrdb1.so.1 => /usr/local2/lib64/kamailio/libsrdb1.so.1
(0x00007faf0cdbf000)
libkcore.so.1 => /usr/local2/lib64/kamailio/libkcore.so.1
(0x00007faf0cbb3000)
libc.so.6 => /lib/libc.so.6 (0x00007faf0c852000)
/lib64/ld-linux-x86-64.so.2 (0x00007faf0d42e000)
Here is extended debug excerpt:
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_val.c:117]: converting STRING [118]
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: lcr
[lcr_mod.c:1236]: loading, cycle 0 with <1> rows
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:62]: freeing rows at 0x7f0dc4afe4d8
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:85]: freeing RES_NAMES[5] at 0x7f0dc4afaa50
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:118]: allocate 48 bytes for result set at 0x7f0dc4afdee8
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:85]: allocate 16 bytes for RES_NAMES[0] at 0x7f0dc4afaa50
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:92]: RES_NAMES(0x7f0dc4afe420)[1]=[ip_addr]
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:85]: allocate 16 bytes for RES_NAMES[4] at 0x7f0dc4afdf78
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:92]: RES_NAMES(0x7f0dc4afe440)[5]=[params]
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:136]: use DB1_STRING result type
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:136]: use DB1_STRING result type
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:100]: use DB1_INT result type
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:85]: allocate 16 bytes for RES_NAMES[12] at 0x7f0dc4afe3d8
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_val.c:73]: converting INT [0]
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_val.c:56]: converting NULL value
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_val.c:56]: converting NULL value
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:85]: freeing RES_NAMES[1] at 0x7f0dc4afe420
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:85]: freeing RES_NAMES[4] at 0x7f0dc4afdf78
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:85]: freeing RES_NAMES[12] at 0x7f0dc4afe3d8
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:62]: freeing rows at 0x7f0dc4afe488
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:155]: allocate 104 bytes for result names at 0x7f0dc4afe598
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:85]: allocate 16 bytes for RES_NAMES[2] at 0x7f0dc4afe558
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:92]: RES_NAMES(0x7f0dc4afe518)[4]=[transport]
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:136]: use DB1_STRING result type
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:85]: allocate 16 bytes for RES_NAMES[7] at 0x7f0dc4afe440
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:136]: use DB1_STRING result type
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:85]: allocate 16 bytes for RES_NAMES[11] at 0x7f0dc4afe420
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:92]: RES_NAMES(0x7f0dc4afaa50)[12]=[id]
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:85]: freeing RES_NAMES[3] at 0x7f0dc4afe538
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:85]: freeing RES_NAMES[8] at 0x7f0dc4afdf78
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_res.c:94]: freeing result names at 0x7f0dc4afe598
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:100]: use DB1_INT result type
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:92]: RES_NAMES(0x7f0dc4afe400)[1]=[gw_id]
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
[km_res.c:100]: use DB1_INT result type
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
[db_val.c:73]: converting INT [0]
Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: lcr
[hash.c:166]: could not find (disabled) rule with id <2617960>
Antanas
NTT
On 2012.07.24 10:53, Alex Balashov wrote:
> When calling load_gws(), try putting $rU and $fu in double quotes,
> e.g. "$rU" rather than $rU bare.
>
>
>
>
> -- Alex
>
> --
> Sent from my Samsung mobile, and thus lacking in the refinement one
> might expect from a proper keyboard.
>
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> Tel: +1-678-954-0670
> Web: http://www.evaristesys.com/
>
> Antanas Masevicius <antanas.masevicius at ntt.lt> wrote:
> Hello,
>
> having trouble running LCR in kamailio 3.3 (head).
>
> Here is my DB excerpt which i use to reproduce the problem:
> INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
> INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
> INSERT INTO `lcr_gw` VALUES
> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
>
> I stripped all other LCR data from my DB and only this rule with
> from_uri and request_uri seems to bother me.
>
> Tried this version on debian lenny and debian squeeze. On Lenny i am not
> able to load lcr tables at all, get a segfault.
> On squeeze, lcr tables loads up, but this rule gets marked as disabled.
> Here is config part which i use to load a rule:
> if (load_gws(90, $rU, $fu)) {
> if (next_gw()) {
> t_on_failure("FAIL_GW");
> } else {
> route(NO_ROUTE);
> }
>
> On squeeze, if i add following code to lcr_mod.c:1249 :
> LM_INFO("LOADING lcr rule <%u> \n", rule_id);
> right after:
> rule_id = (unsigned int)VAL_INT(ROW_VALUES(row));
>
> rule_id is still printed, but i get segfault like this:
>
> Jul 24 10:17:43 sp1 kernel: [23482626.105865] kamailio[15136]: segfault
> at a4 ip 00007fde15cb8802 sp 00007fff39d68320 error 4 in
> lcr.so[7fde15ca8000+23000]
>
> Not sure what i do terribly wrong. Setting from_uri and request_uri to
> anythig but NULL makes the code to segfault with that print line added.
> Without print line, kamailio starts, but never loads that rule.
>
> Any help would be appreciated.
>
> best regards,
>
> Antanas Masevicius
> NTT
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
--
Antanas Masevic(ius
Technikos direktorius
UAB "Nacionalinis telekomunikaciju tinklas"
Tel. +370 5 2056000
Tel. +370 700 00031 (tiesioginis)
Fax. +370 700 00034
el.p: antanas.masevicius at ntt.lt
www.ntt.lt
www.spykas.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/01f70cdc/attachment-0001.htm>
From alex at speakup.nl Tue Jul 24 10:20:09 2012
From: alex at speakup.nl (Alex Hermann)
Date: Tue, 24 Jul 2012 10:20:09 +0200
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500E0C93.6000806@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
<500E0C93.6000806@evaristesys.com>
Message-ID: <201207241020.09662.alex@speakup.nl>
On Tuesday 24 July 2012 04:46:43 Alex Balashov wrote:
> So, perhaps my issue comes down to the while() loop breaking before the
> queue is truly empty. That is, unless those thousands of records are
> somehow showing up between the while() condition evaluation and my log
> statement, which seems quite unlikely. Any way to fix that?
Just to be sure, you do have set max_while_loops high enough to handle your
message rate?
--
Alex Hermann
From abalashov at evaristesys.com Tue Jul 24 10:26:37 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 24 Jul 2012 04:26:37 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <201207241020.09662.alex@speakup.nl>
References: <500DEE82.2060304@evaristesys.com>
<500E0C93.6000806@evaristesys.com>
<201207241020.09662.alex@speakup.nl>
Message-ID: <500E5C3D.9080405@evaristesys.com>
On 07/24/2012 04:20 AM, Alex Hermann wrote:
> On Tuesday 24 July 2012 04:46:43 Alex Balashov wrote:
>> So, perhaps my issue comes down to the while() loop breaking before the
>> queue is truly empty. That is, unless those thousands of records are
>> somehow showing up between the while() condition evaluation and my log
>> statement, which seems quite unlikely. Any way to fix that?
>
>
> Just to be sure, you do have set max_while_loops high enough to handle your
> message rate?
I have it set to 2000, and am not exceeding 80-90 CPS, which each
generate ~4-5 events/sec. I would think that would be high enough, but
I suppose it's worth testing that theory just in case. Good call.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From antanas.masevicius at ntt.lt Tue Jul 24 11:20:36 2012
From: antanas.masevicius at ntt.lt (Antanas Masevicius)
Date: Tue, 24 Jul 2012 12:20:36 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <500E5A13.4070801@ntt.lt>
References: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
<500E5A13.4070801@ntt.lt>
Message-ID: <500E68E4.10109@ntt.lt>
Hello,
Looks like i finally got it. REGEXP patterns in from_uri and request_uri
must be terminated between //.
Maybe someone could add a notice about this in LCR documentation?
Only got it after reading some documentation on pcre lib.
best regards,
Antanas
NTT
On 2012.07.24 11:17, Antanas Masevicius wrote:
> Hello,
>
> thanks for the tip Alex, but still getting the same error:
>
> lcr [hash.c:166]: could not find (disabled) rule with id <2617960>
>
> if it helps, here is my ldd output for lcr.so:
>
> linux-vdso.so.1 => (0x00007ffffe7ff000)
> libpcre.so.3 => /lib/libpcre.so.3 (0x00007faf0cfd1000)
> libsrdb1.so.1 => /usr/local2/lib64/kamailio/libsrdb1.so.1
> (0x00007faf0cdbf000)
> libkcore.so.1 => /usr/local2/lib64/kamailio/libkcore.so.1
> (0x00007faf0cbb3000)
> libc.so.6 => /lib/libc.so.6 (0x00007faf0c852000)
> /lib64/ld-linux-x86-64.so.2 (0x00007faf0d42e000)
>
> Here is extended debug excerpt:
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_val.c:117]: converting STRING [118]
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: lcr
> [lcr_mod.c:1236]: loading, cycle 0 with <1> rows
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:62]: freeing rows at 0x7f0dc4afe4d8
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:85]: freeing RES_NAMES[5] at 0x7f0dc4afaa50
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:118]: allocate 48 bytes for result set at 0x7f0dc4afdee8
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:85]: allocate 16 bytes for RES_NAMES[0] at 0x7f0dc4afaa50
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:92]: RES_NAMES(0x7f0dc4afe420)[1]=[ip_addr]
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:85]: allocate 16 bytes for RES_NAMES[4] at 0x7f0dc4afdf78
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:92]: RES_NAMES(0x7f0dc4afe440)[5]=[params]
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:136]: use DB1_STRING result type
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:136]: use DB1_STRING result type
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:100]: use DB1_INT result type
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:85]: allocate 16 bytes for RES_NAMES[12] at 0x7f0dc4afe3d8
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_val.c:73]: converting INT [0]
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_val.c:56]: converting NULL value
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_val.c:56]: converting NULL value
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:85]: freeing RES_NAMES[1] at 0x7f0dc4afe420
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:85]: freeing RES_NAMES[4] at 0x7f0dc4afdf78
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:85]: freeing RES_NAMES[12] at 0x7f0dc4afe3d8
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:62]: freeing rows at 0x7f0dc4afe488
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:155]: allocate 104 bytes for result names at 0x7f0dc4afe598
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:85]: allocate 16 bytes for RES_NAMES[2] at 0x7f0dc4afe558
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:92]: RES_NAMES(0x7f0dc4afe518)[4]=[transport]
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:136]: use DB1_STRING result type
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:85]: allocate 16 bytes for RES_NAMES[7] at 0x7f0dc4afe440
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:136]: use DB1_STRING result type
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:85]: allocate 16 bytes for RES_NAMES[11] at 0x7f0dc4afe420
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:92]: RES_NAMES(0x7f0dc4afaa50)[12]=[id]
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:85]: freeing RES_NAMES[3] at 0x7f0dc4afe538
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:85]: freeing RES_NAMES[8] at 0x7f0dc4afdf78
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_res.c:94]: freeing result names at 0x7f0dc4afe598
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:100]: use DB1_INT result type
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:92]: RES_NAMES(0x7f0dc4afe400)[1]=[gw_id]
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
> [km_res.c:100]: use DB1_INT result type
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
> [db_val.c:73]: converting INT [0]
> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: lcr
> [hash.c:166]: could not find (disabled) rule with id <2617960>
>
> Antanas
> NTT
>
> On 2012.07.24 10:53, Alex Balashov wrote:
>> When calling load_gws(), try putting $rU and $fu in double quotes,
>> e.g. "$rU" rather than $rU bare.
>>
>>
>>
>>
>> -- Alex
>>
>> --
>> Sent from my Samsung mobile, and thus lacking in the refinement one
>> might expect from a proper keyboard.
>>
>> Alex Balashov - Principal
>> Evariste Systems LLC
>> 235 E Ponce de Leon Ave
>> Suite 106
>> Decatur, GA 30030
>> Tel: +1-678-954-0670
>> Web: http://www.evaristesys.com/
>>
>> Antanas Masevicius <antanas.masevicius at ntt.lt> wrote:
>> Hello,
>>
>> having trouble running LCR in kamailio 3.3 (head).
>>
>> Here is my DB excerpt which i use to reproduce the problem:
>> INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
>> INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
>> INSERT INTO `lcr_gw` VALUES
>> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
>>
>> I stripped all other LCR data from my DB and only this rule with
>> from_uri and request_uri seems to bother me.
>>
>> Tried this version on debian lenny and debian squeeze. On Lenny i am not
>> able to load lcr tables at all, get a segfault.
>> On squeeze, lcr tables loads up, but this rule gets marked as disabled.
>> Here is config part which i use to load a rule:
>> if (load_gws(90, $rU, $fu)) {
>> if (next_gw()) {
>> t_on_failure("FAIL_GW");
>> } else {
>> route(NO_ROUTE);
>> }
>>
>> On squeeze, if i add following code to lcr_mod.c:1249 :
>> LM_INFO("LOADING lcr rule <%u> \n", rule_id);
>> right after:
>> rule_id = (unsigned int)VAL_INT(ROW_VALUES(row));
>>
>> rule_id is still printed, but i get segfault like this:
>>
>> Jul 24 10:17:43 sp1 kernel: [23482626.105865] kamailio[15136]: segfault
>> at a4 ip 00007fde15cb8802 sp 00007fff39d68320 error 4 in
>> lcr.so[7fde15ca8000+23000]
>>
>> Not sure what i do terribly wrong. Setting from_uri and request_uri to
>> anythig but NULL makes the code to segfault with that print line added.
>> Without print line, kamailio starts, but never loads that rule.
>>
>> Any help would be appreciated.
>>
>> best regards,
>>
>> Antanas Masevicius
>> NTT
>>
>>
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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
>
> --
> Antanas Masevic(ius
> Technikos direktorius
> UAB "Nacionalinis telekomunikaciju tinklas"
> Tel. +370 5 2056000
> Tel. +370 700 00031 (tiesioginis)
> Fax. +370 700 00034
> el.p: antanas.masevicius at ntt.lt
> www.ntt.lt
> www.spykas.com
--
Antanas Masevic(ius
Technikos direktorius
UAB "Nacionalinis telekomunikaciju tinklas"
Tel. +370 5 2056000
Tel. +370 700 00031 (tiesioginis)
Fax. +370 700 00034
el.p: antanas.masevicius at ntt.lt
www.ntt.lt
www.spykas.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/cb21aed1/attachment.htm>
From neill.wilkinson at btinternet.com Tue Jul 24 11:28:06 2012
From: neill.wilkinson at btinternet.com (Neill Wilkinson)
Date: Tue, 24 Jul 2012 10:28:06 +0100
Subject: [SR-Users] Kamailio with APNS
In-Reply-To: <CADNPFHQX7PWzpLM9+oWQfwnQNVE-oLPpJtbr_-C_-66r9XaB_Q@mail.gmail.com>
References: <CADNPFHQX7PWzpLM9+oWQfwnQNVE-oLPpJtbr_-C_-66r9XaB_Q@mail.gmail.com>
Message-ID: <CAJ-mRNOWdgve87fti8h6934qgXHK-sqn5SsPwrnNZ+6RjQJKgg@mail.gmail.com>
Are you doing this because your SIP client is sleeping on the device? If so
did you set the properties for the application to change the background
mode for VoIP apps, the
<key>UIBackgroundModes</key> settings in the info.plist file for the app?
http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html
This should enable the app to be woken up when necessary by iOS, may avoid
you having to code around it.
Neill...;o)
Aeonvista Ltd
Opening Up New Ideas
On 24 July 2012 04:55, Duong Manh Truong <ngoahotanglongbk at gmail.com> wrote:
> Hi list,
>
> My team are developing a SIP client for mobile running iOS ,
>
> then having to deal with the "back ground mode" problem while this soft is
> installed on mobiles
>
> One of the solutions is using APNS. (Apple Push Notification Service)
>
> I wanna to use Kamailio as SIP Redirect / Proxy for my current SIP server
>
> The model is like that:
>
> User A <---------> Kamailio <---------> SIP server <--------> User B
>
> IF UserA call UserB, UserB is not available now (not registered yet),
> normally, SIP server will reply Kamailio with "404 Not found"
>
> In that case, i want to set up Kamailio do the communication with APNS and
> waiting for UserB "Wake up" then RESEND the Invite message ......
> (instead of forwarding this 404 message to UserA)
>
> I am getting stuck at how Kamailio can control "404 Not found" message
> which it receives from SIP server .
>
> I do searching around several days but still can not get any clearer
> points.
>
> Please help me with some instruction/ configuration of Kamailio for this
> case !
>
> Thank you very much.
>
>
>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/f5ea0105/attachment-0001.htm>
From antanas.masevicius at ntt.lt Tue Jul 24 14:55:37 2012
From: antanas.masevicius at ntt.lt (Antanas Masevicius)
Date: Tue, 24 Jul 2012 15:55:37 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <500E68E4.10109@ntt.lt>
References: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
<500E5A13.4070801@ntt.lt> <500E68E4.10109@ntt.lt>
Message-ID: <500E9B49.2090706@ntt.lt>
Hello once again,
It looks like core issue was not a termination of regexp. Was not
getting segfaults, but did not get a match either.
After changing rule_id from 2617960 to 0, rule got loaded properly:
sercmd> lcr.dump_rules
{
lcr_id: 90
rule_id: 0
prefix: 118
from_uri: sip:00000000 at xx.xx.lt
request_uri: 118
stopper: 1
}
{
gw_index: 1
priority: 0
weight: 100
}
3
I suspect that lcr code somehow a bit differently stores such rules
internally and primary id fragmentation results in rules set loaded with
improper rule_id:
sercmd> lcr.dump_rules
{
lcr_id: 90
rule_id: 0
prefix: 118
from_uri: sip:00000000 at xx.xx.lt
request_uri: 118
stopper: 1
}
Here, in dump above it should contain rule_id=2617960, but contains 0.
Also for such rule gw fails to be identified.
Antanas
NTT
On 2012.07.24 12:20, Antanas Masevicius wrote:
> Hello,
>
> Looks like i finally got it. REGEXP patterns in from_uri and
> request_uri must be terminated between //.
> Maybe someone could add a notice about this in LCR documentation?
> Only got it after reading some documentation on pcre lib.
>
> best regards,
>
> Antanas
> NTT
>
> On 2012.07.24 11:17, Antanas Masevicius wrote:
>> Hello,
>>
>> thanks for the tip Alex, but still getting the same error:
>>
>> lcr [hash.c:166]: could not find (disabled) rule with id <2617960>
>>
>> if it helps, here is my ldd output for lcr.so:
>>
>> linux-vdso.so.1 => (0x00007ffffe7ff000)
>> libpcre.so.3 => /lib/libpcre.so.3 (0x00007faf0cfd1000)
>> libsrdb1.so.1 => /usr/local2/lib64/kamailio/libsrdb1.so.1
>> (0x00007faf0cdbf000)
>> libkcore.so.1 => /usr/local2/lib64/kamailio/libkcore.so.1
>> (0x00007faf0cbb3000)
>> libc.so.6 => /lib/libc.so.6 (0x00007faf0c852000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007faf0d42e000)
>>
>> Here is extended debug excerpt:
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_val.c:117]: converting STRING [118]
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: lcr
>> [lcr_mod.c:1236]: loading, cycle 0 with <1> rows
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:62]: freeing rows at 0x7f0dc4afe4d8
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:85]: freeing RES_NAMES[5] at 0x7f0dc4afaa50
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:118]: allocate 48 bytes for result set at 0x7f0dc4afdee8
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:85]: allocate 16 bytes for RES_NAMES[0] at 0x7f0dc4afaa50
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:92]: RES_NAMES(0x7f0dc4afe420)[1]=[ip_addr]
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:85]: allocate 16 bytes for RES_NAMES[4] at 0x7f0dc4afdf78
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:92]: RES_NAMES(0x7f0dc4afe440)[5]=[params]
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:136]: use DB1_STRING result type
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:136]: use DB1_STRING result type
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:100]: use DB1_INT result type
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:85]: allocate 16 bytes for RES_NAMES[12] at 0x7f0dc4afe3d8
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_val.c:73]: converting INT [0]
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_val.c:56]: converting NULL value
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_val.c:56]: converting NULL value
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:85]: freeing RES_NAMES[1] at 0x7f0dc4afe420
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:85]: freeing RES_NAMES[4] at 0x7f0dc4afdf78
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:85]: freeing RES_NAMES[12] at 0x7f0dc4afe3d8
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:62]: freeing rows at 0x7f0dc4afe488
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:155]: allocate 104 bytes for result names at 0x7f0dc4afe598
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:85]: allocate 16 bytes for RES_NAMES[2] at 0x7f0dc4afe558
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:92]: RES_NAMES(0x7f0dc4afe518)[4]=[transport]
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:136]: use DB1_STRING result type
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:85]: allocate 16 bytes for RES_NAMES[7] at 0x7f0dc4afe440
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:136]: use DB1_STRING result type
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:85]: allocate 16 bytes for RES_NAMES[11] at 0x7f0dc4afe420
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:92]: RES_NAMES(0x7f0dc4afaa50)[12]=[id]
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:85]: freeing RES_NAMES[3] at 0x7f0dc4afe538
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:85]: freeing RES_NAMES[8] at 0x7f0dc4afdf78
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_res.c:94]: freeing result names at 0x7f0dc4afe598
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:100]: use DB1_INT result type
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:92]: RES_NAMES(0x7f0dc4afe400)[1]=[gw_id]
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: db_mysql
>> [km_res.c:100]: use DB1_INT result type
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: <core>
>> [db_val.c:73]: converting INT [0]
>> Jul 24 11:12:54 xx /usr/local2/sbin/kamailio[26004] DEBUG: lcr
>> [hash.c:166]: could not find (disabled) rule with id <2617960>
>>
>> Antanas
>> NTT
>>
>> On 2012.07.24 10:53, Alex Balashov wrote:
>>> When calling load_gws(), try putting $rU and $fu in double quotes,
>>> e.g. "$rU" rather than $rU bare.
>>>
>>>
>>>
>>>
>>> -- Alex
>>>
>>> --
>>> Sent from my Samsung mobile, and thus lacking in the refinement one
>>> might expect from a proper keyboard.
>>>
>>> Alex Balashov - Principal
>>> Evariste Systems LLC
>>> 235 E Ponce de Leon Ave
>>> Suite 106
>>> Decatur, GA 30030
>>> Tel: +1-678-954-0670
>>> Web: http://www.evaristesys.com/
>>>
>>> Antanas Masevicius <antanas.masevicius at ntt.lt> wrote:
>>> Hello,
>>>
>>> having trouble running LCR in kamailio 3.3 (head).
>>>
>>> Here is my DB excerpt which i use to reproduce the problem:
>>> INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
>>> INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
>>> INSERT INTO `lcr_gw` VALUES
>>> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
>>>
>>> I stripped all other LCR data from my DB and only this rule with
>>> from_uri and request_uri seems to bother me.
>>>
>>> Tried this version on debian lenny and debian squeeze. On Lenny i am not
>>> able to load lcr tables at all, get a segfault.
>>> On squeeze, lcr tables loads up, but this rule gets marked as disabled.
>>> Here is config part which i use to load a rule:
>>> if (load_gws(90, $rU, $fu)) {
>>> if (next_gw()) {
>>> t_on_failure("FAIL_GW");
>>> } else {
>>> route(NO_ROUTE);
>>> }
>>>
>>> On squeeze, if i add following code to lcr_mod.c:1249 :
>>> LM_INFO("LOADING lcr rule <%u> \n", rule_id);
>>> right after:
>>> rule_id = (unsigned int)VAL_INT(ROW_VALUES(row));
>>>
>>> rule_id is still printed, but i get segfault like this:
>>>
>>> Jul 24 10:17:43 sp1 kernel: [23482626.105865] kamailio[15136]: segfault
>>> at a4 ip 00007fde15cb8802 sp 00007fff39d68320 error 4 in
>>> lcr.so[7fde15ca8000+23000]
>>>
>>> Not sure what i do terribly wrong. Setting from_uri and request_uri to
>>> anythig but NULL makes the code to segfault with that print line added.
>>> Without print line, kamailio starts, but never loads that rule.
>>>
>>> Any help would be appreciated.
>>>
>>> best regards,
>>>
>>> Antanas Masevicius
>>> NTT
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> --
>> Antanas Masevic(ius
>> Technikos direktorius
>> UAB "Nacionalinis telekomunikaciju tinklas"
>> Tel. +370 5 2056000
>> Tel. +370 700 00031 (tiesioginis)
>> Fax. +370 700 00034
>> el.p: antanas.masevicius at ntt.lt
>> www.ntt.lt
>> www.spykas.com
>
> --
> Antanas Masevic(ius
> Technikos direktorius
> UAB "Nacionalinis telekomunikaciju tinklas"
> Tel. +370 5 2056000
> Tel. +370 700 00031 (tiesioginis)
> Fax. +370 700 00034
> el.p: antanas.masevicius at ntt.lt
> www.ntt.lt
> www.spykas.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
--
Antanas Masevic(ius
Technikos direktorius
UAB "Nacionalinis telekomunikaciju tinklas"
Tel. +370 5 2056000
Tel. +370 700 00031 (tiesioginis)
Fax. +370 700 00034
el.p: antanas.masevicius at ntt.lt
www.ntt.lt
www.spykas.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/13e41a51/attachment.htm>
From klaus.mailinglists at pernau.at Tue Jul 24 15:53:50 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Tue, 24 Jul 2012 15:53:50 +0200
Subject: [SR-Users] Kamailio with APNS
In-Reply-To: <CADNPFHQgNHdOXPt82xK4N=-5DNUeNREpdY69-SfM+NJ5q2LOJg@mail.gmail.com>
References: <CADNPFHQgNHdOXPt82xK4N=-5DNUeNREpdY69-SfM+NJ5q2LOJg@mail.gmail.com>
Message-ID: <500EA8EE.7070702@pernau.at>
Hi!
You have to use a failure route
(http://kamailio.org/docs/modules/3.3.x/modules/tm.html#t_on_failure).
In the failure route check if the reply code is 404 and if yes, trigger
the APNS logic and then put the call e.g. on a stack and resume e.g.
every second and ofrward to the "SIP server" again to see if the client
is registered meanwhile.
For the asynchronous processing take a look at these functions:
t_suspend(),t_resume()[1]. For example you can call t_resume in a timer
route every second. For the timer route, to know which transactions are
currently suspended and are waiting for further processing, you could
put the transaction identifiers in a message-queue [2] and read the
queue from the timer route.
regards
Klaus
[1] http://kamailio.org/docs/modules/3.3.x/modules_k/tmx.html#id2535968
[2] http://kamailio.org/docs/modules/3.3.x/modules/mqueue.html
On 24.07.2012 06:02, Duong Manh Truong wrote:
> Hi list,
>
> My team are developing a SIP client for mobile running iOS ,
>
> then having to deal with the "back ground mode" problem while this soft
> is installed on mobiles
>
> One of the solutions is using APNS. (Apple Push Notification Service)
>
> I wanna to use Kamailio as SIP Redirect / Proxy for my current SIP server
>
> The model is like that:
>
> User A <---------> Kamailio <---------> SIP server <--------> User B
>
> IF UserA call UserB, UserB is not available now (not registered yet),
> normally, SIP server will reply Kamailio with "404 Not found"
>
> In that case, i want to set up Kamailio do the communication with APNS
> and waiting for UserB "Wake up" then RESEND the Invite message ......
> (instead of forwarding this 404 message to UserA)
>
> I am getting stuck at how Kamailio can control "404 Not found" message
> which it receives from SIP server .
>
> I do searching around several days but still can not get any clearer
> points.
>
> Please help me with some instruction/ configuration of Kamailio for this
> case !
>
> Thank you very much.
>
>
> _______________________________________________
> 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
>
From agranig at sipwise.com Tue Jul 24 16:32:28 2012
From: agranig at sipwise.com (Andreas Granig)
Date: Tue, 24 Jul 2012 16:32:28 +0200
Subject: [SR-Users] Kamailio with APNS
In-Reply-To: <500EA8EE.7070702@pernau.at>
References: <CADNPFHQgNHdOXPt82xK4N=-5DNUeNREpdY69-SfM+NJ5q2LOJg@mail.gmail.com>
<500EA8EE.7070702@pernau.at>
Message-ID: <500EB1FC.20508@sipwise.com>
Hi,
On 07/24/2012 03:53 PM, Klaus Darilion wrote:
> In the failure route check if the reply code is 404 and if yes, trigger
> the APNS logic and then put the call e.g. on a stack and resume e.g.
> every second and ofrward to the "SIP server" again to see if the client
> is registered meanwhile.
>
> For the asynchronous processing take a look at these functions:
> t_suspend(),t_resume()[1]. For example you can call t_resume in a timer
> route every second. For the timer route, to know which transactions are
> currently suspended and are waiting for further processing, you could
> put the transaction identifiers in a message-queue [2] and read the
> queue from the timer route.
We've looked into that a year ago. Not sure how much the asynch
processing progressed in the meanwhile, but back then there were a
couple of show stoppers which prevented us to go this path.
As a plan B we instead opted for sending via uac module the invite to an
oversip instance (it's open-source since a week or two), which triggers
an HTTP request towards APNS, and on kamailio check with inv-timers
every few seconds whether the client came online in the meanwhile, then
complete the call. The drawback is that you can wait only for so many
loop interations due to the max branch limitation in kamailio (you'd
need to recompile it to set it higher).
In any case it's not optimal either because of the unnecessary call
setup delays, so in our latest sip:provider PRO version we just relay
the invite to sems, which triggers an HTTP request to APNS, sends back
183 with early media, sends a subscribe to pua_reginfo module, and once
the subscriber comes online, pua_reginfo sends a notify to sems, which
in turn passes back a 3xx, and then the call setup completes on
kamailio. Not trivial either, but there are no call setup delays, there
is media to tell the caller it might take a bit longer (or not), and the
call flow is perfectly clean. Yeah, SIP/SIMPLE has its cases where it
shines, even though not too many :)
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/76a2eefc/attachment.pgp>
From ales999 at gmail.com Tue Jul 24 17:07:03 2012
From: ales999 at gmail.com (Alexey Mechanoshin)
Date: Tue, 24 Jul 2012 21:07:03 +0600
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <500E9B49.2090706@ntt.lt>
References: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
<500E5A13.4070801@ntt.lt> <500E68E4.10109@ntt.lt>
<500E9B49.2090706@ntt.lt>
Message-ID: <CADJsLxh-Ht3nwFfP0mi5V0ng8Cz8n3e+Eg+cLJ5XEOe96KpnLA@mail.gmail.com>
My lcr module *not* work in 3.3.x version if use from_uri data table. Only
in 3.2 !
Check thread:
http://lists.sip-router.org/pipermail/sr-users/2012-June/073712.html
2012/7/24 Antanas Masevicius <antanas.masevicius at ntt.lt>
[skip]
---
? ?????????, ????????? ???????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/83355259/attachment.htm>
From klaus.mailinglists at pernau.at Tue Jul 24 17:14:46 2012
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Tue, 24 Jul 2012 17:14:46 +0200
Subject: [SR-Users] Kamailio with APNS
In-Reply-To: <500EB1FC.20508@sipwise.com>
References: <CADNPFHQgNHdOXPt82xK4N=-5DNUeNREpdY69-SfM+NJ5q2LOJg@mail.gmail.com>
<500EA8EE.7070702@pernau.at> <500EB1FC.20508@sipwise.com>
Message-ID: <500EBBE6.9070809@pernau.at>
On 24.07.2012 16:32, Andreas Granig wrote:
> Hi,
>
> On 07/24/2012 03:53 PM, Klaus Darilion wrote:
>> In the failure route check if the reply code is 404 and if yes, trigger
>> the APNS logic and then put the call e.g. on a stack and resume e.g.
>> every second and ofrward to the "SIP server" again to see if the client
>> is registered meanwhile.
>>
>> For the asynchronous processing take a look at these functions:
>> t_suspend(),t_resume()[1]. For example you can call t_resume in a timer
>> route every second. For the timer route, to know which transactions are
>> currently suspended and are waiting for further processing, you could
>> put the transaction identifiers in a message-queue [2] and read the
>> queue from the timer route.
>
> We've looked into that a year ago. Not sure how much the asynch
> processing progressed in the meanwhile, but back then there were a
> couple of show stoppers which prevented us to go this path.
>
> As a plan B we instead opted for sending via uac module the invite to an
> oversip instance (it's open-source since a week or two), which triggers
interesting ....
> an HTTP request towards APNS, and on kamailio check with inv-timers
> every few seconds whether the client came online in the meanwhile, then
> complete the call. The drawback is that you can wait only for so many
> loop interations due to the max branch limitation in kamailio (you'd
> need to recompile it to set it higher).
Or on the last branch spiral the INVITE to Kamailio again (dirty :-)
>
> In any case it's not optimal either because of the unnecessary call
> setup delays, so in our latest sip:provider PRO version we just relay
> the invite to sems, which triggers an HTTP request to APNS, sends back
> 183 with early media, sends a subscribe to pua_reginfo module, and once
> the subscriber comes online, pua_reginfo sends a notify to sems, which
> in turn passes back a 3xx, and then the call setup completes on
> kamailio. Not trivial either, but there are no call setup delays, there
> is media to tell the caller it might take a bit longer (or not), and the
> call flow is perfectly clean. Yeah, SIP/SIMPLE has its cases where it
> shines, even though not too many :)
Indeed nice :-)
Klaus
From Gary.Chen at lightyear.net Tue Jul 24 21:39:28 2012
From: Gary.Chen at lightyear.net (Gary Chen)
Date: Tue, 24 Jul 2012 15:39:28 -0400
Subject: [SR-Users] lcr.dump_gws problem
Message-ID: <A6C2711F9706AF4992FFEC48EA19CA90174144E272@lyepkyexc.LYEPLYEXC.local>
Kamailio 3.2.0
When testing Kamailio 3.2.0, I notice that lcr.dump_gws command does not display ip_addr correctly. Here is my output:
lcr_id: 3
gw_id: 15
gw_index: 2
gw_name: gateway_1
scheme: sip
ip_addr: 1273060816.0.0.0
hostname:
port: 5060
params:
strip: 0
prefix:
tag:
flags: 0
defunct_until: 0
LCR is still working correctly. It just does not display IP in the right form. Does any body also has the same problem?
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/cd3c0bef/attachment.htm>
From Gary.Chen at lightyear.net Tue Jul 24 21:44:17 2012
From: Gary.Chen at lightyear.net (Gary Chen)
Date: Tue, 24 Jul 2012 15:44:17 -0400
Subject: [SR-Users] lcr.dump_gws problem
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA90174144E272@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA90174144E272@lyepkyexc.LYEPLYEXC.local>
Message-ID: <A6C2711F9706AF4992FFEC48EA19CA90174144E274@lyepkyexc.LYEPLYEXC.local>
Sorry, it should be Kamailio 3.3.0 not 3.2.0.
From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Gary Chen
Sent: Tuesday, July 24, 2012 3:39 PM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Subject: [SR-Users] lcr.dump_gws problem
Kamailio 3.2.0
When testing Kamailio 3.2.0, I notice that lcr.dump_gws command does not display ip_addr correctly. Here is my output:
lcr_id: 3
gw_id: 15
gw_index: 2
gw_name: gateway_1
scheme: sip
ip_addr: 1273060816.0.0.0
hostname:
port: 5060
params:
strip: 0
prefix:
tag:
flags: 0
defunct_until: 0
LCR is still working correctly. It just does not display IP in the right form. Does any body also has the same problem?
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/862dda9e/attachment.htm>
From apogrebennyk at sipwise.com Tue Jul 24 21:55:34 2012
From: apogrebennyk at sipwise.com (Andrew Pogrebennyk)
Date: Tue, 24 Jul 2012 21:55:34 +0200
Subject: [SR-Users] lcr.dump_gws problem
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA90174144E272@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA90174144E272@lyepkyexc.LYEPLYEXC.local>
Message-ID: <500EFDB6.9020708@sipwise.com>
Hi Gary,
Yes, that's an old/known issue. You can convert the IP to common format
with a simple command:
perl -MSocket -le 'print inet_ntoa(pack("N", 1273060816))'
Maybe somebody from the kamailio team will take time to fix this.
On 07/24/2012 09:39 PM, Gary Chen wrote:
> Kamailio 3.2.0
>
>
>
> When testing Kamailio 3.2.0, I notice that lcr.dump_gws command does not
> display ip_addr correctly. Here is my output:
>
> lcr_id: 3
>
> gw_id: 15
>
> gw_index: 2
>
> gw_name: gateway_1
>
> scheme: sip
>
> ip_addr: 1273060816.0.0.0
>
> hostname:
>
> port: 5060
>
> params:
>
> strip: 0
>
> prefix:
>
> tag:
>
> flags: 0
>
> defunct_until: 0
>
>
>
> LCR is still working correctly. It just does not display IP in the right
> form. Does any body also has the same problem?
>
>
>
> Gary
>
From kamailio.org at spam.lublink.net Tue Jul 24 23:47:30 2012
From: kamailio.org at spam.lublink.net (David)
Date: Tue, 24 Jul 2012 17:47:30 -0400
Subject: [SR-Users] Cleanup location table on failed NAT ping
Message-ID: <500F17F2.1060900@spam.lublink.net>
Hello,
I am using kamailio 3.2.3.
I am using the nathelper module to "ping" users in the location table to
keep the NAT bindings alive.
In the event of 3 failed NAT pings, I would like to mark the entry as
"unavailable" or completely delete it from the location table to avoid
having stale data.
Is this a feature that exists ? Is not, are their plans for it in the
future ?
When the REGISTER expires after 3600, if the phone doesn't register, the
location entry gets cleaned up. So I have to wait up to one hour before
the bad entry is purged. I was hoping to have it purged sooner.
Thanks,
David
version: kamailio 3.2.3 (x86_64/linux)
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,
DBG_QM_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 14:19:23 Apr 19 2012 with gcc 4.4.3
From forums at akan.net Wed Jul 25 07:28:55 2012
From: forums at akan.net (Akan)
Date: Wed, 25 Jul 2012 00:28:55 -0500
Subject: [SR-Users] Error Loading db_postgres.so on Startup
Message-ID: <500F8417.3070108@akan.net>
I am getting this error when trying to run kamailio on Centos 5.5. I
have Postgresql 9.1.4 installed and I have tried with both OpenSSL
v0.9.8e and v1.0.1c and I still get the same error. Any help would be
appreciated.
ERROR: <core> [sr_module.c:565]: ERROR: load_module: could not open
module </usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so>:
/usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so: undefined
symbol: TLSv1_method
Thanks
Nathaniel
From abalashov at evaristesys.com Wed Jul 25 08:02:33 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 25 Jul 2012 02:02:33 -0400
Subject: [SR-Users] Error Loading db_postgres.so on Startup
In-Reply-To: <500F8417.3070108@akan.net>
References: <500F8417.3070108@akan.net>
Message-ID: <500F8BF9.2080909@evaristesys.com>
Please post output of:
ldd /usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so
On 07/25/2012 01:28 AM, Akan wrote:
> I am getting this error when trying to run kamailio on Centos 5.5. I
> have Postgresql 9.1.4 installed and I have tried with both OpenSSL
> v0.9.8e and v1.0.1c and I still get the same error. Any help would be
> appreciated.
>
> ERROR: <core> [sr_module.c:565]: ERROR: load_module: could not open
> module </usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so>:
> /usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so: undefined
> symbol: TLSv1_method
>
>
> Thanks
>
> Nathaniel
>
> _______________________________________________
> 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
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From forums at akan.net Wed Jul 25 08:26:41 2012
From: forums at akan.net (Akan)
Date: Wed, 25 Jul 2012 01:26:41 -0500
Subject: [SR-Users] Error Loading db_postgres.so on Startup
In-Reply-To: <500F8BF9.2080909@evaristesys.com>
References: <500F8417.3070108@akan.net> <500F8BF9.2080909@evaristesys.com>
Message-ID: <500F91A1.1090006@akan.net>
Here is the output:
ldd /usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so
libsrdb2.so.1 =>
/usr/local/kamailio-3.2/lib64/kamailio/libsrdb2.so.1 (0x00002b1e331ea000)
libsrdb1.so.1 =>
/usr/local/kamailio-3.2/lib64/kamailio/libsrdb1.so.1 (0x00002b1e333f1000)
libc.so.6 => /lib64/libc.so.6 (0x00002b1e33615000)
/lib64/ld-linux-x86-64.so.2 (0x0000003961c00000)
Thanks
Nathaniel
On 7/25/2012 1:02 AM, Alex Balashov wrote:
> ldd /usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so
From abalashov at evaristesys.com Wed Jul 25 08:29:41 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 25 Jul 2012 02:29:41 -0400
Subject: [SR-Users] Error Loading db_postgres.so on Startup
In-Reply-To: <500F91A1.1090006@akan.net>
References: <500F8417.3070108@akan.net> <500F8BF9.2080909@evaristesys.com>
<500F91A1.1090006@akan.net>
Message-ID: <500F9255.6050802@evaristesys.com>
Did you build from source?
On 07/25/2012 02:26 AM, Akan wrote:
> Here is the output:
>
> ldd /usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so
> libsrdb2.so.1 =>
> /usr/local/kamailio-3.2/lib64/kamailio/libsrdb2.so.1 (0x00002b1e331ea000)
> libsrdb1.so.1 =>
> /usr/local/kamailio-3.2/lib64/kamailio/libsrdb1.so.1 (0x00002b1e333f1000)
> libc.so.6 => /lib64/libc.so.6 (0x00002b1e33615000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003961c00000)
>
> Thanks
>
> Nathaniel
>
> On 7/25/2012 1:02 AM, Alex Balashov wrote:
>> ldd /usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so
>
>
> _______________________________________________
> 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
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From forums at akan.net Wed Jul 25 08:43:50 2012
From: forums at akan.net (Akan)
Date: Wed, 25 Jul 2012 01:43:50 -0500
Subject: [SR-Users] Error Loading db_postgres.so on Startup
In-Reply-To: <500F9255.6050802@evaristesys.com>
References: <500F8417.3070108@akan.net> <500F8BF9.2080909@evaristesys.com>
<500F91A1.1090006@akan.net> <500F9255.6050802@evaristesys.com>
Message-ID: <500F95A6.90302@akan.net>
Kamailio was build from the git source, postgres and openssl was
installed with yum
On 7/25/2012 1:29 AM, Alex Balashov wrote:
> Did you build from source?
>
> On 07/25/2012 02:26 AM, Akan wrote:
>
>> Here is the output:
>>
>> ldd /usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so
>> libsrdb2.so.1 =>
>> /usr/local/kamailio-3.2/lib64/kamailio/libsrdb2.so.1
>> (0x00002b1e331ea000)
>> libsrdb1.so.1 =>
>> /usr/local/kamailio-3.2/lib64/kamailio/libsrdb1.so.1
>> (0x00002b1e333f1000)
>> libc.so.6 => /lib64/libc.so.6 (0x00002b1e33615000)
>> /lib64/ld-linux-x86-64.so.2 (0x0000003961c00000)
>>
>> Thanks
>>
>> Nathaniel
>>
>> On 7/25/2012 1:02 AM, Alex Balashov wrote:
>>> ldd /usr/local/kamailio-3.2/lib64/kamailio/modules/db_postgres.so
>>
>>
>> _______________________________________________
>> 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
>
>
From miconda at gmail.com Wed Jul 25 09:25:29 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 25 Jul 2012 09:25:29 +0200
Subject: [SR-Users] Cleanup location table on failed NAT ping
In-Reply-To: <500F17F2.1060900@spam.lublink.net>
References: <500F17F2.1060900@spam.lublink.net>
Message-ID: <500F9F69.8060204@gmail.com>
Hello,
On 7/24/12 11:47 PM, David wrote:
> Hello,
>
> I am using kamailio 3.2.3.
>
> I am using the nathelper module to "ping" users in the location table
> to keep the NAT bindings alive.
>
> In the event of 3 failed NAT pings, I would like to mark the entry as
> "unavailable" or completely delete it from the location table to avoid
> having stale data.
>
> Is this a feature that exists ? Is not, are their plans for it in the
> future ?
>
> When the REGISTER expires after 3600, if the phone doesn't register,
> the location entry gets cleaned up. So I have to wait up to one hour
> before the bad entry is purged. I was hoping to have it purged sooner.
auto-unregister on nat keepalives timeout does not exist -- actually the
nat keepalive si a simply udp send (even for OPTIONS) for performance
reasons, there is no transaction created for it, the reply is handled
stateless by core and discarded due to single Via header.
I think it can be implemented by using an external tool to send the
keepalives, like sipsak, and by using a failure route for them, in the
case of timeout, one can call unregister() -- this would work if there
is one contact per subscriber.
Regarding the development of such feature, I don't have it in my short
terms plans and I am not aware of anyone else working on it, but maybe
other developers can comment on that.
From my point of view, it will not bring significant benefits, but can
add lot of load to tm for handling keepalive transactions when dealing
with large number of location records.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From abalashov at evaristesys.com Wed Jul 25 09:30:22 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 25 Jul 2012 03:30:22 -0400
Subject: [SR-Users] Cleanup location table on failed NAT ping
In-Reply-To: <500F9F69.8060204@gmail.com>
References: <500F17F2.1060900@spam.lublink.net> <500F9F69.8060204@gmail.com>
Message-ID: <500FA08E.5060900@evaristesys.com>
On 07/25/2012 03:25 AM, Daniel-Constantin Mierla wrote:
> From my point of view, it will not bring significant benefits, but
> can add lot of load to tm for handling keepalive transactions when
> dealing with large number of location records.
Perhaps it can be dealt with by having nat_traversal/nathelper/whatever
is doing the pinging expose an event route for repeatedly failed NAT
pings, and populating a little bit of context, like the AOR that was
being pinged?
This would allow the user to intervene manually in the manner of his
choosing, e.g. DELETE FROM location via sqlops?
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Wed Jul 25 09:32:23 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 25 Jul 2012 03:32:23 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500E47D3.2010205@gmail.com>
References: <500DEE82.2060304@evaristesys.com>
<500E0C93.6000806@evaristesys.com> <500E47D3.2010205@gmail.com>
Message-ID: <500FA107.8030002@evaristesys.com>
On 07/24/2012 02:59 AM, Daniel-Constantin Mierla wrote:
> The way mqueue is consuming items from queue does not ensure queue
> locking until all items are consumed. So the first item there is removed
> from queue and cloned in private memory where is accessible via PV, then
> the queue is unlocked so others can consume or add to it.
>
> Not being in office for few days, I cannot run tests myself ... do you
> have heavy writers? Can you add few more timer processes to consume from
> queue and see what happens?
I figured it out; Alex Hermann nailed it. The number of accounting
events I was generating was tripping max_while_loops. I thought I had
it set high enough, but I guess I didn't. I didn't catch the log
message because it was being lost in thousands of lines per second of
logging.
Sorry for the noise and the idiocy on my part!
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Wed Jul 25 09:37:37 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 25 Jul 2012 03:37:37 -0400
Subject: [SR-Users] rtimer execution period - round two
In-Reply-To: <500FA107.8030002@evaristesys.com>
References: <500DEE82.2060304@evaristesys.com>
<500E0C93.6000806@evaristesys.com> <500E47D3.2010205@gmail.com>
<500FA107.8030002@evaristesys.com>
Message-ID: <500FA241.9080508@evaristesys.com>
On 07/25/2012 03:32 AM, Alex Balashov wrote:
> On 07/24/2012 02:59 AM, Daniel-Constantin Mierla wrote:
>
>> The way mqueue is consuming items from queue does not ensure queue
>> locking until all items are consumed. So the first item there is removed
>> from queue and cloned in private memory where is accessible via PV, then
>> the queue is unlocked so others can consume or add to it.
>>
>> Not being in office for few days, I cannot run tests myself ... do you
>> have heavy writers? Can you add few more timer processes to consume from
>> queue and see what happens?
>
> I figured it out; Alex Hermann nailed it. The number of accounting
> events I was generating was tripping max_while_loops. I thought I had
> it set high enough, but I guess I didn't. I didn't catch the log
> message because it was being lost in thousands of lines per second of
> logging.
There is an occasional situation where the queue empties out,
while(mq_fetch(...)) returns false, and an instant later, something is
added back to the queue, but now we must wait 1 rtimer task interval for
event writing to resume.
However, the ability to do microsecond-based intervals in Kamailio 3.3
has made this problem largely irrelevant. :-)
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From jh at tutpro.com Wed Jul 25 18:08:17 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Wed, 25 Jul 2012 19:08:17 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <500E9B49.2090706@ntt.lt>
References: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
<500E5A13.4070801@ntt.lt> <500E68E4.10109@ntt.lt>
<500E9B49.2090706@ntt.lt>
Message-ID: <20496.6641.679289.269332@siika.tutpro.com>
Antanas Masevicius writes:
> It looks like core issue was not a termination of regexp. Was not
> getting segfaults, but did not get a match either.
> After changing rule_id from 2617960 to 0, rule got loaded properly:
i have been offline and will check this tomorrow.
-- juha
From mkaplan at appcomsci.com Wed Jul 25 19:49:04 2012
From: mkaplan at appcomsci.com (Kaplan, Michael A)
Date: Wed, 25 Jul 2012 17:49:04 +0000
Subject: [SR-Users] Overload Control
Message-ID: <F53A37DAD8610C458EEB8EF9B34D406A0C464D@rrc-ats-exmb1>
Folks,
I'm trying to figure out if either Kamailio or OpenSIPs provides the various overload control algorithms recommended in the IETF or elsewhere. I haven't found documentation to this effect. Has anyone looked into this or used such techniques?
Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120725/a5aeba54/attachment.htm>
From abalashov at evaristesys.com Wed Jul 25 20:29:22 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 25 Jul 2012 14:29:22 -0400
Subject: [SR-Users] Overload Control
In-Reply-To: <F53A37DAD8610C458EEB8EF9B34D406A0C464D@rrc-ats-exmb1>
References: <F53A37DAD8610C458EEB8EF9B34D406A0C464D@rrc-ats-exmb1>
Message-ID: <50103B02.6070404@evaristesys.com>
Can you elaborate as to what you mean by that term, "overload control"?
On 07/25/2012 01:49 PM, Kaplan, Michael A wrote:
> Folks,
>
> I?m trying to figure out if either Kamailio or OpenSIPs provides the
> various overload control algorithms recommended in the IETF or
> elsewhere. I haven?t found documentation to this effect. Has anyone
> looked into this or used such techniques?
>
> Thanks,
>
> Mike
>
>
>
> _______________________________________________
> 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
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From mkaplan at appcomsci.com Wed Jul 25 20:33:16 2012
From: mkaplan at appcomsci.com (Kaplan, Michael A)
Date: Wed, 25 Jul 2012 18:33:16 +0000
Subject: [SR-Users] Overload Control
In-Reply-To: <50103B02.6070404@evaristesys.com>
References: <F53A37DAD8610C458EEB8EF9B34D406A0C464D@rrc-ats-exmb1>
<50103B02.6070404@evaristesys.com>
Message-ID: <F53A37DAD8610C458EEB8EF9B34D406A0C4674@rrc-ats-exmb1>
Sure - I'm referring to mechanisms for the server to advertise to upstream neighbors to reduce request rates. This could include methods that appear in RFC 6357 (e.g. rate-limits, window-based control, loss-rate enforcement). I suppose the try-again-after method would be of interest as well.
-----Original Message-----
From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Alex Balashov
Sent: Wednesday, July 25, 2012 2:29 PM
To: sr-users at lists.sip-router.org
Subject: Re: [SR-Users] Overload Control
Can you elaborate as to what you mean by that term, "overload control"?
On 07/25/2012 01:49 PM, Kaplan, Michael A wrote:
> Folks,
>
> I'm trying to figure out if either Kamailio or OpenSIPs provides the
> various overload control algorithms recommended in the IETF or
> elsewhere. I haven't found documentation to this effect. Has anyone
> looked into this or used such techniques?
>
> Thanks,
>
> Mike
>
>
>
> _______________________________________________
> 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
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
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
From abalashov at evaristesys.com Wed Jul 25 20:38:34 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 25 Jul 2012 14:38:34 -0400
Subject: [SR-Users] Overload Control
In-Reply-To: <F53A37DAD8610C458EEB8EF9B34D406A0C4674@rrc-ats-exmb1>
References: <F53A37DAD8610C458EEB8EF9B34D406A0C464D@rrc-ats-exmb1>
<50103B02.6070404@evaristesys.com>
<F53A37DAD8610C458EEB8EF9B34D406A0C4674@rrc-ats-exmb1>
Message-ID: <50103D2A.70001@evaristesys.com>
You can always construct such a reply yourself, and append headers to it.
On 07/25/2012 02:33 PM, Kaplan, Michael A wrote:
> Sure - I'm referring to mechanisms for the server to advertise to upstream neighbors to reduce request rates. This could include methods that appear in RFC 6357 (e.g. rate-limits, window-based control, loss-rate enforcement). I suppose the try-again-after method would be of interest as well.
>
>
> -----Original Message-----
> From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Alex Balashov
> Sent: Wednesday, July 25, 2012 2:29 PM
> To: sr-users at lists.sip-router.org
> Subject: Re: [SR-Users] Overload Control
>
> Can you elaborate as to what you mean by that term, "overload control"?
>
> On 07/25/2012 01:49 PM, Kaplan, Michael A wrote:
>
>> Folks,
>>
>> I'm trying to figure out if either Kamailio or OpenSIPs provides the
>> various overload control algorithms recommended in the IETF or
>> elsewhere. I haven't found documentation to this effect. Has anyone
>> looked into this or used such techniques?
>>
>> Thanks,
>>
>> Mike
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> Tel: +1-678-954-0670
> Fax: +1-404-961-1892
> 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
>
> _______________________________________________
> 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
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From abalashov at evaristesys.com Wed Jul 25 20:39:12 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 25 Jul 2012 14:39:12 -0400
Subject: [SR-Users] Overload Control
In-Reply-To: <F53A37DAD8610C458EEB8EF9B34D406A0C4674@rrc-ats-exmb1>
References: <F53A37DAD8610C458EEB8EF9B34D406A0C464D@rrc-ats-exmb1>
<50103B02.6070404@evaristesys.com>
<F53A37DAD8610C458EEB8EF9B34D406A0C4674@rrc-ats-exmb1>
Message-ID: <50103D50.7040003@evaristesys.com>
But also, check out this module:
http://www.kamailio.org/docs/modules/3.3.x/modules/pipelimit.html
On 07/25/2012 02:33 PM, Kaplan, Michael A wrote:
> Sure - I'm referring to mechanisms for the server to advertise to upstream neighbors to reduce request rates. This could include methods that appear in RFC 6357 (e.g. rate-limits, window-based control, loss-rate enforcement). I suppose the try-again-after method would be of interest as well.
>
>
> -----Original Message-----
> From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Alex Balashov
> Sent: Wednesday, July 25, 2012 2:29 PM
> To: sr-users at lists.sip-router.org
> Subject: Re: [SR-Users] Overload Control
>
> Can you elaborate as to what you mean by that term, "overload control"?
>
> On 07/25/2012 01:49 PM, Kaplan, Michael A wrote:
>
>> Folks,
>>
>> I'm trying to figure out if either Kamailio or OpenSIPs provides the
>> various overload control algorithms recommended in the IETF or
>> elsewhere. I haven't found documentation to this effect. Has anyone
>> looked into this or used such techniques?
>>
>> Thanks,
>>
>> Mike
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> Tel: +1-678-954-0670
> Fax: +1-404-961-1892
> 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
>
> _______________________________________________
> 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
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From jh at tutpro.com Thu Jul 26 09:16:36 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 26 Jul 2012 10:16:36 +0300
Subject: [SR-Users] lcr.dump_gws problem
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA90174144E274@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA90174144E272@lyepkyexc.LYEPLYEXC.local>
<A6C2711F9706AF4992FFEC48EA19CA90174144E274@lyepkyexc.LYEPLYEXC.local>
Message-ID: <20496.61140.9934.745551@siika.tutpro.com>
Gary Chen writes:
> When testing Kamailio 3.2.0 (corrected 3.3.0), I notice that
> lcr.dump_gws command does not display ip_addr correctly. Here
> is my output:
> lcr_id: 3
> gw_id: 15
> gw_index: 2
> gw_name: gateway_1
> scheme: sip
> ip_addr: 1273060816.0.0.0
> hostname:
> port: 5060
> params:
> strip: 0
> prefix:
> tag:
> flags: 0
> defunct_until: 0
looks like printing of ipv4 got broken as result of these two commits by Richard Fuchs <rfuchs at sipwise.com>:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=d1f44a95f6ca16fcf691981112e97a9dcf5ae26c
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=d1ed60050d9c16b8b1b58559a5a1aea23f640b2d
printing of ip4v addresses worked fine it worked in 3.2.0. also,
printing of NULL gw address is broken.
since the commits made non-trivial changes to ip address handling,
perhaps richard can check what has happened. the only thing i can do is
to revert the ipv6 patches.
-- juha
From jh at tutpro.com Thu Jul 26 10:52:14 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 26 Jul 2012 11:52:14 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <500E68E4.10109@ntt.lt>
References: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
<500E5A13.4070801@ntt.lt> <500E68E4.10109@ntt.lt>
Message-ID: <20497.1342.306212.233586@siika.tutpro.com>
Antanas Masevicius writes:
> Looks like i finally got it. REGEXP patterns in from_uri and request_uri
> must be terminated between //.
that is not true. i just tested, and, for example, from_uri column value
\+35832345670 matched to from uri sip:+35832345670 at test.fi.
-- juha
From jh at tutpro.com Thu Jul 26 10:54:34 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 26 Jul 2012 11:54:34 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <500E9B49.2090706@ntt.lt>
References: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
<500E5A13.4070801@ntt.lt> <500E68E4.10109@ntt.lt>
<500E9B49.2090706@ntt.lt>
Message-ID: <20497.1482.618007.285128@siika.tutpro.com>
Antanas Masevicius writes:
> It looks like core issue was not a termination of regexp. Was not
> getting segfaults, but did not get a match either.
> After changing rule_id from 2617960 to 0, rule got loaded properly:
i just tested and rule_id value 2617960 worked fine. can you give your
lcr table contents (just the rows that are needed in the test) as mysql
insert statements?
-- juha
From jh at tutpro.com Thu Jul 26 11:12:00 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 26 Jul 2012 12:12:00 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <500E539B.9030300@ntt.lt>
References: <500E539B.9030300@ntt.lt>
Message-ID: <20497.2528.581689.906893@siika.tutpro.com>
Antanas Masevicius writes:
> Here is my DB excerpt which i use to reproduce the problem:
> INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
> INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
> INSERT INTO `lcr_gw` VALUES
> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
when i try the above, last insert gives:
INSERT INTO `lcr_gw` VALUES
-> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
ERROR 1048 (23000): Column 'flags' cannot be null
looks like you have made some mistake in above, because according to the
schema, flags column cannot be null.
-- juha
From mkaplan at appcomsci.com Thu Jul 26 17:37:40 2012
From: mkaplan at appcomsci.com (Kaplan, Michael A)
Date: Thu, 26 Jul 2012 15:37:40 +0000
Subject: [SR-Users] Overload Control
In-Reply-To: <50103D50.7040003@evaristesys.com>
References: <F53A37DAD8610C458EEB8EF9B34D406A0C464D@rrc-ats-exmb1>
<50103B02.6070404@evaristesys.com>
<F53A37DAD8610C458EEB8EF9B34D406A0C4674@rrc-ats-exmb1>
<50103D50.7040003@evaristesys.com>
Message-ID: <F53A37DAD8610C458EEB8EF9B34D406A0C477D@rrc-ats-exmb1>
Thanks, this is very much what I was looking for. It appears the ratelimit/piplimit modules offer some degree of overload control through queue drops and invite rejections based on a server's local cpu load. Some of the other overload control mechanisms described in the RFC (e.g. window based control and loss based control) would also be of interest to me. Not sure if public implementations exist or if they are restricted to research implementations. Thanks for the pointer to ratelimit nevertheless.
-----Original Message-----
From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Alex Balashov
Sent: Wednesday, July 25, 2012 2:39 PM
To: sr-users at lists.sip-router.org
Subject: Re: [SR-Users] Overload Control
But also, check out this module:
http://www.kamailio.org/docs/modules/3.3.x/modules/pipelimit.html
On 07/25/2012 02:33 PM, Kaplan, Michael A wrote:
> Sure - I'm referring to mechanisms for the server to advertise to upstream neighbors to reduce request rates. This could include methods that appear in RFC 6357 (e.g. rate-limits, window-based control, loss-rate enforcement). I suppose the try-again-after method would be of interest as well.
>
>
> -----Original Message-----
> From: sr-users-bounces at lists.sip-router.org
> [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Alex
> Balashov
> Sent: Wednesday, July 25, 2012 2:29 PM
> To: sr-users at lists.sip-router.org
> Subject: Re: [SR-Users] Overload Control
>
> Can you elaborate as to what you mean by that term, "overload control"?
>
> On 07/25/2012 01:49 PM, Kaplan, Michael A wrote:
>
>> Folks,
>>
>> I'm trying to figure out if either Kamailio or OpenSIPs provides the
>> various overload control algorithms recommended in the IETF or
>> elsewhere. I haven't found documentation to this effect. Has anyone
>> looked into this or used such techniques?
>>
>> Thanks,
>>
>> Mike
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> Tel: +1-678-954-0670
> Fax: +1-404-961-1892
> 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
>
> _______________________________________________
> 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
>
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
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
From yang_hong at hotmail.com Thu Jul 26 18:38:45 2012
From: yang_hong at hotmail.com (Yang Hong)
Date: Thu, 26 Jul 2012 12:38:45 -0400
Subject: [SR-Users] Overload Control
In-Reply-To: <F53A37DAD8610C458EEB8EF9B34D406A0C477D@rrc-ats-exmb1>
References: <F53A37DAD8610C458EEB8EF9B34D406A0C464D@rrc-ats-exmb1>,
<50103B02.6070404@evaristesys.com>,
<F53A37DAD8610C458EEB8EF9B34D406A0C4674@rrc-ats-exmb1>,
<50103D50.7040003@evaristesys.com>,
<F53A37DAD8610C458EEB8EF9B34D406A0C477D@rrc-ats-exmb1>
Message-ID: <SNT115-W4167574ADBDDD9EEBAE9648FC20@phx.gbl>
Dear all, >Kaplan, Michael A wrote:
> Sure - I'm referring to mechanisms for the server to advertise to upstream neighbors to reduce request rates. This could include methods that appear > in RFC 6357 (e.g. rate-limits, window-based control, loss-rate enforcement). I suppose the try-again-after method would be of interest as well.
>IETF RFC 6357 "Design Considerations for Session Initiation Protocol (SIP) Overload Control"
Can be found in the following link.
http://tools.ietf.org/rfc/rfc6357.txt Please note that mechanisms for the server to advertise to upstream neighbors to reduce request rates must modify SIP header. This is called "Explicit Overload Control Feedback" in RFC6357. Unfortunately Changing the SIP header requires a time-consuming standardization process, because all the SIP servers from different service providers in different countries have to implement new SIP with new headers. >Kaplan, Michael A wrote:
>Some of the other overload control mechanisms described in the RFC (e.g. window based control and loss based control) would also be of interest to me. Not sure if public implementations exist or if they are restricted to research implementations. Yes. "Explicit Overload Control Feedback" proposed by RFC6357 are restricted to research implementations. Public implementations require cooperation from all the service providers of SIP. However, implicit overload control does not require any modification of SIP header and time-consuming standardization process. Any SIP server can implement implicit overload control. >Alex Balashov wrote:
>You can always construct such a reply yourself, and append headers to it.Yes. But appending headerers requires RFC standardization process and cooperation from all the service providers of SIP at different countries all over the world.
From zolia at ntt.lt Thu Jul 26 21:43:13 2012
From: zolia at ntt.lt (Antanas Masevicius)
Date: Thu, 26 Jul 2012 22:43:13 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <20497.1482.618007.285128@siika.tutpro.com>
References: <jsw0x3m2e1qc416n7mbn2246.1343116426508@email.android.com>
<500E5A13.4070801@ntt.lt> <500E68E4.10109@ntt.lt>
<500E9B49.2090706@ntt.lt>
<20497.1482.618007.285128@siika.tutpro.com>
Message-ID: <50119DD1.4050007@ntt.lt>
Hello Juha,
i just posted my inserts in one of my previous emails. Here are inserts:
/INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
//INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
//INSERT INTO `lcr_gw` VALUES// (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);/
those are the only records in lcr tables. System i am running it on is
was kamailio 3.3 head (debian squeeze).
best regards,
Antanas
NTT
On 2012.07.26 11:54, Juha Heinanen wrote:
> Antanas Masevicius writes:
>
>> It looks like core issue was not a termination of regexp. Was not
>> getting segfaults, but did not get a match either.
>> After changing rule_id from 2617960 to 0, rule got loaded properly:
> i just tested and rule_id value 2617960 worked fine. can you give your
> lcr table contents (just the rows that are needed in the test) as mysql
> insert statements?
>
> -- juha
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120726/f37f5a28/attachment-0001.htm>
From zolia at ntt.lt Thu Jul 26 22:03:07 2012
From: zolia at ntt.lt (Antanas Masevicius)
Date: Thu, 26 Jul 2012 23:03:07 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <20497.2528.581689.906893@siika.tutpro.com>
References: <500E539B.9030300@ntt.lt>
<20497.2528.581689.906893@siika.tutpro.com>
Message-ID: <5011A27B.7070800@ntt.lt>
Hello Juha,
it looks like column order a bit changed in my system after using alter table during migrations.
That is prefix col is not it its place. Thus this data:
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
should be fixed as:
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,NULL,'11#',1,NULL);
Antanas
NTT
On 2012.07.26 12:12, Juha Heinanen wrote:
> Antanas Masevicius writes:
>
>> Here is my DB excerpt which i use to reproduce the problem:
>> INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
>> INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
>> INSERT INTO `lcr_gw` VALUES
>> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
> when i try the above, last insert gives:
>
> INSERT INTO `lcr_gw` VALUES
> -> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
> ERROR 1048 (23000): Column 'flags' cannot be null
>
> looks like you have made some mistake in above, because according to the
> schema, flags column cannot be null.
>
> -- juha
>
> _______________________________________________
> 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
From jmillan at aliax.net Thu Jul 26 23:30:39 2012
From: jmillan at aliax.net (=?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?=)
Date: Thu, 26 Jul 2012 23:30:39 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
Message-ID: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
Hi,
I'm using Kamilio 3.3.0 as registrar server. I`m using an outbound proxy
so 'use_path' parameter or 'registrar' module is enabled.
According to RFC 5626, a re-registration from a specific combination of
AoR, instance_id and reg_id must update the binding.
""
If the registrar receives a re-registration for a specific
combination of AOR, and instance-id and reg-id values, the registrar
MUST update any information that uniquely identifies the network flow
over which the request arrived if that information has changed, and
SHOULD update the time the binding was last updated.
""
In my installation this is not fullfilled as shown:
""
AOR:: jmillan
Contact:: sip:jmillan at MY_IP;transport=ws;ov-ob=a570655c14 Q=
Expires:: 181
Callid:: 1hgq3khalq2rzfr
Cseq:: 108
User-agent:: JsSIP 0.1.0
Path:: <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:a570655c14 at OUTBOUND_IP
:10080;transport=ws;lr;ovid=de0c0b9f;ob>
State:: CS_SYNC
Flags:: 0
Cflag:: 0
Socket:: tcp:KAM_IP:5060
Methods:: 783
Ruid:: uloc-50119d99-328e-1
Instance:: <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
Reg-Id:: 1
Contact:: sip:jmillan at MY_IP;transport=ws;ov-ob=1dd97b4d51 Q=
Expires:: 193
Callid:: 1hgq3khalq2rzfr
Cseq:: 110
User-agent:: JsSIP 0.1.0
Path:: <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:1dd97b4d51 at OUTBOUND_IP
:10080;transport=ws;lr;ovid=de0c0b9f;ob>
State:: CS_SYNC
Flags:: 0
Cflag:: 0
Socket:: tcp:KAM_IP:5060
Methods:: 783
Ruid:: uloc-50119d99-3290-2
Instance:: <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
Reg-Id:: 1
""
The scenario is such that when the client looses the connection with the
Outbound Server, it reconnects and re-registers to Kamailio in order to
replace registration and be able to receive in-dialog messages.
Any comment is wellcome.
Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120726/46370615/attachment.htm>
From tony.ferrario at onmobile.com Thu Jul 26 21:17:46 2012
From: tony.ferrario at onmobile.com (Tony Ferrario)
Date: Thu, 26 Jul 2012 19:17:46 +0000
Subject: [SR-Users] siremis errors
Message-ID: <6C26F7F82C909340B515DF6385D6D64B0A2168@JETWINSRVRPS01.onmobile.com>
I just installed a Siremis 3.2.1 on a server with an already working Kamailio 3.2.1. bellow is a typical error message I keep getting.
Can you point me to a solution
-Thanks
[http://192.168.105.196/siremis/themes/default/images/icon_forbidden.gif]
System Internal Error
The detailed error message are below:
[2012-07-26 19:14:11 (GMT)] An exception occurred while executing this script:
Error message: #0, Error in query:: SELECT T0.id, T0.method, T0.from_tag, T0.to_tag, T0.callid, T0.sip_code, T0.sip_reason, T0.time, T0.src_ip, T0.dst_user, T0.dst_domain, T0.dst_ouser, T0.src_user, T0.src_domain, T0.cdr_id FROM `acc` T0 WHERE method='INVITE' AND T0.src_user='admin' LIMIT 10. SQLSTATE[42S22]: Column not found: 1054 Unknown column 'T0.src_ip' in 'field list'
Script name and line number of error: /var/www/siremis-3.2.1/openbiz/bin/data/BizDataObj_Lite.php:447
function: _run_search ( Array(2) ) @ /var/www/siremis-3.2.1/openbiz/bin/data/BizDataObj_Lite.php 243
function: fetch ( ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/EasyForm.php 690
function: fetchDataSet ( ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/FormRenderer.php 69
function: renderSmarty ( Object(EasyForm), "/var/www/siremis-3.2.1/siremis/modules/sipuser/template/grid.tpl" ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/FormRenderer.php 45
function: render ( Object(EasyForm) ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/EasyForm.php 1648
function: renderHTML ( ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/EasyForm.php 1538
function: render ( ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/ViewRenderer.php 83
function: renderSmarty ( Object(EasyView), "/var/www/siremis-3.2.1/siremis/modules/sipuser/template/view.tpl" ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/ViewRenderer.php 40
function: render ( Object(EasyView) ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/EasyView.php 274
function: _render ( ) @ /var/www/siremis-3.2.1/openbiz/bin/easy/EasyView.php 237
function: render ( ) @ /var/www/siremis-3.2.1/openbiz/bin/BizController.php 221
function: renderView ( "sipuser.view.AccListView", "", "", Null, "" ) @ /var/www/siremis-3.2.1/openbiz/bin/BizController.php 107
function: dispatchRequest ( ) @ /var/www/siremis-3.2.1/openbiz/bin/BizController.php 32
function: include_once ( "/var/www/siremis-3.2.1/openbiz/bin/BizController.php" ) @ /var/www/siremis-3.2.1/siremis/bin/controller.php 6
function: include ( "/var/www/siremis-3.2.1/siremis/bin/controller.php" ) @ /var/www/siremis-3.2.1/siremis/bin/_forward.php 102
function: include ( "/var/www/siremis-3.2.1/siremis/bin/_forward.php" ) @ /var/www/siremis-3.2.1/siremis/index.php 3
________________________________
Please ask system administrator for help...
Tony Ferrario
Manager SVT & Ops
OnMobile Global Limited
3950 Civic Center Drive , Suite 200
San Rafael, Ca 94903
Phone: 415-223-8206
Cell: 707-508-7285
tony.ferrario at onmobile.com
________________________________
DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120726/77b9b02a/attachment.htm>
From ibc at aliax.net Fri Jul 27 10:05:54 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri, 27 Jul 2012 10:05:54 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
Message-ID: <CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
Hi, full agree with this bug report. Adding the devel maillist. More
comments at the end of the mail:
2012/7/26 Jos? Luis Mill?n <jmillan at aliax.net>:
> Hi,
>
> I'm using Kamilio 3.3.0 as registrar server. I`m using an outbound proxy so
> 'use_path' parameter or 'registrar' module is enabled.
>
> According to RFC 5626, a re-registration from a specific combination of AoR,
> instance_id and reg_id must update the binding.
>
> ""
> If the registrar receives a re-registration for a specific
> combination of AOR, and instance-id and reg-id values, the registrar
> MUST update any information that uniquely identifies the network flow
> over which the request arrived if that information has changed, and
> SHOULD update the time the binding was last updated.
> ""
>
> In my installation this is not fullfilled as shown:
>
> ""
> AOR:: jmillan
> Contact:: sip:jmillan at MY_IP;transport=ws;ov-ob=a570655c14 Q=
> Expires:: 181
> Callid:: 1hgq3khalq2rzfr
> Cseq:: 108
> User-agent:: JsSIP 0.1.0
> Path::
> <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:a570655c14 at OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
> State:: CS_SYNC
> Flags:: 0
> Cflag:: 0
> Socket:: tcp:KAM_IP:5060
> Methods:: 783
> Ruid:: uloc-50119d99-328e-1
> Instance::
> <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
> Reg-Id:: 1
> Contact:: sip:jmillan at MY_IP;transport=ws;ov-ob=1dd97b4d51 Q=
> Expires:: 193
> Callid:: 1hgq3khalq2rzfr
> Cseq:: 110
> User-agent:: JsSIP 0.1.0
> Path::
> <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:1dd97b4d51 at OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
> State:: CS_SYNC
> Flags:: 0
> Cflag:: 0
> Socket:: tcp:KAM_IP:5060
> Methods:: 783
> Ruid:: uloc-50119d99-3290-2
> Instance::
> <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
> Reg-Id:: 1
> ""
>
> The scenario is such that when the client looses the connection with the
> Outbound Server, it reconnects and re-registers to Kamailio in order to
> replace registration and be able to receive in-dialog messages.
Receiving in-dialog requests should work since GRUU is also being
used. The problem is that the new REGISTER (after UA disconnection)
does not update the previous one (as this thread reports) so Kamailio
still chooses the previous binding which does not work anymore.
Regards.
--
I?aki Baz Castillo
<ibc at aliax.net>
From jh at tutpro.com Fri Jul 27 11:41:55 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Fri, 27 Jul 2012 12:41:55 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <5011A27B.7070800@ntt.lt>
References: <500E539B.9030300@ntt.lt>
<20497.2528.581689.906893@siika.tutpro.com>
<5011A27B.7070800@ntt.lt>
Message-ID: <20498.25187.406838.61391@siika.tutpro.com>
Antanas Masevicius writes:
> it looks like column order a bit changed in my system after using alter table during migrations.
> That is prefix col is not it its place. Thus this data:
> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
> should be fixed as:
> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,NULL,'11#',1,NULL);
antanas,
i tried with your lcr data and calling 118 worked fine. by changing
load_gw function syslog log messages to INFOs, i got:
Jul 27 12:18:56 siika /usr/sbin/sip-proxy[7260]: INFO: lcr [lcr_mod.c:1855]: load_gws(90, 118, sip:+35832345670 at test.fi)
Jul 27 12:18:56 siika /usr/sbin/sip-proxy[7260]: INFO: lcr [lcr_mod.c:1929]: added matched_gws[0]=[1, 3, 0, 545355600]
and then my proxy tried to send the request to the given ip address.
check that your lcr_count param value is at least 90. name of the param is
misleading. it should be called max_lcr_id.
-- juha
From antanas.masevicius at ntt.lt Fri Jul 27 12:37:31 2012
From: antanas.masevicius at ntt.lt (Antanas Masevicius)
Date: Fri, 27 Jul 2012 13:37:31 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <20498.25187.406838.61391@siika.tutpro.com>
References: <500E539B.9030300@ntt.lt>
<20497.2528.581689.906893@siika.tutpro.com>
<5011A27B.7070800@ntt.lt>
<20498.25187.406838.61391@siika.tutpro.com>
Message-ID: <50126F6B.3030500@ntt.lt>
Hello Juha,
i have my lcr_count set as modparam("lcr", "lcr_count", 102).
This is really messy then. Is there something else which could help to
understand the cause of this?
I see you use sip-proxy as flavorful, maybe there something is a bit
different?
Antanas
On 2012.07.27 12:41, Juha Heinanen wrote:
> Antanas Masevicius writes:
>
>> it looks like column order a bit changed in my system after using alter table during migrations.
>> That is prefix col is not it its place. Thus this data:
>> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
>> should be fixed as:
>> (1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,NULL,'11#',1,NULL);
> antanas,
>
> i tried with your lcr data and calling 118 worked fine. by changing
> load_gw function syslog log messages to INFOs, i got:
>
> Jul 27 12:18:56 siika /usr/sbin/sip-proxy[7260]: INFO: lcr [lcr_mod.c:1855]: load_gws(90, 118, sip:+35832345670 at test.fi)
> Jul 27 12:18:56 siika /usr/sbin/sip-proxy[7260]: INFO: lcr [lcr_mod.c:1929]: added matched_gws[0]=[1, 3, 0, 545355600]
>
> and then my proxy tried to send the request to the given ip address.
>
> check that your lcr_count param value is at least 90. name of the param is
> misleading. it should be called max_lcr_id.
>
> -- juha
>
--
Antanas Masevi?ius
Technikos direktorius
UAB "Nacionalinis telekomunikaciju tinklas"
Tel. +370 5 2056000
Tel. +370 700 00031 (tiesioginis)
Fax. +370 700 00034
el.p: antanas.masevicius at ntt.lt
www.ntt.lt
www.spykas.com
From jh at tutpro.com Fri Jul 27 12:44:20 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Fri, 27 Jul 2012 13:44:20 +0300
Subject: [SR-Users] Cant make from_uri, request_uri work for LCR module
In-Reply-To: <50126F6B.3030500@ntt.lt>
References: <500E539B.9030300@ntt.lt>
<20497.2528.581689.906893@siika.tutpro.com>
<5011A27B.7070800@ntt.lt>
<20498.25187.406838.61391@siika.tutpro.com>
<50126F6B.3030500@ntt.lt>
Message-ID: <20498.28932.969983.415009@siika.tutpro.com>
Antanas Masevicius writes:
> i have my lcr_count set as modparam("lcr", "lcr_count", 102).
> This is really messy then. Is there something else which could help to
> understand the cause of this?
i did my tests on amd64 architecture, but it should not matter because
all ints in your data fit into unsigned ints also on 32 bit architecture.
-- juha
From intel at intrans.baku.az Fri Jul 27 13:00:51 2012
From: intel at intrans.baku.az (intel at intrans.baku.az)
Date: Fri, 27 Jul 2012 16:00:51 +0500 (AZST)
Subject: [SR-Users] How to change _only_ next hop and dpn't touch content of
message?
Message-ID: <51958.85.132.76.4.1343386851.squirrel@mail.az>
I want retransmit some me ssages to other sip server as is.
f.e server sip1.com receives invite message
INVITE user at somewhere.org
i want to send it to server sip2.com as is.
Unfortunately, if i use rewritehostport() function, or modify $rp $rd
pseudovariables
fe $rp='sip2.com', kamailio changes invite uri, and send to sip2.com
INVITE user at sip2.com
The To: filed left untouched
How can I resend message without modifications?
I've tried also modify $dp and $dd pseudovariables, but then message
wasn't sent anywhere,and in log I can see this message:
Jul 27 15:44:54 dsdb01 /usr/sbin/kamailio[17786]: ERROR: tm
[t_fwd.c:1523]: ERROR: t_forward_nonack: no branches for forwarding
Jul 27 15:44:54 dsdb01 /usr/sbin/kamailio[17786]: ERROR: tm [tm.c:1375]:
ERROR: w_t_relay_to: t_relay_to failed
What else can I try?
--
From miconda at gmail.com Fri Jul 27 13:33:49 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Fri, 27 Jul 2012 13:33:49 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
Message-ID: <50127C9D.7070908@gmail.com>
Hello,
just to be sure before going to any further investigation (as I
remember, such case I tested a bit with some command line tools due to
lack of a sip phone with good ob/gruu support), do you have in the config:
modparam("registrar", "gruu_enabled", 1)
The default config file in 3.3, has the parameter set to 0.
Cheers,
Daniel
On 7/27/12 10:05 AM, I?aki Baz Castillo wrote:
> Hi, full agree with this bug report. Adding the devel maillist. More
> comments at the end of the mail:
>
>
> 2012/7/26 Jos? Luis Mill?n <jmillan at aliax.net>:
>> Hi,
>>
>> I'm using Kamilio 3.3.0 as registrar server. I`m using an outbound proxy so
>> 'use_path' parameter or 'registrar' module is enabled.
>>
>> According to RFC 5626, a re-registration from a specific combination of AoR,
>> instance_id and reg_id must update the binding.
>>
>> ""
>> If the registrar receives a re-registration for a specific
>> combination of AOR, and instance-id and reg-id values, the registrar
>> MUST update any information that uniquely identifies the network flow
>> over which the request arrived if that information has changed, and
>> SHOULD update the time the binding was last updated.
>> ""
>>
>> In my installation this is not fullfilled as shown:
>>
>> ""
>> AOR:: jmillan
>> Contact:: sip:jmillan at MY_IP;transport=ws;ov-ob=a570655c14 Q=
>> Expires:: 181
>> Callid:: 1hgq3khalq2rzfr
>> Cseq:: 108
>> User-agent:: JsSIP 0.1.0
>> Path::
>> <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:a570655c14 at OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 0
>> Socket:: tcp:KAM_IP:5060
>> Methods:: 783
>> Ruid:: uloc-50119d99-328e-1
>> Instance::
>> <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
>> Reg-Id:: 1
>> Contact:: sip:jmillan at MY_IP;transport=ws;ov-ob=1dd97b4d51 Q=
>> Expires:: 193
>> Callid:: 1hgq3khalq2rzfr
>> Cseq:: 110
>> User-agent:: JsSIP 0.1.0
>> Path::
>> <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:1dd97b4d51 at OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 0
>> Socket:: tcp:KAM_IP:5060
>> Methods:: 783
>> Ruid:: uloc-50119d99-3290-2
>> Instance::
>> <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
>> Reg-Id:: 1
>> ""
>>
>> The scenario is such that when the client looses the connection with the
>> Outbound Server, it reconnects and re-registers to Kamailio in order to
>> replace registration and be able to receive in-dialog messages.
> Receiving in-dialog requests should work since GRUU is also being
> used. The problem is that the new REGISTER (after UA disconnection)
> does not update the previous one (as this thread reports) so Kamailio
> still chooses the previous binding which does not work anymore.
>
>
> Regards.
>
>
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From bruno.bresciani at gmail.com Fri Jul 27 15:00:42 2012
From: bruno.bresciani at gmail.com (Bruno Bresciani)
Date: Fri, 27 Jul 2012 10:00:42 -0300
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
Message-ID: <CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
Hi Users,
This is my ultimate try to ask for some help to debug the two cores
generated by fm_realloc() function. If somebody can give me a feedback
about my questions or doubts I will be very grateful, this user list of
kamailio always help me to solve my problems.
Best Regards
2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com>
> Hi All,
>
> I imagine that this core doesn't easy to replicate but somebody can help
> me to understand why it was generated? There is some way to prevent it?
>
> Best Regards
>
>
>
> 2012/7/18 Renan Capaverde <renan.capaverde at digitro.com.br>
>
>> I am having the same problem on kamailio 3.1.6. Someone please help.
>>
>> Cheers,
>> Renan
>>
>> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>>
>> Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
>>
>> Best Regards
>>
>>
>> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com>
>>
>>> Hello,
>>>
>>> send also the version 'kamailio -V' to match the proper sources.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>>
>>> Hi all,
>>>
>>> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0,
>>> size=0) at mem/f_malloc.c:536.
>>>
>>> I don't know exactly what may be caused this core because the debug of
>>> kamailio is disabled, but looking at backtrace (gdb) and source code I
>>> could notice a relationship with TLS connection establishment (handshake).
>>> Other important fact is that core was generated by the kamalio itself with
>>> signal 6 (abort) because it can't find the pointer to memory realloc.
>>> I'd like to know if someone already observed this issue and if my
>>> analyse above is correct?
>>>
>>> Bellow is backtrace full with gdb:
>>>
>>> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>>> /var/run/kamailio.pid'.
>>> Program terminated with signal 6, Aborted.
>>> #0 0x00f30402 in __kernel_vsyscall ()
>>> (gdb)
>>> (gdb)
>>> (gdb)
>>> (gdb)
>>> (gdb) bt full
>>> #0 0x00f30402 in __kernel_vsyscall ()
>>> No symbol table info available.
>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>> No symbol table info available.
>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>> No symbol table info available.
>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
>>> mem/f_malloc.c:536
>>> f = (struct fm_frag *) 0xb61f0bb8
>>> pf = <value optimized out>
>>> orig_size = 18
>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>> ptr = <value optimized out>
>>> hash = 23548
>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
>>> ../../mem/shm_mem.h:266
>>> No locals.
>>> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
>>> tls_server.c:346
>>> ret = <value optimized out>
>>> ssl = (SSL *) 0xb61c1878
>>> cert = <value optimized out>
>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>> tls_log = <value optimized out>
>>> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
>>> tls_server.c:1028
>>> r = (struct tcp_req *) 0xb621affc
>>> bytes_free = 4095
>>> bytes_read = 70
>>> read_size = 4095
>>> ssl_error = 0
>>> ssl_read = 0
>>> ssl = (SSL *) 0xb61c1878
>>> rd_buf = "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>>
>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>> wr_buf =
>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>
>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70, size
>>> = 65536}
>>> wr = {
>>> buf = 0xbf8fdfa4
>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>> pos = 0, used = 0,
>>> size = 65536}
>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>> n = 0
>>> flush_flags = <value optimized out>
>>> err_src = 0x541a83 "TLS read:"
>>> x = <value optimized out>
>>> #15 0x08158ade in tcp_read_headers (c=0xb621af88, read_flags=0xbf91e200)
>>> at tcp_read.c:406
>>> bytes = -1
>>> remaining = <value optimized out>
>>> p = <value optimized out>
>>> r = (struct tcp_req *) 0xb621affc
>>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204,
>>> read_flags=0xbf91e200) at tcp_read.c:871
>>> bytes = <value optimized out>
>>> total_bytes = 0
>>> resp = <value optimized out>
>>> size = <value optimized out>
>>> req = (struct tcp_req *) 0xb621affc
>>> dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data =
>>> "\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family =
>>> 57540,
>>> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
>>> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port =
>>> 49041,
>>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 =
>>> {0, 0, 16, 0, 1, 0,
>>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}}, id
>>> = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask = 0
>>> '\0'}}
>>> c = 10 '\n'
>>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
>>> tcp_read.c:1150
>>> ret = 4
>>> n = 4
>>> read_flags = 1
>>> con = (struct tcp_connection *) 0xb621af88
>>> s = 12
>>> resp = <value optimized out>
>>> t = <value optimized out>
>>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
>>> No locals.
>>> ---Type <return> to continue, or q <return> to quit---
>>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>>> r = 3
>>> reader_fd_1 = 35
>>> pid = <value optimized out>
>>> si = <value optimized out>
>>> #20 0x080ad412 in main_loop () at main.c:1632
>>> i = 4
>>> pid = <value optimized out>
>>> si = (struct socket_info *) 0x0
>>> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
>>> \000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted
>>> DWARF expression.
>>> ) at main.c:2398
>>> cfg_stream = (FILE *) 0x8a2d008
>>> c = <value optimized out>
>>> r = 0
>>> tmp = 0xbf91e674
>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>> tmp_len = 10492229
>>> port = 136192361
>>> proto = -1080957480
>>> ret = <value optimized out>
>>> seed = 21782655
>>> rfd = 4
>>> debug_save = <value optimized out>
>>> debug_flag = 0
>>> dont_fork_cnt = 0
>>> n_lst = <value optimized out>
>>> p = <value optimized out>
>>>
>>>
>>> Best Regards
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>
>>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120727/82042044/attachment-0001.htm>
From dominic at timedicer.co.uk Fri Jul 27 15:19:39 2012
From: dominic at timedicer.co.uk (Dominic Raferd)
Date: Fri, 27 Jul 2012 14:19:39 +0100
Subject: [SR-Users] Add CallerID to SIP header
Message-ID: <5012956B.4030500@timedicer.co.uk>
I'm not yet using Kamailio. I am looking for something to do a job which
sounds really simple but may not be. Our PBX connects to a SIP service
(voicetrading.com) but does not supply our CallerID, this means that
voicetrading.com provide some very weird callerids for the person at the
other end (international numbers etc). Which is not good.
There is no way to get our PBX to add CallerID itself, so I thought
maybe I could set up a local sip proxy? or sip redirect? server
(Kamailio?) to do nothing other than add in the callerid details to the
sip header and then forward the sip message on to voicetrading i.e. be
otherwise 'invisible'?
If Kamailio is not the right thing to do this with, is there something
else that could do it?
Thanks for any suggestions.
Dominic
From charles.chance at sipcentric.com Fri Jul 27 15:55:56 2012
From: charles.chance at sipcentric.com (Charles Chance)
Date: Fri, 27 Jul 2012 14:55:56 +0100
Subject: [SR-Users] Add CallerID to SIP header
In-Reply-To: <5012956B.4030500@timedicer.co.uk>
Message-ID: <mailman.6.1343397381.2418.sr-users@lists.sip-router.org>
Hello Dominic,
I think the UAC module should help you -
http://kamailio.org/docs/modules/stable/modules_k/uac.html
You should check first that your upstream provider allows you to pass caller
ID - if not, they'll just replace/remove it anyway.
Out of interest, what PBX do you have that does not support setting caller
ID anyway?
Charles
www.sipcentric.com
Follow us on twitter @sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592.
Registered office: 9th Floor, Centre City Tower, Hill Street, Birmingham, B5
4UA.
-----Original Message-----
From: sr-users-bounces at lists.sip-router.org
[mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Dominic Raferd
Sent: 27 July 2012 14:20
To: sr-users at lists.sip-router.org
Subject: [SR-Users] Add CallerID to SIP header
I'm not yet using Kamailio. I am looking for something to do a job which
sounds really simple but may not be. Our PBX connects to a SIP service
(voicetrading.com) but does not supply our CallerID, this means that
voicetrading.com provide some very weird callerids for the person at the
other end (international numbers etc). Which is not good.
There is no way to get our PBX to add CallerID itself, so I thought
maybe I could set up a local sip proxy? or sip redirect? server
(Kamailio?) to do nothing other than add in the callerid details to the
sip header and then forward the sip message on to voicetrading i.e. be
otherwise 'invisible'?
If Kamailio is not the right thing to do this with, is there something
else that could do it?
Thanks for any suggestions.
Dominic
_______________________________________________
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
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5157 - Release Date: 07/26/12
From dominic at timedicer.co.uk Fri Jul 27 16:28:16 2012
From: dominic at timedicer.co.uk (Dominic Raferd)
Date: Fri, 27 Jul 2012 15:28:16 +0100
Subject: [SR-Users] Add CallerID to SIP header
In-Reply-To: <E1Sul2H-0006yy-Fl@www.kamailio.org>
References: <E1Sul2H-0006yy-Fl@www.kamailio.org>
Message-ID: <5012A580.60905@timedicer.co.uk>
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120727/3f040cd6/attachment.htm>
From apogrebennyk at sipwise.com Fri Jul 27 17:53:17 2012
From: apogrebennyk at sipwise.com (Andrew Pogrebennyk)
Date: Fri, 27 Jul 2012 17:53:17 +0200
Subject: [SR-Users] lcr.dump_gws problem
In-Reply-To: <A6C2711F9706AF4992FFEC48EA19CA90174144E274@lyepkyexc.LYEPLYEXC.local>
References: <A6C2711F9706AF4992FFEC48EA19CA90174144E272@lyepkyexc.LYEPLYEXC.local>
<A6C2711F9706AF4992FFEC48EA19CA90174144E274@lyepkyexc.LYEPLYEXC.local>
Message-ID: <5012B96D.7090501@sipwise.com>
Hi Gary,
It was fixed already by Richard in 3.3 branch:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=28be16549831df46dd1b8312da223b02359d8a9c
(and master)
Thank you for the report.
On 07/24/2012 09:44 PM, Gary Chen wrote:
> Sorry, it should be Kamailio 3.3.0 not 3.2.0.
>
>
>
> *From:*sr-users-bounces at lists.sip-router.org
> [mailto:sr-users-bounces at lists.sip-router.org] *On Behalf Of *Gary Chen
> *Sent:* Tuesday, July 24, 2012 3:39 PM
> *To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> Users Mailing List
> *Subject:* [SR-Users] lcr.dump_gws problem
>
>
>
> Kamailio 3.2.0
>
>
>
> When testing Kamailio 3.2.0, I notice that lcr.dump_gws command does not
> display ip_addr correctly. Here is my output:
>
> lcr_id: 3
>
> gw_id: 15
>
> gw_index: 2
>
> gw_name: gateway_1
>
> scheme: sip
>
> ip_addr: 1273060816.0.0.0
>
> hostname:
>
> port: 5060
>
> params:
>
> strip: 0
>
> prefix:
>
> tag:
>
> flags: 0
>
> defunct_until: 0
>
>
>
> LCR is still working correctly. It just does not display IP in the right
> form. Does any body also has the same problem?
>
>
>
> Gary
>
>
>
>
>
> _______________________________________________
> 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
>
From jmillan at aliax.net Fri Jul 27 13:43:25 2012
From: jmillan at aliax.net (=?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?=)
Date: Fri, 27 Jul 2012 13:43:25 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <50127C9D.7070908@gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
Message-ID: <CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
Yes,
Verified, 'gruu_enabled' is set to one.
Regards
2012/7/27 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> just to be sure before going to any further investigation (as I remember,
> such case I tested a bit with some command line tools due to lack of a sip
> phone with good ob/gruu support), do you have in the config:
>
> modparam("registrar", "gruu_enabled", 1)
>
> The default config file in 3.3, has the parameter set to 0.
>
> Cheers,
> Daniel
>
>
> On 7/27/12 10:05 AM, I?aki Baz Castillo wrote:
>
>> Hi, full agree with this bug report. Adding the devel maillist. More
>> comments at the end of the mail:
>>
>>
>> 2012/7/26 Jos? Luis Mill?n <jmillan at aliax.net>:
>>
>>> Hi,
>>>
>>> I'm using Kamilio 3.3.0 as registrar server. I`m using an outbound
>>> proxy so
>>> 'use_path' parameter or 'registrar' module is enabled.
>>>
>>> According to RFC 5626, a re-registration from a specific combination of
>>> AoR,
>>> instance_id and reg_id must update the binding.
>>>
>>> ""
>>> If the registrar receives a re-registration for a specific
>>> combination of AOR, and instance-id and reg-id values, the registrar
>>> MUST update any information that uniquely identifies the network flow
>>> over which the request arrived if that information has changed, and
>>> SHOULD update the time the binding was last updated.
>>> ""
>>>
>>> In my installation this is not fullfilled as shown:
>>>
>>> ""
>>> AOR:: jmillan
>>> Contact:: sip:jmillan at MY_IP;transport=**ws;ov-ob=a570655c14
>>> Q=
>>> Expires:: 181
>>> Callid:: 1hgq3khalq2rzfr
>>> Cseq:: 108
>>> User-agent:: JsSIP 0.1.0
>>> Path::
>>> <sip:OUTBOUND_IP:9090;**transport=tcp;lr;ovid=**
>>> de0c0b9f>,<sip:a570655c14@**OUTBOUND_IP:10080;transport=**
>>> ws;lr;ovid=de0c0b9f;ob>
>>> State:: CS_SYNC
>>> Flags:: 0
>>> Cflag:: 0
>>> Socket:: tcp:KAM_IP:5060
>>> Methods:: 783
>>> Ruid:: uloc-50119d99-328e-1
>>> Instance::
>>> <urn:uuid:38dce009-ae1f-4fd1-**91dc-99ed9affddc1>
>>> Reg-Id:: 1
>>> Contact:: sip:jmillan at MY_IP;transport=**ws;ov-ob=1dd97b4d51
>>> Q=
>>> Expires:: 193
>>> Callid:: 1hgq3khalq2rzfr
>>> Cseq:: 110
>>> User-agent:: JsSIP 0.1.0
>>> Path::
>>> <sip:OUTBOUND_IP:9090;**transport=tcp;lr;ovid=**
>>> de0c0b9f>,<sip:1dd97b4d51@**OUTBOUND_IP:10080;transport=**
>>> ws;lr;ovid=de0c0b9f;ob>
>>> State:: CS_SYNC
>>> Flags:: 0
>>> Cflag:: 0
>>> Socket:: tcp:KAM_IP:5060
>>> Methods:: 783
>>> Ruid:: uloc-50119d99-3290-2
>>> Instance::
>>> <urn:uuid:38dce009-ae1f-4fd1-**91dc-99ed9affddc1>
>>> Reg-Id:: 1
>>> ""
>>>
>>> The scenario is such that when the client looses the connection with the
>>> Outbound Server, it reconnects and re-registers to Kamailio in order to
>>> replace registration and be able to receive in-dialog messages.
>>>
>> Receiving in-dialog requests should work since GRUU is also being
>> used. The problem is that the new REGISTER (after UA disconnection)
>> does not update the previous one (as this thread reports) so Kamailio
>> still chooses the previous binding which does not work anymore.
>>
>>
>> Regards.
>>
>>
>>
>>
>>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/**miconda<http://www.linkedin.com/in/miconda>
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
>
> ______________________________**_________________
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120727/17bb2a8f/attachment-0001.htm>
From tayeb at vobradio.org Sat Jul 28 14:25:04 2012
From: tayeb at vobradio.org (Tayeb Meftah)
Date: Sat, 28 Jul 2012 15:25:04 +0300
Subject: [SR-Users] Error 403 not relaying
Message-ID: <CAE1B-ryhb0_h1nY8A2+PVh7b59a1FDNsDLU0pQoCDnwfA3ob3w@mail.gmail.com>
hello,
i'm using Kamailio with a simple registrare configuration
i used the apt repository to install the developmant package of kamailio
domain sip.tmvoip.net have 2 records, A record and AAA record (dual stacked)
i configured it in my kamailio using siremis and in the kamctlrc
config below:
Kamailio.cfg: http://paste.debian.net/180972/
Kamctlrc: http://paste.debian.net/180973/
siptrace: http://paste.debian.net/180974/
note that 172.28.0.0/21 and 41.221.20.12/30 is routed, no nat.
my current issue is if i register or i invite, i get error 403 not relaying
trying to investigate this issu but i have no clue
thank you everyone,
--
Voice of the blind ? broadcast freedom
Phones:
Algeria: +213-660-347746
USA, NewYork: +1(347)759-5883
iNum: +883510001288000
we're blind, but not deaf!
From brandon at cryy.com Sat Jul 28 20:42:42 2012
From: brandon at cryy.com (Brandon Armstead)
Date: Sat, 28 Jul 2012 11:42:42 -0700
Subject: [SR-Users] BYE Race Condition
Message-ID: <CACr1DbCJ+9mvtGNgev+xrAPaGg3K4nuqzeAf6RsB7FEvfAJ7hg@mail.gmail.com>
Hello,
I am running into an issue where there is a race condition happening. I
am looking for opinions / ideas on how to handle the following below
scenario.
Scenario.
UAC places an outbound call -> upstream carrier.
The call is disconnected on both ends at the exact same time,
UAC -> sends BYE upstream
Upstream Carrier -> sends BYE downstream
Upstream 200 OK's the BYE
UAC sends 481 back to Upstream Carrier for their generated BYE.
The upstream carrier is complaining about receiving the relayed 481
responses -- so my first thought was simply to drop() these from relaying
upstream.
I am curious how other people are handling this?
Would you suggest simply dropping the relay from being sent back upstream
on the 481?
Would you simply always 200 OK a downstream BYE from trusted carriers
regardless of UAC response, and create separate transaction to send BYE
downstream?
Thank you as always. Look forward to your thoughts / suggestions / ideas.
Sincerely,
Brandon Armstead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120728/a54a957a/attachment.htm>
From brandon at cryy.com Sat Jul 28 20:55:36 2012
From: brandon at cryy.com (Brandon Armstead)
Date: Sat, 28 Jul 2012 11:55:36 -0700
Subject: [SR-Users] BYE Race Condition
Message-ID: <CACr1DbAHM+LWbtnzQresbko=_WCtuDN8Ccry_txV4fU9tyXjAw@mail.gmail.com>
*** Please forgive if this is a duplicate ***
Hello,
I am running into an issue where there is a race condition happening. I
am looking for opinions / ideas on how to handle the following below
scenario.
Scenario.
UAC places an outbound call -> upstream carrier.
The call is disconnected on both ends at the exact same time,
UAC -> sends BYE upstream
Upstream Carrier -> sends BYE downstream
Upstream 200 OK's the BYE
UAC sends 481 back to Upstream Carrier for their generated BYE.
The upstream carrier is complaining about receiving the relayed 481
responses -- so my first thought was simply to drop() these from relaying
upstream.
I am curious how other people are handling this?
Would you suggest simply dropping the relay from being sent back upstream
on the 481?
Would you simply always 200 OK a downstream BYE from trusted carriers
regardless of UAC response, and create separate transaction to send BYE
downstream?
Thank you as always. Look forward to your thoughts / suggestions / ideas.
Sincerely,
Brandon Armstead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120728/42ca5bd9/attachment.htm>
From jh at tutpro.com Sun Jul 29 13:25:44 2012
From: jh at tutpro.com (Juha Heinanen)
Date: Sun, 29 Jul 2012 14:25:44 +0300
Subject: [SR-Users] How to change _only_ next hop and dpn't touch content
of message?
In-Reply-To: <51958.85.132.76.4.1343386851.squirrel@mail.az>
References: <51958.85.132.76.4.1343386851.squirrel@mail.az>
Message-ID: <20501.7608.211652.745581@siika.tutpro.com>
intel at intrans.baku.az writes:
> What else can I try?
just in case you didn't get another reply, try setting $du.
-- juha
From ngoahotanglongbk at gmail.com Sun Jul 29 20:52:51 2012
From: ngoahotanglongbk at gmail.com (Duong Manh Truong)
Date: Mon, 30 Jul 2012 01:52:51 +0700
Subject: [SR-Users] Kamailio with APNS
Message-ID: <CADNPFHRvF0NecT1P7ESvY8gSc5dTUetGAqPB2Javm90v3NLqQQ@mail.gmail.com>
Thank Klaus,
I've try with t_suspend() and t_continue() as your guide,
*#Failure route to react with negative messages
failure_route[1] {
if (t_check_status("5[0-9][2-9]"))
{ if(t_suspend())
{
xlog("proceesing suspended in trasaction
[$T(id_index):$T(id_label)]\n");
xlog("before sleep \n");
}
if(async_sleep("20"))
xlog("After sleep 20s \n");
if(t_continue('1','1','MYROUTE'))
xlog("Continuation successfully \n");
exit;
};*
And i found that t_suspend() and async_sleep() runnung ok but
t_continue() seems not running.
I read about TMX module and TMX module Pseudo-Variables but still can
not figure out it :(
Secondly, in case of t_continue() runs successfully , please tell me
how to let Kamailio resend the INVITE message
to client B (before the t_continue(), i think so ) - while client B is
waking up ?
Which functions and modules that i need to do this?
Thanks.
-----------------------------------------------------------------
Hi!
You have to use a failure route
(http://kamailio.org/docs/modules/3.3.x/modules/tm.html#t_on_failure).
In the failure route check if the reply code is 404 and if yes, trigger
the APNS logic and then put the call e.g. on a stack and resume e.g.
every second and ofrward to the "SIP server" again to see if the client
is registered meanwhile.
For the asynchronous processing take a look at these functions:
t_suspend(),t_resume()[1]. For example you can call t_resume in a timer
route every second. For the timer route, to know which transactions are
currently suspended and are waiting for further processing, you could
put the transaction identifiers in a message-queue [2] and read the
queue from the timer route.
regards
Klaus
[1] http://kamailio.org/docs/modules/3.3.x/modules_k/tmx.html#id2535968
[2] http://kamailio.org/docs/modules/3.3.x/modules/mqueue.html
On 24.07.2012 06:02, Duong Manh Truong wrote:
>* Hi list,*>**>* My team are developing a SIP client for mobile running iOS ,*>**>* then having to deal with the "back ground mode" problem while this soft*>* is installed on mobiles*>**>* One of the solutions is using APNS. (Apple Push Notification Service)*>**>* I wanna to use Kamailio as SIP Redirect / Proxy for my current SIP server*>**>* The model is like that:*>**>* User A <---------> Kamailio <---------> SIP server <--------> User B*>**>* IF UserA call UserB, UserB is not available now (not registered yet),*>* normally, SIP server will reply Kamailio with "404 Not found"*>**>* In that case, i want to set up Kamailio do the communication with APNS*>* and waiting for UserB "Wake up" then RESEND the Invite message ......*>* (instead of forwarding this 404 message to UserA)*>**>* I am getting stuck at how Kamailio can control "404 Not found" message*>* which it receives from SIP server .*>**>* I do searching around several days but still can not get any clearer*>* points.*>**>* Please help me with some instruction/ configuration of Kamailio for this*>* case !*>**>* Thank you very much.*>**>**>* _______________________________________________*>* 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*>**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/b2daf28c/attachment.htm>
From ngoahotanglongbk at gmail.com Mon Jul 30 04:40:42 2012
From: ngoahotanglongbk at gmail.com (Duong Manh Truong)
Date: Mon, 30 Jul 2012 09:40:42 +0700
Subject: [SR-Users] Reply to one topic correctly
Message-ID: <CADNPFHTGrfpWne6dv9W3PgwvSEPuEeH_S77BYHo6fkgxavw02g@mail.gmail.com>
Hi list,
I am a newbie of the maillist,
I'm wondering that whenever i reply to a specific topic with the subject of
"RE: [SR-Users]....",
my email come to maillist in the way dislike what i wish,
my email appears like a NEW topic instead of SUB topic (reply message form)
I try several ways but still not get the correct method of reply, please
help me to fix this, thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/d7a257d3/attachment.htm>
From dnotivol at gmail.com Mon Jul 30 08:53:40 2012
From: dnotivol at gmail.com (David Notivol)
Date: Mon, 30 Jul 2012 08:53:40 +0200
Subject: [SR-Users] ACK not relayed
Message-ID: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
In a UAC-Kamailio-UAS scenario, we've found a case where the ACK coming
from uac is not relayed by our proxy to the uas. This is the log for the
ACK message:
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:624]: SIP Request:
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:626]: method: <ACK>
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:628]: uri:
<sip:59138553189 at 79.170.68.157> <sip:59138553189 at 79.170.68.157>
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:630]: version: <SIP/2.0>
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/parse_via.c:1286]: Found param type 235, <rport> =
<n/a>; state=6
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/parse_via.c:1286]: Found param type 232, <branch> =
<z9hG4bKKc4gKXyemS9HD>; state=16
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/parse_via.c:2561]: end of header reached, state=5
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:513]: parse_headers: this is the first
via
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [receive.c:149]: After parse_msg...
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [receive.c:190]: preparing to run routing scripts...
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: sl [sl_funcs.c:396]: DEBUG : sl_filter_ACK: to late to be a local
ACK!
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: maxfwd [mf_funcs.c:85]: value = 65
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/parse_to.c:802]: end of header reached, state=29
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52];
uri=[sip:59138553189 at 79.170.68.157]
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:190]: DEBUG: to body [
<sip:59138553189 at 79.170.68.157> <sip:59138553189 at 79.170.68.157>]
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>:
<31362871> <ACK>
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:202]: DEBUG: get_hdr_body :
content_length=0
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/msg_parser.c:104]: found end of header
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: <core> [parser/parse_to.c:802]: end of header reached, state=29
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: sanity [mod_sanity.c:255]: sanity checks result: 1
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: siputils [checks.c:106]: totag found
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
ERROR: <script>: ESTAMOS EN WITHIN
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: rr [loose.c:108]: No Route headers found
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: rr [loose.c:829]: There is no Route HF
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
ERROR: <script>: NO LOOSE ROUTE
However, in a pcap trace I clearly see the Route header:
This is the Record-Route in the 200 message
Record-Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
And this is the Route header in the ACk:
Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
I haven't been able to figure out what's going on. We have plenty of
traffic working in that proxy. What am I missing?
Thanks in advance
David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/da953d9f/attachment-0001.htm>
From miconda at gmail.com Mon Jul 30 09:51:04 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 09:51:04 +0200
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
<CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
Message-ID: <50163CE8.2050903@gmail.com>
Hello,
it is in my to-do list to investigate, so far I was not able to reproduce.
Vacation time together with other travelings makes a bit more slower
process. Please add it also to the tracker:
http://sip-router.org/tracker/
A minor release for 3.3 branch is going to be soon, being there makes
sure it will be reviewed to see if it applies.
Cheers,
Daniel
On 7/27/12 3:00 PM, Bruno Bresciani wrote:
> Hi Users,
>
> This is my ultimate try to ask for some help to debug the two cores
> generated by fm_realloc() function. If somebody can give me a feedback
> about my questions or doubts I will be very grateful, this user list
> of kamailio always help me to solve my problems.
>
> Best Regards
>
>
> 2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com
> <mailto:bruno.bresciani at gmail.com>>
>
> Hi All,
>
> I imagine that this core doesn't easy to replicate but somebody
> can help me to understand why it was generated? There is some way
> to prevent it?
>
> Best Regards
>
>
>
> 2012/7/18 Renan Capaverde <renan.capaverde at digitro.com.br
> <mailto:renan.capaverde at digitro.com.br>>
>
> I am having the same problem on kamailio 3.1.6. Someone please
> help.
>
> Cheers,
> Renan
>
> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>> Excuse-me Daniel, I forgot this information... Kamailio
>> version 3.1.2
>>
>> Best Regards
>>
>>
>> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>>
>>
>> Hello,
>>
>> send also the version 'kamailio -V' to match the proper
>> sources.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>> Hi all,
>>>
>>> I observed two at 0x08173bf0 in fm_realloc
>>> (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at mem/f_malloc.c:536.
>>>
>>> I don't know exactly what may be caused this core
>>> because the debug of kamailio is disabled, but looking
>>> at backtrace (gdb) and source code I could notice a
>>> relationship with TLS connection establishment
>>> (handshake). Other important fact is that core was
>>> generated by the kamalio itself with signal 6 (abort)
>>> because it can't find the pointer to memory realloc.
>>> I'd like to know if someone already observed this issue
>>> and if my analyse above is correct?
>>>
>>> Bellow is backtrace full with gdb:
>>>
>>> Core was generated by
>>> `/home2/local/kamailio/sbin/kamailio -P
>>> /var/run/kamailio.pid'.
>>> Program terminated with signal 6, Aborted.
>>> #0 0x00f30402 in __kernel_vsyscall ()
>>> (gdb)
>>> (gdb)
>>> (gdb)
>>> (gdb)
>>> (gdb) bt full
>>> #0 0x00f30402 in __kernel_vsyscall ()
>>> No symbol table info available.
>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>> No symbol table info available.
>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>> No symbol table info available.
>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536
>>> f = (struct fm_frag *) 0xb61f0bb8
>>> pf = <value optimized out>
>>> orig_size = 18
>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>> ptr = <value optimized out>
>>> hash = 23548
>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32)
>>> at ../../mem/shm_mem.h:266
>>> No locals.
>>> #5 0x00460295 in OPENSSL_cleanse () from
>>> /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from
>>> /lib/libssl.so.6
>>> No symbol table info available.
>>> #10 0x007aa9f3 in ssl3_get_client_hello () from
>>> /lib/libssl.so.6
>>> No symbol table info available.
>>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #13 0x005278e3 in tls_accept (c=0xb621af88,
>>> error=0xbf91dfc8) at tls_server.c:346
>>> ret = <value optimized out>
>>> ssl = (SSL *) 0xb61c1878
>>> cert = <value optimized out>
>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>> tls_log = <value optimized out>
>>> #14 0x0052da8e in tls_read_f (c=0xb621af88,
>>> flags=0xbf91e200) at tls_server.c:1028
>>> r = (struct tcp_req *) 0xb621affc
>>> bytes_free = 4095
>>> bytes_read = 70
>>> read_size = 4095
>>> ssl_error = 0
>>> ssl_read = 0
>>> ssl = (SSL *) 0xb61c1878
>>> rd_buf =
>>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>> wr_buf =
>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70,
>>> used = 70, size = 65536}
>>> wr = {
>>> buf = 0xbf8fdfa4
>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>> pos = 0, used = 0,
>>> size = 65536}
>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>> n = 0
>>> flush_flags = <value optimized out>
>>> err_src = 0x541a83 "TLS read:"
>>> x = <value optimized out>
>>> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
>>> read_flags=0xbf91e200) at tcp_read.c:406
>>> bytes = -1
>>> remaining = <value optimized out>
>>> p = <value optimized out>
>>> r = (struct tcp_req *) 0xb621affc
>>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88,
>>> bytes_read=0xbf91e204, read_flags=0xbf91e200) at
>>> tcp_read.c:871
>>> bytes = <value optimized out>
>>> total_bytes = 0
>>> resp = <value optimized out>
>>> size = <value optimized out>
>>> req = (struct tcp_req *) 0xb621affc
>>> dst = {send_sock = 0x1, to = {s = {sa_family =
>>> 57540, sa_data =
>>> "\221??\020\000\000\000\000\000\000\000\020\000\000"},
>>> sin = {sin_family = 57540,
>>> sin_port = 49041, sin_addr = {s_addr = 16},
>>> sin_zero = "\000\000\000\000\020\000\000"}, sin6 =
>>> {sin6_family = 57540, sin6_port = 49041,
>>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8
>>> =
>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000",
>>> u6_addr16 = {0, 0, 16, 0, 1, 0,
>>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}},
>>> sin6_scope_id = 12}}, id = -1080958468, proto = 4
>>> '\004', send_flags = {f = 0 '\0', blst_imask = 0 '\0'}}
>>> c = 10 '\n'
>>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1,
>>> idx=-1) at tcp_read.c:1150
>>> ret = 4
>>> n = 4
>>> read_flags = 1
>>> con = (struct tcp_connection *) 0xb621af88
>>> s = 12
>>> resp = <value optimized out>
>>> t = <value optimized out>
>>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at
>>> io_wait.h:1091
>>> No locals.
>>> ---Type <return> to continue, or q <return> to quit---
>>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>>> r = 3
>>> reader_fd_1 = 35
>>> pid = <value optimized out>
>>> si = <value optimized out>
>>> #20 0x080ad412 in main_loop () at main.c:1632
>>> i = 4
>>> pid = <value optimized out>
>>> si = (struct socket_info *) 0x0
>>> si_desc = "udp receiver child=3
>>> sock=192.168.166.31:5060
>>> <http://192.168.166.31:5060>\000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>> #21 0x080afbe7 in main (argc=3,
>>> argv=dwarf2_read_address: Corrupted DWARF expression.
>>> ) at main.c:2398
>>> cfg_stream = (FILE *) 0x8a2d008
>>> c = <value optimized out>
>>> r = 0
>>> tmp = 0xbf91e674
>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>> tmp_len = 10492229
>>> port = 136192361
>>> proto = -1080957480
>>> ret = <value optimized out>
>>> seed = 21782655
>>> rfd = 4
>>> debug_save = <value optimized out>
>>> debug_flag = 0
>>> dont_fork_cnt = 0
>>> n_lst = <value optimized out>
>>> p = <value optimized out>
>>>
>>>
>>> Best Regards
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at 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 at lists.sip-router.org
> <mailto:sr-users at 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 at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/b0299433/attachment-0001.htm>
From miconda at gmail.com Mon Jul 30 09:53:59 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 09:53:59 +0200
Subject: [SR-Users] ACK not relayed
In-Reply-To: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
References: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
Message-ID: <50163D97.9000805@gmail.com>
Hello,
can you add a log message to print the source ip, call id and r-uri?
It may happen that the ACK is looping back if r-uri is pointing to itself.
Also, try to get the ngrep on all devices, like:
ngrep -d any -qt -W byline port 5060
Pasting the ACK request here will help to see if something is wrong with it.
Cheers,
Daniel
On 7/30/12 8:53 AM, David Notivol wrote:
> In a UAC-Kamailio-UAS scenario, we've found a case where the ACK
> coming from uac is not relayed by our proxy to the uas. This is the
> log for the ACK message:
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:624]: SIP Request:
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:626]: method: <ACK>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:628]: uri: <sip:59138553189 at 79.170.68.157>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:630]: version: <SIP/2.0>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>; state=6
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_via.c:1286]: Found param type 232, <branch> =
> <z9hG4bKKc4gKXyemS9HD>; state=16
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_via.c:2561]: end of header reached, state=5
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:513]: parse_headers: this is the first via
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [receive.c:149]: After parse_msg...
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [receive.c:190]: preparing to run routing scripts...
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl [sl_funcs.c:396]:
> DEBUG : sl_filter_ACK: to late to be a local ACK!
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd
> [mf_funcs.c:85]: value = 65
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_to.c:802]: end of header reached, state=29
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52];
> uri=[sip:59138553189 at 79.170.68.157]
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:190]: DEBUG: to body
> [<sip:59138553189 at 79.170.68.157>]
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <31362871> <ACK>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=0
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:104]: found end of header
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_to.c:802]: end of header reached, state=29
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity
> [mod_sanity.c:255]: sanity checks result: 1
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: siputils
> [checks.c:106]: totag found
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: ESTAMOS EN
> WITHIN
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:108]: No
> Route headers found
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:829]:
> There is no Route HF
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: NO LOOSE ROUTE
>
> However, in a pcap trace I clearly see the Route header:
> This is the Record-Route in the 200 message
> Record-Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
> And this is the Route header in the ACk:
> Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>
> I haven't been able to figure out what's going on. We have plenty of
> traffic working in that proxy. What am I missing?
>
> Thanks in advance
> David.
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/1b03dc93/attachment.htm>
From miconda at gmail.com Mon Jul 30 09:56:41 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 09:56:41 +0200
Subject: [SR-Users] Reply to one topic correctly
In-Reply-To: <CADNPFHTGrfpWne6dv9W3PgwvSEPuEeH_S77BYHo6fkgxavw02g@mail.gmail.com>
References: <CADNPFHTGrfpWne6dv9W3PgwvSEPuEeH_S77BYHo6fkgxavw02g@mail.gmail.com>
Message-ID: <50163E39.5050102@gmail.com>
Hello,
what email client application do you use? By hitting reply all button,
the email client should preserve the thread id in a header (which is not
visible unless you show the headers -- usually an option to most of
email clients).
Anyhow, the right way to reply is to be sure the mailing list is always
at least cc-ed (or directly addressed) -- the keeping of thread id is a
matter of the right email client.
Cheers,
Daniel
On 7/30/12 4:40 AM, Duong Manh Truong wrote:
> Hi list,
>
> I am a newbie of the maillist,
>
> I'm wondering that whenever i reply to a specific topic with the
> subject of "RE: [SR-Users]....",
> my email come to maillist in the way dislike what i wish,
>
> my email appears like a NEW topic instead of SUB topic (reply message
> form)
>
> I try several ways but still not get the correct method of reply,
> please help me to fix this, thanks.
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/471c5986/attachment.htm>
From miconda at gmail.com Mon Jul 30 10:03:11 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 10:03:11 +0200
Subject: [SR-Users] BYE Race Condition
In-Reply-To: <CACr1DbCJ+9mvtGNgev+xrAPaGg3K4nuqzeAf6RsB7FEvfAJ7hg@mail.gmail.com>
References: <CACr1DbCJ+9mvtGNgev+xrAPaGg3K4nuqzeAf6RsB7FEvfAJ7hg@mail.gmail.com>
Message-ID: <50163FBF.4000400@gmail.com>
Hello,
first, such race can happen always and it is ok from sip rfc point of
view. The carrier UA should have received the BYE from the other side
and close the dialog, then ignore the rest. So it is a broken UA
implementation imo.
Let's say you just drop the 481, then the BYE will time out (408)? Is
the carrier UA still complaining? You can make a failure route for BYE
and if it is 481, then use t_reply("408", "Timeout") if that makes the
UA happier.
Cheers,
Daniel
On 7/28/12 8:42 PM, Brandon Armstead wrote:
> Hello,
>
> I am running into an issue where there is a race condition
> happening. I am looking for opinions / ideas on how to handle the
> following below scenario.
>
> Scenario.
>
> UAC places an outbound call -> upstream carrier.
>
> The call is disconnected on both ends at the exact same time,
>
> UAC -> sends BYE upstream
>
> Upstream Carrier -> sends BYE downstream
>
> Upstream 200 OK's the BYE
>
> UAC sends 481 back to Upstream Carrier for their generated BYE.
>
> The upstream carrier is complaining about receiving the relayed 481
> responses -- so my first thought was simply to drop() these from
> relaying upstream.
>
> I am curious how other people are handling this?
>
> Would you suggest simply dropping the relay from being sent back
> upstream on the 481?
>
> Would you simply always 200 OK a downstream BYE from trusted carriers
> regardless of UAC response, and create separate transaction to send
> BYE downstream?
>
> Thank you as always. Look forward to your thoughts / suggestions / ideas.
>
> Sincerely,
> Brandon Armstead
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/e044bc94/attachment-0001.htm>
From miconda at gmail.com Mon Jul 30 10:06:00 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 10:06:00 +0200
Subject: [SR-Users] Error 403 not relaying
In-Reply-To: <CAE1B-ryhb0_h1nY8A2+PVh7b59a1FDNsDLU0pQoCDnwfA3ob3w@mail.gmail.com>
References: <CAE1B-ryhb0_h1nY8A2+PVh7b59a1FDNsDLU0pQoCDnwfA3ob3w@mail.gmail.com>
Message-ID: <50164068.3050200@gmail.com>
Hello,
if your config is based on the default one, the 403 not relaying is sent
when both caller and callee are not local users, preventing the proxy to
act as an open relay and be abused to do attacks.
So, first, be sure you have the domains you serve as aliases to match
the myself condition.
Cheers,
Daniel
On 7/28/12 2:25 PM, Tayeb Meftah wrote:
> hello,
> i'm using Kamailio with a simple registrare configuration
> i used the apt repository to install the developmant package of kamailio
> domain sip.tmvoip.net have 2 records, A record and AAA record (dual stacked)
> i configured it in my kamailio using siremis and in the kamctlrc
> config below:
> Kamailio.cfg: http://paste.debian.net/180972/
> Kamctlrc: http://paste.debian.net/180973/
> siptrace: http://paste.debian.net/180974/
> note that 172.28.0.0/21 and 41.221.20.12/30 is routed, no nat.
> my current issue is if i register or i invite, i get error 403 not relaying
> trying to investigate this issu but i have no clue
> thank you everyone,
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Mon Jul 30 10:10:46 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 10:10:46 +0200
Subject: [SR-Users] Can't initialize shared memory
In-Reply-To: <CAMMbDhTmH6XaCaH0anAOqqOJhZmv=gzuTJsNGvj94A4mh=qrFQ@mail.gmail.com>
References: <CAMMbDhT73TGdwP=ofMdp+fv2cq_nEwC2hnkFcy8XMxS074O3ZQ@mail.gmail.com>
<CAMMbDhTmH6XaCaH0anAOqqOJhZmv=gzuTJsNGvj94A4mh=qrFQ@mail.gmail.com>
Message-ID: <50164186.2010109@gmail.com>
Hello,
these are only the error messages, with debug=4, there should be lot of
DEBUG messages that will help to see what parts of code were loaded.
Cheers,
Daniel
On 7/24/12 9:30 AM, Uri Shacked wrote:
>
> this is the log when debug is 4...
> Jul 24 10:19:37 RNDSRV kamailio: : <core> [cfg.y:3532]: parse
> error in config file /usr/local/etc/kamailio/global_params.cfg,
> line 121, column 54: Can't initialize shared memory
> Jul 24 10:19:37 RNDSRV kamailio: ERROR: mi_fifo [mi_fifo.c:271]:
> FIFO stat failed: Bad address
> not much.
> line 121 on the file is the modparam for mi_fifo indication the
> /tmp/kamailio_fifo file.
> # ----- mi_fifo params -----
> modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")
> any ideas?
>
>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/f5e1ffe9/attachment.htm>
From dnotivol at gmail.com Mon Jul 30 10:35:39 2012
From: dnotivol at gmail.com (David Notivol)
Date: Mon, 30 Jul 2012 10:35:39 +0200
Subject: [SR-Users] ACK not relayed
In-Reply-To: <50163D97.9000805@gmail.com>
References: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
<50163D97.9000805@gmail.com>
Message-ID: <CAOHrEOAuSfOuB7GCMYj2zONcDj9rzXd-k-8hEOZDKKbaqTLmYQ@mail.gmail.com>
Hi Daniel,
This is the ACK message:
U 2012/07/30 04:23:31.604721 79.170.68.151:5060 -> 79.170.68.157:5060
ACK sip:200.87.137.150:5060;user=phone SIP/2.0.
Via: SIP/2.0/UDP 79.170.68.151:5060
;branch=z9hG4bK334faa4497ll114a52eACK450932302031.
Max-Forwards: 70.
Route: <sip:79.170.68.157;lr;ftag=45093230-co8241-INS033>.
To: <sip:59146292331 at 79.170.68.157
;user=phone;noa=international>;tag=ldb0cbn6-CC-23.
From: "Javi Gallart"<sip:34917019888 at 79.170.68.151
;user=phone;noa=national>;tag=45093230-co8241-INS033.
Call-ID: 071ae17301d3eb470f5cdde00cd9b24b at ens.com.
CSeq: 824101 ACK.
User-Agent: ENSR3.0.66.34-IS33-RMRG106382-RG105488-CPO13110.
Content-Length: 0.
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> can you add a log message to print the source ip, call id and r-uri?
>
> It may happen that the ACK is looping back if r-uri is pointing to itself.
>
> Also, try to get the ngrep on all devices, like:
>
> ngrep -d any -qt -W byline port 5060
>
> Pasting the ACK request here will help to see if something is wrong with
> it.
>
> Cheers,
> Daniel
>
>
> On 7/30/12 8:53 AM, David Notivol wrote:
>
> In a UAC-Kamailio-UAS scenario, we've found a case where the ACK coming
> from uac is not relayed by our proxy to the uas. This is the log for the
> ACK message:
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:624]: SIP Request:
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:626]: method: <ACK>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:628]: uri: <sip:59138553189 at 79.170.68.157><sip:59138553189 at 79.170.68.157>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:630]: version: <SIP/2.0>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>; state=6
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_via.c:1286]: Found param type 232, <branch> =
> <z9hG4bKKc4gKXyemS9HD>; state=16
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_via.c:2561]: end of header reached, state=5
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:513]: parse_headers: this is the first via
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:149]:
> After parse_msg...
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:190]:
> preparing to run routing scripts...
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl [sl_funcs.c:396]: DEBUG
> : sl_filter_ACK: to late to be a local ACK!
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd [mf_funcs.c:85]:
> value = 65
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_to.c:802]: end of header reached, state=29
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52]; uri=[
> sip:59138553189 at 79.170.68.157]
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:190]: DEBUG: to body [<sip:59138553189 at 79.170.68.157><sip:59138553189 at 79.170.68.157>]
>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <31362871> <ACK>
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=0
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/msg_parser.c:104]: found end of header
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
> [parser/parse_to.c:802]: end of header reached, state=29
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity [mod_sanity.c:255]:
> sanity checks result: 1
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: siputils [checks.c:106]:
> totag found
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: ESTAMOS EN
> WITHIN
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:108]: No Route
> headers found
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:829]: There is
> no Route HF
> Jul 27 10:04:59 theseus-test
> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: NO LOOSE ROUTE
>
> However, in a pcap trace I clearly see the Route header:
> This is the Record-Route in the 200 message
> Record-Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
> And this is the Route header in the ACk:
> Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>
> I haven't been able to figure out what's going on. We have plenty of
> traffic working in that proxy. What am I missing?
>
> Thanks in advance
> David.
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/1a1a8d95/attachment-0001.htm>
From miconda at gmail.com Mon Jul 30 10:49:02 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 10:49:02 +0200
Subject: [SR-Users] ACK not relayed
In-Reply-To: <CAOHrEOAuSfOuB7GCMYj2zONcDj9rzXd-k-8hEOZDKKbaqTLmYQ@mail.gmail.com>
References: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
<50163D97.9000805@gmail.com>
<CAOHrEOAuSfOuB7GCMYj2zONcDj9rzXd-k-8hEOZDKKbaqTLmYQ@mail.gmail.com>
Message-ID: <50164A7E.2060905@gmail.com>
Hello,
if your config is based on the default one, there is a check for
associated INVITE transaction and if that does not exist, then the ACK
is droppend.
You can use debugger module with cfgtrace set on in order to see what
actions in the config file are executed. That will help to see if it
gets to t_check_trans() and then exit.
Cheers,
Daniel
On 7/30/12 10:35 AM, David Notivol wrote:
> Hi Daniel,
>
> This is the ACK message:
>
> U 2012/07/30 04:23:31.604721 79.170.68.151:5060
> <http://79.170.68.151:5060> -> 79.170.68.157:5060
> <http://79.170.68.157:5060>
> ACK sip:200.87.137.150:5060;user=phone SIP/2.0.
> Via: SIP/2.0/UDP
> 79.170.68.151:5060;branch=z9hG4bK334faa4497ll114a52eACK450932302031.
> Max-Forwards: 70.
> Route: <sip:79.170.68.157;lr;ftag=45093230-co8241-INS033>.
> To: <sip:59146292331 at 79.170.68.157
> <mailto:sip%3A59146292331 at 79.170.68.157>;user=phone;noa=international>;tag=ldb0cbn6-CC-23.
> From: "Javi Gallart"<sip:34917019888 at 79.170.68.151
> <mailto:sip%3A34917019888 at 79.170.68.151>;user=phone;noa=national>;tag=45093230-co8241-INS033.
> Call-ID: 071ae17301d3eb470f5cdde00cd9b24b at ens.com
> <mailto:071ae17301d3eb470f5cdde00cd9b24b at ens.com>.
> CSeq: 824101 ACK.
> User-Agent: ENSR3.0.66.34-IS33-RMRG106382-RG105488-CPO13110.
> Content-Length: 0.
>
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> can you add a log message to print the source ip, call id and r-uri?
>
> It may happen that the ACK is looping back if r-uri is pointing to
> itself.
>
> Also, try to get the ngrep on all devices, like:
>
> ngrep -d any -qt -W byline port 5060
>
> Pasting the ACK request here will help to see if something is
> wrong with it.
>
> Cheers,
> Daniel
>
>
> On 7/30/12 8:53 AM, David Notivol wrote:
>> In a UAC-Kamailio-UAS scenario, we've found a case where the ACK
>> coming from uac is not relayed by our proxy to the uas. This is
>> the log for the ACK message:
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:624]: SIP Request:
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:626]: method: <ACK>
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:628]: uri: <sip:59138553189 at 79.170.68.157>
>> <mailto:sip:59138553189 at 79.170.68.157>
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:630]: version: <SIP/2.0>
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>;
>> state=6
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_via.c:1286]: Found param type 232, <branch> =
>> <z9hG4bKKc4gKXyemS9HD>; state=16
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_via.c:2561]: end of header reached, state=5
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:513]: parse_headers: this is the first via
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [receive.c:149]: After parse_msg...
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [receive.c:190]: preparing to run routing scripts...
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl
>> [sl_funcs.c:396]: DEBUG : sl_filter_ACK: to late to be a local ACK!
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd
>> [mf_funcs.c:85]: value = 65
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_to.c:802]: end of header reached, state=29
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52];
>> uri=[sip:59138553189 at 79.170.68.157
>> <mailto:sip:59138553189 at 79.170.68.157>]
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:190]: DEBUG: to body
>> [<sip:59138553189 at 79.170.68.157>
>> <mailto:sip:59138553189 at 79.170.68.157>]
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <31362871>
>> <ACK>
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=0
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:104]: found end of header
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_to.c:802]: end of header reached, state=29
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity
>> [mod_sanity.c:255]: sanity checks result: 1
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: siputils
>> [checks.c:106]: totag found
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>:
>> ESTAMOS EN WITHIN
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr
>> [loose.c:108]: No Route headers found
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr
>> [loose.c:829]: There is no Route HF
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: NO
>> LOOSE ROUTE
>>
>> However, in a pcap trace I clearly see the Route header:
>> This is the Record-Route in the 200 message
>> Record-Route:
>> <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>> And this is the Route header in the ACk:
>> Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>
>> I haven't been able to figure out what's going on. We have plenty
>> of traffic working in that proxy. What am I missing?
>>
>> Thanks in advance
>> David.
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/345cde2a/attachment.htm>
From rzheng at gmail.com Mon Jul 30 10:56:21 2012
From: rzheng at gmail.com (Richard Zheng)
Date: Sun, 29 Jul 2012 22:56:21 -1000
Subject: [SR-Users] routing based on username
Message-ID: <CACcFbj4NVQ_c1qAcrF1qcvOaovp28aSd2BR-9ZhDg_m2FWHJVA@mail.gmail.com>
Hi,
We are trying to follow
http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdbto
setup Kamailio as front end and multiple PBXs as back end.
We need to forward sip messages to the respective servers based on the
contact. For example, users 101, 102 go to PBX at 1.1.1.1 and users 201,
202 go to PBX at 1.1.1.2. Where is a good place to save this info and how
to route them in the config?
Also we have some users with fixed IP addresses which don't use
authentication. How do we route the calls based on source IP? Since we
have plenty of these users, we'd like to save them in database too.
Any advice is appreciated!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120729/e7949db8/attachment-0001.htm>
From dnotivol at gmail.com Mon Jul 30 11:10:14 2012
From: dnotivol at gmail.com (David Notivol)
Date: Mon, 30 Jul 2012 11:10:14 +0200
Subject: [SR-Users] ACK not relayed
In-Reply-To: <50164A7E.2060905@gmail.com>
References: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
<50163D97.9000805@gmail.com>
<CAOHrEOAuSfOuB7GCMYj2zONcDj9rzXd-k-8hEOZDKKbaqTLmYQ@mail.gmail.com>
<50164A7E.2060905@gmail.com>
Message-ID: <CAOHrEOBXNS2hbYZbMC=qspi0yCgkDr6MWj3xDmwhG9aUhw2dwg@mail.gmail.com>
This is the code that's being executed:
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
xlog("ESTAMOS EN WITHIN\n");
if (loose_route()){
xlog("LOOSE ROUTE DETECTED\n");
if (is_method("ACK")) {
xlog("ES UN ACK\n");
}
route(BYE);
route(RELAY);
} else {
xlog("NO LOOSE ROUTE\n");
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
xlog("NO LOOSE AND TRANSACTION FOUND\n");
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
t_relay();
exit;
} else {
xlog("NO LOOSE AND TRANSACTION NOT FOUND\n");
# ACK without matching transaction ... ignore and
discard
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
}
And the call log with cfgtrace. It seems to be clear that the transaction
is not matched, but we can't see why.
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=335 a=26
n=xlog
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
<script>: ESTAMOS EN WITHIN
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=360 a=17
n=if
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=336 a=25
n=loose_route
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: DEBUG:
rr [loose.c:108]: No Route headers found
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: DEBUG:
rr [loose.c:838]: There is no Route HF
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=344 a=26
n=xlog
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
<script>: NO LOOSE ROUTE
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=359 a=17
n=if
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=345 a=26
n=is_method
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=357 a=17
n=if
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=346 a=25
n=t_check_trans
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: DEBUG:
tm [t_lookup.c:1079]: DEBUG: t_check_msg: msg id=12 global id=10 T
start=(nil)
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: DEBUG:
tm [t_lookup.c:527]: t_lookup_request: start searching: hash=58737, isACK=1
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: DEBUG:
tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: DEBUG:
tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: DEBUG:
tm [t_lookup.c:1148]: DEBUG: t_check_msg: msg id=12 global id=12 T
end=(nil)
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=354 a=26
n=xlog
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
<script>: NO LOOSE AND TRANSACTION NOT FOUND
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: ERROR:
*** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=356 a=3
n=exit
Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]: DEBUG:
<core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> if your config is based on the default one, there is a check for
> associated INVITE transaction and if that does not exist, then the ACK is
> droppend.
>
> You can use debugger module with cfgtrace set on in order to see what
> actions in the config file are executed. That will help to see if it gets
> to t_check_trans() and then exit.
>
> Cheers,
> Daniel
>
>
> On 7/30/12 10:35 AM, David Notivol wrote:
>
> Hi Daniel,
>
> This is the ACK message:
>
> U 2012/07/30 04:23:31.604721 79.170.68.151:5060 -> 79.170.68.157:5060
> ACK sip:200.87.137.150:5060;user=phone SIP/2.0.
> Via: SIP/2.0/UDP 79.170.68.151:5060
> ;branch=z9hG4bK334faa4497ll114a52eACK450932302031.
> Max-Forwards: 70.
> Route: <sip:79.170.68.157;lr;ftag=45093230-co8241-INS033>.
> To: <sip:59146292331 at 79.170.68.157
> ;user=phone;noa=international>;tag=ldb0cbn6-CC-23.
> From: "Javi Gallart"<sip:34917019888 at 79.170.68.151
> ;user=phone;noa=national>;tag=45093230-co8241-INS033.
> Call-ID: 071ae17301d3eb470f5cdde00cd9b24b at ens.com.
> CSeq: 824101 ACK.
> User-Agent: ENSR3.0.66.34-IS33-RMRG106382-RG105488-CPO13110.
> Content-Length: 0.
>
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>
>> Hello,
>>
>> can you add a log message to print the source ip, call id and r-uri?
>>
>> It may happen that the ACK is looping back if r-uri is pointing to itself.
>>
>> Also, try to get the ngrep on all devices, like:
>>
>> ngrep -d any -qt -W byline port 5060
>>
>> Pasting the ACK request here will help to see if something is wrong with
>> it.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/30/12 8:53 AM, David Notivol wrote:
>>
>> In a UAC-Kamailio-UAS scenario, we've found a case where the ACK coming
>> from uac is not relayed by our proxy to the uas. This is the log for the
>> ACK message:
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:624]: SIP Request:
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:626]: method: <ACK>
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:628]: uri: <sip:59138553189 at 79.170.68.157><sip:59138553189 at 79.170.68.157>
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:630]: version: <SIP/2.0>
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>; state=6
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_via.c:1286]: Found param type 232, <branch> =
>> <z9hG4bKKc4gKXyemS9HD>; state=16
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_via.c:2561]: end of header reached, state=5
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:513]: parse_headers: this is the first via
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:149]:
>> After parse_msg...
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:190]:
>> preparing to run routing scripts...
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl [sl_funcs.c:396]: DEBUG
>> : sl_filter_ACK: to late to be a local ACK!
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd [mf_funcs.c:85]:
>> value = 65
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_to.c:802]: end of header reached, state=29
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52]; uri=[
>> sip:59138553189 at 79.170.68.157]
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:190]: DEBUG: to body [
>> <sip:59138553189 at 79.170.68.157> <sip:59138553189 at 79.170.68.157>]
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <31362871> <ACK>
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=0
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/msg_parser.c:104]: found end of header
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>> [parser/parse_to.c:802]: end of header reached, state=29
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity [mod_sanity.c:255]:
>> sanity checks result: 1
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: siputils [checks.c:106]:
>> totag found
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: ESTAMOS EN
>> WITHIN
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:108]: No Route
>> headers found
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:829]: There is
>> no Route HF
>> Jul 27 10:04:59 theseus-test
>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: NO LOOSE ROUTE
>>
>> However, in a pcap trace I clearly see the Route header:
>> This is the Record-Route in the 200 message
>> Record-Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>> And this is the Route header in the ACk:
>> Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>
>> I haven't been able to figure out what's going on. We have plenty of
>> traffic working in that proxy. What am I missing?
>>
>> Thanks in advance
>> David.
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
--
Saludos,
David Notivol
dnotivol at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/b5cc833b/attachment-0001.htm>
From tayeb at vobradio.org Mon Jul 30 11:27:17 2012
From: tayeb at vobradio.org (Tayeb)
Date: Mon, 30 Jul 2012 10:27:17 +0100
Subject: [SR-Users] Error 403 not relaying
In-Reply-To: <50164068.3050200@gmail.com>
References: <CAE1B-ryhb0_h1nY8A2+PVh7b59a1FDNsDLU0pQoCDnwfA3ob3w@mail.gmail.com>
<50164068.3050200@gmail.com>
Message-ID: <C4E2EF57-5F9C-44DE-B09E-0568A4650896@vobradio.org>
Domain added
But same
Envoy? de mon iPhone
Le 30 juil. 2012 ? 09:06, Daniel-Constantin Mierla <miconda at gmail.com> a ?crit :
> Hello,
>
> if your config is based on the default one, the 403 not relaying is sent when both caller and callee are not local users, preventing the proxy to act as an open relay and be abused to do attacks.
>
> So, first, be sure you have the domains you serve as aliases to match the myself condition.
>
> Cheers,
> Daniel
>
> On 7/28/12 2:25 PM, Tayeb Meftah wrote:
>> hello,
>> i'm using Kamailio with a simple registrare configuration
>> i used the apt repository to install the developmant package of kamailio
>> domain sip.tmvoip.net have 2 records, A record and AAA record (dual stacked)
>> i configured it in my kamailio using siremis and in the kamctlrc
>> config below:
>> Kamailio.cfg: http://paste.debian.net/180972/
>> Kamctlrc: http://paste.debian.net/180973/
>> siptrace: http://paste.debian.net/180974/
>> note that 172.28.0.0/21 and 41.221.20.12/30 is routed, no nat.
>> my current issue is if i register or i invite, i get error 403 not relaying
>> trying to investigate this issu but i have no clue
>> thank you everyone,
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
From miconda at gmail.com Mon Jul 30 11:38:37 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 11:38:37 +0200
Subject: [SR-Users] ACK not relayed
In-Reply-To: <CAOHrEOBXNS2hbYZbMC=qspi0yCgkDr6MWj3xDmwhG9aUhw2dwg@mail.gmail.com>
References: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
<50163D97.9000805@gmail.com>
<CAOHrEOAuSfOuB7GCMYj2zONcDj9rzXd-k-8hEOZDKKbaqTLmYQ@mail.gmail.com>
<50164A7E.2060905@gmail.com>
<CAOHrEOBXNS2hbYZbMC=qspi0yCgkDr6MWj3xDmwhG9aUhw2dwg@mail.gmail.com>
Message-ID: <5016561D.9060202@gmail.com>
Hello,
the log message shows that the transaction is not found. Is the ACK
coming late after 200ok ? There is a tm module parameter that you can
adjust to prolong the time a transaction is kept after completion, if
that is the case.
Also, be sure the INVITE is sent using tm functions, not stateless via
core function.
Then, instead of dropping, you can just try forwarding it if the uri si
not myself, like adding:
if(uri!=myself) t_relay();
before the exit.
Cheers,
Daniel
On 7/30/12 11:10 AM, David Notivol wrote:
> This is the code that's being executed:
>
> route[WITHINDLG] {
> if (has_totag()) {
> # sequential request withing a dialog should
> # take the path determined by record-routing
> xlog("ESTAMOS EN WITHIN\n");
> if (loose_route()){
> xlog("LOOSE ROUTE DETECTED\n");
> if (is_method("ACK")) {
> xlog("ES UN ACK\n");
> }
> route(BYE);
> route(RELAY);
> } else {
> xlog("NO LOOSE ROUTE\n");
> if ( is_method("ACK") ) {
> if ( t_check_trans() ) {
> xlog("NO LOOSE AND TRANSACTION FOUND\n");
> # no loose-route, but stateful ACK;
> # must be an ACK after a 487
> # or e.g. 404 from upstream server
> t_relay();
> exit;
> } else {
> xlog("NO LOOSE AND TRANSACTION NOT FOUND\n");
> # ACK without matching transaction ... ignore and
> discard
> exit;
> }
> }
> sl_send_reply("404","Not here");
> }
> exit;
> }
> }
>
>
> And the call log with cfgtrace. It seems to be clear that the
> transaction is not matched, but we can't see why.
>
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=335 a=26 n=xlog
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: <script>: ESTAMOS EN WITHIN
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=360 a=17 n=if
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=336 a=25 n=loose_route
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: rr [loose.c:108]: No Route headers found
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: rr [loose.c:838]: There is no Route HF
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=344 a=26 n=xlog
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: <script>: NO LOOSE ROUTE
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=359 a=17 n=if
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=345 a=26 n=is_method
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=357 a=17 n=if
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=346 a=25 n=t_check_trans
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:1079]: DEBUG: t_check_msg: msg id=12 global
> id=10 T start=(nil)
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching:
> hash=58737, isACK=1
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:1148]: DEBUG: t_check_msg: msg id=12 global
> id=12 T end=(nil)
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=354 a=26 n=xlog
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: <script>: NO LOOSE AND TRANSACTION NOT FOUND
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=356 a=3 n=exit
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list
> (nil)
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> if your config is based on the default one, there is a check for
> associated INVITE transaction and if that does not exist, then the
> ACK is droppend.
>
> You can use debugger module with cfgtrace set on in order to see
> what actions in the config file are executed. That will help to
> see if it gets to t_check_trans() and then exit.
>
> Cheers,
> Daniel
>
>
> On 7/30/12 10:35 AM, David Notivol wrote:
>> Hi Daniel,
>>
>> This is the ACK message:
>>
>> U 2012/07/30 04:23:31.604721 79.170.68.151:5060
>> <http://79.170.68.151:5060> -> 79.170.68.157:5060
>> <http://79.170.68.157:5060>
>> ACK sip:200.87.137.150:5060;user=phone SIP/2.0.
>> Via: SIP/2.0/UDP
>> 79.170.68.151:5060;branch=z9hG4bK334faa4497ll114a52eACK450932302031.
>> Max-Forwards: 70.
>> Route: <sip:79.170.68.157;lr;ftag=45093230-co8241-INS033>.
>> To: <sip:59146292331 at 79.170.68.157
>> <mailto:sip%3A59146292331 at 79.170.68.157>;user=phone;noa=international>;tag=ldb0cbn6-CC-23.
>> From: "Javi Gallart"<sip:34917019888 at 79.170.68.151
>> <mailto:sip%3A34917019888 at 79.170.68.151>;user=phone;noa=national>;tag=45093230-co8241-INS033.
>> Call-ID: 071ae17301d3eb470f5cdde00cd9b24b at ens.com
>> <mailto:071ae17301d3eb470f5cdde00cd9b24b at ens.com>.
>> CSeq: 824101 ACK.
>> User-Agent: ENSR3.0.66.34-IS33-RMRG106382-RG105488-CPO13110.
>> Content-Length: 0.
>>
>>
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>>
>>
>> Hello,
>>
>> can you add a log message to print the source ip, call id and
>> r-uri?
>>
>> It may happen that the ACK is looping back if r-uri is
>> pointing to itself.
>>
>> Also, try to get the ngrep on all devices, like:
>>
>> ngrep -d any -qt -W byline port 5060
>>
>> Pasting the ACK request here will help to see if something is
>> wrong with it.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/30/12 8:53 AM, David Notivol wrote:
>>> In a UAC-Kamailio-UAS scenario, we've found a case where the
>>> ACK coming from uac is not relayed by our proxy to the uas.
>>> This is the log for the ACK message:
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:624]: SIP Request:
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:626]: method: <ACK>
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:628]: uri:
>>> <sip:59138553189 at 79.170.68.157>
>>> <mailto:sip:59138553189 at 79.170.68.157>
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:630]: version: <SIP/2.0>
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_via.c:1286]: Found param type 235, <rport> =
>>> <n/a>; state=6
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_via.c:1286]: Found param type 232, <branch> =
>>> <z9hG4bKKc4gKXyemS9HD>; state=16
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_via.c:2561]: end of header reached, state=5
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:513]: parse_headers: this is the first via
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [receive.c:149]: After parse_msg...
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [receive.c:190]: preparing to run routing scripts...
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl
>>> [sl_funcs.c:396]: DEBUG : sl_filter_ACK: to late to be a
>>> local ACK!
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd
>>> [mf_funcs.c:85]: value = 65
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_to.c:802]: end of header reached, state=29
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52];
>>> uri=[sip:59138553189 at 79.170.68.157
>>> <mailto:sip:59138553189 at 79.170.68.157>]
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:190]: DEBUG: to body
>>> [<sip:59138553189 at 79.170.68.157>
>>> <mailto:sip:59138553189 at 79.170.68.157>]
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>:
>>> <31362871> <ACK>
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:202]: DEBUG: get_hdr_body :
>>> content_length=0
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:104]: found end of header
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_to.c:802]: end of header reached, state=29
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity
>>> [mod_sanity.c:255]: sanity checks result: 1
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: siputils
>>> [checks.c:106]: totag found
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>:
>>> ESTAMOS EN WITHIN
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr
>>> [loose.c:108]: No Route headers found
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr
>>> [loose.c:829]: There is no Route HF
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>:
>>> NO LOOSE ROUTE
>>>
>>> However, in a pcap trace I clearly see the Route header:
>>> This is the Record-Route in the 200 message
>>> Record-Route:
>>> <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>> And this is the Route header in the ACk:
>>> Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>>
>>> I haven't been able to figure out what's going on. We have
>>> plenty of traffic working in that proxy. What am I missing?
>>>
>>> Thanks in advance
>>> David.
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>>
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
>
>
> --
> Saludos,
> David Notivol
> dnotivol at gmail.com <mailto:dnotivol at gmail.com>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/48ab69b2/attachment-0001.htm>
From miconda at gmail.com Mon Jul 30 11:39:52 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 11:39:52 +0200
Subject: [SR-Users] Error 403 not relaying
In-Reply-To: <C4E2EF57-5F9C-44DE-B09E-0568A4650896@vobradio.org>
References: <CAE1B-ryhb0_h1nY8A2+PVh7b59a1FDNsDLU0pQoCDnwfA3ob3w@mail.gmail.com>
<50164068.3050200@gmail.com>
<C4E2EF57-5F9C-44DE-B09E-0568A4650896@vobradio.org>
Message-ID: <50165668.10803@gmail.com>
Enable debugger module with cfgtrace and see what actions of your config
file are executed. Maybe there is a mistake in your routing logic.
Cheers,
Daniel
On 7/30/12 11:27 AM, Tayeb wrote:
> Domain added
> But same
> Envoy? de mon iPhone
>
> Le 30 juil. 2012 ? 09:06, Daniel-Constantin Mierla <miconda at gmail.com> a ?crit :
>
>> Hello,
>>
>> if your config is based on the default one, the 403 not relaying is sent when both caller and callee are not local users, preventing the proxy to act as an open relay and be abused to do attacks.
>>
>> So, first, be sure you have the domains you serve as aliases to match the myself condition.
>>
>> Cheers,
>> Daniel
>>
>> On 7/28/12 2:25 PM, Tayeb Meftah wrote:
>>> hello,
>>> i'm using Kamailio with a simple registrare configuration
>>> i used the apt repository to install the developmant package of kamailio
>>> domain sip.tmvoip.net have 2 records, A record and AAA record (dual stacked)
>>> i configured it in my kamailio using siremis and in the kamctlrc
>>> config below:
>>> Kamailio.cfg: http://paste.debian.net/180972/
>>> Kamctlrc: http://paste.debian.net/180973/
>>> siptrace: http://paste.debian.net/180974/
>>> note that 172.28.0.0/21 and 41.221.20.12/30 is routed, no nat.
>>> my current issue is if i register or i invite, i get error 403 not relaying
>>> trying to investigate this issu but i have no clue
>>> thank you everyone,
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Mon Jul 30 12:06:58 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 12:06:58 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
Message-ID: <50165CC2.7050400@gmail.com>
Hello,
can you send the requests for registration and re-registration (ngrep
with -W byline or pcap) in order to test them here? I tried to reproduce
with an UA I have here and the registration update does the right thing.
Cheers,
Daniel
On 7/27/12 1:43 PM, Jos? Luis Mill?n wrote:
> Yes,
>
> Verified, 'gruu_enabled' is set to one.
>
> Regards
>
> 2012/7/27 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> just to be sure before going to any further investigation (as I
> remember, such case I tested a bit with some command line tools
> due to lack of a sip phone with good ob/gruu support), do you have
> in the config:
>
> modparam("registrar", "gruu_enabled", 1)
>
> The default config file in 3.3, has the parameter set to 0.
>
> Cheers,
> Daniel
>
>
> On 7/27/12 10:05 AM, I?aki Baz Castillo wrote:
>
> Hi, full agree with this bug report. Adding the devel
> maillist. More
> comments at the end of the mail:
>
>
> 2012/7/26 Jos? Luis Mill?n <jmillan at aliax.net
> <mailto:jmillan at aliax.net>>:
>
> Hi,
>
> I'm using Kamilio 3.3.0 as registrar server. I`m using an
> outbound proxy so
> 'use_path' parameter or 'registrar' module is enabled.
>
> According to RFC 5626, a re-registration from a specific
> combination of AoR,
> instance_id and reg_id must update the binding.
>
> ""
> If the registrar receives a re-registration for a specific
> combination of AOR, and instance-id and reg-id values,
> the registrar
> MUST update any information that uniquely identifies
> the network flow
> over which the request arrived if that information has
> changed, and
> SHOULD update the time the binding was last updated.
> ""
>
> In my installation this is not fullfilled as shown:
>
> ""
> AOR:: jmillan
> Contact::
> sip:jmillan at MY_IP;transport=ws;ov-ob=a570655c14 Q=
> Expires:: 181
> Callid:: 1hgq3khalq2rzfr
> Cseq:: 108
> User-agent:: JsSIP 0.1.0
> Path::
> <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:a570655c14 at OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
> State:: CS_SYNC
> Flags:: 0
> Cflag:: 0
> Socket:: tcp:KAM_IP:5060
> Methods:: 783
> Ruid:: uloc-50119d99-328e-1
> Instance::
> <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
> Reg-Id:: 1
> Contact::
> sip:jmillan at MY_IP;transport=ws;ov-ob=1dd97b4d51 Q=
> Expires:: 193
> Callid:: 1hgq3khalq2rzfr
> Cseq:: 110
> User-agent:: JsSIP 0.1.0
> Path::
> <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:1dd97b4d51 at OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
> State:: CS_SYNC
> Flags:: 0
> Cflag:: 0
> Socket:: tcp:KAM_IP:5060
> Methods:: 783
> Ruid:: uloc-50119d99-3290-2
> Instance::
> <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
> Reg-Id:: 1
> ""
>
> The scenario is such that when the client looses the
> connection with the
> Outbound Server, it reconnects and re-registers to
> Kamailio in order to
> replace registration and be able to receive in-dialog
> messages.
>
> Receiving in-dialog requests should work since GRUU is also being
> used. The problem is that the new REGISTER (after UA
> disconnection)
> does not update the previous one (as this thread reports) so
> Kamailio
> still chooses the previous binding which does not work anymore.
>
>
> Regards.
>
>
>
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
> http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> sr-users at lists.sip-router.org <mailto:sr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/eff27fe2/attachment.htm>
From miconda at gmail.com Mon Jul 30 13:29:08 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 13:29:08 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <50165CC2.7050400@gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com>
Message-ID: <50167004.7060301@gmail.com>
After playing a bit more with it, I pushed some commits on master
branch. Can you try to see if they fixed the issue you reported?
Cheers,
Daniel
On 7/30/12 12:06 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> can you send the requests for registration and re-registration (ngrep
> with -W byline or pcap) in order to test them here? I tried to
> reproduce with an UA I have here and the registration update does the
> right thing.
>
> Cheers,
> Daniel
>
> On 7/27/12 1:43 PM, Jos? Luis Mill?n wrote:
>> Yes,
>>
>> Verified, 'gruu_enabled' is set to one.
>>
>> Regards
>>
>> 2012/7/27 Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>>
>>
>> Hello,
>>
>> just to be sure before going to any further investigation (as I
>> remember, such case I tested a bit with some command line tools
>> due to lack of a sip phone with good ob/gruu support), do you
>> have in the config:
>>
>> modparam("registrar", "gruu_enabled", 1)
>>
>> The default config file in 3.3, has the parameter set to 0.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/27/12 10:05 AM, I?aki Baz Castillo wrote:
>>
>> Hi, full agree with this bug report. Adding the devel
>> maillist. More
>> comments at the end of the mail:
>>
>>
>> 2012/7/26 Jos? Luis Mill?n <jmillan at aliax.net
>> <mailto:jmillan at aliax.net>>:
>>
>> Hi,
>>
>> I'm using Kamilio 3.3.0 as registrar server. I`m using
>> an outbound proxy so
>> 'use_path' parameter or 'registrar' module is enabled.
>>
>> According to RFC 5626, a re-registration from a specific
>> combination of AoR,
>> instance_id and reg_id must update the binding.
>>
>> ""
>> If the registrar receives a re-registration for a
>> specific
>> combination of AOR, and instance-id and reg-id
>> values, the registrar
>> MUST update any information that uniquely identifies
>> the network flow
>> over which the request arrived if that information
>> has changed, and
>> SHOULD update the time the binding was last updated.
>> ""
>>
>> In my installation this is not fullfilled as shown:
>>
>> ""
>> AOR:: jmillan
>> Contact::
>> sip:jmillan at MY_IP;transport=ws;ov-ob=a570655c14 Q=
>> Expires:: 181
>> Callid:: 1hgq3khalq2rzfr
>> Cseq:: 108
>> User-agent:: JsSIP 0.1.0
>> Path::
>> <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:a570655c14 at OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 0
>> Socket:: tcp:KAM_IP:5060
>> Methods:: 783
>> Ruid:: uloc-50119d99-328e-1
>> Instance::
>> <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
>> Reg-Id:: 1
>> Contact::
>> sip:jmillan at MY_IP;transport=ws;ov-ob=1dd97b4d51 Q=
>> Expires:: 193
>> Callid:: 1hgq3khalq2rzfr
>> Cseq:: 110
>> User-agent:: JsSIP 0.1.0
>> Path::
>> <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:1dd97b4d51 at OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 0
>> Socket:: tcp:KAM_IP:5060
>> Methods:: 783
>> Ruid:: uloc-50119d99-3290-2
>> Instance::
>> <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
>> Reg-Id:: 1
>> ""
>>
>> The scenario is such that when the client looses the
>> connection with the
>> Outbound Server, it reconnects and re-registers to
>> Kamailio in order to
>> replace registration and be able to receive in-dialog
>> messages.
>>
>> Receiving in-dialog requests should work since GRUU is also being
>> used. The problem is that the new REGISTER (after UA
>> disconnection)
>> does not update the previous one (as this thread reports) so
>> Kamailio
>> still chooses the previous binding which does not work anymore.
>>
>>
>> Regards.
>>
>>
>>
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
>> http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
>> http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
>> http://asipto.com/u/kpw
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/69fd1b6b/attachment-0001.htm>
From bruno.bresciani at gmail.com Mon Jul 30 13:44:55 2012
From: bruno.bresciani at gmail.com (Bruno Bresciani)
Date: Mon, 30 Jul 2012 08:44:55 -0300
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <50163CE8.2050903@gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
<CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
<50163CE8.2050903@gmail.com>
Message-ID: <CAKv6MrYOx1iGtUjsiNQwnUnmyBm3m=97BMnGhCVhhgB2gB+mnQ@mail.gmail.com>
Thank's for feedback Daniel,
This core is add to the tracker with ID 247...
Best Regards
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> it is in my to-do list to investigate, so far I was not able to reproduce.
>
> Vacation time together with other travelings makes a bit more slower
> process. Please add it also to the tracker:
>
> http://sip-router.org/tracker/
>
> A minor release for 3.3 branch is going to be soon, being there makes sure
> it will be reviewed to see if it applies.
>
> Cheers,
> Daniel
>
>
> On 7/27/12 3:00 PM, Bruno Bresciani wrote:
>
> Hi Users,
>
> This is my ultimate try to ask for some help to debug the two cores
> generated by fm_realloc() function. If somebody can give me a feedback
> about my questions or doubts I will be very grateful, this user list of
> kamailio always help me to solve my problems.
>
> Best Regards
>
>
> 2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com>
>
>> Hi All,
>>
>> I imagine that this core doesn't easy to replicate but somebody can help
>> me to understand why it was generated? There is some way to prevent it?
>>
>> Best Regards
>>
>>
>>
>> 2012/7/18 Renan Capaverde <renan.capaverde at digitro.com.br>
>>
>>> I am having the same problem on kamailio 3.1.6. Someone please help.
>>>
>>> Cheers,
>>> Renan
>>>
>>> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>>>
>>> Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
>>>
>>> Best Regards
>>>
>>>
>>> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com>
>>>
>>>> Hello,
>>>>
>>>> send also the version 'kamailio -V' to match the proper sources.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>>>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536.
>>>>
>>>> I don't know exactly what may be caused this core because the debug of
>>>> kamailio is disabled, but looking at backtrace (gdb) and source code I
>>>> could notice a relationship with TLS connection establishment (handshake).
>>>> Other important fact is that core was generated by the kamalio itself with
>>>> signal 6 (abort) because it can't find the pointer to memory realloc.
>>>> I'd like to know if someone already observed this issue and if my
>>>> analyse above is correct?
>>>>
>>>> Bellow is backtrace full with gdb:
>>>>
>>>> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>>>> /var/run/kamailio.pid'.
>>>> Program terminated with signal 6, Aborted.
>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>> (gdb)
>>>> (gdb)
>>>> (gdb)
>>>> (gdb)
>>>> (gdb) bt full
>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>> No symbol table info available.
>>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>>> No symbol table info available.
>>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>>> No symbol table info available.
>>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
>>>> mem/f_malloc.c:536
>>>> f = (struct fm_frag *) 0xb61f0bb8
>>>> pf = <value optimized out>
>>>> orig_size = 18
>>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>>> ptr = <value optimized out>
>>>> hash = 23548
>>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
>>>> ../../mem/shm_mem.h:266
>>>> No locals.
>>>> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
>>>> No symbol table info available.
>>>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>>>> No symbol table info available.
>>>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>>>> No symbol table info available.
>>>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>>>> No symbol table info available.
>>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
>>>> No symbol table info available.
>>>> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
>>>> No symbol table info available.
>>>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>>>> No symbol table info available.
>>>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>>>> No symbol table info available.
>>>> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
>>>> tls_server.c:346
>>>> ret = <value optimized out>
>>>> ssl = (SSL *) 0xb61c1878
>>>> cert = <value optimized out>
>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>> tls_log = <value optimized out>
>>>> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
>>>> tls_server.c:1028
>>>> r = (struct tcp_req *) 0xb621affc
>>>> bytes_free = 4095
>>>> bytes_read = 70
>>>> read_size = 4095
>>>> ssl_error = 0
>>>> ssl_read = 0
>>>> ssl = (SSL *) 0xb61c1878
>>>> rd_buf = "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>>>
>>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>>> wr_buf =
>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>
>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70,
>>>> size = 65536}
>>>> wr = {
>>>> buf = 0xbf8fdfa4
>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>>> pos = 0, used = 0,
>>>> size = 65536}
>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>>> n = 0
>>>> flush_flags = <value optimized out>
>>>> err_src = 0x541a83 "TLS read:"
>>>> x = <value optimized out>
>>>> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
>>>> read_flags=0xbf91e200) at tcp_read.c:406
>>>> bytes = -1
>>>> remaining = <value optimized out>
>>>> p = <value optimized out>
>>>> r = (struct tcp_req *) 0xb621affc
>>>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204,
>>>> read_flags=0xbf91e200) at tcp_read.c:871
>>>> bytes = <value optimized out>
>>>> total_bytes = 0
>>>> resp = <value optimized out>
>>>> size = <value optimized out>
>>>> req = (struct tcp_req *) 0xb621affc
>>>> dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data =
>>>> "\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family =
>>>> 57540,
>>>> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
>>>> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port =
>>>> 49041,
>>>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
>>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 =
>>>> {0, 0, 16, 0, 1, 0,
>>>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}},
>>>> id = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask =
>>>> 0 '\0'}}
>>>> c = 10 '\n'
>>>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
>>>> tcp_read.c:1150
>>>> ret = 4
>>>> n = 4
>>>> read_flags = 1
>>>> con = (struct tcp_connection *) 0xb621af88
>>>> s = 12
>>>> resp = <value optimized out>
>>>> t = <value optimized out>
>>>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
>>>> No locals.
>>>> ---Type <return> to continue, or q <return> to quit---
>>>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>>>> r = 3
>>>> reader_fd_1 = 35
>>>> pid = <value optimized out>
>>>> si = <value optimized out>
>>>> #20 0x080ad412 in main_loop () at main.c:1632
>>>> i = 4
>>>> pid = <value optimized out>
>>>> si = (struct socket_info *) 0x0
>>>> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
>>>> \000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>>> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted
>>>> DWARF expression.
>>>> ) at main.c:2398
>>>> cfg_stream = (FILE *) 0x8a2d008
>>>> c = <value optimized out>
>>>> r = 0
>>>> tmp = 0xbf91e674
>>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>>> tmp_len = 10492229
>>>> port = 136192361
>>>> proto = -1080957480
>>>> ret = <value optimized out>
>>>> seed = 21782655
>>>> rfd = 4
>>>> debug_save = <value optimized out>
>>>> debug_flag = 0
>>>> dont_fork_cnt = 0
>>>> n_lst = <value optimized out>
>>>> p = <value optimized out>
>>>>
>>>>
>>>> Best Regards
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/bb5cb6e2/attachment-0001.htm>
From dnotivol at gmail.com Mon Jul 30 15:55:42 2012
From: dnotivol at gmail.com (David Notivol)
Date: Mon, 30 Jul 2012 15:55:42 +0200
Subject: [SR-Users] ACK not relayed
In-Reply-To: <5016561D.9060202@gmail.com>
References: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
<50163D97.9000805@gmail.com>
<CAOHrEOAuSfOuB7GCMYj2zONcDj9rzXd-k-8hEOZDKKbaqTLmYQ@mail.gmail.com>
<50164A7E.2060905@gmail.com>
<CAOHrEOBXNS2hbYZbMC=qspi0yCgkDr6MWj3xDmwhG9aUhw2dwg@mail.gmail.com>
<5016561D.9060202@gmail.com>
Message-ID: <CAOHrEOBnushqXd59LyENPyinxkepEFFLw-=iFTaB5SUzEsfDMA@mail.gmail.com>
Hello,
It looks like the r-uri in the trace is different from the one kamailio
considers. From the ACK message captured with ngrep:
ACK sip:200.87.137.150:5060;user=phone SIP/2.0
But form the logs:
Jul 30 09:15:00 theseus-test /usr/local/kamailio/sbin/kamailio[1577]:
DEBUG: <core> [parser/msg_parser.c:630]: method: <ACK>
Jul 30 09:15:00 theseus-test /usr/local/kamailio/sbin/kamailio[1577]:
DEBUG: <core> [parser/msg_parser.c:632]: uri:
<sip:59146938249 at 79.170.68.157:5060;user=phone><sip:59146938249 at 79.170.68.157:5060;user=phone>
Regards,
David.
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> the log message shows that the transaction is not found. Is the ACK coming
> late after 200ok ? There is a tm module parameter that you can adjust to
> prolong the time a transaction is kept after completion, if that is the
> case.
>
> Also, be sure the INVITE is sent using tm functions, not stateless via
> core function.
>
> Then, instead of dropping, you can just try forwarding it if the uri si
> not myself, like adding:
>
> if(uri!=myself) t_relay();
>
> before the exit.
>
> Cheers,
> Daniel
>
>
> On 7/30/12 11:10 AM, David Notivol wrote:
>
> This is the code that's being executed:
>
> route[WITHINDLG] {
> if (has_totag()) {
> # sequential request withing a dialog should
> # take the path determined by record-routing
> xlog("ESTAMOS EN WITHIN\n");
> if (loose_route()){
> xlog("LOOSE ROUTE DETECTED\n");
> if (is_method("ACK")) {
> xlog("ES UN ACK\n");
> }
> route(BYE);
> route(RELAY);
> } else {
> xlog("NO LOOSE ROUTE\n");
> if ( is_method("ACK") ) {
> if ( t_check_trans() ) {
> xlog("NO LOOSE AND TRANSACTION FOUND\n");
> # no loose-route, but stateful ACK;
> # must be an ACK after a 487
> # or e.g. 404 from upstream server
> t_relay();
> exit;
> } else {
> xlog("NO LOOSE AND TRANSACTION NOT FOUND\n");
> # ACK without matching transaction ... ignore and
> discard
> exit;
> }
> }
> sl_send_reply("404","Not here");
> }
> exit;
> }
> }
>
>
> And the call log with cfgtrace. It seems to be clear that the transaction
> is not matched, but we can't see why.
>
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=335 a=26 n=xlog
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: <script>: ESTAMOS EN WITHIN
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=360 a=17 n=if
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=336 a=25 n=loose_route
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: rr [loose.c:108]: No Route headers found
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: rr [loose.c:838]: There is no Route HF
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=344 a=26 n=xlog
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: <script>: NO LOOSE ROUTE
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=359 a=17 n=if
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=345 a=26 n=is_method
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=357 a=17 n=if
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=346 a=25 n=t_check_trans
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:1079]: DEBUG: t_check_msg: msg id=12 global id=10 T
> start=(nil)
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=58737,
> isACK=1
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: tm [t_lookup.c:1148]: DEBUG: t_check_msg: msg id=12 global id=12 T
> end=(nil)
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=354 a=26 n=xlog
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: <script>: NO LOOSE AND TRANSACTION NOT FOUND
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
> l=356 a=3 n=exit
> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
> DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list
> (nil)
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>
>> Hello,
>>
>> if your config is based on the default one, there is a check for
>> associated INVITE transaction and if that does not exist, then the ACK is
>> droppend.
>>
>> You can use debugger module with cfgtrace set on in order to see what
>> actions in the config file are executed. That will help to see if it gets
>> to t_check_trans() and then exit.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/30/12 10:35 AM, David Notivol wrote:
>>
>> Hi Daniel,
>>
>> This is the ACK message:
>>
>> U 2012/07/30 04:23:31.604721 79.170.68.151:5060 -> 79.170.68.157:5060
>> ACK sip:200.87.137.150:5060;user=phone SIP/2.0.
>> Via: SIP/2.0/UDP 79.170.68.151:5060
>> ;branch=z9hG4bK334faa4497ll114a52eACK450932302031.
>> Max-Forwards: 70.
>> Route: <sip:79.170.68.157;lr;ftag=45093230-co8241-INS033>.
>> To: <sip:59146292331 at 79.170.68.157
>> ;user=phone;noa=international>;tag=ldb0cbn6-CC-23.
>> From: "Javi Gallart"<sip:34917019888 at 79.170.68.151
>> ;user=phone;noa=national>;tag=45093230-co8241-INS033.
>> Call-ID: 071ae17301d3eb470f5cdde00cd9b24b at ens.com.
>> CSeq: 824101 ACK.
>> User-Agent: ENSR3.0.66.34-IS33-RMRG106382-RG105488-CPO13110.
>> Content-Length: 0.
>>
>>
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>>
>>> Hello,
>>>
>>> can you add a log message to print the source ip, call id and r-uri?
>>>
>>> It may happen that the ACK is looping back if r-uri is pointing to
>>> itself.
>>>
>>> Also, try to get the ngrep on all devices, like:
>>>
>>> ngrep -d any -qt -W byline port 5060
>>>
>>> Pasting the ACK request here will help to see if something is wrong with
>>> it.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/30/12 8:53 AM, David Notivol wrote:
>>>
>>> In a UAC-Kamailio-UAS scenario, we've found a case where the ACK
>>> coming from uac is not relayed by our proxy to the uas. This is the log for
>>> the ACK message:
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:624]: SIP Request:
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:626]: method: <ACK>
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:628]: uri: <sip:59138553189 at 79.170.68.157><sip:59138553189 at 79.170.68.157>
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:630]: version: <SIP/2.0>
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>; state=6
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_via.c:1286]: Found param type 232, <branch> =
>>> <z9hG4bKKc4gKXyemS9HD>; state=16
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_via.c:2561]: end of header reached, state=5
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:513]: parse_headers: this is the first via
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:149]:
>>> After parse_msg...
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:190]:
>>> preparing to run routing scripts...
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl [sl_funcs.c:396]: DEBUG
>>> : sl_filter_ACK: to late to be a local ACK!
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd [mf_funcs.c:85]:
>>> value = 65
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_to.c:802]: end of header reached, state=29
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52]; uri=[
>>> sip:59138553189 at 79.170.68.157]
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:190]: DEBUG: to body [
>>> <sip:59138553189 at 79.170.68.157> <sip:59138553189 at 79.170.68.157>]
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <31362871> <ACK>
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=0
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/msg_parser.c:104]: found end of header
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>> [parser/parse_to.c:802]: end of header reached, state=29
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity [mod_sanity.c:255]:
>>> sanity checks result: 1
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: siputils [checks.c:106]:
>>> totag found
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: ESTAMOS EN
>>> WITHIN
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:108]: No Route
>>> headers found
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:829]: There is
>>> no Route HF
>>> Jul 27 10:04:59 theseus-test
>>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: NO LOOSE ROUTE
>>>
>>> However, in a pcap trace I clearly see the Route header:
>>> This is the Record-Route in the 200 message
>>> Record-Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>> And this is the Route header in the ACk:
>>> Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>>
>>> I haven't been able to figure out what's going on. We have plenty of
>>> traffic working in that proxy. What am I missing?
>>>
>>> Thanks in advance
>>> David.
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>
>>>
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
>
> --
> Saludos,
> David Notivol
> dnotivol at gmail.com
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/a353441e/attachment-0001.htm>
From miconda at gmail.com Mon Jul 30 16:27:05 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 16:27:05 +0200
Subject: [SR-Users] ACK not relayed
In-Reply-To: <CAOHrEOBnushqXd59LyENPyinxkepEFFLw-=iFTaB5SUzEsfDMA@mail.gmail.com>
References: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
<50163D97.9000805@gmail.com>
<CAOHrEOAuSfOuB7GCMYj2zONcDj9rzXd-k-8hEOZDKKbaqTLmYQ@mail.gmail.com>
<50164A7E.2060905@gmail.com>
<CAOHrEOBXNS2hbYZbMC=qspi0yCgkDr6MWj3xDmwhG9aUhw2dwg@mail.gmail.com>
<5016561D.9060202@gmail.com>
<CAOHrEOBnushqXd59LyENPyinxkepEFFLw-=iFTaB5SUzEsfDMA@mail.gmail.com>
Message-ID: <501699B9.9080405@gmail.com>
Hello,
add $si, $ru and $ci in the xlog(...) from the config to compare with
ngrep trace, maybe there are different ACKs.
Cheers,
Daniel
On 7/30/12 3:55 PM, David Notivol wrote:
> Hello,
>
> It looks like the r-uri in the trace is different from the one
> kamailio considers. From the ACK message captured with ngrep:
> ACK sip:200.87.137.150:5060;user=phone SIP/2.0
>
> But form the logs:
> Jul 30 09:15:00 theseus-test /usr/local/kamailio/sbin/kamailio[1577]:
> DEBUG: <core> [parser/msg_parser.c:630]: method: <ACK>
> Jul 30 09:15:00 theseus-test /usr/local/kamailio/sbin/kamailio[1577]:
> DEBUG: <core> [parser/msg_parser.c:632]: uri:
> <sip:59146938249 at 79.170.68.157:5060;user=phone>
>
>
> Regards,
> David.
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> the log message shows that the transaction is not found. Is the
> ACK coming late after 200ok ? There is a tm module parameter that
> you can adjust to prolong the time a transaction is kept after
> completion, if that is the case.
>
> Also, be sure the INVITE is sent using tm functions, not stateless
> via core function.
>
> Then, instead of dropping, you can just try forwarding it if the
> uri si not myself, like adding:
>
> if(uri!=myself) t_relay();
>
> before the exit.
>
> Cheers,
> Daniel
>
>
> On 7/30/12 11:10 AM, David Notivol wrote:
>> This is the code that's being executed:
>>
>> route[WITHINDLG] {
>> if (has_totag()) {
>> # sequential request withing a dialog should
>> # take the path determined by record-routing
>> xlog("ESTAMOS EN WITHIN\n");
>> if (loose_route()){
>> xlog("LOOSE ROUTE DETECTED\n");
>> if (is_method("ACK")) {
>> xlog("ES UN ACK\n");
>> }
>> route(BYE);
>> route(RELAY);
>> } else {
>> xlog("NO LOOSE ROUTE\n");
>> if ( is_method("ACK") ) {
>> if ( t_check_trans() ) {
>> xlog("NO LOOSE AND TRANSACTION FOUND\n");
>> # no loose-route, but stateful ACK;
>> # must be an ACK after a 487
>> # or e.g. 404 from upstream server
>> t_relay();
>> exit;
>> } else {
>> xlog("NO LOOSE AND TRANSACTION NOT FOUND\n");
>> # ACK without matching transaction ... ignore
>> and discard
>> exit;
>> }
>> }
>> sl_send_reply("404","Not here");
>> }
>> exit;
>> }
>> }
>>
>>
>> And the call log with cfgtrace. It seems to be clear that the
>> transaction is not matched, but we can't see why.
>>
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=335 a=26 n=xlog
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: <script>: ESTAMOS
>> EN WITHIN
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=360 a=17 n=if
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=336 a=25
>> n=loose_route
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: DEBUG: rr [loose.c:108]:
>> No Route headers found
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: DEBUG: rr [loose.c:838]:
>> There is no Route HF
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=344 a=26 n=xlog
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: <script>: NO LOOSE
>> ROUTE
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=359 a=17 n=if
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=345 a=26
>> n=is_method
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=357 a=17 n=if
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=346 a=25
>> n=t_check_trans
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: DEBUG: tm
>> [t_lookup.c:1079]: DEBUG: t_check_msg: msg id=12 global id=10 T
>> start=(nil)
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: DEBUG: tm
>> [t_lookup.c:527]: t_lookup_request: start searching: hash=58737,
>> isACK=1
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: DEBUG: tm
>> [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: DEBUG: tm
>> [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: DEBUG: tm
>> [t_lookup.c:1148]: DEBUG: t_check_msg: msg id=12 global id=12 T
>> end=(nil)
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=354 a=26 n=xlog
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: <script>: NO LOOSE
>> AND TRANSACTION NOT FOUND
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: ERROR: *** cfgtrace:
>> c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg] l=356 a=3 n=exit
>> Jul 30 04:58:08 theseus-test
>> /usr/local/kamailio/sbin/kamailio[577]: DEBUG: <core>
>> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
>>
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>>
>>
>> Hello,
>>
>> if your config is based on the default one, there is a check
>> for associated INVITE transaction and if that does not exist,
>> then the ACK is droppend.
>>
>> You can use debugger module with cfgtrace set on in order to
>> see what actions in the config file are executed. That will
>> help to see if it gets to t_check_trans() and then exit.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/30/12 10:35 AM, David Notivol wrote:
>>> Hi Daniel,
>>>
>>> This is the ACK message:
>>>
>>> U 2012/07/30 04:23:31.604721 79.170.68.151:5060
>>> <http://79.170.68.151:5060> -> 79.170.68.157:5060
>>> <http://79.170.68.157:5060>
>>> ACK sip:200.87.137.150:5060;user=phone SIP/2.0.
>>> Via: SIP/2.0/UDP
>>> 79.170.68.151:5060;branch=z9hG4bK334faa4497ll114a52eACK450932302031.
>>> Max-Forwards: 70.
>>> Route: <sip:79.170.68.157;lr;ftag=45093230-co8241-INS033>.
>>> To: <sip:59146292331 at 79.170.68.157
>>> <mailto:sip%3A59146292331 at 79.170.68.157>;user=phone;noa=international>;tag=ldb0cbn6-CC-23.
>>> From: "Javi Gallart"<sip:34917019888 at 79.170.68.151
>>> <mailto:sip%3A34917019888 at 79.170.68.151>;user=phone;noa=national>;tag=45093230-co8241-INS033.
>>> Call-ID: 071ae17301d3eb470f5cdde00cd9b24b at ens.com
>>> <mailto:071ae17301d3eb470f5cdde00cd9b24b at ens.com>.
>>> CSeq: 824101 ACK.
>>> User-Agent: ENSR3.0.66.34-IS33-RMRG106382-RG105488-CPO13110.
>>> Content-Length: 0.
>>>
>>>
>>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
>>> <mailto:miconda at gmail.com>>
>>>
>>> Hello,
>>>
>>> can you add a log message to print the source ip, call
>>> id and r-uri?
>>>
>>> It may happen that the ACK is looping back if r-uri is
>>> pointing to itself.
>>>
>>> Also, try to get the ngrep on all devices, like:
>>>
>>> ngrep -d any -qt -W byline port 5060
>>>
>>> Pasting the ACK request here will help to see if
>>> something is wrong with it.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/30/12 8:53 AM, David Notivol wrote:
>>>> In a UAC-Kamailio-UAS scenario, we've found a case
>>>> where the ACK coming from uac is not relayed by our
>>>> proxy to the uas. This is the log for the ACK message:
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:624]: SIP Request:
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:626]: method: <ACK>
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:628]: uri:
>>>> <sip:59138553189 at 79.170.68.157>
>>>> <mailto:sip:59138553189 at 79.170.68.157>
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:630]: version: <SIP/2.0>
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_via.c:1286]: Found param type 235,
>>>> <rport> = <n/a>; state=6
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_via.c:1286]: Found param type 232,
>>>> <branch> = <z9hG4bKKc4gKXyemS9HD>; state=16
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_via.c:2561]: end of header reached, state=5
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:511]: parse_headers: Via found,
>>>> flags=2
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:513]: parse_headers: this is the
>>>> first via
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [receive.c:149]: After parse_msg...
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [receive.c:190]: preparing to run routing scripts...
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl
>>>> [sl_funcs.c:396]: DEBUG : sl_filter_ACK: to late to be
>>>> a local ACK!
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd
>>>> [mf_funcs.c:85]: value = 65
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_to.c:178]: DEBUG: add_param:
>>>> tag=6ne1x6d6-CC-23
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_to.c:802]: end of header reached, state=29
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To>
>>>> [52]; uri=[sip:59138553189 at 79.170.68.157
>>>> <mailto:sip:59138553189 at 79.170.68.157>]
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:190]: DEBUG: to body
>>>> [<sip:59138553189 at 79.170.68.157>
>>>> <mailto:sip:59138553189 at 79.170.68.157>]
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>:
>>>> <31362871> <ACK>
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:202]: DEBUG: get_hdr_body :
>>>> content_length=0
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:104]: found end of header
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_to.c:178]: DEBUG: add_param:
>>>> tag=0cS8trtaF196F
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_to.c:802]: end of header reached, state=29
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity
>>>> [mod_sanity.c:255]: sanity checks result: 1
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG:
>>>> siputils [checks.c:106]: totag found
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR:
>>>> <script>: ESTAMOS EN WITHIN
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr
>>>> [loose.c:108]: No Route headers found
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr
>>>> [loose.c:829]: There is no Route HF
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR:
>>>> <script>: NO LOOSE ROUTE
>>>>
>>>> However, in a pcap trace I clearly see the Route header:
>>>> This is the Record-Route in the 200 message
>>>> Record-Route:
>>>> <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>>> And this is the Route header in the ACk:
>>>> Route:
>>>> <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>>>
>>>> I haven't been able to figure out what's going on. We
>>>> have plenty of traffic working in that proxy. What am I
>>>> missing?
>>>>
>>>> Thanks in advance
>>>> David.
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>>
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>>
>>
>> --
>> Saludos,
>> David Notivol
>> dnotivol at gmail.com <mailto:dnotivol at gmail.com>
>>
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/926cc459/attachment-0001.htm>
From ibc at aliax.net Mon Jul 30 17:21:55 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon, 30 Jul 2012 17:21:55 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <50167004.7060301@gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
Message-ID: <CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>:
> After playing a bit more with it, I pushed some commits on master branch.
> Can you try to see if they fixed the issue you reported?
Hi Daniel, we are testing it. It looks ok for now but we need further
testing, please let us giving a better feedback today or tomorrow.
Thanks a lot.
--
I?aki Baz Castillo
<ibc at aliax.net>
From jmillan at aliax.net Mon Jul 30 17:35:14 2012
From: jmillan at aliax.net (=?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?=)
Date: Mon, 30 Jul 2012 17:35:14 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
Message-ID: <CABw3bnM2SkoBegRzTO6ww4cknixSHa58v2MEOD7fBZtw_6tSeA@mail.gmail.com>
Hi Daniel
It works as expected. Binding is updated correctly now!
Thank you very much.
Regards
2012/7/30 I?aki Baz Castillo <ibc at aliax.net>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>:
> > After playing a bit more with it, I pushed some commits on master branch.
> > Can you try to see if they fixed the issue you reported?
>
> Hi Daniel, we are testing it. It looks ok for now but we need further
> testing, please let us giving a better feedback today or tomorrow.
>
> Thanks a lot.
>
> --
> I?aki Baz Castillo
> <ibc at aliax.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/02dc1601/attachment.htm>
From miconda at gmail.com Mon Jul 30 17:36:51 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 17:36:51 +0200
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <CAKv6MrYOx1iGtUjsiNQwnUnmyBm3m=97BMnGhCVhhgB2gB+mnQ@mail.gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
<CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
<50163CE8.2050903@gmail.com>
<CAKv6MrYOx1iGtUjsiNQwnUnmyBm3m=97BMnGhCVhhgB2gB+mnQ@mail.gmail.com>
Message-ID: <5016AA13.9030806@gmail.com>
Hello,
can you provide output of 'kamailio -V'? Did you enable f_malloc instead
of q_malloc which was default in 3.1?
Cheers,
Daniel
On 7/30/12 1:44 PM, Bruno Bresciani wrote:
> Thank's for feedback Daniel,
>
> This core is add to the tracker with ID 247...
>
> Best Regards
>
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> it is in my to-do list to investigate, so far I was not able to
> reproduce.
>
> Vacation time together with other travelings makes a bit more
> slower process. Please add it also to the tracker:
>
> http://sip-router.org/tracker/
>
> A minor release for 3.3 branch is going to be soon, being there
> makes sure it will be reviewed to see if it applies.
>
> Cheers,
> Daniel
>
>
> On 7/27/12 3:00 PM, Bruno Bresciani wrote:
>> Hi Users,
>>
>> This is my ultimate try to ask for some help to debug the two
>> cores generated by fm_realloc() function. If somebody can give me
>> a feedback about my questions or doubts I will be very grateful,
>> this user list of kamailio always help me to solve my problems.
>>
>> Best Regards
>>
>>
>> 2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com
>> <mailto:bruno.bresciani at gmail.com>>
>>
>> Hi All,
>>
>> I imagine that this core doesn't easy to replicate but
>> somebody can help me to understand why it was generated?
>> There is some way to prevent it?
>>
>> Best Regards
>>
>>
>>
>> 2012/7/18 Renan Capaverde <renan.capaverde at digitro.com.br
>> <mailto:renan.capaverde at digitro.com.br>>
>>
>> I am having the same problem on kamailio 3.1.6. Someone
>> please help.
>>
>> Cheers,
>> Renan
>>
>> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>>> Excuse-me Daniel, I forgot this information... Kamailio
>>> version 3.1.2
>>>
>>> Best Regards
>>>
>>>
>>> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com
>>> <mailto:miconda at gmail.com>>
>>>
>>> Hello,
>>>
>>> send also the version 'kamailio -V' to match the
>>> proper sources.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>>> Hi all,
>>>>
>>>> I observed two at 0x08173bf0 in fm_realloc
>>>> (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
>>>> mem/f_malloc.c:536.
>>>>
>>>> I don't know exactly what may be caused this core
>>>> because the debug of kamailio is disabled, but
>>>> looking at backtrace (gdb) and source code I could
>>>> notice a relationship with TLS connection
>>>> establishment (handshake). Other important fact is
>>>> that core was generated by the kamalio itself with
>>>> signal 6 (abort) because it can't find the pointer
>>>> to memory realloc.
>>>> I'd like to know if someone already observed this
>>>> issue and if my analyse above is correct?
>>>>
>>>> Bellow is backtrace full with gdb:
>>>>
>>>> Core was generated by
>>>> `/home2/local/kamailio/sbin/kamailio -P
>>>> /var/run/kamailio.pid'.
>>>> Program terminated with signal 6, Aborted.
>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>> (gdb)
>>>> (gdb)
>>>> (gdb)
>>>> (gdb)
>>>> (gdb) bt full
>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>> No symbol table info available.
>>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>>> No symbol table info available.
>>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>>> No symbol table info available.
>>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>>>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536
>>>> f = (struct fm_frag *) 0xb61f0bb8
>>>> pf = <value optimized out>
>>>> orig_size = 18
>>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>>> ptr = <value optimized out>
>>>> hash = 23548
>>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0,
>>>> size=32) at ../../mem/shm_mem.h:266
>>>> No locals.
>>>> #5 0x00460295 in OPENSSL_cleanse () from
>>>> /lib/libcrypto.so.6
>>>> No symbol table info available.
>>>> #6 0x004609f7 in CRYPTO_realloc () from
>>>> /lib/libcrypto.so.6
>>>> No symbol table info available.
>>>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>>>> No symbol table info available.
>>>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>>>> No symbol table info available.
>>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from
>>>> /lib/libssl.so.6
>>>> No symbol table info available.
>>>> #10 0x007aa9f3 in ssl3_get_client_hello () from
>>>> /lib/libssl.so.6
>>>> No symbol table info available.
>>>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>>>> No symbol table info available.
>>>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>>>> No symbol table info available.
>>>> #13 0x005278e3 in tls_accept (c=0xb621af88,
>>>> error=0xbf91dfc8) at tls_server.c:346
>>>> ret = <value optimized out>
>>>> ssl = (SSL *) 0xb61c1878
>>>> cert = <value optimized out>
>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>> tls_log = <value optimized out>
>>>> #14 0x0052da8e in tls_read_f (c=0xb621af88,
>>>> flags=0xbf91e200) at tls_server.c:1028
>>>> r = (struct tcp_req *) 0xb621affc
>>>> bytes_free = 4095
>>>> bytes_read = 70
>>>> read_size = 4095
>>>> ssl_error = 0
>>>> ssl_read = 0
>>>> ssl = (SSL *) 0xb61c1878
>>>> rd_buf =
>>>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>>> wr_buf =
>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos
>>>> = 70, used = 70, size = 65536}
>>>> wr = {
>>>> buf = 0xbf8fdfa4
>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>>> pos = 0, used = 0,
>>>> size = 65536}
>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>>> n = 0
>>>> flush_flags = <value optimized out>
>>>> err_src = 0x541a83 "TLS read:"
>>>> x = <value optimized out>
>>>> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
>>>> read_flags=0xbf91e200) at tcp_read.c:406
>>>> bytes = -1
>>>> remaining = <value optimized out>
>>>> p = <value optimized out>
>>>> r = (struct tcp_req *) 0xb621affc
>>>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88,
>>>> bytes_read=0xbf91e204, read_flags=0xbf91e200) at
>>>> tcp_read.c:871
>>>> bytes = <value optimized out>
>>>> total_bytes = 0
>>>> resp = <value optimized out>
>>>> size = <value optimized out>
>>>> req = (struct tcp_req *) 0xb621affc
>>>> dst = {send_sock = 0x1, to = {s =
>>>> {sa_family = 57540, sa_data =
>>>> "\221??\020\000\000\000\000\000\000\000\020\000\000"},
>>>> sin = {sin_family = 57540,
>>>> sin_port = 49041, sin_addr = {s_addr = 16},
>>>> sin_zero = "\000\000\000\000\020\000\000"}, sin6 =
>>>> {sin6_family = 57540, sin6_port = 49041,
>>>> sin6_flowinfo = 16, sin6_addr = {in6_u =
>>>> {u6_addr8 =
>>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000",
>>>> u6_addr16 = {0, 0, 16, 0, 1, 0,
>>>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}},
>>>> sin6_scope_id = 12}}, id = -1080958468, proto = 4
>>>> '\004', send_flags = {f = 0 '\0', blst_imask = 0 '\0'}}
>>>> c = 10 '\n'
>>>> #17 0x08159a0f in handle_io (fm=0x83296b0,
>>>> events=1, idx=-1) at tcp_read.c:1150
>>>> ret = 4
>>>> n = 4
>>>> read_flags = 1
>>>> con = (struct tcp_connection *) 0xb621af88
>>>> s = 12
>>>> resp = <value optimized out>
>>>> t = <value optimized out>
>>>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35)
>>>> at io_wait.h:1091
>>>> No locals.
>>>> ---Type <return> to continue, or q <return> to quit---
>>>> #19 0x0812885b in tcp_init_children () at
>>>> tcp_main.c:4819
>>>> r = 3
>>>> reader_fd_1 = 35
>>>> pid = <value optimized out>
>>>> si = <value optimized out>
>>>> #20 0x080ad412 in main_loop () at main.c:1632
>>>> i = 4
>>>> pid = <value optimized out>
>>>> si = (struct socket_info *) 0x0
>>>> si_desc = "udp receiver child=3
>>>> sock=192.168.166.31:5060
>>>> <http://192.168.166.31:5060>\000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>>> #21 0x080afbe7 in main (argc=3,
>>>> argv=dwarf2_read_address: Corrupted DWARF expression.
>>>> ) at main.c:2398
>>>> cfg_stream = (FILE *) 0x8a2d008
>>>> c = <value optimized out>
>>>> r = 0
>>>> tmp = 0xbf91e674
>>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>>> tmp_len = 10492229
>>>> port = 136192361
>>>> proto = -1080957480
>>>> ret = <value optimized out>
>>>> seed = 21782655
>>>> rfd = 4
>>>> debug_save = <value optimized out>
>>>> debug_flag = 0
>>>> dont_fork_cnt = 0
>>>> n_lst = <value optimized out>
>>>> p = <value optimized out>
>>>>
>>>>
>>>> Best Regards
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org <mailto:sr-users at 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 at lists.sip-router.org
>> <mailto:sr-users at 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 at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/0fc62c42/attachment-0001.htm>
From peter.dunkley at crocodile-rcs.com Mon Jul 30 18:00:23 2012
From: peter.dunkley at crocodile-rcs.com (Peter Dunkley)
Date: Mon, 30 Jul 2012 17:00:23 +0100
Subject: [SR-Users] [sr-dev] Outbound and Registrar. No binding update
In-Reply-To: <CABw3bnM2SkoBegRzTO6ww4cknixSHa58v2MEOD7fBZtw_6tSeA@mail.gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
<CABw3bnM2SkoBegRzTO6ww4cknixSHa58v2MEOD7fBZtw_6tSeA@mail.gmail.com>
Message-ID: <1343664023.16452.4.camel@pd-notebook-linux.croc.internal>
Hi,
With these changes (and a client that supports it) should I now be able
to use WebSockets without the aliasing from nathelper?
Regards,
Peter
On Mon, 2012-07-30 at 17:35 +0200, Jos? Luis Mill?n wrote:
> Hi Daniel
>
>
>
> It works as expected. Binding is updated correctly now!
>
>
> Thank you very much.
>
>
> Regards
>
>
> 2012/7/30 I?aki Baz Castillo <ibc at aliax.net>
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>:
>
> > After playing a bit more with it, I pushed some commits on
> master branch.
> > Can you try to see if they fixed the issue you reported?
>
>
>
> Hi Daniel, we are testing it. It looks ok for now but we need
> further
> testing, please let us giving a better feedback today or
> tomorrow.
>
> Thanks a lot.
>
>
> --
> I?aki Baz Castillo
> <ibc at aliax.net>
>
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/36cc8b82/attachment.htm>
From ibc at aliax.net Mon Jul 30 18:47:36 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon, 30 Jul 2012 18:47:36 +0200
Subject: [SR-Users] [sr-dev] Outbound and Registrar. No binding update
In-Reply-To: <1343664023.16452.4.camel@pd-notebook-linux.croc.internal>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
<CABw3bnM2SkoBegRzTO6ww4cknixSHa58v2MEOD7fBZtw_6tSeA@mail.gmail.com>
<1343664023.16452.4.camel@pd-notebook-linux.croc.internal>
Message-ID: <CALiegf=rFxizowjWL1OeiKb2tjdqubcL5KOx+4saAXYY0hLbzw@mail.gmail.com>
2012/7/30 Peter Dunkley <peter.dunkley at crocodile-rcs.com>
> With these changes (and a client that supports it) should I now be able to
> use WebSockets without the aliasing from nathelper?
Hi, there should be no difference with the case of SIP over TCP or TLS. The
main benefict of using Outobund and GRUU in clients (with reliable
transport such as TCP/TLS/WS) is that when the UA is in an active dialog
and its connection is closed, it can re-register (using a GRUU Contact),
replace the previous binding in the registrar, and when an incoming request
from the dialog peer arrives to the registrar it chooses the last created
binding for that GRUU Contact, so the request arrives to the UA even
through its new connection.
BTW I *hate* Contact mangling and Contact aliasing, that's an ugly
mechanism. Outbound solves that perfectly.
Regards.
--
I?aki Baz Castillo
<ibc at aliax.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/798809a1/attachment.htm>
From peter.dunkley at crocodile-rcs.com Mon Jul 30 18:51:36 2012
From: peter.dunkley at crocodile-rcs.com (Peter Dunkley)
Date: Mon, 30 Jul 2012 17:51:36 +0100
Subject: [SR-Users] [sr-dev] Outbound and Registrar. No binding update
In-Reply-To: <CALiegf=rFxizowjWL1OeiKb2tjdqubcL5KOx+4saAXYY0hLbzw@mail.gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
<CABw3bnM2SkoBegRzTO6ww4cknixSHa58v2MEOD7fBZtw_6tSeA@mail.gmail.com>
<1343664023.16452.4.camel@pd-notebook-linux.croc.internal>
<CALiegf=rFxizowjWL1OeiKb2tjdqubcL5KOx+4saAXYY0hLbzw@mail.gmail.com>
Message-ID: <422044d2e497bc7a919fc880df7d1b57.squirrel@crocodile-rcs.com>
Hi I?aki,
I'll stop using the mangling and aliasing as soon as Kamailio supports
Outbound. But for now... it works :-)
Peter
> 2012/7/30 Peter Dunkley <peter.dunkley at crocodile-rcs.com>
>
>> With these changes (and a client that supports it) should I now be able
>> to
>> use WebSockets without the aliasing from nathelper?
>
>
> Hi, there should be no difference with the case of SIP over TCP or TLS.
> The
> main benefict of using Outobund and GRUU in clients (with reliable
> transport such as TCP/TLS/WS) is that when the UA is in an active dialog
> and its connection is closed, it can re-register (using a GRUU Contact),
> replace the previous binding in the registrar, and when an incoming
> request
> from the dialog peer arrives to the registrar it chooses the last created
> binding for that GRUU Contact, so the request arrives to the UA even
> through its new connection.
>
> BTW I *hate* Contact mangling and Contact aliasing, that's an ugly
> mechanism. Outbound solves that perfectly.
>
> Regards.
>
> --
> I?aki Baz Castillo
> <ibc at aliax.net>
>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
From miconda at gmail.com Mon Jul 30 19:02:39 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 19:02:39 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
Message-ID: <5016BE2F.6010300@gmail.com>
Hello,
On 7/30/12 5:21 PM, I?aki Baz Castillo wrote:
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>:
>> After playing a bit more with it, I pushed some commits on master branch.
>> Can you try to see if they fixed the issue you reported?
> Hi Daniel, we are testing it. It looks ok for now but we need further
> testing, please let us giving a better feedback today or tomorrow.
>
> Thanks a lot.
quick question to double check if what I understood when I read the
specs was ok -- in gruu/ob, it does not matter anymore the callid/cseq
combination, or there should still be some checks related to it?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From bruno.bresciani at gmail.com Mon Jul 30 19:16:00 2012
From: bruno.bresciani at gmail.com (Bruno Bresciani)
Date: Mon, 30 Jul 2012 14:16:00 -0300
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <5016AA13.9030806@gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
<CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
<50163CE8.2050903@gmail.com>
<CAKv6MrYOx1iGtUjsiNQwnUnmyBm3m=97BMnGhCVhhgB2gB+mnQ@mail.gmail.com>
<5016AA13.9030806@gmail.com>
Message-ID: <CAKv6Mrb_rO-Lr9t9nvb+RvZfzOHQuNpb5uvnNK1ho_jdOLw24Q@mail.gmail.com>
Hi,
Bellow is output of 'kamailio -V'...
------------------------------------------------------------------------------------------------------------------
version: kamailio 3.1.2 (i386/linux) 4d9f90
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,
F_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, PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 4d9f90
compiled on 10:39:54 Apr 29 2011 with gcc 4.1.2
-------------------------------------------------------------------------------------------------------------------
Daniel, I don't remember to enable f_malloc... Actually I do not know the
difference between f_malloc and g_malloc to choose compile kamailio with
f_malloc instead of g_malloc.
My commands to compile kamailio were:
*
$ make PREFIX="/home2/local/kamailio" FLAVOUR=kamailio
include_modules="db_postgres tls" MEMDBG=0 cfg**
$ make all
$ make install*
If you need more informations, I am available...
Best Regards
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> can you provide output of 'kamailio -V'? Did you enable f_malloc instead
> of q_malloc which was default in 3.1?
>
> Cheers,
> Daniel
>
>
> On 7/30/12 1:44 PM, Bruno Bresciani wrote:
>
> Thank's for feedback Daniel,
>
> This core is add to the tracker with ID 247...
>
> Best Regards
>
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>
>> Hello,
>>
>> it is in my to-do list to investigate, so far I was not able to reproduce.
>>
>> Vacation time together with other travelings makes a bit more slower
>> process. Please add it also to the tracker:
>>
>> http://sip-router.org/tracker/
>>
>> A minor release for 3.3 branch is going to be soon, being there makes
>> sure it will be reviewed to see if it applies.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/27/12 3:00 PM, Bruno Bresciani wrote:
>>
>> Hi Users,
>>
>> This is my ultimate try to ask for some help to debug the two cores
>> generated by fm_realloc() function. If somebody can give me a feedback
>> about my questions or doubts I will be very grateful, this user list of
>> kamailio always help me to solve my problems.
>>
>> Best Regards
>>
>>
>> 2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com>
>>
>>> Hi All,
>>>
>>> I imagine that this core doesn't easy to replicate but somebody can
>>> help me to understand why it was generated? There is some way to prevent
>>> it?
>>>
>>> Best Regards
>>>
>>>
>>>
>>> 2012/7/18 Renan Capaverde <renan.capaverde at digitro.com.br>
>>>
>>>> I am having the same problem on kamailio 3.1.6. Someone please help.
>>>>
>>>> Cheers,
>>>> Renan
>>>>
>>>> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>>>>
>>>> Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
>>>>
>>>> Best Regards
>>>>
>>>>
>>>> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com>
>>>>
>>>>> Hello,
>>>>>
>>>>> send also the version 'kamailio -V' to match the proper sources.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>>>>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536.
>>>>>
>>>>> I don't know exactly what may be caused this core because the debug of
>>>>> kamailio is disabled, but looking at backtrace (gdb) and source code I
>>>>> could notice a relationship with TLS connection establishment (handshake).
>>>>> Other important fact is that core was generated by the kamalio itself with
>>>>> signal 6 (abort) because it can't find the pointer to memory realloc.
>>>>> I'd like to know if someone already observed this issue and if my
>>>>> analyse above is correct?
>>>>>
>>>>> Bellow is backtrace full with gdb:
>>>>>
>>>>> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>>>>> /var/run/kamailio.pid'.
>>>>> Program terminated with signal 6, Aborted.
>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>> (gdb)
>>>>> (gdb)
>>>>> (gdb)
>>>>> (gdb)
>>>>> (gdb) bt full
>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>> No symbol table info available.
>>>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>>>> No symbol table info available.
>>>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>>>> No symbol table info available.
>>>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
>>>>> mem/f_malloc.c:536
>>>>> f = (struct fm_frag *) 0xb61f0bb8
>>>>> pf = <value optimized out>
>>>>> orig_size = 18
>>>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>>>> ptr = <value optimized out>
>>>>> hash = 23548
>>>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
>>>>> ../../mem/shm_mem.h:266
>>>>> No locals.
>>>>> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
>>>>> No symbol table info available.
>>>>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>>>>> No symbol table info available.
>>>>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>>>>> No symbol table info available.
>>>>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>>>>> No symbol table info available.
>>>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
>>>>> No symbol table info available.
>>>>> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
>>>>> No symbol table info available.
>>>>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>>>>> No symbol table info available.
>>>>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>>>>> No symbol table info available.
>>>>> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
>>>>> tls_server.c:346
>>>>> ret = <value optimized out>
>>>>> ssl = (SSL *) 0xb61c1878
>>>>> cert = <value optimized out>
>>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>>> tls_log = <value optimized out>
>>>>> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
>>>>> tls_server.c:1028
>>>>> r = (struct tcp_req *) 0xb621affc
>>>>> bytes_free = 4095
>>>>> bytes_read = 70
>>>>> read_size = 4095
>>>>> ssl_error = 0
>>>>> ssl_read = 0
>>>>> ssl = (SSL *) 0xb61c1878
>>>>> rd_buf =
>>>>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>>>>
>>>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>>>> wr_buf =
>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>>
>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>>>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70,
>>>>> size = 65536}
>>>>> wr = {
>>>>> buf = 0xbf8fdfa4
>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>>>> pos = 0, used = 0,
>>>>> size = 65536}
>>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>>>> n = 0
>>>>> flush_flags = <value optimized out>
>>>>> err_src = 0x541a83 "TLS read:"
>>>>> x = <value optimized out>
>>>>> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
>>>>> read_flags=0xbf91e200) at tcp_read.c:406
>>>>> bytes = -1
>>>>> remaining = <value optimized out>
>>>>> p = <value optimized out>
>>>>> r = (struct tcp_req *) 0xb621affc
>>>>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204,
>>>>> read_flags=0xbf91e200) at tcp_read.c:871
>>>>> bytes = <value optimized out>
>>>>> total_bytes = 0
>>>>> resp = <value optimized out>
>>>>> size = <value optimized out>
>>>>> req = (struct tcp_req *) 0xb621affc
>>>>> dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data
>>>>> = "\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family
>>>>> = 57540,
>>>>> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
>>>>> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port =
>>>>> 49041,
>>>>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
>>>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 =
>>>>> {0, 0, 16, 0, 1, 0,
>>>>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}},
>>>>> id = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask =
>>>>> 0 '\0'}}
>>>>> c = 10 '\n'
>>>>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
>>>>> tcp_read.c:1150
>>>>> ret = 4
>>>>> n = 4
>>>>> read_flags = 1
>>>>> con = (struct tcp_connection *) 0xb621af88
>>>>> s = 12
>>>>> resp = <value optimized out>
>>>>> t = <value optimized out>
>>>>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
>>>>> No locals.
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>>>>> r = 3
>>>>> reader_fd_1 = 35
>>>>> pid = <value optimized out>
>>>>> si = <value optimized out>
>>>>> #20 0x080ad412 in main_loop () at main.c:1632
>>>>> i = 4
>>>>> pid = <value optimized out>
>>>>> si = (struct socket_info *) 0x0
>>>>> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
>>>>> \000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>>>> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted
>>>>> DWARF expression.
>>>>> ) at main.c:2398
>>>>> cfg_stream = (FILE *) 0x8a2d008
>>>>> c = <value optimized out>
>>>>> r = 0
>>>>> tmp = 0xbf91e674
>>>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>>>> tmp_len = 10492229
>>>>> port = 136192361
>>>>> proto = -1080957480
>>>>> ret = <value optimized out>
>>>>> seed = 21782655
>>>>> rfd = 4
>>>>> debug_save = <value optimized out>
>>>>> debug_flag = 0
>>>>> dont_fork_cnt = 0
>>>>> n_lst = <value optimized out>
>>>>> p = <value optimized out>
>>>>>
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/3353cccf/attachment-0001.htm>
From miconda at gmail.com Mon Jul 30 19:18:11 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 19:18:11 +0200
Subject: [SR-Users] [sr-dev] Outbound and Registrar. No binding update
In-Reply-To: <422044d2e497bc7a919fc880df7d1b57.squirrel@crocodile-rcs.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
<CABw3bnM2SkoBegRzTO6ww4cknixSHa58v2MEOD7fBZtw_6tSeA@mail.gmail.com>
<1343664023.16452.4.camel@pd-notebook-linux.croc.internal>
<CALiegf=rFxizowjWL1OeiKb2tjdqubcL5KOx+4saAXYY0hLbzw@mail.gmail.com>
<422044d2e497bc7a919fc880df7d1b57.squirrel@crocodile-rcs.com>
Message-ID: <5016C1D3.6090105@gmail.com>
Hello,
On 7/30/12 6:51 PM, Peter Dunkley wrote:
> Hi I?aki,
>
> I'll stop using the mangling and aliasing as soon as Kamailio supports
> Outbound. But for now... it works :-)
for such scenario, the gruu support is enough -- the problem is
selecting the right destination address in case of natted contacts. This
gruu extension is implemented in kamailio, but the big problem is client
side support -- very few SIP soft/hard phones implement it.
From the outbound, the missing part is automatic failover over multiple
streams (i.e., same sip instance but different reg-id values) -- this is
related to the situation when same UA registers via multiple paths in
order to be reachable when one path is down (say reg-id=1 main one is
not working, then try flow with reg-id=2 even for requests within
dialog) . It might be possible to be done via config file operations, by
serializing branches, although never tried, some pieces might still be
needed to be coded. Registering multiple flows is already possible at
this time, the key being (sip.instance, reg-id) when gruu is enabled and
supported by UA, advertised in the headers.
There is one situation that will not work even with gruu/ob -- in sip a
phone can call without registering. A gruu contact is obtained via
registration and then used for next requests by UA itself. By calling
without registering, there is no gruu contact for it, so adding the src
ip and port as alias parameter is still needed. I don't remember I have
seen any rfc making registration mandatory before calling.
In other words, just to summarize the gruu versus contact aliasing. Gruu
allocates an unique token for a SIP UA, mapping it to location record
where source ip and port are stored in memory/database, then looked up
when needed based on this token (even for request within dialog the
lookup() function has to be executed). Contact aliasing is storing the
source ip and port as a parameter to contact header to be processed from
the request itself, where it will be part of R-URI for requests within
dialog.
Cheers,
Daniel
>
> Peter
>
>> 2012/7/30 Peter Dunkley <peter.dunkley at crocodile-rcs.com>
>>
>>> With these changes (and a client that supports it) should I now be able
>>> to
>>> use WebSockets without the aliasing from nathelper?
>>
>> Hi, there should be no difference with the case of SIP over TCP or TLS.
>> The
>> main benefict of using Outobund and GRUU in clients (with reliable
>> transport such as TCP/TLS/WS) is that when the UA is in an active dialog
>> and its connection is closed, it can re-register (using a GRUU Contact),
>> replace the previous binding in the registrar, and when an incoming
>> request
>> from the dialog peer arrives to the registrar it chooses the last created
>> binding for that GRUU Contact, so the request arrives to the UA even
>> through its new connection.
>>
>> BTW I *hate* Contact mangling and Contact aliasing, that's an ugly
>> mechanism. Outbound solves that perfectly.
>>
>> Regards.
>>
>> --
>> I?aki Baz Castillo
>> <ibc at aliax.net>
>>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From ibc at aliax.net Mon Jul 30 19:23:04 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon, 30 Jul 2012 19:23:04 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <5016BE2F.6010300@gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
<5016BE2F.6010300@gmail.com>
Message-ID: <CALiegfm4RzkYXLamBLE3oZc=kT2C1Ki0wcEkQu7T9NVJEgByyw@mail.gmail.com>
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>:
> quick question to double check if what I understood when I read the specs
> was ok -- in gruu/ob, it does not matter anymore the callid/cseq
> combination, or there should still be some checks related to it?
In fact that depends on Outbound instead of GRUU, and not, when using
Outbound the registrar does NOT check the Call-ID and CSeq of the
REGISTER (and using GRUU means that Outbound is also used, so the
Contact has a +sip.instance and reg-id params which are inspected by
the registrar to create/update/delete a binding).
Cheers.
--
I?aki Baz Castillo
<ibc at aliax.net>
From miconda at gmail.com Mon Jul 30 19:23:44 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 30 Jul 2012 19:23:44 +0200
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <CAKv6Mrb_rO-Lr9t9nvb+RvZfzOHQuNpb5uvnNK1ho_jdOLw24Q@mail.gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
<CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
<50163CE8.2050903@gmail.com>
<CAKv6MrYOx1iGtUjsiNQwnUnmyBm3m=97BMnGhCVhhgB2gB+mnQ@mail.gmail.com>
<5016AA13.9030806@gmail.com>
<CAKv6Mrb_rO-Lr9t9nvb+RvZfzOHQuNpb5uvnNK1ho_jdOLw24Q@mail.gmail.com>
Message-ID: <5016C320.5040402@gmail.com>
Hello,
MEMDBG=0 turns on f_malloc, disabling q_malloc. The token F_MALLOC in
the kamailio -V output shows f_malloc is in use.
q_malloc is more suitable for debugging, as it keep trace of location in
the source code that allocates/frees the memory chunks, at the expense
of a bit more memory usage due to tracking overhead. q_malloc was the
default for 3.1, that's why I asked because the trace showed lines from
f_malloc c code.
What is the size of shared memory you start kamailio? Is the default
32MB or you give a different -m parameter value? Was the serve very
loaded? How many such situations did you get so far?
Cheers,
Daniel
On 7/30/12 7:16 PM, Bruno Bresciani wrote:
> Hi,
>
> Bellow is output of 'kamailio -V'...
>
> ------------------------------------------------------------------------------------------------------------------
> version: kamailio 3.1.2 (i386/linux) 4d9f90
> 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, F_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, PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 4d9f90
> compiled on 10:39:54 Apr 29 2011 with gcc 4.1.2
> -------------------------------------------------------------------------------------------------------------------
>
> Daniel, I don't remember to enable f_malloc... Actually I do not know
> the difference between f_malloc and g_malloc to choose compile
> kamailio with f_malloc instead of g_malloc.
> My commands to compile kamailio were:
> *
> $ make PREFIX="/home2/local/kamailio" FLAVOUR=kamailio
> include_modules="db_postgres tls" MEMDBG=0 cfg**
> $ make all
> $ make install*
>
> If you need more informations, I am available...
>
> Best Regards
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> can you provide output of 'kamailio -V'? Did you enable f_malloc
> instead of q_malloc which was default in 3.1?
>
> Cheers,
> Daniel
>
>
> On 7/30/12 1:44 PM, Bruno Bresciani wrote:
>> Thank's for feedback Daniel,
>>
>> This core is add to the tracker with ID 247...
>>
>> Best Regards
>>
>>
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>>
>>
>> Hello,
>>
>> it is in my to-do list to investigate, so far I was not able
>> to reproduce.
>>
>> Vacation time together with other travelings makes a bit more
>> slower process. Please add it also to the tracker:
>>
>> http://sip-router.org/tracker/
>>
>> A minor release for 3.3 branch is going to be soon, being
>> there makes sure it will be reviewed to see if it applies.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/27/12 3:00 PM, Bruno Bresciani wrote:
>>> Hi Users,
>>>
>>> This is my ultimate try to ask for some help to debug the
>>> two cores generated by fm_realloc() function. If somebody
>>> can give me a feedback about my questions or doubts I will
>>> be very grateful, this user list of kamailio always help me
>>> to solve my problems.
>>>
>>> Best Regards
>>>
>>>
>>> 2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com
>>> <mailto:bruno.bresciani at gmail.com>>
>>>
>>> Hi All,
>>>
>>> I imagine that this core doesn't easy to replicate but
>>> somebody can help me to understand why it was
>>> generated? There is some way to prevent it?
>>>
>>> Best Regards
>>>
>>>
>>>
>>> 2012/7/18 Renan Capaverde
>>> <renan.capaverde at digitro.com.br
>>> <mailto:renan.capaverde at digitro.com.br>>
>>>
>>> I am having the same problem on kamailio 3.1.6.
>>> Someone please help.
>>>
>>> Cheers,
>>> Renan
>>>
>>> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>>>> Excuse-me Daniel, I forgot this information...
>>>> Kamailio version 3.1.2
>>>>
>>>> Best Regards
>>>>
>>>>
>>>> 2012/7/17 Daniel-Constantin Mierla
>>>> <miconda at gmail.com <mailto:miconda at gmail.com>>
>>>>
>>>> Hello,
>>>>
>>>> send also the version 'kamailio -V' to match
>>>> the proper sources.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>>>> Hi all,
>>>>>
>>>>> I observed two at 0x08173bf0 in fm_realloc
>>>>> (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
>>>>> mem/f_malloc.c:536.
>>>>>
>>>>> I don't know exactly what may be caused this
>>>>> core because the debug of kamailio is
>>>>> disabled, but looking at backtrace (gdb) and
>>>>> source code I could notice a relationship with
>>>>> TLS connection establishment (handshake).
>>>>> Other important fact is that core was
>>>>> generated by the kamalio itself with signal 6
>>>>> (abort) because it can't find the pointer to
>>>>> memory realloc.
>>>>> I'd like to know if someone already observed
>>>>> this issue and if my analyse above is correct?
>>>>>
>>>>> Bellow is backtrace full with gdb:
>>>>>
>>>>> Core was generated by
>>>>> `/home2/local/kamailio/sbin/kamailio -P
>>>>> /var/run/kamailio.pid'.
>>>>> Program terminated with signal 6, Aborted.
>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>> (gdb)
>>>>> (gdb)
>>>>> (gdb)
>>>>> (gdb)
>>>>> (gdb) bt full
>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>> No symbol table info available.
>>>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>>>> No symbol table info available.
>>>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>>>> No symbol table info available.
>>>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>>>>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536
>>>>> f = (struct fm_frag *) 0xb61f0bb8
>>>>> pf = <value optimized out>
>>>>> orig_size = 18
>>>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>>>> ptr = <value optimized out>
>>>>> hash = 23548
>>>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0,
>>>>> size=32) at ../../mem/shm_mem.h:266
>>>>> No locals.
>>>>> #5 0x00460295 in OPENSSL_cleanse () from
>>>>> /lib/libcrypto.so.6
>>>>> No symbol table info available.
>>>>> #6 0x004609f7 in CRYPTO_realloc () from
>>>>> /lib/libcrypto.so.6
>>>>> No symbol table info available.
>>>>> #7 0x003efb22 in sk_insert () from
>>>>> /lib/libcrypto.so.6
>>>>> No symbol table info available.
>>>>> #8 0x003efbaa in sk_push () from
>>>>> /lib/libcrypto.so.6
>>>>> No symbol table info available.
>>>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list ()
>>>>> from /lib/libssl.so.6
>>>>> No symbol table info available.
>>>>> #10 0x007aa9f3 in ssl3_get_client_hello ()
>>>>> from /lib/libssl.so.6
>>>>> No symbol table info available.
>>>>> #11 0x007ab815 in ssl3_accept () from
>>>>> /lib/libssl.so.6
>>>>> No symbol table info available.
>>>>> #12 0x007c1c3a in SSL_accept () from
>>>>> /lib/libssl.so.6
>>>>> No symbol table info available.
>>>>> #13 0x005278e3 in tls_accept (c=0xb621af88,
>>>>> error=0xbf91dfc8) at tls_server.c:346
>>>>> ret = <value optimized out>
>>>>> ssl = (SSL *) 0xb61c1878
>>>>> cert = <value optimized out>
>>>>> tls_c = (struct tls_extra_data *)
>>>>> 0xb6208e58
>>>>> tls_log = <value optimized out>
>>>>> #14 0x0052da8e in tls_read_f (c=0xb621af88,
>>>>> flags=0xbf91e200) at tls_server.c:1028
>>>>> r = (struct tcp_req *) 0xb621affc
>>>>> bytes_free = 4095
>>>>> bytes_read = 70
>>>>> read_size = 4095
>>>>> ssl_error = 0
>>>>> ssl_read = 0
>>>>> ssl = (SSL *) 0xb61c1878
>>>>> rd_buf =
>>>>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>>>> wr_buf =
>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>>>> rd = {buf = 0xbf90dfa4 "\026\003\001",
>>>>> pos = 70, used = 70, size = 65536}
>>>>> wr = {
>>>>> buf = 0xbf8fdfa4
>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>>>> pos = 0, used = 0,
>>>>> size = 65536}
>>>>> tls_c = (struct tls_extra_data *)
>>>>> 0xb6208e58
>>>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>>>> n = 0
>>>>> flush_flags = <value optimized out>
>>>>> err_src = 0x541a83 "TLS read:"
>>>>> x = <value optimized out>
>>>>> #15 0x08158ade in tcp_read_headers
>>>>> (c=0xb621af88, read_flags=0xbf91e200) at
>>>>> tcp_read.c:406
>>>>> bytes = -1
>>>>> remaining = <value optimized out>
>>>>> p = <value optimized out>
>>>>> r = (struct tcp_req *) 0xb621affc
>>>>> #16 0x08158fd4 in tcp_read_req
>>>>> (con=0xb621af88, bytes_read=0xbf91e204,
>>>>> read_flags=0xbf91e200) at tcp_read.c:871
>>>>> bytes = <value optimized out>
>>>>> total_bytes = 0
>>>>> resp = <value optimized out>
>>>>> size = <value optimized out>
>>>>> req = (struct tcp_req *) 0xb621affc
>>>>> dst = {send_sock = 0x1, to = {s =
>>>>> {sa_family = 57540, sa_data =
>>>>> "\221??\020\000\000\000\000\000\000\000\020\000\000"},
>>>>> sin = {sin_family = 57540,
>>>>> sin_port = 49041, sin_addr = {s_addr =
>>>>> 16}, sin_zero =
>>>>> "\000\000\000\000\020\000\000"}, sin6 =
>>>>> {sin6_family = 57540, sin6_port = 49041,
>>>>> sin6_flowinfo = 16, sin6_addr = {in6_u =
>>>>> {u6_addr8 =
>>>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000",
>>>>> u6_addr16 = {0, 0, 16, 0, 1, 0,
>>>>> 1, 0}, u6_addr32 = {0, 16, 1,
>>>>> 1}}}, sin6_scope_id = 12}}, id = -1080958468,
>>>>> proto = 4 '\004', send_flags = {f = 0 '\0',
>>>>> blst_imask = 0 '\0'}}
>>>>> c = 10 '\n'
>>>>> #17 0x08159a0f in handle_io (fm=0x83296b0,
>>>>> events=1, idx=-1) at tcp_read.c:1150
>>>>> ret = 4
>>>>> n = 4
>>>>> read_flags = 1
>>>>> con = (struct tcp_connection *) 0xb621af88
>>>>> s = 12
>>>>> resp = <value optimized out>
>>>>> t = <value optimized out>
>>>>> #18 0x0815d653 in tcp_receive_loop
>>>>> (unix_sock=35) at io_wait.h:1091
>>>>> No locals.
>>>>> ---Type <return> to continue, or q <return> to
>>>>> quit---
>>>>> #19 0x0812885b in tcp_init_children () at
>>>>> tcp_main.c:4819
>>>>> r = 3
>>>>> reader_fd_1 = 35
>>>>> pid = <value optimized out>
>>>>> si = <value optimized out>
>>>>> #20 0x080ad412 in main_loop () at main.c:1632
>>>>> i = 4
>>>>> pid = <value optimized out>
>>>>> si = (struct socket_info *) 0x0
>>>>> si_desc = "udp receiver child=3
>>>>> sock=192.168.166.31:5060
>>>>> <http://192.168.166.31:5060>\000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>>>> #21 0x080afbe7 in main (argc=3,
>>>>> argv=dwarf2_read_address: Corrupted DWARF
>>>>> expression.
>>>>> ) at main.c:2398
>>>>> cfg_stream = (FILE *) 0x8a2d008
>>>>> c = <value optimized out>
>>>>> r = 0
>>>>> tmp = 0xbf91e674
>>>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>>>> tmp_len = 10492229
>>>>> port = 136192361
>>>>> proto = -1080957480
>>>>> ret = <value optimized out>
>>>>> seed = 21782655
>>>>> rfd = 4
>>>>> debug_save = <value optimized out>
>>>>> debug_flag = 0
>>>>> dont_fork_cnt = 0
>>>>> n_lst = <value optimized out>
>>>>> p = <value optimized out>
>>>>>
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org <mailto:sr-users at 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 at lists.sip-router.org
>>> <mailto:sr-users at 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 at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/d44cf766/attachment-0001.htm>
From bruno.bresciani at gmail.com Mon Jul 30 21:01:25 2012
From: bruno.bresciani at gmail.com (Bruno Bresciani)
Date: Mon, 30 Jul 2012 16:01:25 -0300
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <5016C320.5040402@gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
<CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
<50163CE8.2050903@gmail.com>
<CAKv6MrYOx1iGtUjsiNQwnUnmyBm3m=97BMnGhCVhhgB2gB+mnQ@mail.gmail.com>
<5016AA13.9030806@gmail.com>
<CAKv6Mrb_rO-Lr9t9nvb+RvZfzOHQuNpb5uvnNK1ho_jdOLw24Q@mail.gmail.com>
<5016C320.5040402@gmail.com>
Message-ID: <CAKv6MrYB1kYTuiAKuJNRiEh4rw_AFU2POP4GD+BHD5h9_ru81A@mail.gmail.com>
Hi,
I compiled kamailio with MEMDBG = 0 because I didn't want the memory debug
in kamailio log, but I didn't know these turns on f_malloc and disabling
q_malloc...
Probably the size of shared memory that I start kamailio is 32MB because I
didn't gave a different -m parameter value, exist a command to verify this
information?
At moment that crash happened, there were few registered users agents and
were being made tests with register and calls with TLS protocol. I got only
the two situations that I showed at first email.
Best Regards
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> MEMDBG=0 turns on f_malloc, disabling q_malloc. The token F_MALLOC in the
> kamailio -V output shows f_malloc is in use.
>
> q_malloc is more suitable for debugging, as it keep trace of location in
> the source code that allocates/frees the memory chunks, at the expense of a
> bit more memory usage due to tracking overhead. q_malloc was the default
> for 3.1, that's why I asked because the trace showed lines from f_malloc c
> code.
>
> What is the size of shared memory you start kamailio? Is the default 32MB
> or you give a different -m parameter value? Was the serve very loaded? How
> many such situations did you get so far?
>
> Cheers,
> Daniel
>
>
>
> On 7/30/12 7:16 PM, Bruno Bresciani wrote:
>
> Hi,
>
> Bellow is output of 'kamailio -V'...
>
>
> ------------------------------------------------------------------------------------------------------------------
> version: kamailio 3.1.2 (i386/linux) 4d9f90
> 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,
> F_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, PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 4d9f90
> compiled on 10:39:54 Apr 29 2011 with gcc 4.1.2
>
> -------------------------------------------------------------------------------------------------------------------
>
> Daniel, I don't remember to enable f_malloc... Actually I do not know the
> difference between f_malloc and g_malloc to choose compile kamailio with
> f_malloc instead of g_malloc.
> My commands to compile kamailio were:
> *
> $ make PREFIX="/home2/local/kamailio" FLAVOUR=kamailio
> include_modules="db_postgres tls" MEMDBG=0 cfg**
> $ make all
> $ make install*
>
> If you need more informations, I am available...
>
> Best Regards
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>
>> Hello,
>>
>> can you provide output of 'kamailio -V'? Did you enable f_malloc instead
>> of q_malloc which was default in 3.1?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/30/12 1:44 PM, Bruno Bresciani wrote:
>>
>> Thank's for feedback Daniel,
>>
>> This core is add to the tracker with ID 247...
>>
>> Best Regards
>>
>>
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>>
>>> Hello,
>>>
>>> it is in my to-do list to investigate, so far I was not able to
>>> reproduce.
>>>
>>> Vacation time together with other travelings makes a bit more slower
>>> process. Please add it also to the tracker:
>>>
>>> http://sip-router.org/tracker/
>>>
>>> A minor release for 3.3 branch is going to be soon, being there makes
>>> sure it will be reviewed to see if it applies.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/27/12 3:00 PM, Bruno Bresciani wrote:
>>>
>>> Hi Users,
>>>
>>> This is my ultimate try to ask for some help to debug the two cores
>>> generated by fm_realloc() function. If somebody can give me a feedback
>>> about my questions or doubts I will be very grateful, this user list of
>>> kamailio always help me to solve my problems.
>>>
>>> Best Regards
>>>
>>>
>>> 2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com>
>>>
>>>> Hi All,
>>>>
>>>> I imagine that this core doesn't easy to replicate but somebody can
>>>> help me to understand why it was generated? There is some way to prevent
>>>> it?
>>>>
>>>> Best Regards
>>>>
>>>>
>>>>
>>>> 2012/7/18 Renan Capaverde <renan.capaverde at digitro.com.br>
>>>>
>>>>> I am having the same problem on kamailio 3.1.6. Someone please help.
>>>>>
>>>>> Cheers,
>>>>> Renan
>>>>>
>>>>> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>>>>>
>>>>> Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> send also the version 'kamailio -V' to match the proper sources.
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>
>>>>>>
>>>>>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>>>>>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536.
>>>>>>
>>>>>> I don't know exactly what may be caused this core because the debug
>>>>>> of kamailio is disabled, but looking at backtrace (gdb) and source code I
>>>>>> could notice a relationship with TLS connection establishment (handshake).
>>>>>> Other important fact is that core was generated by the kamalio itself with
>>>>>> signal 6 (abort) because it can't find the pointer to memory realloc.
>>>>>> I'd like to know if someone already observed this issue and if my
>>>>>> analyse above is correct?
>>>>>>
>>>>>> Bellow is backtrace full with gdb:
>>>>>>
>>>>>> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>>>>>> /var/run/kamailio.pid'.
>>>>>> Program terminated with signal 6, Aborted.
>>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>>> (gdb)
>>>>>> (gdb)
>>>>>> (gdb)
>>>>>> (gdb)
>>>>>> (gdb) bt full
>>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>>> No symbol table info available.
>>>>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>>>>> No symbol table info available.
>>>>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>>>>> No symbol table info available.
>>>>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
>>>>>> mem/f_malloc.c:536
>>>>>> f = (struct fm_frag *) 0xb61f0bb8
>>>>>> pf = <value optimized out>
>>>>>> orig_size = 18
>>>>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>>>>> ptr = <value optimized out>
>>>>>> hash = 23548
>>>>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
>>>>>> ../../mem/shm_mem.h:266
>>>>>> No locals.
>>>>>> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
>>>>>> No symbol table info available.
>>>>>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>>>>>> No symbol table info available.
>>>>>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>>>>>> No symbol table info available.
>>>>>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>>>>>> No symbol table info available.
>>>>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
>>>>>> No symbol table info available.
>>>>>> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
>>>>>> No symbol table info available.
>>>>>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>>>>>> No symbol table info available.
>>>>>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>>>>>> No symbol table info available.
>>>>>> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
>>>>>> tls_server.c:346
>>>>>> ret = <value optimized out>
>>>>>> ssl = (SSL *) 0xb61c1878
>>>>>> cert = <value optimized out>
>>>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>>>> tls_log = <value optimized out>
>>>>>> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
>>>>>> tls_server.c:1028
>>>>>> r = (struct tcp_req *) 0xb621affc
>>>>>> bytes_free = 4095
>>>>>> bytes_read = 70
>>>>>> read_size = 4095
>>>>>> ssl_error = 0
>>>>>> ssl_read = 0
>>>>>> ssl = (SSL *) 0xb61c1878
>>>>>> rd_buf =
>>>>>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>>>>>
>>>>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>>>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>>>>> wr_buf =
>>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>>>
>>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>>>>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70,
>>>>>> size = 65536}
>>>>>> wr = {
>>>>>> buf = 0xbf8fdfa4
>>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>>>>> pos = 0, used = 0,
>>>>>> size = 65536}
>>>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>>>>> n = 0
>>>>>> flush_flags = <value optimized out>
>>>>>> err_src = 0x541a83 "TLS read:"
>>>>>> x = <value optimized out>
>>>>>> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
>>>>>> read_flags=0xbf91e200) at tcp_read.c:406
>>>>>> bytes = -1
>>>>>> remaining = <value optimized out>
>>>>>> p = <value optimized out>
>>>>>> r = (struct tcp_req *) 0xb621affc
>>>>>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88,
>>>>>> bytes_read=0xbf91e204, read_flags=0xbf91e200) at tcp_read.c:871
>>>>>> bytes = <value optimized out>
>>>>>> total_bytes = 0
>>>>>> resp = <value optimized out>
>>>>>> size = <value optimized out>
>>>>>> req = (struct tcp_req *) 0xb621affc
>>>>>> dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data
>>>>>> = "\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family
>>>>>> = 57540,
>>>>>> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
>>>>>> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port =
>>>>>> 49041,
>>>>>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
>>>>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 =
>>>>>> {0, 0, 16, 0, 1, 0,
>>>>>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}},
>>>>>> id = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask =
>>>>>> 0 '\0'}}
>>>>>> c = 10 '\n'
>>>>>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
>>>>>> tcp_read.c:1150
>>>>>> ret = 4
>>>>>> n = 4
>>>>>> read_flags = 1
>>>>>> con = (struct tcp_connection *) 0xb621af88
>>>>>> s = 12
>>>>>> resp = <value optimized out>
>>>>>> t = <value optimized out>
>>>>>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
>>>>>> No locals.
>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>>>>>> r = 3
>>>>>> reader_fd_1 = 35
>>>>>> pid = <value optimized out>
>>>>>> si = <value optimized out>
>>>>>> #20 0x080ad412 in main_loop () at main.c:1632
>>>>>> i = 4
>>>>>> pid = <value optimized out>
>>>>>> si = (struct socket_info *) 0x0
>>>>>> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
>>>>>> \000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>>>>> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted
>>>>>> DWARF expression.
>>>>>> ) at main.c:2398
>>>>>> cfg_stream = (FILE *) 0x8a2d008
>>>>>> c = <value optimized out>
>>>>>> r = 0
>>>>>> tmp = 0xbf91e674
>>>>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>>>>> tmp_len = 10492229
>>>>>> port = 136192361
>>>>>> proto = -1080957480
>>>>>> ret = <value optimized out>
>>>>>> seed = 21782655
>>>>>> rfd = 4
>>>>>> debug_save = <value optimized out>
>>>>>> debug_flag = 0
>>>>>> dont_fork_cnt = 0
>>>>>> n_lst = <value optimized out>
>>>>>> p = <value optimized out>
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120730/addc8c3c/attachment-0001.htm>
From miconda at gmail.com Tue Jul 31 08:24:05 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 31 Jul 2012 08:24:05 +0200
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <CAKv6MrYB1kYTuiAKuJNRiEh4rw_AFU2POP4GD+BHD5h9_ru81A@mail.gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
<CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
<50163CE8.2050903@gmail.com>
<CAKv6MrYOx1iGtUjsiNQwnUnmyBm3m=97BMnGhCVhhgB2gB+mnQ@mail.gmail.com>
<5016AA13.9030806@gmail.com>
<CAKv6Mrb_rO-Lr9t9nvb+RvZfzOHQuNpb5uvnNK1ho_jdOLw24Q@mail.gmail.com>
<5016C320.5040402@gmail.com>
<CAKv6MrYB1kYTuiAKuJNRiEh4rw_AFU2POP4GD+BHD5h9_ru81A@mail.gmail.com>
Message-ID: <50177A05.5020104@gmail.com>
Hello,
On 7/30/12 9:01 PM, Bruno Bresciani wrote:
> Hi,
>
> I compiled kamailio with MEMDBG = 0 because I didn't want the memory
> debug in kamailio log, but I didn't know these turns on f_malloc and
> disabling q_malloc...
the log messages related to memory operations can be controlled by
global parameters memdbg and memlog.
>
> Probably the size of shared memory that I start kamailio is 32MB
> because I didn't gave a different -m parameter value, exist a command
> to verify this information?
kamctl fifo get_statistics all
and see the shared memory total value. It will be interesting to see
available shared memory as well.
>
> At moment that crash happened, there were few registered users agents
> and were being made tests with register and calls with TLS protocol. I
> got only the two situations that I showed at first email.
If you plan to start a new installation, I strongly recommend 3.3
branch, the code is more actual and easier to debug. 3.1 is no longer an
official maintained branch, those being now 3.3 and 3.2. I'm looking at
this issue to be sure it is no longer in latest stable.
Cheers,
Daniel
>
>
> Best Regards
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
>
> Hello,
>
> MEMDBG=0 turns on f_malloc, disabling q_malloc. The token F_MALLOC
> in the kamailio -V output shows f_malloc is in use.
>
> q_malloc is more suitable for debugging, as it keep trace of
> location in the source code that allocates/frees the memory
> chunks, at the expense of a bit more memory usage due to tracking
> overhead. q_malloc was the default for 3.1, that's why I asked
> because the trace showed lines from f_malloc c code.
>
> What is the size of shared memory you start kamailio? Is the
> default 32MB or you give a different -m parameter value? Was the
> serve very loaded? How many such situations did you get so far?
>
> Cheers,
> Daniel
>
>
>
> On 7/30/12 7:16 PM, Bruno Bresciani wrote:
>> Hi,
>>
>> Bellow is output of 'kamailio -V'...
>>
>> ------------------------------------------------------------------------------------------------------------------
>> version: kamailio 3.1.2 (i386/linux) 4d9f90
>> 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, F_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, PKG_SIZE 4MB
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>> id: 4d9f90
>> compiled on 10:39:54 Apr 29 2011 with gcc 4.1.2
>> -------------------------------------------------------------------------------------------------------------------
>>
>> Daniel, I don't remember to enable f_malloc... Actually I do not
>> know the difference between f_malloc and g_malloc to choose
>> compile kamailio with f_malloc instead of g_malloc.
>> My commands to compile kamailio were:
>> *
>> $ make PREFIX="/home2/local/kamailio" FLAVOUR=kamailio
>> include_modules="db_postgres tls" MEMDBG=0 cfg**
>> $ make all
>> $ make install*
>>
>> If you need more informations, I am available...
>>
>> Best Regards
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>>
>>
>> Hello,
>>
>> can you provide output of 'kamailio -V'? Did you enable
>> f_malloc instead of q_malloc which was default in 3.1?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/30/12 1:44 PM, Bruno Bresciani wrote:
>>> Thank's for feedback Daniel,
>>>
>>> This core is add to the tracker with ID 247...
>>>
>>> Best Regards
>>>
>>>
>>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com
>>> <mailto:miconda at gmail.com>>
>>>
>>> Hello,
>>>
>>> it is in my to-do list to investigate, so far I was not
>>> able to reproduce.
>>>
>>> Vacation time together with other travelings makes a bit
>>> more slower process. Please add it also to the tracker:
>>>
>>> http://sip-router.org/tracker/
>>>
>>> A minor release for 3.3 branch is going to be soon,
>>> being there makes sure it will be reviewed to see if it
>>> applies.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/27/12 3:00 PM, Bruno Bresciani wrote:
>>>> Hi Users,
>>>>
>>>> This is my ultimate try to ask for some help to debug
>>>> the two cores generated by fm_realloc() function. If
>>>> somebody can give me a feedback about my questions or
>>>> doubts I will be very grateful, this user list of
>>>> kamailio always help me to solve my problems.
>>>>
>>>> Best Regards
>>>>
>>>>
>>>> 2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com
>>>> <mailto:bruno.bresciani at gmail.com>>
>>>>
>>>> Hi All,
>>>>
>>>> I imagine that this core doesn't easy to replicate
>>>> but somebody can help me to understand why it was
>>>> generated? There is some way to prevent it?
>>>>
>>>> Best Regards
>>>>
>>>>
>>>>
>>>> 2012/7/18 Renan Capaverde
>>>> <renan.capaverde at digitro.com.br
>>>> <mailto:renan.capaverde at digitro.com.br>>
>>>>
>>>> I am having the same problem on kamailio 3.1.6.
>>>> Someone please help.
>>>>
>>>> Cheers,
>>>> Renan
>>>>
>>>> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>>>>> Excuse-me Daniel, I forgot this information...
>>>>> Kamailio version 3.1.2
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>> 2012/7/17 Daniel-Constantin Mierla
>>>>> <miconda at gmail.com <mailto:miconda at gmail.com>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> send also the version 'kamailio -V' to
>>>>> match the proper sources.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I observed two at 0x08173bf0 in
>>>>>> fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0,
>>>>>> size=0) at mem/f_malloc.c:536.
>>>>>>
>>>>>> I don't know exactly what may be caused
>>>>>> this core because the debug of kamailio
>>>>>> is disabled, but looking at backtrace
>>>>>> (gdb) and source code I could notice a
>>>>>> relationship with TLS connection
>>>>>> establishment (handshake). Other
>>>>>> important fact is that core was generated
>>>>>> by the kamalio itself with signal 6
>>>>>> (abort) because it can't find the pointer
>>>>>> to memory realloc.
>>>>>> I'd like to know if someone already
>>>>>> observed this issue and if my analyse
>>>>>> above is correct?
>>>>>>
>>>>>> Bellow is backtrace full with gdb:
>>>>>>
>>>>>> Core was generated by
>>>>>> `/home2/local/kamailio/sbin/kamailio -P
>>>>>> /var/run/kamailio.pid'.
>>>>>> Program terminated with signal 6, Aborted.
>>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>>> (gdb)
>>>>>> (gdb)
>>>>>> (gdb)
>>>>>> (gdb)
>>>>>> (gdb) bt full
>>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>>> No symbol table info available.
>>>>>> #1 0x009fec10 in raise () from
>>>>>> /lib/libc.so.6
>>>>>> No symbol table info available.
>>>>>> #2 0x00a00521 in abort () from
>>>>>> /lib/libc.so.6
>>>>>> No symbol table info available.
>>>>>> #3 0x08173bf0 in fm_realloc
>>>>>> (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at
>>>>>> mem/f_malloc.c:536
>>>>>> f = (struct fm_frag *) 0xb61f0bb8
>>>>>> pf = <value optimized out>
>>>>>> orig_size = 18
>>>>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>>>>> ptr = <value optimized out>
>>>>>> hash = 23548
>>>>>> #4 0x0051a87f in ser_realloc
>>>>>> (ptr=0xb61f0bc0, size=32) at
>>>>>> ../../mem/shm_mem.h:266
>>>>>> No locals.
>>>>>> #5 0x00460295 in OPENSSL_cleanse () from
>>>>>> /lib/libcrypto.so.6
>>>>>> No symbol table info available.
>>>>>> #6 0x004609f7 in CRYPTO_realloc () from
>>>>>> /lib/libcrypto.so.6
>>>>>> No symbol table info available.
>>>>>> #7 0x003efb22 in sk_insert () from
>>>>>> /lib/libcrypto.so.6
>>>>>> No symbol table info available.
>>>>>> #8 0x003efbaa in sk_push () from
>>>>>> /lib/libcrypto.so.6
>>>>>> No symbol table info available.
>>>>>> #9 0x007c2ac3 in
>>>>>> ssl_bytes_to_cipher_list () from
>>>>>> /lib/libssl.so.6
>>>>>> No symbol table info available.
>>>>>> #10 0x007aa9f3 in ssl3_get_client_hello
>>>>>> () from /lib/libssl.so.6
>>>>>> No symbol table info available.
>>>>>> #11 0x007ab815 in ssl3_accept () from
>>>>>> /lib/libssl.so.6
>>>>>> No symbol table info available.
>>>>>> #12 0x007c1c3a in SSL_accept () from
>>>>>> /lib/libssl.so.6
>>>>>> No symbol table info available.
>>>>>> #13 0x005278e3 in tls_accept
>>>>>> (c=0xb621af88, error=0xbf91dfc8) at
>>>>>> tls_server.c:346
>>>>>> ret = <value optimized out>
>>>>>> ssl = (SSL *) 0xb61c1878
>>>>>> cert = <value optimized out>
>>>>>> tls_c = (struct tls_extra_data *)
>>>>>> 0xb6208e58
>>>>>> tls_log = <value optimized out>
>>>>>> #14 0x0052da8e in tls_read_f
>>>>>> (c=0xb621af88, flags=0xbf91e200) at
>>>>>> tls_server.c:1028
>>>>>> r = (struct tcp_req *) 0xb621affc
>>>>>> bytes_free = 4095
>>>>>> bytes_read = 70
>>>>>> read_size = 4095
>>>>>> ssl_error = 0
>>>>>> ssl_read = 0
>>>>>> ssl = (SSL *) 0xb61c1878
>>>>>> rd_buf =
>>>>>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>>>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>>>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>>>>> wr_buf =
>>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>>>>> rd = {buf = 0xbf90dfa4
>>>>>> "\026\003\001", pos = 70, used = 70, size
>>>>>> = 65536}
>>>>>> wr = {
>>>>>> buf = 0xbf8fdfa4
>>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>>>>> pos = 0, used = 0,
>>>>>> size = 65536}
>>>>>> tls_c = (struct tls_extra_data *)
>>>>>> 0xb6208e58
>>>>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>>>>> n = 0
>>>>>> flush_flags = <value optimized out>
>>>>>> err_src = 0x541a83 "TLS read:"
>>>>>> x = <value optimized out>
>>>>>> #15 0x08158ade in tcp_read_headers
>>>>>> (c=0xb621af88, read_flags=0xbf91e200) at
>>>>>> tcp_read.c:406
>>>>>> bytes = -1
>>>>>> remaining = <value optimized out>
>>>>>> p = <value optimized out>
>>>>>> r = (struct tcp_req *) 0xb621affc
>>>>>> #16 0x08158fd4 in tcp_read_req
>>>>>> (con=0xb621af88, bytes_read=0xbf91e204,
>>>>>> read_flags=0xbf91e200) at tcp_read.c:871
>>>>>> bytes = <value optimized out>
>>>>>> total_bytes = 0
>>>>>> resp = <value optimized out>
>>>>>> size = <value optimized out>
>>>>>> req = (struct tcp_req *) 0xb621affc
>>>>>> dst = {send_sock = 0x1, to = {s =
>>>>>> {sa_family = 57540, sa_data =
>>>>>> "\221??\020\000\000\000\000\000\000\000\020\000\000"},
>>>>>> sin = {sin_family = 57540,
>>>>>> sin_port = 49041, sin_addr =
>>>>>> {s_addr = 16}, sin_zero =
>>>>>> "\000\000\000\000\020\000\000"}, sin6 =
>>>>>> {sin6_family = 57540, sin6_port = 49041,
>>>>>> sin6_flowinfo = 16, sin6_addr = {in6_u =
>>>>>> {u6_addr8 =
>>>>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000",
>>>>>> u6_addr16 = {0, 0, 16, 0, 1, 0,
>>>>>> 1, 0}, u6_addr32 = {0, 16, 1,
>>>>>> 1}}}, sin6_scope_id = 12}}, id =
>>>>>> -1080958468, proto = 4 '\004', send_flags
>>>>>> = {f = 0 '\0', blst_imask = 0 '\0'}}
>>>>>> c = 10 '\n'
>>>>>> #17 0x08159a0f in handle_io
>>>>>> (fm=0x83296b0, events=1, idx=-1) at
>>>>>> tcp_read.c:1150
>>>>>> ret = 4
>>>>>> n = 4
>>>>>> read_flags = 1
>>>>>> con = (struct tcp_connection *)
>>>>>> 0xb621af88
>>>>>> s = 12
>>>>>> resp = <value optimized out>
>>>>>> t = <value optimized out>
>>>>>> #18 0x0815d653 in tcp_receive_loop
>>>>>> (unix_sock=35) at io_wait.h:1091
>>>>>> No locals.
>>>>>> ---Type <return> to continue, or q
>>>>>> <return> to quit---
>>>>>> #19 0x0812885b in tcp_init_children () at
>>>>>> tcp_main.c:4819
>>>>>> r = 3
>>>>>> reader_fd_1 = 35
>>>>>> pid = <value optimized out>
>>>>>> si = <value optimized out>
>>>>>> #20 0x080ad412 in main_loop () at main.c:1632
>>>>>> i = 4
>>>>>> pid = <value optimized out>
>>>>>> si = (struct socket_info *) 0x0
>>>>>> si_desc = "udp receiver child=3
>>>>>> sock=192.168.166.31:5060
>>>>>> <http://192.168.166.31:5060>\000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>>>>> #21 0x080afbe7 in main (argc=3,
>>>>>> argv=dwarf2_read_address: Corrupted DWARF
>>>>>> expression.
>>>>>> ) at main.c:2398
>>>>>> cfg_stream = (FILE *) 0x8a2d008
>>>>>> c = <value optimized out>
>>>>>> r = 0
>>>>>> tmp = 0xbf91e674
>>>>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>>>>> tmp_len = 10492229
>>>>>> port = 136192361
>>>>>> proto = -1080957480
>>>>>> ret = <value optimized out>
>>>>>> seed = 21782655
>>>>>> rfd = 4
>>>>>> debug_save = <value optimized out>
>>>>>> debug_flag = 0
>>>>>> dont_fork_cnt = 0
>>>>>> n_lst = <value optimized out>
>>>>>> p = <value optimized out>
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>>>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>> sr-users at lists.sip-router.org <mailto:sr-users at 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 at lists.sip-router.org
>>>> <mailto:sr-users at 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 at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/04e46e7a/attachment-0001.htm>
From miconda at gmail.com Tue Jul 31 08:40:02 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 31 Jul 2012 08:40:02 +0200
Subject: [SR-Users] planning release of v3.3.1
Message-ID: <50177DC2.8080505@gmail.com>
Hello,
I am planning to package v3.3.1 out of the latest branch 3.3 this
Thursday, August 2. If you are aware of issues that are not listed on
the tracker (http://sip-router.org/tracker/), add them there to see what
can be sorted out before.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Tue Jul 31 08:42:55 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 31 Jul 2012 08:42:55 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <CALiegfm4RzkYXLamBLE3oZc=kT2C1Ki0wcEkQu7T9NVJEgByyw@mail.gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
<5016BE2F.6010300@gmail.com>
<CALiegfm4RzkYXLamBLE3oZc=kT2C1Ki0wcEkQu7T9NVJEgByyw@mail.gmail.com>
Message-ID: <50177E6F.4030003@gmail.com>
Hello,
On 7/30/12 7:23 PM, I?aki Baz Castillo wrote:
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>:
>> quick question to double check if what I understood when I read the specs
>> was ok -- in gruu/ob, it does not matter anymore the callid/cseq
>> combination, or there should still be some checks related to it?
> In fact that depends on Outbound instead of GRUU, and not, when using
> Outbound the registrar does NOT check the Call-ID and CSeq of the
> REGISTER (and using GRUU means that Outbound is also used, so the
> Contact has a +sip.instance and reg-id params which are inspected by
> the registrar to create/update/delete a binding).
but what about same callid with lower cseq, combined with same sip
instance and reg-id?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From miconda at gmail.com Tue Jul 31 08:56:02 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 31 Jul 2012 08:56:02 +0200
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <5007089F.708@digitro.com.br>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
Message-ID: <50178182.3090407@gmail.com>
Hello,
do you have a backtrace that you can send just to compare with the one
from Bruno?
Also, send the output of 'kamailio -V' to look at compile flags. Bruno
had a custom compile time flag, a matter of that a different memory
manager was used comparing with the default one for 3.1 series. If you
have the default one, it may include more info that can give some hints.
Cheers,
Daniel
On 7/18/12 9:03 PM, Renan Capaverde wrote:
> I am having the same problem on kamailio 3.1.6. Someone please help.
>
> Cheers,
> Renan
>
> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>> Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
>>
>> Best Regards
>>
>>
>> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>>
>>
>> Hello,
>>
>> send also the version 'kamailio -V' to match the proper sources.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>> Hi all,
>>>
>>> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536.
>>>
>>> I don't know exactly what may be caused this core because the
>>> debug of kamailio is disabled, but looking at backtrace (gdb)
>>> and source code I could notice a relationship with TLS
>>> connection establishment (handshake). Other important fact is
>>> that core was generated by the kamalio itself with signal 6
>>> (abort) because it can't find the pointer to memory realloc.
>>> I'd like to know if someone already observed this issue and if
>>> my analyse above is correct?
>>>
>>> Bellow is backtrace full with gdb:
>>>
>>> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>>> /var/run/kamailio.pid'.
>>> Program terminated with signal 6, Aborted.
>>> #0 0x00f30402 in __kernel_vsyscall ()
>>> (gdb)
>>> (gdb)
>>> (gdb)
>>> (gdb)
>>> (gdb) bt full
>>> #0 0x00f30402 in __kernel_vsyscall ()
>>> No symbol table info available.
>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>> No symbol table info available.
>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>> No symbol table info available.
>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0,
>>> size=0) at mem/f_malloc.c:536
>>> f = (struct fm_frag *) 0xb61f0bb8
>>> pf = <value optimized out>
>>> orig_size = 18
>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>> ptr = <value optimized out>
>>> hash = 23548
>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
>>> ../../mem/shm_mem.h:266
>>> No locals.
>>> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>>> No symbol table info available.
>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>>> No symbol table info available.
>>> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
>>> tls_server.c:346
>>> ret = <value optimized out>
>>> ssl = (SSL *) 0xb61c1878
>>> cert = <value optimized out>
>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>> tls_log = <value optimized out>
>>> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
>>> tls_server.c:1028
>>> r = (struct tcp_req *) 0xb621affc
>>> bytes_free = 4095
>>> bytes_read = 70
>>> read_size = 4095
>>> ssl_error = 0
>>> ssl_read = 0
>>> ssl = (SSL *) 0xb61c1878
>>> rd_buf =
>>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>> wr_buf =
>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used =
>>> 70, size = 65536}
>>> wr = {
>>> buf = 0xbf8fdfa4
>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>> pos = 0, used = 0,
>>> size = 65536}
>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>> n = 0
>>> flush_flags = <value optimized out>
>>> err_src = 0x541a83 "TLS read:"
>>> x = <value optimized out>
>>> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
>>> read_flags=0xbf91e200) at tcp_read.c:406
>>> bytes = -1
>>> remaining = <value optimized out>
>>> p = <value optimized out>
>>> r = (struct tcp_req *) 0xb621affc
>>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88,
>>> bytes_read=0xbf91e204, read_flags=0xbf91e200) at tcp_read.c:871
>>> bytes = <value optimized out>
>>> total_bytes = 0
>>> resp = <value optimized out>
>>> size = <value optimized out>
>>> req = (struct tcp_req *) 0xb621affc
>>> dst = {send_sock = 0x1, to = {s = {sa_family = 57540,
>>> sa_data = "\221??\020\000\000\000\000\000\000\000\020\000\000"},
>>> sin = {sin_family = 57540,
>>> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
>>> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540,
>>> sin6_port = 49041,
>>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000",
>>> u6_addr16 = {0, 0, 16, 0, 1, 0,
>>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id =
>>> 12}}, id = -1080958468, proto = 4 '\004', send_flags = {f = 0
>>> '\0', blst_imask = 0 '\0'}}
>>> c = 10 '\n'
>>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
>>> tcp_read.c:1150
>>> ret = 4
>>> n = 4
>>> read_flags = 1
>>> con = (struct tcp_connection *) 0xb621af88
>>> s = 12
>>> resp = <value optimized out>
>>> t = <value optimized out>
>>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
>>> No locals.
>>> ---Type <return> to continue, or q <return> to quit---
>>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>>> r = 3
>>> reader_fd_1 = 35
>>> pid = <value optimized out>
>>> si = <value optimized out>
>>> #20 0x080ad412 in main_loop () at main.c:1632
>>> i = 4
>>> pid = <value optimized out>
>>> si = (struct socket_info *) 0x0
>>> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
>>> <http://192.168.166.31:5060>\000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address:
>>> Corrupted DWARF expression.
>>> ) at main.c:2398
>>> cfg_stream = (FILE *) 0x8a2d008
>>> c = <value optimized out>
>>> r = 0
>>> tmp = 0xbf91e674
>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>> tmp_len = 10492229
>>> port = 136192361
>>> proto = -1080957480
>>> ret = <value optimized out>
>>> seed = 21782655
>>> rfd = 4
>>> debug_save = <value optimized out>
>>> debug_flag = 0
>>> dont_fork_cnt = 0
>>> n_lst = <value optimized out>
>>> p = <value optimized out>
>>>
>>>
>>> Best Regards
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org <mailto:sr-users at 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://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/bae4ff7e/attachment-0001.htm>
From miconda at gmail.com Tue Jul 31 08:58:21 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 31 Jul 2012 08:58:21 +0200
Subject: [SR-Users] routing based on username
In-Reply-To: <CACcFbj4NVQ_c1qAcrF1qcvOaovp28aSd2BR-9ZhDg_m2FWHJVA@mail.gmail.com>
References: <CACcFbj4NVQ_c1qAcrF1qcvOaovp28aSd2BR-9ZhDg_m2FWHJVA@mail.gmail.com>
Message-ID: <5017820D.7040704@gmail.com>
Hello,
On 7/30/12 10:56 AM, Richard Zheng wrote:
> Hi,
>
> We are trying to follow
> http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb
> to setup Kamailio as front end and multiple PBXs as back end.
>
> We need to forward sip messages to the respective servers based on the
> contact. For example, users 101, 102 go to PBX at 1.1.1.1 and users
> 201, 202 go to PBX at 1.1.1.2. Where is a good place to save this
> info and how to route them in the config?
you can use modules such as pdt, lcr, carrierroute or drouting to route
based on longest prefix matching.
>
> Also we have some users with fixed IP addresses which don't use
> authentication. How do we route the calls based on source IP? Since
> we have plenty of these users, we'd like to save them in database too.
Use permissions module for IP authentication, default configuration file
has some parts withing WITH_IPAUTH define that can help you getting started.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From brandon at cryy.com Tue Jul 31 09:25:19 2012
From: brandon at cryy.com (Brandon Armstead)
Date: Tue, 31 Jul 2012 00:25:19 -0700
Subject: [SR-Users] BYE Race Condition
In-Reply-To: <50163FBF.4000400@gmail.com>
References: <CACr1DbCJ+9mvtGNgev+xrAPaGg3K4nuqzeAf6RsB7FEvfAJ7hg@mail.gmail.com>
<50163FBF.4000400@gmail.com>
Message-ID: <CACr1DbApMW3DxtuEUBgJ315uAo3qzPU9xt5YxCJUEaOCEawfZA@mail.gmail.com>
Daniel,
I will try this -- and get back to you. I noticed the 408 timeout as
well -- and thought that this call flow was strange. Thanks!
Sincerely,
Brandon Armstead
On Mon, Jul 30, 2012 at 1:03 AM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:
> Hello,
>
> first, such race can happen always and it is ok from sip rfc point of
> view. The carrier UA should have received the BYE from the other side and
> close the dialog, then ignore the rest. So it is a broken UA implementation
> imo.
>
> Let's say you just drop the 481, then the BYE will time out (408)? Is the
> carrier UA still complaining? You can make a failure route for BYE and if
> it is 481, then use t_reply("408", "Timeout") if that makes the UA happier.
>
> Cheers,
> Daniel
>
>
> On 7/28/12 8:42 PM, Brandon Armstead wrote:
>
> Hello,
>
> I am running into an issue where there is a race condition happening.
> I am looking for opinions / ideas on how to handle the following below
> scenario.
>
> Scenario.
>
> UAC places an outbound call -> upstream carrier.
>
> The call is disconnected on both ends at the exact same time,
>
> UAC -> sends BYE upstream
>
> Upstream Carrier -> sends BYE downstream
>
> Upstream 200 OK's the BYE
>
> UAC sends 481 back to Upstream Carrier for their generated BYE.
>
> The upstream carrier is complaining about receiving the relayed 481
> responses -- so my first thought was simply to drop() these from relaying
> upstream.
>
> I am curious how other people are handling this?
>
> Would you suggest simply dropping the relay from being sent back
> upstream on the 481?
>
> Would you simply always 200 OK a downstream BYE from trusted carriers
> regardless of UAC response, and create separate transaction to send BYE
> downstream?
>
> Thank you as always. Look forward to your thoughts / suggestions /
> ideas.
>
> Sincerely,
> Brandon Armstead
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/70595e8d/attachment.htm>
From dnotivol at gmail.com Tue Jul 31 10:08:57 2012
From: dnotivol at gmail.com (David Notivol)
Date: Tue, 31 Jul 2012 10:08:57 +0200
Subject: [SR-Users] ACK not relayed
In-Reply-To: <501699B9.9080405@gmail.com>
References: <CAOHrEOB4_qjpLKZse0-92MMspE6N5rTTwg5DrqqsLyRtdxsG8w@mail.gmail.com>
<50163D97.9000805@gmail.com>
<CAOHrEOAuSfOuB7GCMYj2zONcDj9rzXd-k-8hEOZDKKbaqTLmYQ@mail.gmail.com>
<50164A7E.2060905@gmail.com>
<CAOHrEOBXNS2hbYZbMC=qspi0yCgkDr6MWj3xDmwhG9aUhw2dwg@mail.gmail.com>
<5016561D.9060202@gmail.com>
<CAOHrEOBnushqXd59LyENPyinxkepEFFLw-=iFTaB5SUzEsfDMA@mail.gmail.com>
<501699B9.9080405@gmail.com>
Message-ID: <CAOHrEOCGoQmcAuEGUEsy_eYUqa21tDM_emttMgg39gUZWVH+yg@mail.gmail.com>
Hello,
We found out the problem, it was out fault. The ACK was dropped because the
was a previous (and incorrect) evaluation of $rU. Being $null for these
calls, the ACK wasn't relayed. We already fixed it; thanks for the
assistance.
Regards,
David.
2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
> add $si, $ru and $ci in the xlog(...) from the config to compare with
> ngrep trace, maybe there are different ACKs.
>
> Cheers,
> Daniel
>
>
> On 7/30/12 3:55 PM, David Notivol wrote:
>
> Hello,
>
> It looks like the r-uri in the trace is different from the one kamailio
> considers. From the ACK message captured with ngrep:
> ACK sip:200.87.137.150:5060;user=phone SIP/2.0
>
> But form the logs:
> Jul 30 09:15:00 theseus-test /usr/local/kamailio/sbin/kamailio[1577]:
> DEBUG: <core> [parser/msg_parser.c:630]: method: <ACK>
> Jul 30 09:15:00 theseus-test /usr/local/kamailio/sbin/kamailio[1577]:
> DEBUG: <core> [parser/msg_parser.c:632]: uri:
> <sip:59146938249 at 79.170.68.157:5060;user=phone><sip:59146938249 at 79.170.68.157:5060;user=phone>
>
>
> Regards,
> David.
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>
>> Hello,
>>
>> the log message shows that the transaction is not found. Is the ACK
>> coming late after 200ok ? There is a tm module parameter that you can
>> adjust to prolong the time a transaction is kept after completion, if that
>> is the case.
>>
>> Also, be sure the INVITE is sent using tm functions, not stateless via
>> core function.
>>
>> Then, instead of dropping, you can just try forwarding it if the uri si
>> not myself, like adding:
>>
>> if(uri!=myself) t_relay();
>>
>> before the exit.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/30/12 11:10 AM, David Notivol wrote:
>>
>> This is the code that's being executed:
>>
>> route[WITHINDLG] {
>> if (has_totag()) {
>> # sequential request withing a dialog should
>> # take the path determined by record-routing
>> xlog("ESTAMOS EN WITHIN\n");
>> if (loose_route()){
>> xlog("LOOSE ROUTE DETECTED\n");
>> if (is_method("ACK")) {
>> xlog("ES UN ACK\n");
>> }
>> route(BYE);
>> route(RELAY);
>> } else {
>> xlog("NO LOOSE ROUTE\n");
>> if ( is_method("ACK") ) {
>> if ( t_check_trans() ) {
>> xlog("NO LOOSE AND TRANSACTION FOUND\n");
>> # no loose-route, but stateful ACK;
>> # must be an ACK after a 487
>> # or e.g. 404 from upstream server
>> t_relay();
>> exit;
>> } else {
>> xlog("NO LOOSE AND TRANSACTION NOT FOUND\n");
>> # ACK without matching transaction ... ignore and
>> discard
>> exit;
>> }
>> }
>> sl_send_reply("404","Not here");
>> }
>> exit;
>> }
>> }
>>
>>
>> And the call log with cfgtrace. It seems to be clear that the transaction
>> is not matched, but we can't see why.
>>
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=335 a=26 n=xlog
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: <script>: ESTAMOS EN WITHIN
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=360 a=17 n=if
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=336 a=25 n=loose_route
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> DEBUG: rr [loose.c:108]: No Route headers found
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> DEBUG: rr [loose.c:838]: There is no Route HF
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=344 a=26 n=xlog
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: <script>: NO LOOSE ROUTE
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=359 a=17 n=if
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=345 a=26 n=is_method
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=357 a=17 n=if
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=346 a=25 n=t_check_trans
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> DEBUG: tm [t_lookup.c:1079]: DEBUG: t_check_msg: msg id=12 global id=10 T
>> start=(nil)
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=58737,
>> isACK=1
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> DEBUG: tm [t_lookup.c:1148]: DEBUG: t_check_msg: msg id=12 global id=12 T
>> end=(nil)
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=354 a=26 n=xlog
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: <script>: NO LOOSE AND TRANSACTION NOT FOUND
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> ERROR: *** cfgtrace: c=[/usr/local/kamailio/etc/kamailio/kamailio.cfg]
>> l=356 a=3 n=exit
>> Jul 30 04:58:08 theseus-test /usr/local/kamailio/sbin/kamailio[577]:
>> DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list
>> (nil)
>>
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>>
>>> Hello,
>>>
>>> if your config is based on the default one, there is a check for
>>> associated INVITE transaction and if that does not exist, then the ACK is
>>> droppend.
>>>
>>> You can use debugger module with cfgtrace set on in order to see what
>>> actions in the config file are executed. That will help to see if it gets
>>> to t_check_trans() and then exit.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/30/12 10:35 AM, David Notivol wrote:
>>>
>>> Hi Daniel,
>>>
>>> This is the ACK message:
>>>
>>> U 2012/07/30 04:23:31.604721 79.170.68.151:5060 -> 79.170.68.157:5060
>>> ACK sip:200.87.137.150:5060;user=phone SIP/2.0.
>>> Via: SIP/2.0/UDP 79.170.68.151:5060
>>> ;branch=z9hG4bK334faa4497ll114a52eACK450932302031.
>>> Max-Forwards: 70.
>>> Route: <sip:79.170.68.157;lr;ftag=45093230-co8241-INS033>.
>>> To: <sip:59146292331 at 79.170.68.157
>>> ;user=phone;noa=international>;tag=ldb0cbn6-CC-23.
>>> From: "Javi Gallart"<sip:34917019888 at 79.170.68.151
>>> ;user=phone;noa=national>;tag=45093230-co8241-INS033.
>>> Call-ID: 071ae17301d3eb470f5cdde00cd9b24b at ens.com.
>>> CSeq: 824101 ACK.
>>> User-Agent: ENSR3.0.66.34-IS33-RMRG106382-RG105488-CPO13110.
>>> Content-Length: 0.
>>>
>>>
>>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>>>
>>>> Hello,
>>>>
>>>> can you add a log message to print the source ip, call id and r-uri?
>>>>
>>>> It may happen that the ACK is looping back if r-uri is pointing to
>>>> itself.
>>>>
>>>> Also, try to get the ngrep on all devices, like:
>>>>
>>>> ngrep -d any -qt -W byline port 5060
>>>>
>>>> Pasting the ACK request here will help to see if something is wrong
>>>> with it.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 7/30/12 8:53 AM, David Notivol wrote:
>>>>
>>>> In a UAC-Kamailio-UAS scenario, we've found a case where the ACK
>>>> coming from uac is not relayed by our proxy to the uas. This is the log for
>>>> the ACK message:
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:624]: SIP Request:
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:626]: method: <ACK>
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:628]: uri: <sip:59138553189 at 79.170.68.157><sip:59138553189 at 79.170.68.157>
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:630]: version: <SIP/2.0>
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>; state=6
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_via.c:1286]: Found param type 232, <branch> =
>>>> <z9hG4bKKc4gKXyemS9HD>; state=16
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_via.c:2561]: end of header reached, state=5
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:513]: parse_headers: this is the first via
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:149]:
>>>> After parse_msg...
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:190]:
>>>> preparing to run routing scripts...
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl [sl_funcs.c:396]: DEBUG
>>>> : sl_filter_ACK: to late to be a local ACK!
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd [mf_funcs.c:85]:
>>>> value = 65
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_to.c:802]: end of header reached, state=29
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52]; uri=[
>>>> sip:59138553189 at 79.170.68.157]
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:190]: DEBUG: to body [
>>>> <sip:59138553189 at 79.170.68.157> <sip:59138553189 at 79.170.68.157>]
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <31362871> <ACK>
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=0
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/msg_parser.c:104]: found end of header
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core>
>>>> [parser/parse_to.c:802]: end of header reached, state=29
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity [mod_sanity.c:255]:
>>>> sanity checks result: 1
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: siputils [checks.c:106]:
>>>> totag found
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: ESTAMOS EN
>>>> WITHIN
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:108]: No Route
>>>> headers found
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:829]: There is
>>>> no Route HF
>>>> Jul 27 10:04:59 theseus-test
>>>> /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: NO LOOSE ROUTE
>>>>
>>>> However, in a pcap trace I clearly see the Route header:
>>>> This is the Record-Route in the 200 message
>>>> Record-Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>>> And this is the Route header in the ACk:
>>>> Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033>
>>>>
>>>> I haven't been able to figure out what's going on. We have plenty of
>>>> traffic working in that proxy. What am I missing?
>>>>
>>>> Thanks in advance
>>>> David.
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>>
>>>>
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>
>>>
>>
>>
>> --
>> Saludos,
>> David Notivol
>> dnotivol at gmail.com
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/e7ac72fb/attachment-0001.htm>
From infoananthk at gmail.com Tue Jul 31 11:03:52 2012
From: infoananthk at gmail.com (Ananth Kollipara)
Date: Tue, 31 Jul 2012 14:33:52 +0530
Subject: [SR-Users] Add Own Plug-in
Message-ID: <CACJ9FatODfYWEG+y6_U_=-xxsxt65Ca=5FV2NFBQrYw+grS=ZQ@mail.gmail.com>
Hi,
Can you please provide the steps to add a plug-in?
Regards,
Ananth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/7311abed/attachment.htm>
From abalashov at evaristesys.com Tue Jul 31 11:10:36 2012
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 31 Jul 2012 05:10:36 -0400
Subject: [SR-Users] Add Own Plug-in
In-Reply-To: <CACJ9FatODfYWEG+y6_U_=-xxsxt65Ca=5FV2NFBQrYw+grS=ZQ@mail.gmail.com>
References: <CACJ9FatODfYWEG+y6_U_=-xxsxt65Ca=5FV2NFBQrYw+grS=ZQ@mail.gmail.com>
Message-ID: <5017A10C.2020107@evaristesys.com>
On 07/31/2012 05:03 AM, Ananth Kollipara wrote:
> Can you please provide the steps to add a plug-in?
You mean develop a custom module for Kamailio?
You'd want to start here:
http://www.asipto.com/pub/kamailio-devel-guide/
However, perhaps a custom module is not the fastest or most optimal way
to achieve what you want. There may already be facilities to
accommodate your requirements. So, a useful start to the conversation
might be: what do you want to accomplish?
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
From apogrebennyk at sipwise.com Tue Jul 31 12:12:38 2012
From: apogrebennyk at sipwise.com (Andrew Pogrebennyk)
Date: Tue, 31 Jul 2012 12:12:38 +0200
Subject: [SR-Users] New Wiki Site has problems?
Message-ID: <5017AF96.90406@sipwise.com>
At least some links at http://www.kamailio.org/wiki/ don't work at the
moment:
Install Kamailio v3.3.x From GIT
Upgrade Kamailio v3.1.x to v3.2.0
Upgrade Kamailio v3.2.x to v3.3.0
you are redirected to some instruction from DokuWiki Installer when
trying to visit them. Could somebody please check it?
Thanks.
Andrew
From govoiper at gmail.com Tue Jul 31 12:39:35 2012
From: govoiper at gmail.com (SamyGo)
Date: Tue, 31 Jul 2012 15:39:35 +0500
Subject: [SR-Users] routing based on username
In-Reply-To: <5017820D.7040704@gmail.com>
References: <CACcFbj4NVQ_c1qAcrF1qcvOaovp28aSd2BR-9ZhDg_m2FWHJVA@mail.gmail.com>
<5017820D.7040704@gmail.com>
Message-ID: <CAJUJwtiKV+hQJK9uQZmpRH_hbR6sZGZtwwVcmNWQ8xgRimi-vA@mail.gmail.com>
Hi,
I'd suggest you to use multi-domain i.e separate domain for 1XX users and
a separate domain for 2XX users. Then for each domain map their own group
of load-balanced Asterisk servers (not just one server for 1XX clients but
a pool of servers for capacity and fail safe)
Next - if you want your Static IPs to use the same scenario i.e one public
IP goes to defined asterisk(s) then you may need to put in an extra
identifier in permission module's table that will identify the domain
mapping of that static IP, hence as soon as an IP will get authenticated
you will get the digit telling you which group of Asterisk to pick from the
load-balancer and route the call to. It could be one Asterisk for one
group-id or multiple, your choice.
Hope it made some sense.
Thanks
Sammy
On Tue, Jul 31, 2012 at 11:58 AM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:
> Hello,
>
>
> On 7/30/12 10:56 AM, Richard Zheng wrote:
>
>> Hi,
>>
>> We are trying to follow http://kb.asipto.com/asterisk:**
>> realtime:kamailio-3.1.x-**asterisk-1.6.2-astdb<http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb>to setup Kamailio as front end and multiple PBXs as back end.
>>
>> We need to forward sip messages to the respective servers based on the
>> contact. For example, users 101, 102 go to PBX at 1.1.1.1 and users 201,
>> 202 go to PBX at 1.1.1.2. Where is a good place to save this info and how
>> to route them in the config?
>>
> you can use modules such as pdt, lcr, carrierroute or drouting to route
> based on longest prefix matching.
>
>
>
>> Also we have some users with fixed IP addresses which don't use
>> authentication. How do we route the calls based on source IP? Since we
>> have plenty of these users, we'd like to save them in database too.
>>
> Use permissions module for IP authentication, default configuration file
> has some parts withing WITH_IPAUTH define that can help you getting started.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/**miconda<http://www.linkedin.com/in/miconda>
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
> ______________________________**_________________
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/a1750035/attachment.htm>
From miconda at gmail.com Tue Jul 31 12:39:52 2012
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 31 Jul 2012 12:39:52 +0200
Subject: [SR-Users] New Wiki Site has problems?
In-Reply-To: <5017AF96.90406@sipwise.com>
References: <5017AF96.90406@sipwise.com>
Message-ID: <5017B5F8.9010108@gmail.com>
Hello,
fixed -- it happened due to dokuwiki system upgrade.
Cheers,
Daniel
On 7/31/12 12:12 PM, Andrew Pogrebennyk wrote:
> At least some links at http://www.kamailio.org/wiki/ don't work at the
> moment:
>
> Install Kamailio v3.3.x From GIT
> Upgrade Kamailio v3.1.x to v3.2.0
> Upgrade Kamailio v3.2.x to v3.3.0
>
> you are redirected to some instruction from DokuWiki Installer when
> trying to visit them. Could somebody please check it?
>
> Thanks.
> Andrew
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
From jmillan at aliax.net Tue Jul 31 13:59:44 2012
From: jmillan at aliax.net (=?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?=)
Date: Tue, 31 Jul 2012 13:59:44 +0200
Subject: [SR-Users] Outbound and Registrar. No binding update
In-Reply-To: <50177E6F.4030003@gmail.com>
References: <CABw3bnPLyckUJ=UXAJLpDuvdEesmv_Yr3Th45FQDsOR9zxbQTg@mail.gmail.com>
<CALiegf=4kAfdJTdm0foF2rnbTM_War1+2+8KZRLzUk0RiNUGzg@mail.gmail.com>
<50127C9D.7070908@gmail.com>
<CABw3bnMjjeLO8zg3cKLm4ths1t1VFpEFY6A6jpObu1COKzHbrw@mail.gmail.com>
<50165CC2.7050400@gmail.com> <50167004.7060301@gmail.com>
<CALiegf=3nGPYedATnWhqRtwsZyGQZn0_O=7n78QFwv6aBoDu1A@mail.gmail.com>
<5016BE2F.6010300@gmail.com>
<CALiegfm4RzkYXLamBLE3oZc=kT2C1Ki0wcEkQu7T9NVJEgByyw@mail.gmail.com>
<50177E6F.4030003@gmail.com>
Message-ID: <CABw3bnPQBapqcTj7oZNdUEo4PPwLQAoRrkyQE0r9Rd9PiZKChw@mail.gmail.com>
Hi,
Outbound provides the UAC a way to update a binding even if it reboots. For
that, a unique and permanent value of instance-id is used, which in
conjunction with the AoR and reg-id determines the binding to the UAC.
Having said this, I guess that the CSeq comparison between the one in the
Register request and the one in the binding does not apply in this scenario
since it is not guaranteed that a UAC saves the CSeq value of the
registration among reboots.
Regards.
2012/7/31 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
>
> On 7/30/12 7:23 PM, I?aki Baz Castillo wrote:
>
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>:
>>
>>> quick question to double check if what I understood when I read the specs
>>> was ok -- in gruu/ob, it does not matter anymore the callid/cseq
>>> combination, or there should still be some checks related to it?
>>>
>> In fact that depends on Outbound instead of GRUU, and not, when using
>> Outbound the registrar does NOT check the Call-ID and CSeq of the
>> REGISTER (and using GRUU means that Outbound is also used, so the
>> Contact has a +sip.instance and reg-id params which are inspected by
>> the registrar to create/update/delete a binding).
>>
> but what about same callid with lower cseq, combined with same sip
> instance and reg-id?
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/**miconda<http://www.linkedin.com/in/miconda>
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/7f43b84c/attachment.htm>
From alex_solt at hotmail.com Tue Jul 31 15:06:48 2012
From: alex_solt at hotmail.com (Alex Solt)
Date: Tue, 31 Jul 2012 09:06:48 -0400
Subject: [SR-Users] cannot allocate memory & increase shared memory
Message-ID: <COL104-W339B4C7B7571AA6D51FA8B84C50@phx.gbl>
Hi,
We are getting "cannot allocate memory" error in the log file. I was wondering which one is the right way to increase the shared memory:
1) adding the following to /etc/openser/openserctl
STARTOPTIONS="-m 128"
2) modify the following in /etc/default/openser
MEMORY=1024
Thanks,AS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/e8e11286/attachment.htm>
From bruno.bresciani at gmail.com Tue Jul 31 15:39:27 2012
From: bruno.bresciani at gmail.com (Bruno Bresciani)
Date: Tue, 31 Jul 2012 10:39:27 -0300
Subject: [SR-Users] Core fm_realloc function
In-Reply-To: <50177A05.5020104@gmail.com>
References: <CAKv6MrYkEVCs8taSaEXNcV2ohi6yQSLHMAWpAqEc_FK4HAhXFw@mail.gmail.com>
<50059EC2.6060409@gmail.com>
<CAKv6MrY5_+mJ04pvXFfeYMa8HPSSjujEihjRYzu1azzHC+DR6g@mail.gmail.com>
<5007089F.708@digitro.com.br>
<CAKv6Mrauh-2xA4f4H7JMKpUXUFtw+HUJsurwJ8DV+P8v5whmhA@mail.gmail.com>
<CAKv6MrbFb6krEmLiyHWB0Zho2bPOJ3_fSno945An=55WDm42Gw@mail.gmail.com>
<50163CE8.2050903@gmail.com>
<CAKv6MrYOx1iGtUjsiNQwnUnmyBm3m=97BMnGhCVhhgB2gB+mnQ@mail.gmail.com>
<5016AA13.9030806@gmail.com>
<CAKv6Mrb_rO-Lr9t9nvb+RvZfzOHQuNpb5uvnNK1ho_jdOLw24Q@mail.gmail.com>
<5016C320.5040402@gmail.com>
<CAKv6MrYB1kYTuiAKuJNRiEh4rw_AFU2POP4GD+BHD5h9_ru81A@mail.gmail.com>
<50177A05.5020104@gmail.com>
Message-ID: <CAKv6MrZxGYHCTUr3ogtHJJqVYMig1DN7yokMmFHpUkjBPt7cpw@mail.gmail.com>
Hello,
I didn't know that log messages related to memory operations can be
controlled by global parameter, but I like to know if is recommendable I
recompile kamailio using q_malloc (default) and not f_malloc... memory
operations using q_malloc is more reliable and avoid problems or crashes or
it is only more suitable for debugging? What do you suggest Daniel?
The 'get_statistics all' command is avaliable by a specific module? I run
'kamctl fifo get_statistics all' and return '500 command 'get_statistics'
not available'
For while is impossible to start a new installation, first because I don't
know how much time I will spend to port and second because I am involved
with other developments and I have no time to make this. I know that 3.1
is no longer a official branch but now start a new installation it's very
very difficult, my in intention is discover what caused the crash and if
exists a way to fix or prevent it.
Best Regards
2012/7/31 Daniel-Constantin Mierla <miconda at gmail.com>
> Hello,
>
>
> On 7/30/12 9:01 PM, Bruno Bresciani wrote:
>
> Hi,
>
> I compiled kamailio with MEMDBG = 0 because I didn't want the memory
> debug in kamailio log, but I didn't know these turns on f_malloc and
> disabling q_malloc...
>
> the log messages related to memory operations can be controlled by global
> parameters memdbg and memlog.
>
>
>
> Probably the size of shared memory that I start kamailio is 32MB because I
> didn't gave a different -m parameter value, exist a command to verify this
> information?
>
>
> kamctl fifo get_statistics all
>
> and see the shared memory total value. It will be interesting to see
> available shared memory as well.
>
>
>
> At moment that crash happened, there were few registered users agents and
> were being made tests with register and calls with TLS protocol. I got only
> the two situations that I showed at first email.
>
>
> If you plan to start a new installation, I strongly recommend 3.3 branch,
> the code is more actual and easier to debug. 3.1 is no longer an official
> maintained branch, those being now 3.3 and 3.2. I'm looking at this issue
> to be sure it is no longer in latest stable.
>
> Cheers,
> Daniel
>
>
>
>
> Best Regards
>
> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>
>> Hello,
>>
>> MEMDBG=0 turns on f_malloc, disabling q_malloc. The token F_MALLOC in the
>> kamailio -V output shows f_malloc is in use.
>>
>> q_malloc is more suitable for debugging, as it keep trace of location in
>> the source code that allocates/frees the memory chunks, at the expense of a
>> bit more memory usage due to tracking overhead. q_malloc was the default
>> for 3.1, that's why I asked because the trace showed lines from f_malloc c
>> code.
>>
>> What is the size of shared memory you start kamailio? Is the default 32MB
>> or you give a different -m parameter value? Was the serve very loaded? How
>> many such situations did you get so far?
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> On 7/30/12 7:16 PM, Bruno Bresciani wrote:
>>
>> Hi,
>>
>> Bellow is output of 'kamailio -V'...
>>
>>
>> ------------------------------------------------------------------------------------------------------------------
>> version: kamailio 3.1.2 (i386/linux) 4d9f90
>> 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,
>> F_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, PKG_SIZE 4MB
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>> id: 4d9f90
>> compiled on 10:39:54 Apr 29 2011 with gcc 4.1.2
>>
>> -------------------------------------------------------------------------------------------------------------------
>>
>> Daniel, I don't remember to enable f_malloc... Actually I do not know
>> the difference between f_malloc and g_malloc to choose compile kamailio
>> with f_malloc instead of g_malloc.
>> My commands to compile kamailio were:
>> *
>> $ make PREFIX="/home2/local/kamailio" FLAVOUR=kamailio
>> include_modules="db_postgres tls" MEMDBG=0 cfg**
>> $ make all
>> $ make install*
>>
>> If you need more informations, I am available...
>>
>> Best Regards
>>
>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>>
>>> Hello,
>>>
>>> can you provide output of 'kamailio -V'? Did you enable f_malloc instead
>>> of q_malloc which was default in 3.1?
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/30/12 1:44 PM, Bruno Bresciani wrote:
>>>
>>> Thank's for feedback Daniel,
>>>
>>> This core is add to the tracker with ID 247...
>>>
>>> Best Regards
>>>
>>>
>>> 2012/7/30 Daniel-Constantin Mierla <miconda at gmail.com>
>>>
>>>> Hello,
>>>>
>>>> it is in my to-do list to investigate, so far I was not able to
>>>> reproduce.
>>>>
>>>> Vacation time together with other travelings makes a bit more slower
>>>> process. Please add it also to the tracker:
>>>>
>>>> http://sip-router.org/tracker/
>>>>
>>>> A minor release for 3.3 branch is going to be soon, being there makes
>>>> sure it will be reviewed to see if it applies.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 7/27/12 3:00 PM, Bruno Bresciani wrote:
>>>>
>>>> Hi Users,
>>>>
>>>> This is my ultimate try to ask for some help to debug the two cores
>>>> generated by fm_realloc() function. If somebody can give me a feedback
>>>> about my questions or doubts I will be very grateful, this user list of
>>>> kamailio always help me to solve my problems.
>>>>
>>>> Best Regards
>>>>
>>>>
>>>> 2012/7/23 Bruno Bresciani <bruno.bresciani at gmail.com>
>>>>
>>>>> Hi All,
>>>>>
>>>>> I imagine that this core doesn't easy to replicate but somebody can
>>>>> help me to understand why it was generated? There is some way to prevent
>>>>> it?
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>>
>>>>> 2012/7/18 Renan Capaverde <renan.capaverde at digitro.com.br>
>>>>>
>>>>>> I am having the same problem on kamailio 3.1.6. Someone please help.
>>>>>>
>>>>>> Cheers,
>>>>>> Renan
>>>>>>
>>>>>> Em 17/7/2012 14:26, Bruno Bresciani escreveu:
>>>>>>
>>>>>> Excuse-me Daniel, I forgot this information... Kamailio version 3.1.2
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>>
>>>>>> 2012/7/17 Daniel-Constantin Mierla <miconda at gmail.com>
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> send also the version 'kamailio -V' to match the proper sources.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>>
>>>>>>> On 7/17/12 7:11 PM, Bruno Bresciani wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000,
>>>>>>> p=0xb61f0bc0, size=0) at mem/f_malloc.c:536.
>>>>>>>
>>>>>>> I don't know exactly what may be caused this core because the debug
>>>>>>> of kamailio is disabled, but looking at backtrace (gdb) and source code I
>>>>>>> could notice a relationship with TLS connection establishment (handshake).
>>>>>>> Other important fact is that core was generated by the kamalio itself with
>>>>>>> signal 6 (abort) because it can't find the pointer to memory realloc.
>>>>>>> I'd like to know if someone already observed this issue and if my
>>>>>>> analyse above is correct?
>>>>>>>
>>>>>>> Bellow is backtrace full with gdb:
>>>>>>>
>>>>>>> Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>>>>>>> /var/run/kamailio.pid'.
>>>>>>> Program terminated with signal 6, Aborted.
>>>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>>>> (gdb)
>>>>>>> (gdb)
>>>>>>> (gdb)
>>>>>>> (gdb)
>>>>>>> (gdb) bt full
>>>>>>> #0 0x00f30402 in __kernel_vsyscall ()
>>>>>>> No symbol table info available.
>>>>>>> #1 0x009fec10 in raise () from /lib/libc.so.6
>>>>>>> No symbol table info available.
>>>>>>> #2 0x00a00521 in abort () from /lib/libc.so.6
>>>>>>> No symbol table info available.
>>>>>>> #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0)
>>>>>>> at mem/f_malloc.c:536
>>>>>>> f = (struct fm_frag *) 0xb61f0bb8
>>>>>>> pf = <value optimized out>
>>>>>>> orig_size = 18
>>>>>>> L=?b???2n = (struct fm_frag *) 0xb61f0bd2
>>>>>>> ptr = <value optimized out>
>>>>>>> hash = 23548
>>>>>>> #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at
>>>>>>> ../../mem/shm_mem.h:266
>>>>>>> No locals.
>>>>>>> #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6
>>>>>>> No symbol table info available.
>>>>>>> #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6
>>>>>>> No symbol table info available.
>>>>>>> #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6
>>>>>>> No symbol table info available.
>>>>>>> #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6
>>>>>>> No symbol table info available.
>>>>>>> #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6
>>>>>>> No symbol table info available.
>>>>>>> #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6
>>>>>>> No symbol table info available.
>>>>>>> #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6
>>>>>>> No symbol table info available.
>>>>>>> #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6
>>>>>>> No symbol table info available.
>>>>>>> #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at
>>>>>>> tls_server.c:346
>>>>>>> ret = <value optimized out>
>>>>>>> ssl = (SSL *) 0xb61c1878
>>>>>>> cert = <value optimized out>
>>>>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>>>>> tls_log = <value optimized out>
>>>>>>> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at
>>>>>>> tls_server.c:1028
>>>>>>> r = (struct tcp_req *) 0xb621affc
>>>>>>> bytes_free = 4095
>>>>>>> bytes_read = 70
>>>>>>> read_size = 4095
>>>>>>> ssl_error = 0
>>>>>>> ssl_read = 0
>>>>>>> ssl = (SSL *) 0xb61c1878
>>>>>>> rd_buf =
>>>>>>> "\026\003\001\000A\001\000\000=\003\001O??\v??ywP\fk?D?
>>>>>>>
>>>>>>> 0/\000\a\000\005\001\000?????000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00
>>>>>>> 202i<??<????\031??234? \237??030Y){l??"...06?'?r9??????{[??\t\205\037\036??HPH5??\t(??32?027????036??\"\r??Y?215u??\027)??000??215\v?? ??Ea\023x??J\206T\204C?
>>>>>>> wr_buf =
>>>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>>>>
>>>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...
>>>>>>> rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70,
>>>>>>> size = 65536}
>>>>>>> wr = {
>>>>>>> buf = 0xbf8fdfa4
>>>>>>> "\027\003\001\003? w??'\016???033?L?021?)?\220hnL??\020X??\236\200\tIh???Sf\234?\r?
>>>>>>> ?????\024F?\200??/\2264R?a???IpX?????035??Qh\211?026??4?U+\asr??/`??O??1A??qU????v????\205"...,
>>>>>>> pos = 0, used = 0,
>>>>>>> size = 65536}
>>>>>>> tls_c = (struct tls_extra_data *) 0xb6208e58
>>>>>>> enc_rd_buf = (struct tls_rd_buf *) 0x0
>>>>>>> n = 0
>>>>>>> flush_flags = <value optimized out>
>>>>>>> err_src = 0x541a83 "TLS read:"
>>>>>>> x = <value optimized out>
>>>>>>> #15 0x08158ade in tcp_read_headers (c=0xb621af88,
>>>>>>> read_flags=0xbf91e200) at tcp_read.c:406
>>>>>>> bytes = -1
>>>>>>> remaining = <value optimized out>
>>>>>>> p = <value optimized out>
>>>>>>> r = (struct tcp_req *) 0xb621affc
>>>>>>> #16 0x08158fd4 in tcp_read_req (con=0xb621af88,
>>>>>>> bytes_read=0xbf91e204, read_flags=0xbf91e200) at tcp_read.c:871
>>>>>>> bytes = <value optimized out>
>>>>>>> total_bytes = 0
>>>>>>> resp = <value optimized out>
>>>>>>> size = <value optimized out>
>>>>>>> req = (struct tcp_req *) 0xb621affc
>>>>>>> dst = {send_sock = 0x1, to = {s = {sa_family = 57540,
>>>>>>> sa_data = "\221??\020\000\000\000\000\000\000\000\020\000\000"}, sin =
>>>>>>> {sin_family = 57540,
>>>>>>> sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero =
>>>>>>> "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port =
>>>>>>> 49041,
>>>>>>> sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 =
>>>>>>> "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 =
>>>>>>> {0, 0, 16, 0, 1, 0,
>>>>>>> 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id =
>>>>>>> 12}}, id = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0',
>>>>>>> blst_imask = 0 '\0'}}
>>>>>>> c = 10 '\n'
>>>>>>> #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at
>>>>>>> tcp_read.c:1150
>>>>>>> ret = 4
>>>>>>> n = 4
>>>>>>> read_flags = 1
>>>>>>> con = (struct tcp_connection *) 0xb621af88
>>>>>>> s = 12
>>>>>>> resp = <value optimized out>
>>>>>>> t = <value optimized out>
>>>>>>> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091
>>>>>>> No locals.
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>> #19 0x0812885b in tcp_init_children () at tcp_main.c:4819
>>>>>>> r = 3
>>>>>>> reader_fd_1 = 35
>>>>>>> pid = <value optimized out>
>>>>>>> si = <value optimized out>
>>>>>>> #20 0x080ad412 in main_loop () at main.c:1632
>>>>>>> i = 4
>>>>>>> pid = <value optimized out>
>>>>>>> si = (struct socket_info *) 0x0
>>>>>>> si_desc = "udp receiver child=3 sock=192.168.166.31:5060
>>>>>>> \000\221??\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000????21??\001\000\000\000??????026??\000\000\000\000\000???\030s2\b\002\000\000\000??f\b\000???\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000????????????21??"
>>>>>>> #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted
>>>>>>> DWARF expression.
>>>>>>> ) at main.c:2398
>>>>>>> cfg_stream = (FILE *) 0x8a2d008
>>>>>>> c = <value optimized out>
>>>>>>> r = 0
>>>>>>> tmp = 0xbf91e674
>>>>>>> "\212??\221??\233??\221??????\221??????\221???\221????1??\020??\221??D??\221??L??\221??W??\221??]??\221??o??\221??{??\221??\202??\221
>>>>>>> tmp_len = 10492229
>>>>>>> port = 136192361
>>>>>>> proto = -1080957480
>>>>>>> ret = <value optimized out>
>>>>>>> seed = 21782655
>>>>>>> rfd = 4
>>>>>>> debug_save = <value optimized out>
>>>>>>> debug_flag = 0
>>>>>>> dont_fork_cnt = 0
>>>>>>> n_lst = <value optimized out>
>>>>>>> p = <value optimized out>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>>>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>>
>>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120731/1d57b750/attachment-0001.htm>