sr-users April 2020

sr-users@lists.kamailio.org

70 participants
99 discussions

Callee BYE routing issue
by Daniel W. Graham 13 Apr '20

13 Apr '20

Have an issue with BYE routing in a lab setup, any suggestions on what I should be looking at? Topology: UA1 <-> NAT device 1 <-> Proxy1 <-> Registrar/B2BUA <-> Proxy1 <-> NAT device 1 <-> UA2 All UA to UA calls flow through B2BUA. All IP’s are public except for UA1 and UA2. -Both endpoints can call each other. -If the caller hangs up first, BYE is routed properly. -If the callee hangs up first, BYE causes proxy to send 478. On calls where BYE results in 478: if(!isdsturiset()) { ……….…………………….not executed handle_ruri_alias() } return; Example issue call: UA2 to UA1, UA1 hang-up. Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=540 a=16 n=if Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=532 a=24 n=isdsturiset Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=540 a=2 n=return ……….. Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} tm [ut.h:245]: uri2dst2(): bad_uri: [sip::;transport=] Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} tm [t_fwd.c:1732]: t_forward_nonack(): failure to add branches Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): request_route=[RELAY] c=[/usr/local/etc/kamailio/kamailio.cfg] l=275 a=24 n=sl_reply_error Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} sl [sl_funcs.c:401]: sl_reply_error(): stateless error reply used: Unresolvable destination (478/SL) Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): request_route=[RELAY] c=[/usr/local/etc/kamailio/kamailio.cfg] l=277 a=2 n=exit 2020/04/10 00:31:28.625060 NAT_Device_IP:57808 -> Proxy_IP:5060 BYE sip:398@B2BUA_IP:5160 SIP/2.0 Via: SIP/2.0/UDP UA1_IP:52884;branch=z9hG4bK-524287-1---43b5f31829f20952 Max-Forwards: 70 Route: <sip:Proxy_IP;lr=on;ftag=as78671fd9;did=b1b.a27> Contact: <sip:399@UA1_IP:52884> To: "Dan Test" <sip:398@B2BUA_IP:5160>;tag=as78671fd9 From: <sip:399@UA1_IP:52884;rinstance=705e0af5f4be485c;alias=NAT_Device_IP:~57808~1>;tag=64f4b712 Call-ID: 24dc84a4592515245177483c2a657042@B2BUA_IP:5160 CSeq: 2 BYE User-Agent: xxxxxxxxxxxxxxxx Content-Length: 0 ######################################### For comparison, here is a BYE from another test call: UA1 to UA2, UA1 hang-up. This BYE was routed correctly. 2020/04/10 00:44:02.688608 NAT_Device_IP:57808 -> Proxy_IP:5060 BYE sip:398@B2BUA_IP:5160 SIP/2.0 Via: SIP/2.0/UDP UA1_IP:52884;branch=z9hG4bK-524287-1---ce36df02e8a80a48 Max-Forwards: 70 Route: <sip:Proxy_IP;lr=on;ftag=9078f232;did=49e.8c01> Contact: <sip:399@UA1_IP:52884> To: <sip:398@B2BUA_IP>;tag=as5874901f From: <sip:399@B2BUA_IP:5060>;tag=9078f232 Call-ID: 103104NGU1NjkxNGZkYmM4MzA3Y2FkMzY1OGNkZTZmMTMyZDU CSeq: 3 BYE User-Agent: xxxxxxxxxxxxxxxx Authorization: Digest username= xxxxxxxxxxxxxxxx Content-Length: 0 -dan

4 7

Kamailio as IMS (version - 5.3.3) Error : 403 Forbidden Domain not served
by Pavithra M 13 Apr '20

13 Apr '20

