sr-users August 2018

sr-users@lists.kamailio.org

73 participants
115 discussions

Interesting issue with ACK back from 200 OK INVITE

by Wilkins, Steve

Hello All, I have had an issue for quite some time where I needed to open two UDP ports (via LISTEN) for some softphone UAC's to stay connected. Funny enough there is one Provider that works with the Single UDP. I think I finally see why I was needing two listening UDP ports. When the ACK is returning from Asterisk to Kamailio, the ACK is coming back as protocol TCP, not SIP, causing the call to drop. I finally realized this but I am not sure what would cause this and why one provider phone works but not the others. Once this is resolved, I may actually say...It works! Thank you, -Steve

6 years, 2 months

Notify: stateless error reply used: I'm terribly sorry, server error occurred

by Soltanici Ilie

For some reason, Voicemail Notify messages coming from Asterisk Boxes - are not forwarded to the SIP Extensions by Kamailio. This is the SIP Packet coming to the Kamailio: 2018/08/28 10:59:19.165644 1.1.1.1:5060 -> 2.2.2.2:5060 NOTIFY sip:11@3.3.3.3:21755;rinstance=e6369e13becab3ef;transport=tcp;alias=3.3.3.3~21755~2 SIP/2.0 Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK5f628579;rport Max-Forwards: 70 Route: <sip:2.2.2.2:5060;transport=tcp;ftag=0472e823;lr=on;nat=yes> From: "asterisk" <sip:asterisk@1.1.1.1>;tag=as1833c329 To: <sip:11@3.3.3.3:21755;rinstance=e6369e13becab3ef;transport=tcp;alias=3.3.3.3~21755~2>;tag=0472e823 Contact: <sip:asterisk@1.1.1.1:5060> Call-ID: 93183ZjE3YmI0OGYxMDNiMzhlNzVjZjRjNTc2NTMwZGNmYzk CSeq: 103 NOTIFY User-Agent: NUACOM Event: message-summary Content-Type: application/simple-message-summary Subscription-State: active Content-Length: 93 Messages-Waiting: no Message-Account: sip:asterisk@1.1.1.1 Voice-Message: 0/0 (0/0) And this is the message which I'm receiving in the Kamailio logs: [RELAY] Error when forwarding Request ERROR: sl [sl_funcs.c:362]: sl_reply_error(): stateless error reply used: I'm terribly sorry, server error occurred (1/SL) This is the Relay route: # Forwarding Statefully if ( ! t_relay()) { xlogl( "L_ERR" , "[RELAY] Error when forwarding Request \n " ); sl_reply_error(); } exit ;

6 years, 2 months

Info: Cluecon Weekly about Kamailio, today at 17:00GMT

by Daniel-Constantin Mierla

Hello, if you haven't seen the news article on kamailio.org, today at 17:00GMT I will be part of the Cluecon Weekly online video conference to present about what's new lately in Kamailio, plans for the future as well as address questions about using Kamailio together with FreeSwitch. Anyone can join via audio or video calls, more details about at: * https://www.kamailio.org/w/2018/08/kamailio-on-cluecon-weekly-aug-29-2018/ * https://freeswitch.org/confluence/display/FREESWITCH/ClueCon+Weekly+Confere… Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

6 years, 2 months

Kamailio consuming UDP packets very slowly leading to high RECV - Q

by sagar malam

Hello, I am using Kamailio as a SIP proxy.So it receives SIP packet from internet and forwards it to FS servers in local network.When i execute "ss" command i see very high value in RECV-Q column.I THINK IT IS NOT NORMAL.PLEASE CORRECT ME IF I AM WRONG. ==================================================== [root@fep-1 proc]# ss -u -a -n -e | grep 5060 UNCONN 0 0 10.50.8.1:5060 *:* ino:6831630 sk:fd <-> UNCONN 0 0 10.50.7.18:5060 *:* ino:6831629 sk:fe <-> UNCONN *1183104* 0 10.50.7.254:5060 *:* ino:6831627 sk:ff <-> UNCONN *84864* 0 2607:f900:1:3::254:5060 :::* ino:6831628 sk:100 v6only:1 <-> ====================================================== Initially i thought that there is something in script which must be causing kamailio to process UDP request slower but i faced same issue with a very simple script where i simply reply with stateless 200 OK for each sip request : request_route { sl_send_reply("200","OK");exit; $avp(uuid) = $rm + "-" + $ci; ........ ......... ......... ....... Server configuration : OS : CENTOS 7 Kernel : 4.16 CPU : 5 X Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz RAM : 32 GB Please help me debugging this issue.Thanks in advance

