sr-users May 2016

sr-users@lists.kamailio.org

86 participants
127 discussions

by Hemanshu Vadehra

I'm involved in setting up a Kamailio instance and was hoping to make use of the auth_ephemeral module for authentication. But the module documentation doesn't quite make clear how exactly the module is to be employed or the web service set up. Does anyone have a working example? Regards, Hemanshu Vadehra hemanshu.v(a)directi.com

7 years, 3 months

Siremis installation with postgresql.

by José Seabra

Hi there, I'm facing some issues trying to install siremis with postgresql. The file Config.xml has the correct configuration for postgresql driver but It seems that during installation phase siremis can't create database structure for postgresql. Anyone have installed siremis with postgresql, if yes can you share the steps needed for this installation. -- Cumprimentos José Seabra

7 years, 4 months

Kamailio on Mac

by Carlos Ruiz Díaz

Hi all, I'm switching my development environment from Linux to Mac. Is there any tutorial on how to setup Kamailio on this OS? It may be an Unix flavor, but it's still quite different from Linux :). Thanks, -- Carlos http://caruizdiaz.com http://ngvoice.com +52 55 3048 3303

7 years, 8 months

4.4.1: Only first UDP Listener is producing log messages

by Sebastian Damm

Hi, I upgraded one of our systems today to 4.4.1. And when checking whether everything is okay, I noticed, that only the first UDP listener (from kamcmd core.ps) is actually sending lines to the log. The only other logs I see are from usrloc timer worker. kamcmd> core.ps 10737 main process - attendant 10740 udp receiver child=0 sock=172.20.40.5:5060 10741 udp receiver child=1 sock=172.20.40.5:5060 10742 udp receiver child=2 sock=172.20.40.5:5060 10743 udp receiver child=3 sock=172.20.40.5:5060 We are sending quite a lot of information via xlog("L_NOTICE", "foo"); to syslog, but the only lines I see are from PID 10740. Kamailio works fine otherwise, handling all requests, the usrloc entries didn't drop, and customers don't complain. So I think it's only a logging issue. There are about 50k registrations on the machine and more than 10 Mbit of traffic. When I downgrade to 4.3.5, I get output from all listeners again. Has there been any change between 4.3 and 4.4 regarding logging? The upgrade document says nothing about this. Best Regards, Sebastian

7 years, 9 months

S-CSCF (kamailio) crashes after deregistration of client

by Christoph Valentin

7 years, 9 months

Kamailio 4.3.3 and HUAWEI HG8245. Port 1 call port 2. 481 Call/Transaction Does Not Exist. Warning: 399 No Dialog match.

by Mx R