Hi David, Kindly help me in this regard. I am not getting like it is because of pval issue or some other issue which causes this issue. I have configured kamailio as an IMS server as VM based . PCSCF - 10.x.x.179 ICSCF - 10.x.x.79 SCSCF - 10.x.x.73 HSS - 10.x.x.75 I am using zoiper client for testing the call flow . The *registration is happening properly* in my both zoiper clients for hss configured users (alice and bob). When i am making an *INVITE , *I am getting *403 Forbidden - Domain not served *error from SCSCF. The Call Flow for invite is as follows . call from alice(a)sip.example.com zoiper1 (UE) -> PCSCF ( INVITE sip:bob@sip.example.com;transport=UDP ) PCSCF -> SCSCF ( INVITE sip:bob@sip.example.com;transport=UDP ) SCSCF -> PCSCF (100 trying) SCSCF -> ICSCF ( INVITE sip:bob@sip.example.com;transport=UDP ) ICSCF -> SCSCF (100 trying) ICSCF -> SCSCF ( INVITE sip:bob@sip.example.com;transport=UDP ) SCSCF -> ICSCF (100 trying) SCSCF -> ICSCF (*403 Forbidden - Domain not served*) ICSCF -> SCSCF (Request: ACK sip:bob@sip.example.com | ) ICSCF -> SCSCF ( 403 Forbidden - Domain not served ) SCSCF -> PCSCF ( 403 Forbidden - Domain not served ) PCSCF -> UE ( 403 Forbidden - Domain not served ) Below are the alias configuration i have done in pcscf,icscf,scscf nodes *PCSCF.CFG* # IP-Adress for incoming SIP-Traffic, in the following format: # SIP / UDP listen=udp:10.x.x.179:4060 # SIP / TCP listen=tcp:10.x.x.179:4060 # SIP / TCP/TLS listen=tls:10.x.x.179:4060 # IPSEC / UDP #!define IPSEC_LISTEN_ADDR "0.0.0.0" #!define IPSEC_CLIENT_PORT 5062 #!define IPSEC_SERVER_PORT 5063 #alias="sip.example.com:4060" alias=pcscf.sip.example.com:4060 #!define MY_WS_PORT 80 #!define MY_WSS_PORT 443 #!define PCSCF_URL "sip:pcscf.sip.example.com:4060" #!define TCP_PROCESSES 8 #!subst "/NETWORKNAME/sip.example.com/" #!subst "/HOSTNAME/pcscf.sip.example.com/" *ICSCF.CFG* # SIP / UDP listen=udp:10.x.x.79:4070 # SIP / TCP listen=tcp:10.x.x.79:4070 # SIP / TCP/TLS listen=tls:10.x.x.79:4071 alias="icscf.sip.example.com:4070" #!define NETWORKNAME "sip.example.com" #!define HOSTNAME "icscf.sip.example.com" *SCSCF.CFG* # SIP / UDP listen=udp:10.x.x.73:4080 # SIP / TCP listen=tcp:10.x.x.73:4080 # SIP / TCP/TLS listen=tls:10.x.x.73:4081 #!define NETWORKNAME "sip.example.com" #!define HOSTNAME "scscf.sip.example.com" #!define URI "sip:scscf.sip.example.com:4080" alias=scscf.sip.example.com:4080 # ENUM-Server to query: #!define ENUM_SUFFIX "scscf.sip.example.com." Kindly let me know where i am missing . Kindly need help in this issue since the registration is happening successfully and dropping in the INVITE level. Kindly help.

1 0

kamailio error
by Pavithra M 13 Apr '20

13 Apr '20

Hi, This is the lvalue.c file where i am facing the issue. kindly help. if (unlikely(ret<0)){ LM_ERR("assignment failed at pos: (%d,%d-%d,%d)\n", rve->fpos.s_line, rve->fpos.s_col, rve->fpos.e_line, rve->fpos.e_col); } else { if(unlikely(_log_assign_action!=NULL)) _log_assign_action(msg, lv); } rval_destroy(rv); return ret; error: if (rv) rval_destroy(rv); return -1;

1 0

Kamailio - 5.3.3 Error : 403 domain not served
by Pavithra M 13 Apr '20

13 Apr '20