6 years, 2 months

Using SEMS in IMS-ZTE Network

by Mojtaba

Hello, I am working with IMS (ZTE vendor), I want to use SBC in front of IMS network for some security policy (Hide Topology), I used SEMS as SBC in this regards, (like what we have in IMS/SEMS in kamailio by Mr Carsten Bock). When the Sebscriber want to register, The Register request received by sems and the forward to IMS(ZTE), But the "503 Service Unavailable" is received from IMS. I enable "enable_reg_caching=yes" in register.sbcprofile''s configuration file in sems. If i use kamailio, instead of SEMS, The Registration request is done successfully.In Kamailio i just forward the Register request to IMS.like this: route { if (is_method("REGISTER")) { $du = "sip:172.23.1.1:5080"; route(RELAY); } } Let me know do the issue is from myself or from IMS(ZTE)? In the fillowing, I paste all SIP Register signalling. First in kamailio, second with SEMS. ================Kamailio================== 172.23.1.252.4080 > 172.23.1.1.5080: [bad udp cksum 0x5e58 -> 0x4193!] UDP, length 787 E../....@.]...............^XREGISTER sip:r-kh.com SIP/2.0 Via: SIP/2.0/UDP 172.23.1.252:4080;branch=z9hG4bK018b.e091260b1b7395975a2ff1be0b9bec60.0 Via: SIP/2.0/UDP 192.168.122.1:64407;branch=z9hG4bK-d8754z-7c208b9d587de818-1---d8754z- Max-Forwards: 69 Contact: <sip:+985137054518@192.168.122.1:64407;rinstance=e664e178fc12691e;transport=UDP> From: <sip:+985137054518@r-kh.com;transport=UDP>;tag=5aef0541 Call-ID: ZWYxMzUzNTQzN2I2MTRiMjE2NWZjMzUzMDFmMDhkOWY. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Allow-Events: presence, kpml Content-Length: 0 08:20:53.114198 IP (tos 0x0, ttl 255, id 25839, offset 0, flags [none], proto UDP (17), length 685) 172.23.1.1.5080 > 172.23.1.252.4080: [udp sum ok] UDP, length 657 E...d......$..............l.SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 172.23.1.252:4080;branch=z9hG4bK018b.e091260b1b7395975a2ff1be0b9bec60.0 Via: SIP/2.0/UDP 192.168.122.1:64407;branch=z9hG4bK-d8754z-7c208b9d587de818-1---d8754z- To: <sip:+985137054518@r-kh.com;transport=UDP>;tag=ztesipTR9m3KdZ*3-5-16648*daei.3 From: <sip:+985137054518@r-kh.com;transport=UDP>;tag=5aef0541 Call-ID: ZWYxMzUzNTQzN2I2MTRiMjE2NWZjMzUzMDFmMDhkOWY. CSeq: 1 REGISTER Content-Length: 0 WWW-Authenticate: Digest realm="r-kh.com",domain="sip:scscf1.r-kh.com",nonce="f42b36e39bdbb33b51599924b304445a",opaque="aW1zLmNvbS5jbg==",stale=TRUE,algorithm=MD5,qop="auth" 08:20:53.120142 IP (tos 0x10, ttl 64, id 48874, offset 0, flags [none], proto UDP (17), length 1137) 172.23.1.252.4080 > 172.23.1.1.5080: [bad udp cksum 0x5f9a -> 0xcc62!] UDP, length 1109 E..q....@.\V.............]_.REGISTER sip:r-kh.com SIP/2.0 Via: SIP/2.0/UDP 172.23.1.252:4080;branch=z9hG4bKd08b.4d2858f41d496b471c01a28e76190390.0 Via: SIP/2.0/UDP 192.168.122.1:64407;branch=z9hG4bK-d8754z-a4d19146375d56f6-1---d8754z- Max-Forwards: 69 Contact: <sip:+985137054518@192.168.122.1:64407;rinstance=e664e178fc12691e;transport=UDP> To: <sip:+985137054518@r-kh.com;transport=UDP> From: <sip:+985137054518@r-kh.com;transport=UDP>;tag=5aef0541 Call-ID: ZWYxMzUzNTQzN2I2MTRiMjE2NWZjMzUzMDFmMDhkOWY. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Authorization: Digest username="+985137054518(a)r-kh.com",realm="r-kh.com",nonce="f42b36e39bdbb33b51599924b304445a",uri="sip:r-kh.com;transport=UDP",response="9469852a06c01efeabf3a7a5dd1a9f3b",cnonce="79d36600575648a1cc7221d8e1b5d53d",nc=00000001,qop=auth,algorithm=MD5,opaque="aW1zLmNvbS5jbg==" Allow-Events: presence, kpml Content-Length: 0 08:20:53.203871 IP (tos 0x0, ttl 255, id 25842, offset 0, flags [none], proto UDP (17), length 1118) 172.23.1.1.5080 > 172.23.1.252.4080: [udp sum ok] UDP, length 1090 E..^d......p.............J.5SIP/2.0 200 OK Via: SIP/2.0/UDP 172.23.1.252:4080;branch=z9hG4bKd08b.4d2858f41d496b471c01a28e76190390.0 Via: SIP/2.0/UDP 192.168.122.1:64407;branch=z9hG4bK-d8754z-a4d19146375d56f6-1---d8754z- To: <sip:+985137054518@r-kh.com;transport=UDP>;tag=ztesipjRydzgMa*3-5-16648*daej.3 From: <sip:+985137054518@r-kh.com;transport=UDP>;tag=5aef0541 Call-ID: ZWYxMzUzNTQzN2I2MTRiMjE2NWZjMzUzMDFmMDhkOWY. CSeq: 2 REGISTER Contact: <sip:+985137054518@192.168.122.1:64407;transport=UDP;rinstance=e664e178fc12691e>;expires=1800 Contact: <sip:ZTEAGCF000f425704be720000@agcf2.r-kh.com:5079;appid=2-7;UserRegInfo=002-02-00-0b80-04-172.30.48.143;BACaddr=172.30.48.143;BACport=2944>;expires=1800;+sip.instance="<urn:uuid:172.30.35.41-000>";reg-id=1 P-Associated-URI: <tel:+985137054518> P-Associated-URI: <sip:+985137054518@r-kh.com> Date: Sat, 25 Aug 2018 12:25:17 GMT Authentication-Info: nextnonce="00cfbd64b136c12a4e27b67fd28d19fb",qop=auth,rspauth="91ca956c5eb6ee9f1934e2e770750077",cnonce="79d36600575648a1cc7221d8e1b5d53d",nc=00000001 Content-Length: 0 ============================SEMS======================== 172.23.1.252.5080 > 172.23.1.1.5080: [bad udp cksum 0x5e16 -> 0xe11e!] UDP, length 721 E...C.@.@.................^. REGISTER sip:r-kh.com SIP/2.0 Via: SIP/2.0/UDP 172.23.1.252:5080;branch=z9hG4bK~0uk0ahN;rport From: <sip:+985137054518@r-kh.com;transport=UDP>;tag=34384541-5B814A44000AE296-4B5F5700 To: <sip:+985137054518@r-kh.com;transport=UDP> CSeq: 10 REGISTER Call-ID: 37B52BC0-5B814A44000AE592-4B5F5700 Route: <sip:172.23.1.1:5080;lr> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Allow-Events: presence, kpml Contact: <sip:+985137054518@192.168.122.1:64407;rinstance=868560f8328d39e9;transport=UDP>;expires=3600 Content-Length: 0 08:23:32.790414 IP (tos 0x0, ttl 255, id 35790, offset 0, flags [none], proto UDP (17), length 593) 172.23.1.1.5080 > 172.23.1.252.5080: [udp sum ok] UDP, length 565 E..Q.....................=..SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 172.23.1.252:5080;rport=5080;branch=z9hG4bK~0uk0ahN To: <sip:+985137054518@r-kh.com;transport=UDP>;tag=ztesipDEmH2AWT*3-5-16648*egei.3 From: <sip:+985137054518@r-kh.com;transport=UDP>;tag=34384541-5B814A44000AE296-4B5F5700 Call-ID: 37B52BC0-5B814A44000AE592-4B5F5700 CSeq: 10 REGISTER Content-Length: 0 WWW-Authenticate: Digest realm="r-kh.com",domain="sip:scscf1.r-kh.com",nonce="179797f920a09d65b5641e5e87df0d8c",opaque="aW1zLmNvbS5jbg==",stale=TRUE,algorithm=MD5,qop="auth" 08:23:32.855067 IP (tos 0x0, ttl 64, id 17364, offset 0, flags [DF], proto UDP (17), length 1071) 172.23.1.252.5080 > 172.23.1.1.5080: [bad udp cksum 0x5f58 -> 0xf553!] UDP, length 1043 E../C.@.@................._X REGISTER sip:r-kh.com SIP/2.0 Via: SIP/2.0/UDP 172.23.1.252:5080;branch=z9hG4bKeAfKkaZa;rport From: <sip:+985137054518@r-kh.com;transport=UDP>;tag=5A64C27D-5B814A44000CD034-4B6F6700 To: <sip:+985137054518@r-kh.com;transport=UDP> CSeq: 10 REGISTER Call-ID: 5380C97E-5B814A44000CD2A5-4B6F6700 Route: <sip:172.23.1.1:5080;lr> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Authorization: Digest username="+985137054518(a)r-kh.com",realm="r-kh.com",nonce="179797f920a09d65b5641e5e87df0d8c",uri="sip:r-kh.com;transport=UDP",response="017efb986e17506a82bb01e8eb136b90",cnonce="3764fd5eb2ea9539d61ec14196a2bf00",nc=00000001,qop=auth,algorithm=MD5,opaque="aW1zLmNvbS5jbg==" Allow-Events: presence, kpml Contact: <sip:+985137054518@192.168.122.1:64407;rinstance=868560f8328d39e9;transport=UDP>;expires=3600 Content-Length: 0 08:23:32.860417 IP (tos 0x0, ttl 255, id 35804, offset 0, flags [none], proto UDP (17), length 508) 172.23.1.1.5080 > 172.23.1.252.5080: [udp sum ok] UDP, length 480 E...........................SIP/2.0 503 Service Unavailable Via: SIP/2.0/UDP 172.23.1.252:5080;rport=5080;branch=z9hG4bKeAfKkaZa To: <sip:+985137054518@r-kh.com;transport=UDP>;tag=ztesipxxsD3FR2VG8e9zxR_1dx*1-1-16648*ihad.1 From: <sip:+985137054518@r-kh.com;transport=UDP>;tag=5A64C27D-5B814A44000CD034-4B6F6700 Call-ID: 5380C97E-5B814A44000CD2A5-4B6F6700 CSeq: 10 REGISTER X-ZTE-Cause: "CSCF-1.1.BC004016-BC004288-0-0.pcscf1.r-kh.com" Retry-After: 30 Content-Length: 0 -- --Mojtaba Esfandiari.S