Hi there. In our network we used several ONT Huawei models. But with one model HUAWEI-EchoLife HG8245 / V1R003C00S205 we have the following problem. When connecting to this device in the POTS ports of the two phones. From the first port we can not call to the second and from the second port can not call to the first port. On the other ONT Huawei devices, there is no such problem. Earlier we had set OpenSIP and this device did not have a problem. The problem is likely in the configuration because it works at the default settings. kamailio -v Version: kamailio 4.3.3 (x86_64/linux) f69971 /var/log/kamailio May 17 10:53:21 kamailio /usr/local/sbin/kamailio[17875]: INFO: <script>: Callee '123456' is local - M=INVITE RURI=sip:123456@10.10.10.200 F= sip:654321@10.10.10.200 T=sip:123456@10.10.10.200 IP=10.14.197.13 5 ID=lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 May 17 10:53:21 kamailio /usr/local/sbin/kamailio[17875]: INFO: <script>: Call control: dst user '123456' currently has [0/2] active calls - M=INVITE RURI=sip:123456@10.10.10.200 F=sip:654321@10.10.10.200 T=si p:123456@10.10.10.200 IP=10.10.10.100 ID= lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 May 17 10:53:21 kamailio /usr/local/sbin/kamailio[17875]: INFO: <script>: Normalize source: sip:654321@10.10.10.200 -> sip:654321@10.10.10.200 May 17 10:53:21 kamailio /usr/local/sbin/kamailio[17875]: INFO: <script>: Request leaving server - M=INVITE RURI=sip:123456@10.10.10.100:5060;transport=udp F=sip:654321@10.10.10.200 T=sip:123456@178.168.4. 37 IP=10.10.10.100 ID=lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 May 17 10:53:22 kamailio /usr/local/sbin/kamailio[17873]: INFO: <script>: Reply - S=100 D=Trying F=sip:654321@10.10.10.200 T=sip:123456@10.10.10.200 IP=10.10.10.100 ID=lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.1 4.197.135 May 17 10:53:22 kamailio /usr/local/sbin/kamailio[17861]: INFO: <script>: Reply - S=481 D=Call/Transaction Does Not Exist F=sip:654321@10.10.10.200 T= sip:123456@10.10.10.200 IP=10.10.10.100 ID= lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 sngrep 2016/05/17 10:53:21.514702 10.10.10.100:5060 -> 10.10.10.200:5060 INVITE sip:123456@10.10.10.200 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.100:5060;branch=z9hG4bKz4j0izm0i8jcn2pmlkm4c24cz Route: <sip:10.10.10.200:5060;transport=udp;lr> Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 From: <sip:654321@10.10.10.200>;tag=pk4nzz3j To: <sip:123456@10.10.10.200> CSeq: 1 INVITE Contact: <sip:654321@10.10.10.100:5060;transport=udp> Supported: 100rel,replaces,timer,privacy,in-dialog Session-Expires: 1800 Accept: application/sdp,application/simservs+xml Min-SE: 90 Accept-Encoding: identity Accept-Language: en Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER Max-Forwards: 70 User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205 Session-ID: 20zlkckj1kz4ll1i1ic2pl1csk80kli1 Content-Length: 318 Content-Type: application/sdp 2016/05/17 10:53:21.590008 10.10.10.100:5060 -> 10.10.10.200:5060 INVITE sip:123456@10.10.10.200 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.100:5060;branch=z9hG4bK0lz4ll1ikm1k02p20lz4ll1il Route: <sip:10.10.10.200:5060;transport=udp;lr> Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 From: <sip:654321@10.10.10.200>;tag=pk4nzz3j To: <sip:123456@10.10.10.200> CSeq: 2 INVITE Contact: <sip:654321@10.10.10.100:5060;transport=udp> Supported: 100rel,replaces,timer,privacy,in-dialog Session-Expires: 1800 Accept: application/sdp,application/simservs+xml Min-SE: 90 Proxy-Authorization: Digest username="654321",realm="10.10.10.200",nonce="VzrPHVc6zfEYftiGlJYC9XLb4ixCZtQB",uri=" sip:123456@10.10.10.200 ",response="55e03b278f1cbdda52852004bbc8d7c9",algorithm=MD5,cnonce="0f31d b",qop=auth,nc=00000006 Accept-Encoding: identity Accept-Language: en Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER Max-Forwards: 70 User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205 Session-ID: 20zlkckj1kz4ll1i1ic2pl1csk80kli1 Content-Length: 318 Content-Type: application/sdp 2016/05/17 10:53:21.642831 10.10.10.200:5060 -> 10.10.10.100:5060 INVITE sip:123456@10.10.10.100:5060;transport=udp SIP/2.0 Record-Route: <sip:10.10.10.200;lr=on;ftag=pk4nzz3j;nat=yes;did=925.a5a1;vst=AAAAAAkLCwgLCnEDBHgfBg4WHwIWHQMuMzc-;vsf=AAAAAAkLAwgLAnEDBHgfBg4WHwIWHQMuMzc-> Via: SIP/2.0/UDP 10.10.10.200;branch=z9hG4bKd55d.f4d5d1ee3d090fe847af101d0a47ac5e.0 Via: SIP/2.0/UDP 10.10.10.100:5060;rport=5060;branch=z9hG4bK0lz4ll1ikm1k02p20lz4ll1il Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 From: "654321" <sip:654321@10.10.10.200>;tag=pk4nzz3j To: <sip:123456@10.10.10.200> CSeq: 2 INVITE Contact: <sip:654321@10.10.10.100:5060;transport=udp> Supported: 100rel,replaces,timer,privacy,in-dialog Session-Expires: 1800 Accept: application/sdp,application/simservs+xml Min-SE: 90 Accept-Encoding: identity Accept-Language: en Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER Max-Forwards: 69 User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205 Content-Length: 334 Content-Type: application/sdp P-Asserted-Identity: <sip:654321@10.10.10.200> 2016/05/17 10:53:22.121872 10.10.10.200:5060 -> 10.10.10.100:5060 INVITE sip:123456@10.10.10.100:5060;transport=udp SIP/2.0 Record-Route: <sip:10.10.10.200;lr=on;ftag=pk4nzz3j;nat=yes;did=925.a5a1;vst=AAAAAAkLCwgLCnEDBHgfBg4WHwIWHQMuMzc-;vsf=AAAAAAkLAwgLAnEDBHgfBg4WHwIWHQMuMzc-> Via: SIP/2.0/UDP 10.10.10.200;branch=z9hG4bKd55d.f4d5d1ee3d090fe847af101d0a47ac5e.0 Via: SIP/2.0/UDP 10.10.10.100:5060;rport=5060;branch=z9hG4bK0lz4ll1ikm1k02p20lz4ll1il Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 From: "654321" <sip:654321@10.10.10.200>;tag=pk4nzz3j To: <sip:123456@10.10.10.200> CSeq: 2 INVITE Contact: <sip:654321@10.10.10.100:5060;transport=udp> Supported: 100rel,replaces,timer,privacy,in-dialog Session-Expires: 1800 Accept: application/sdp,application/simservs+xml Min-SE: 90 Accept-Encoding: identity Accept-Language: en Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER Max-Forwards: 69 User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205 Content-Length: 334 Content-Type: application/sdp P-Asserted-Identity: <sip:654321@10.10.10.200> 2016/05/17 10:53:22.996850 10.10.10.100:5060 -> 10.10.10.200:5060 SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP 10.10.10.200;branch=z9hG4bKd55d.f4d5d1ee3d090fe847af101d0a47ac5e.0,SIP/2.0/UDP 10.10.10.100:5060;branch=z9hG4bK0lz4ll1ikm1k02p20lz4ll1il;rport=5060 Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100 From: "654321"<sip:654321@10.10.10.200>;tag=pk4nzz3j To: <sip:123456@10.10.10.200>;tag=m2scp1cm CSeq: 2 INVITE Warning: 399 10.10.10.100 "SS100006F143L3557[05552] No Dialog match" User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205 Content-Length: 0