Hi , I have configured kamailio as an IMS server as VM based . PCSCF - 10.x.x.179 ICSCF - 10.x.x.79 SCSCF - 10.x.x.73 HSS - 10.x.x.75 I am using zoiper client for testing the call flow . The *registration is happening properly* in my both zoiper clients for hss configured users (alice and bob). When i am making an *INVITE , *I am getting *403 Forbidden - Domain not served *error from SCSCF. The Call Flow for invite is as follows . call from alice(a)sip.example.com zoiper1 (UE) -> PCSCF ( INVITE sip:bob@sip.example.com;transport=UDP ) PCSCF -> SCSCF ( INVITE sip:bob@sip.example.com;transport=UDP ) SCSCF -> PCSCF (100 trying) SCSCF -> ICSCF ( INVITE sip:bob@sip.example.com;transport=UDP ) ICSCF -> SCSCF (100 trying) ICSCF -> SCSCF ( INVITE sip:bob@sip.example.com;transport=UDP ) SCSCF -> ICSCF (100 trying) SCSCF -> ICSCF (*403 Forbidden - Domain not served*) ICSCF -> SCSCF (Request: ACK sip:bob@sip.example.com | ) ICSCF -> SCSCF ( 403 Forbidden - Domain not served ) SCSCF -> PCSCF ( 403 Forbidden - Domain not served ) PCSCF -> UE ( 403 Forbidden - Domain not served ) Below are the alias configuration i have done in pcscf,icscf,scscf nodes *PCSCF.CFG* # IP-Adress for incoming SIP-Traffic, in the following format: # SIP / UDP listen=udp:10.x.x.179:4060 # SIP / TCP listen=tcp:10.x.x.179:4060 # SIP / TCP/TLS listen=tls:10.x.x.179:4060 # IPSEC / UDP #!define IPSEC_LISTEN_ADDR "0.0.0.0" #!define IPSEC_CLIENT_PORT 5062 #!define IPSEC_SERVER_PORT 5063 #alias="sip.example.com:4060" alias=pcscf.sip.example.com:4060 #!define MY_WS_PORT 80 #!define MY_WSS_PORT 443 #!define PCSCF_URL "sip:pcscf.sip.example.com:4060" #!define TCP_PROCESSES 8 #!subst "/NETWORKNAME/sip.example.com/" #!subst "/HOSTNAME/pcscf.sip.example.com/" *ICSCF.CFG* # SIP / UDP listen=udp:10.x.x.79:4070 # SIP / TCP listen=tcp:10.x.x.79:4070 # SIP / TCP/TLS listen=tls:10.x.x.79:4071 alias="icscf.sip.example.com:4070" #!define NETWORKNAME "sip.example.com" #!define HOSTNAME "icscf.sip.example.com" *SCSCF.CFG* # SIP / UDP listen=udp:10.x.x.73:4080 # SIP / TCP listen=tcp:10.x.x.73:4080 # SIP / TCP/TLS listen=tls:10.x.x.73:4081 #!define NETWORKNAME "sip.example.com" #!define HOSTNAME "scscf.sip.example.com" #!define URI "sip:scscf.sip.example.com:4080" alias=scscf.sip.example.com:4080 # ENUM-Server to query: #!define ENUM_SUFFIX "scscf.sip.example.com." Kindly let me know where i am missing . Kindly need help in this issue since the registration is happening successfully and dropping in the INVITE level. Kindly help.

1 0

Kamailio 5.3.2 crashing continuously
by harneet singh 13 Apr '20

13 Apr '20