6 years, 2 months

Parmas in lcr_gw

by Ashutosh chaubey

Hi, How to give username and password for the gateway in params column in lcr_gw? Regards, Ashutosh

6 years, 2 months

regular expression in kamailio

by Wilkins, Steve

Hi All, I am trying get the 10digit number called in on using the following $var(caller) = $(fu{re.subst,[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]}); I thought I could use a regular expression for the expression in re.subst,expression Thank you, -Steve

6 years, 2 months

Listner problems

by Wilkins, Steve

Hi Joel, Actually, I have a strange issue. If I have a single UDP IP:Port listening, most Providers/Phones have two-way Audio/Video, however, with some Providers/Phones, I need to have two UDP IP:Port listners in order to get two-way Audio/Video. Here is the strange thing. If I enable two, the Providers/Phones that worked when I had a single listener only have one-way Audi/Video. I use Kamailio 5.1 and Asterisk 15.3 (pjsip). This behavior is so strange, Thank you, -Steve

6 years, 2 months

add listen dynamically

by Wilkins, Steve

Hi All, Is it possible to add or remove "listen" dynamically? Thank you, -Steve

6 years, 2 months

Struggling with RTPEngine

by Wilkins, Steve

Hi Florian, Thank you for your response. I checked and direct-media is off. Just as a recap, here is where I am I just can't get rtpengine to work. I have tried multiple configurations, but to no avail. Note that calls work good if rtpengine is disabled. Here is my setup => Public IP: 20.20.20.20 Private IP 10.10.10.10 flow => webrtc client <-> kamailio+rtpengine <-> asterisk <-> kamailio <-> legacy sip phone rtpenngine startup (I have tried a few different startups) => rtpengine --interface=int/10.10.10.10 --interface=ext/10.10.10.10\!20.20.20.20 --listen-ng=127.0.0.1:12221 --pidfile=/var/run/rtpengine --dtls-passive -f -m 10000 -M 20000 -E kamailio => Invites: rtpengine_manage("trust-address replace-origin replace-session-connection direction=ext direction=int ICE=remove RTP/AVP"); Reply's: rtpengine_manage("trust-address replace-origin replace-session-connection ICE=force RTP/SAVPF"); I have tried direction ext ext; and many other combinations, each producing its own incorrect behavior. Thanks again, Steve

6 years, 2 months

← Newer
1
2
3
4
5
6
7
...
12
Older →

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 August 2018