7 years, 10 months

question about RTPengine

by Dmitry

hello i read the documentation about RTPengine.and the documentation says that: If INVITE with SDP, when the tm module is loaded, mark transaction with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for rtpengine_answer() what does it mean? actually - according to 3261 RTP media (both ways) may be turned on after ACK

7 years, 10 months

4.4 compiler warnings on debian jessie

by Juha Heinanen

I'll come back to mem/tlsf_malloc.c issue. Camille asked if the compiler warnings on mem/tlsf_malloc.c were occurring on x86 32 bit machine. I now tried and, yes, they do not appear on i386 jessie, but not on amd64 jessie. So looks like this is the same issue that Ovidiu has reported. -- Juha

7 years, 10 months

Wrong Publish status

by Aleš Šturm

Hello, Kamailio 4.3: I am testing Presence module with more complex scenario. I have 2 SIP clients (presentity) with equal identities (3918) and one watcher (2025). All my clients are Monster 0.9.25. My Kamailio Presence module is configured with "retrieve_order=1" (presentity records are retrieve by priority order). I have situation when wrong status is send to the watcher (2025). 1. First all three clients registers and publish its own status. Below is print from my MySQL database (presentity table) mysql> select id,username,priority,expires,received_time,body from presentity ORDER BY received_time DESC; | id | username | priority | expires | received_time | body | 84481 | 3918 | 40 | 1464340695 | 1464337095 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr iding-willingness></dm:person></presence> | | 84480 | 3918 | 40 | 1464340687 | 1464337087 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr iding-willingness></dm:person></presence> | | 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr iding-willingness></dm:person></presence> | 2. Then first 3918 client publishes his mood >11111<. The status in >Presentity< table is refreshed under the id=84480. NOTIFY is sent to 2025 with status with mood >11111<. mysql> select id,username,priority,expires,received_time,body from presentity ORDER BY received_time DESC; | id | username | priority | expires | received_time | body | 84480 | 3918 | 40 | 1464340703 | 1464337103 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><dm:note>11111</dm:note><op:overriding-willingness><opd:basic>op en</opd:basic></op:overriding-willingness></dm:person></presence> | | 84481 | 3918 | 40 | 1464340695 | 1464337095 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr iding-willingness></dm:person></presence> | | 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr iding-willingness></dm:person></presence> | 3. After that the second 3918 client publishes his mood >22222<. The status in >Presentity< table is refreshed under the right id=84481. NOTIFY is sent to 2025 with status with mood >22222<. mysql> select id,username,priority,expires,received_time,body from presentity ORDER BY received_time DESC; | id | username | priority | expires | received_time | body | 84481 | 3918 | 40 | 1464340716 | 1464337116 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><dm:note>22222</dm:note><op:overriding-willingness><opd:basic>op en</opd:basic></op:overriding-willingness></dm:person></presence> | | 84480 | 3918 | 40 | 1464340703 | 1464337103 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><dm:note>11111</dm:note><op:overriding-willingness><opd:basic>op en</opd:basic></op:overriding-willingness></dm:person></presence> | | 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr iding-willingness></dm:person></presence> | 4. Then finally, the first 3918 changes his mood to "33333". The status in >Presentity< table is refreshed under the right id=84480. BUT, to 2025 is sent NOTIFY with mood "22222". "received_time" timestamp of status with mood "33333" is higher than timestamp of status with mood "22222". BUT the "id" attribute of "presentity" table of status with mood "33333" is smaller. I think that statuses with equal "priority" are retrieved by "id" and not by "received_time"!? mysql> select id,username,priority,expires,received_time,body from presentity ORDER BY received_time DESC; | id | username | priority | expires | received_time | body | 84480 | 3918 | 40 | 1464340729 | 1464337129 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><dm:note>33333</dm:note><op:overriding-willingness><opd:basic>op en</opd:basic></op:overriding-willingness></dm:person></presence> | | 84481 | 3918 | 40 | 1464340716 | 1464337116 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><dm:note>22222</dm:note><op:overriding-willingness><opd:basic>op en</opd:basic></op:overriding-willingness></dm:person></presence> | | 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status><op:willingness><opd:basic>ope n</opd:basic></op:willingness></tuple><dm:person id="per123"><op:overriding-willingness><opd:basic>open</opd:basic></op:overr iding-willingness></dm:person></presence> | The Wireshark trace is attached. Can anyone help. Please? We have a big installation in the Gazprom's (Rusia) network, where Kamailio is used as a Presence server only. Thanks Ales

7 years, 10 months

Kamailio 4.4.1 REGISTER Parse Error in PCSCF

by Mihail Dakov

Hi Folks, I have the strangest problem just after installing latest stable version. I had tried both ways using the repo (http://deb.kamailio.org/kamailio44) and downloading code with local compile (https://www.kamailio.org/w/2016/05/kamailio-v4-4-1-released/) The initial scenario is to get M2M with commercial IP and subsequently use the Rx interface to do the same. We are blocked because we cannot even achieve clean register for the UEs. UE1(galaxy s4 zoiper) -------- Kamailio IMS aio | UE2(galaxy s4 zoiper) -------- | What happens is that the first register message triggers some quasi-endless loop in the PCSCF. Hence it cannot be forwarded to SCSCF, ICSCF and HSS. But this doesn't always happen and between all the parse problems there are some register messages which get passed to the scscf icscf and hss. Somehow the parser feeds itself from the previous parse run and thus loops quite intensively. The message I get is SIP/2.0 400 CSeq method does not match request method. I must say that reiterating the registration process sometimes i get the register and sometimes i don't. Has anyone encounter similar issue for similar use case and can share some thoughs about a fix? I attached relevant log file, pcaps and configuration files. Let me know if more config files are needed.

7 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users May 2016