Hi All, As part of our very low cps load at 50 calls per second through Kamailio Version 5.3.2 (Dispatcher Module used with Call Load based Routing - Algorithm 10. Machine is a Centos: 7.7 with kernel version 3.10), we are seeing the kamailio continuously crashing. Please see the data below for 3 types of segfaults seen: Crash-1: -------- Apr 3 19:32:25 FE-A07-34-VM6 kernel: kamailio[10382]: segfault at 7ff300000078 ip 00007ff300000078 sp 00007ffe5f2eafc8 error 14 in libbz2.so.1.0.6[7ff331582000+f000] Apr 3 19:32:25 FE-A07-34-VM6 mysqld: 2020-04-03 19:32:25 6131 [Warning] Aborted connection 6131 to db: 'kamailio' user: 'kamailio' host: 'localhost' (Got an error reading communication packets) Apr 3 19:32:25 FE-A07-34-VM6 /usr/sbin/kamailio[10423]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 13 Apr 3 19:32:25 FE-A07-34-VM6 /usr/sbin/kamailio[10381]: ALERT: <core> [main.c:767]: handle_sigs(): child process 10382 exited by a signal 11 Apr 3 19:32:25 FE-A07-34-VM6 /usr/sbin/kamailio[10381]: ALERT: <core> [main.c:770]: handle_sigs(): core was not generated =============================== Crash-2: ------- Apr 3 19:36:11 FE-A07-34-VM6 kernel: kamailio[12838]: segfault at 7efe00000078 ip 00007efe00000078 sp 00007ffdc876b868 error 15 in zero (deleted)[7efdc407f000+40000000] Apr 3 19:36:11 FE-A07-34-VM6 mysqld: 2020-04-03 19:36:11 6175 [Warning] Aborted connection 6175 to db: 'kamailio' user: 'kamailio' host: 'localhost' (Got an error reading communication packets) Apr 3 19:36:11 FE-A07-34-VM6 /usr/sbin/kamailio[12874]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 18 Apr 3 19:36:11 FE-A07-34-VM6 /usr/sbin/kamailio[12826]: ALERT: <core> [main.c:767]: handle_sigs(): child process 12838 exited by a signal 11 Apr 3 19:36:11 FE-A07-34-VM6 /usr/sbin/kamailio[12826]: ALERT: <core> [main.c:770]: handle_sigs(): core was not generated ============================ Crash-3: -------- Apr 3 19:40:53 FE-A07-34-VM6 kernel: kamailio[13542]: segfault at 80 ip 000000000065e193 sp 00007ffdae10c1f0 error 4 in kamailio[400000+476000] Apr 3 19:40:53 FE-A07-34-VM6 mysqld: 2020-04-03 19:40:53 6222 [Warning] Aborted connection 6222 to db: 'kamailio' user: 'kamailio' host: 'localhost' (Got an error reading communication packets) Apr 3 19:40:53 FE-A07-34-VM6 /usr/sbin/kamailio[13516]: ALERT: <core> [main.c:767]: handle_sigs(): child process 13542 exited by a signal 11 Apr 3 19:40:53 FE-A07-34-VM6 /usr/sbin/kamailio[13558]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 38 Apr 3 19:40:53 FE-A07-34-VM6 /usr/sbin/kamailio[13516]: ALERT: <core> [main.c:770]: handle_sigs(): core was not generated Any pointers for resolution are most welcome as we need to quickly resolve this. Regards, Harneet Singh -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

2 3

IPSec and USIM
by Mohammad Elahi 12 Apr '20

12 Apr '20

Hi All, When my VoLTE Mobile is registered to the Kamailio IMS that support IPSec by AKAv1 algorithm, inside the ESP packet is clear text (not encrypted). Is that because my mistake in configuration or for my USIM card? thanks in advance. Mohammad

1 1

kamailio as SBC for Teams
by Aidar Kamalov 10 Apr '20

10 Apr '20

Hello, I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying to use kamailio for teams. But I faced that MS not responding ACK to my 200OK. Somethin is wrong, but I don't know what. I call from teams to kamailio. Can you help me please This is initial INVITE from Teams: 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061 INVITE sip:+xxxxxxxxx@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls SIP/2.0 FROM: Aidar Kamalov<sip:+xxxxxxxxx@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=de28a5b5333b451a97312097f91f5564 TO: <sip:xxxxxxxx@MY_KAMAILIO_FQDN:5061;user=phone> CSEQ: 1 INVITE CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1 MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c RECORD-ROUTE: <sip:sip-du-a-as.pstnhub.microsoft.com:5061;transport=tls;lr> CONTACT: <sip:api-du-a-euno.pstnhub.microsoft.com:443 ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4> CONTENT-LENGTH: 2426 USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5 CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY v=0 o=- 0 0 IN IP4 52.114.252.146 s=session c=IN IP4 52.114.252.146 b=CT:50000 t=0 0 m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101 a=rtcp:52925 a=ice-ufrag:rKBm a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O a=rtcp-mux a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr 31.13.144.55 rport 57780 a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr 31.13.144.55 rport 57781 a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr 100.78.247.179 rport 39182 a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr 100.78.247.179 rport 39183 a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr 100.78.247.179 rport 41775 a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr 100.78.247.179 rport 41775 a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr 31.13.144.55 rport 9761 a=candidate:6 2 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr 31.13.144.55 rport 9761 a=candidate:7 1 tcp-act 174846462 52.114.252.130 59925 typ relay raddr 31.13.144.55 rport 9761 a=candidate:7 2 tcp-act 174846462 52.114.252.130 59925 typ relay raddr 31.13.144.55 rport 9761 a=x-candidate-info:4 network-type=WWAN a=x-candidate-info:1 network-type=WWAN a=x-candidate-info:2 network-type=WWAN a=x-candidate-info:3 network-type=WWAN a=x-candidate-info:5 network-type=WWAN a=x-candidate-info:6 network-type=WWAN a=x-candidate-info:7 network-type=WWAN a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31 a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31|1:1 a=rtpmap:104 SILK/16000 a=fmtp:104 useinbandfec=1; usedtx=0 a=rtpmap:9 G722/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:103 SILK/8000 a=fmtp:103 useinbandfec=1; usedtx=0 a=rtpmap:97 RED/8000 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=rtpmap:119 CN/24000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:200 and my 200OK to MS is: 2020/04/09 22:55:19.976427 KAMAILIO_IP:5061 -> 52.114.7.24:1024 SIP/2.0 200 OK Record-Route: <sip:KAMAILIO_FQDN_DOMAIN:5061;transport=tls;ftag=de28a5b5333b451a97312097f91f5564;lr=on> Record-Route: <sip:KAMAILIO_IP:5060;ftag=de28a5b5333b451a97312097f91f5564;lr=on> Via: SIP/2.0/TLS 52.114.7.24:5061;rport=1024;branch=z9hG4bKdb903e2c Record-Route: <sip:ENDPOINT_BEHIND_KAMAILIO_IP;line=sr-QyfKA15Kw1rKw1hKEoPljM0oE1VLX10RQ1VLX10gkY37WJufE1BBjJhVE6E6r14VEJ5Nj6ElE1UNjyrNEJrVjnr.AyudmMV1rg52rJrlAyNBkMVNmSE*> Record-Route: <sip:ENDPOINT_BEHIND_KAMAILIO_IP;r2=on;lr=on;ftag=de28a5b5333b451a97312097f91f5564;did=cba.af1;nat=yes> Record-Route: <sip:KAMAILIO_IP;r2=on;lr=on;ftag=de28a5b5333b451a97312097f91f5564;did=cba.42a1;nat=yes> Record-Route: <sip:KAMAILIO_IP:5061;transport=tls;r2=on;lr=on;ftag=de28a5b5333b451a97312097f91f5564;did=cba.42a1;nat=yes> Record-Route: <sip:sip-du-a-as.pstnhub.microsoft.com:5061;transport=tls;lr> To: <sip:+xxxxxxxxxx@KAMAILIO_FQDN_DOMAIN :5061;user=phone>;tag=3795432917-393759697 From: <sip:+xxxxxxxxxx@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=de28a5b5333b451a97312097f91f5564 Call-ID: 3d5ad3cdd01457be94d127fa20478cf1 CSeq: 1 INVITE Allow: PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL Content-Type: application/sdp Accept: application/sdp Content-Length: 282 User-Agent: MY_DOMAIN Contact: <sip:KAMAILIO_IP;line=sr-DHZToOtmMdn7MODy9AnmD10TGLpUrL4noJCE4A03DdQE9LUaMXr*> v=0 o=ETPI-MSX1 0 0 IN IP4 KAMAILIO_IP s=sip call c=IN IP4 KAMAILIO_IP t=0 0 m=audio 12176 RTP/SAVP 8 b=AS:64 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=sendrecv a=rtcp:12177 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:03ZmcR+CxxB7k7C8QvWBgseYq7cH7py7VxqfLM8j a=ptime:20 -- Aydar A. Kamalov

4 8

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
by Luis Rojas G. 10 Apr '20

10 Apr '20

Hello, I just realized that I had the dispatcher configured using a hash of Call-ID. That means, after recvfrom there must be an extra processing finding the Call-ID header in message, to calculate a hash and then forward() message. The more the processing, the more cases when 200 could arrive before 180. I just changed it to round robin, and the amount decreased a lot, but it's still there. If I send a burst of 1000 messages, about 5 of them leave out of order every time. Best regards, Luis On 4/9/20 1:48 PM, Luis Rojas G. wrote: > Hello, > > I have a lot of experience developing mutithreaded applications, and I > don't see it so unlikely at all that a process loses cpu just after > recvfrom(). It's just as probable as to lose it just before, or when > writing on a cache or just before of after sendto(). If there are many > messages going through, some of them will fall in this scenario. if I > try sending a burst of 100 messages, I see two or three presenting the > scenario. > > Just forward() with a single process does not give the capacity. I'm > getting almost 1000caps. More than that and start getting errores, > retransmissions, etc. And this is just one way. I need to receive the > call to go back to the network (our application is a B2BUA), so I will > be down to 500caps, with a simple scenario, with no reliable > responses, reinvites, updates, etc. I will end up having as many > standalone kamailio processes as the current servers I do have now. > > I really think the simplest way would be to add a small delay to 200 > OK. Very small, like 10ms, should be enough. Simple and it should > work. As Alex Balashov commented he did for the case with ACK-Re-Invite. > > I have to figure out how to make async_ms_sleep() work in reply_route(). > > Thanks for all the comments and ideas > > Best regards, > > Luis > > > > . On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote: >> >> >> MICONDA(a)GMAIL.COM appears similar to someone who previously sent you >> email, but may not be that person. Learn why this could be a risk >> <http://aka.ms/LearnAboutSenderIdentification> >> Feedback <http://aka.ms/SafetyTipsFeedback> >> >> Hello, >> >> then the overtaking is in between reading from the socket and getting >> to parsing the call-id value -- the cpu is lost by first reader after >> recvfrom() and the second process get enough cpu time to go ahead >> further. I haven't encountered this case, but as I said previously, >> it is very unlikely, but still possible. I added the route_locks_size >> because in the past I had cases when processing of some messages took >> longer executing config (e.g., due to authentication, accounting, ..) >> and I needed to be sure they are processed in the order they enter >> config execution. >> >> Then the option is to see if a single process with stateless sending >> out (using forward()) gives the capacity, if you don't do any other >> complex processing. Or if you do more complex processing, use a >> dispatcher process with forwarding to local host or in a similar >> manner try to use mqueue+rtimer for dispatching using shared memory >> queues. >> >> Of course, it is open source and there is also the C coding way, to >> add a synchronizing mechanism to protect against parallel execution >> of the code from recvfrom() till call-id lock is acquired. >> >> Cheers, >> Daniel >> -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.rojas@sixbell.com http://www.sixbell.com

3 4

t_relay failure when dropping all branches in same destination set
by Sergiu Pojoga 09 Apr '20

09 Apr '20

Hi there, Can someone help figure out why there's this t_relay error, if I decide to drop the single master branch either all branches belonging to the same destination set, even though there are more serial sets to try later? *Error:* *tm [t_funcs.c:337]: t_relay_to(): t_forward_nonack returned error -6 (-6)* *tm [t_funcs.c:355]: t_relay_to(): -6 error reply generation delayed * *Example:* request_route { seturi("sip:a@mydomain.net"); append_branch("sip:b@mydomain.net", "0.5"); append_branch("sip:c@mydomain.net", "0.5"); append_branch("sip:d@10.22.0.30", "1.0"); # append_branch("sip:e@mydomain.net", "1.0"); # no error if I add this branch with same Q=1.0 t_load_contacts(); t_next_contacts(); t_on_branch("check_branch"); t_on_failure("serial"); t_relay(); break; } branch_route[check_branch] { if($rd=="10.22.0.30") drop; } failure_route["serial"] { if (!t_next_contacts()) exit; } t_on_branch("check_branch"); t_on_failure("serial"); t_relay(); } Thanks in advance. --Sergiu

1 1

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
by Alex Balashov 09 Apr '20

09 Apr '20

On Thu, Apr 09, 2020 at 02:26:45PM +0100, David Villasmil wrote: > How about just not forwarding the 180 if it’s coming right after the > 200ok? I know it’s a hack, but a 180 is a provisional response > indicating the ring status, not the actual audio for the ring... so if > a 200 is received, the call is already established, no need to forward > the 180. There is a general principle, particularly in PSTN interworking, that signalling should be reliably conserved end-to-end. I think dropping messages is the most cavalier option available, perhaps worth considering only if every other logical possibility has been exhausted first. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users April 2020