sr-users

sr-users@lists.kamailio.org

39 participants
37513 discussions

function 'sl_send_reply' is not available
by David Villasmil 04 May '22

04 May '22

Hello guys, I'm starting to try KEMI and i already hit a snag... right now i'm simply testing with: loadmodule "app_lua.so" modparam("app_lua", "load", "/etc/kamailio/myscript.lua") cfgengine "lua" route { lua_run("send_reply"); } But i'm always getting: 0(118) ERROR: app_lua [app_lua_api.c:1633]: sr_kemi_lua_modf(): function 'sl_send_reply' is not available I'm guessing that function is not exported by the module.. if that's the case, how can i use it? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 3

Dispatcher SRV load balancing
by Nicolas Chapleau 03 May '22

03 May '22

Just having a hard time trying to see if the Dispatcher module does LB when SRV records are used as the destination. Will the destinations be picked based on the SRV list or will it simply use the first name received? Read lots of docs, but can't seem to figure it out Thanks, Nic.

1 0

Problem with Record-Route in Public to Private Network
by Carlos Escalona 03 May '22

03 May '22

Hello! I wish everyone who reads this message a good day. I would appreciate some guidance with the configuration of my Kamailio. Initially, I have the following architecture: Endpoints <----Public IP----> Kamailio (listen PrivateIP advertise PublicIP) <----Private IP----> Asterisk CONFIG: https://gist.github.com/Carlos-Escalona94/3a289af05b05c69ae563ab29c9ec4710 In general, calls initiated from outside the system work perfectly, but I have a problem with calls initiated from Asterisk. According to what I was able to investigate and understand, the problem arises from the fact that Kamailio uses the public IP for the entire routing system that involves the Record-Route and Route Headers. This in turn causes Asterisk to get lost trying to send messages outside of the INITIAL INVITE transaction, for example, the ACK response to the 200 Ok received from the Endpoint since it tries to use Kamailio's public IP to which Asterisk doesn't have access. I tried to force Asterisk to send all messages to Kamailio's private IP regardless of their nature, but it doesn't seem like an appropriate solution. On the other hand, I tried to modify the architecture a bit so that it was something similar to this: Endpoints <---- Public IP----> Kamailio (listen PrivateIP:P1 advertise PublicIP) <---- PrivateIP-----> Kamailio (listen PrivateIP:P2) <---- PrivateIP ----> Asterisk CONFIG: https://gist.github.com/Carlos-Escalona94/4d681bb189c6190941d291965e123889 It seems to me that this would solve the problem, but I have two doubts about this architecture, the first is that I would like to know if there is an easier way to solve the problem that I am not considering, and on the other hand, I have not found a way to identify from which interface is receiving the message to perform the routing properly. Thanks for the attention. -- *Esta mensagem pode conter informação confidencial ou privilegiada, sendo seu sigilo protegido por lei. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não pode usar, copiar ou divulgar as informações nela contidas ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor, avise imediatamente ao remetente, respondendo o e-mail e em seguida apague-a. Agradecemos sua cooperação. ** * *This message may contain confidential or privileged information and its confidentiality is protected by law. If you are not the addressed or authorized person to receive this message, you must not use, copy, disclose or take any action based on it or any information herein. If you have received this message by mistake, please advise the sender immediately by replying the e-mail and then deleting it. Thank you for your cooperation. *

3 2

Getting "uac.reg_add" to work (documentation unclarities)
by Rick van Rein 29 Apr '22

29 Apr '22

Hello, I am trying to make UAC register with a SIP telco. But when I run... shell$ kamctl rpc uac.reg_add mydomain.com 0123456789 myteldomain.com 0123456789 sip6.telco.nl telcoreseller.nl 999999 secretpw . udp:sip6.telco.nl 360 0 10 'udp:[fd8:9::10]:5090' ...it gives me the cryptic response... ERROR: jsonrpcs [jsonrpcs_mod.c:666]: jsonrpc_scan(): field is not a string - type 3 The module docs only give "..." as example of attributes. And, according to... http://www.kamailio.net/docs/modules/5.4.x/modules/uac.html#uac.r.uac.reg_a… https://github.com/kamailio/kamailio/blob/5.4.4/src/modules/uac/uac_reg.c#1… ...it also seems to be behind on diff_expires, timer_expires, reg_init. What I am missing is the format, and in some cases the purpose of attributes. Could you help me to an example, perhaps based on the command I am trying? Thanks, -Rick P.S. It's been years since I worked with OpenSIPS. It feels like Kamailio is friendlier, and easier to use.

3 4

Dispatcher Usage and change of $rU
by Benoît Panizzon 29 Apr '22

29 Apr '22

Hi Gang I have a observation which I don't understand... Let's assume we have an inbound $rU = 12345 And I want to change $rU outbound to 0012345 Doing: $rU = "0012345"; ds_select_dst("2000"),"6"); route(RELAY) The call is being sent out with unaltered R-URI Username: 12345 Doing: $rU = "0012345"; ds_select_domain("2000", "6"); route(RELAY); The call is being sent out with the intended new R-URI Username: 0012345 Looking at the docs: https://kamailio.org/docs/modules/5.4.x/modules/dispatcher.html#dispatcher.… I can not figure out, why I see this difference. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 3

Incorrect Socket and Tcpconn-Id with Mid-Registrar and WebSockets
by Grant Bagdasarian 29 Apr '22

29 Apr '22

Hi, We're attempting to implement a mid-registrar for websocket connections but are running into some issues where the tcpconn-id and socket attributes are not stored correctly in memory (usrloc). REGISTER Flow: UA1 -> P1 (Mid-Registrar) ~> P2 (Core Proxy/Registrar) INVITE Flow: UA2 -> P2 -> P1 -> UA1 UA1: baresip cli connecting to P1 using websockets UA2: softphone Everything is running locally on a dev machine, and we're using Docker to launch P1 and P2. The below code snippet is what we use on P1, and has been simplified. The general idea is as following: 1) UA1 sets up the websocket connection and sends a REGISTER request to P1 2) P1 checks if this request has already been sent to P2 2.a) If not, then relay the request to P2. Upon receiving a 200 OK from P2 we save the registration in usrloc 2.b) If so, then absorb the request (save) and generate a reply 3) UA2 tries to call UA1 via P1 and P2 The problem occurs at 2.a since the REGISTER request is forwarded using UDP and the 200 OK is also received using UDP. When the registration is stored in reply route, the Socket (udp:x.x.x.x:xxxx) and Tcpconn-Id (-1) are not set to what we would prefer (see Output 1) TCP was also tried as the transport between P1 and P2. Upon receiving the reply from P2 the Tcpconn-Id and Socket of the connection between P1 and P2 was saved in the binding. When 2.b occurs the Socket and Tcpconn-Id are set to the correct values (see Output 2) Making a call when the binding state is at 2.a we receive the following error: "TCP/TLS connection (id: 0) for WebSocket could not be found" Making a call when the binding state is at 2.b works perfectly fine since the correct Tcpconn-Id is set. We did find a solution, or rather a workaround to this issue: 1) Always call the save function in request_route 2) If P2 responds with an error (non-200 OK) use the unregister function to remove the binding We also tried the tcpops tcp_set_otcpid and tcp_set_otcpid_flag functions after lookup, but this didn't do anything. KEMI Script def ksr_request_route(self, msg): if kemi.is_REGISTER(): aor = "aor" if result := kemi.htable.sht_is_null("registrations", aor) == 1: kemi.tm.t_on_reply("ksr_register_reply_route") kemi.dispatcher.ds_select_dst(1, 4) kemi.tm.t_relay() return 1 kemi.registrar.save("registrations", 1) return 1 if kemi.is_INVITE(): aor = "aor" if result := kemi.registrar.lookup_uri("registrations", aor): kemi.tm.t_relay() return 1 def ksr_register_reply_route(self, msg): if kemi.tm.t_check_status("200") == 1: kemi.registrar.save("registrations", 1) aor = "aor" kemi.htable.sht_sets("registrations", aor, "") return 1 Output 1: Binding state when request is being forwarded kamcmd ul.dump { Domains: { Domain: { Domain: registrations Size: 1024 AoRs: { Info: { AoR: grant(a)127.0.0.1 HashID: 409622189 Contacts: { Contact: { Address: sip:grant-0x7fe915a79138@172.16.99.12:9;transport=ws Expires: 13 Q: 1.000000 Call-ID: 7cdfbf93f23bb54f CSeq: 34818 User-Agent: n/a Received: sip:192.168.80.1:62184;transport=ws Path: [not set] State: CS_NEW Flags: 1 CFlags: 20 Socket: udp:10.2.0.15:5060 Methods: -1 Ruid: uloc-626a80d3-46-1 Instance: <urn:uuid:c67df38d-d5e0-e834-1d98-a8df2d3f291b> Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 0 Last-Keepalive: 1651146965 KA-Roundtrip: 0 Last-Modified: 1651146965 } } } } Stats: { Records: 1 Max-Slots: 1 } } } } kamcmd core.tcp_list { id: 1 type: WS state: CONN_OK timeout: 2 lifetime: 120 ref_count: 2 src_ip: 192.168.80.1 src_port: 62184 dst_ip: 192.168.80.15 dst_port: 80 } kamcmd ws.dump { connections: { 1: ws:192.168.80.1:62184 -> ws:192.168.80.15:80 (state: OPEN, last used 3s ago, sub-protocol: sip) } info: { wscounter: 1 truncated: no } } Output 2: Binding state when request is being absorbed kamcmd ul.dump { Domains: { Domain: { Domain: registrations Size: 1024 AoRs: { Info: { AoR: grant(a)127.0.0.1 HashID: 409622189 Contacts: { Contact: { Address: sip:grant-0x7fe915a79138@172.16.99.12:9;transport=ws Expires: 9 Q: 1.000000 Call-ID: 7cdfbf93f23bb54f CSeq: 34819 User-Agent: baresip v2.0.2 (x86_64/darwin) Received: sip:192.168.80.1:62184;transport=ws Path: [not set] State: CS_NEW Flags: 1 CFlags: 20 Socket: tcp:192.168.80.15:80 Methods: 5087 Ruid: uloc-626a80d3-46-1 Instance: <urn:uuid:c67df38d-d5e0-e834-1d98-a8df2d3f291b> Reg-Id: 0 Server-Id: 0 Tcpconn-Id: 1 Keepalive: 0 Last-Keepalive: 1651146979 KA-Roundtrip: 0 Last-Modified: 1651146979 } } } } Stats: { Records: 1 Max-Slots: 1 } } } } kamcmd core.tcp_list { id: 1 type: WS state: CONN_OK timeout: 3 lifetime: 120 ref_count: 2 src_ip: 192.168.80.1 src_port: 62184 dst_ip: 192.168.80.15 dst_port: 80 } kamcmd ws.dump { connections: { 1: ws:192.168.80.1:62184 -> ws:192.168.80.15:80 (state: OPEN, last used 1s ago, sub-protocol: sip) } info: { wscounter: 1 truncated: no } }

1 0

TOPOS, 183 (before a 200OK) and SIP INFO
by Giovanni Tommasini 28 Apr '22

28 Apr '22

Hi kamailiers, I ask your help for a strange situation with topos, 183 (before a 200OK) and SIP INFO My topology is kamailio in front of asterisks; so kamailio has 2 interfaces (1Public to talk with customers and carriers and 1 Private to talk with asterisk). In the image: - the first column is the customer - the second is the public interface of kamailio - the third is the private interface of kamaiio - the fourth is asterisk As you can see in the image, the customer send an INVITE and the carrier give back the IVR messages in a 183 (before a 200OK) asking for an IVR selection. The customer (configured to use SIP INFO) types a key and sends in INFO, but as you can see kamailio sends the INFO to himself to private interface instead of sending it to asterisk as if the contact that handled topos contained incorrect information. [image: Schermata 2022-04-26 alle 19.40.32.png] - If the customer is configured with a RFC2833 - or if the IVR messages is not in a 183 but is sent after a 200OK - or if I disabe TOPOS *all works fine* I used kamailio 5.5.3, I also try to upgrade to 5.5.4 but nothing change Maybe could be connected with https://github.com/kamailio/kamailio/issues/2344 https://github.com/kamailio/kamailio/issues/1077 Could be a kamailio bug for this particular situation or am I getting lost in a glass of water? thanks a lot cheers Giovanni Tommasini *evoseed s.r.l.* phone: +39 340 11 28 800 mail: giovanni.tommasini(a)evoseed.io site: evoseed.io address: Via Lucrezio 13, Trieste Italy

3 4

Kamailio functionality clarification - call forwarding no replay (call is ringing but not answered)
by Pavel Veselovsky 28 Apr '22

28 Apr '22

Hallo all, I would need help with Kamailio. I hope, you can give me some hints. I would like use Kamailio for CFNRy feature call forward no replay, i.e. - call is forked to multiple destination - 180 is received, call is ringing, but not answered, no 200 OK is received from destinations - after predefined time (CFNRy timer), the specific branch has to be rerouted to another destination Expected behaviour is described in this flow: [image: image.png] My current behavior: - Kamailio TM module is involved for parallel forking ( https://www.kamailio.org/docs/modules/stable/modules/tm.html#:~:text=1.-,Ov… ) - all branches are CANCEL-ed, it is not possible send CANCEL just to one specific branch [image: image.png] My questions: - is it possible to CANCEL just specific branch of parallel forked calls? - is it possible start timer just for specific branch? - do you think is it possible implement this feature with Kamailio? Thanks a lot in advance for any comments. Pavel.

3 2

t_check_trans failed on ACK
by Linux Vince 28 Apr '22

28 Apr '22

I am using Kamailio as registrar and proxy for underlying asterisk server. I am able to call but ACK on 200 OK respond from client phones are not validating transaction and thus not relaying correctly. Below are my Invites and 200 OK responses. Invite from Asterisk to Kamailio INVITE sip:31313004@rigel.com:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 65.20.69.72:5060 ;rport;branch=z9hG4bKd6ffff9d46ceb899c245ece204e51c87 From: "R31313005 N31313005" <sip:31313005@65.20.69.72:5060 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com:5060> Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 CSeq: 1 INVITE Contact: <sip:65.20.69.72:5060> max-forwards: 70 Allow: PUBLISH, SUBSCRIBE, MESSAGE, ACK, NOTIFY, OPTIONS, REFER, INFO, BYE, CANCEL, INVITE Content-Type: application/sdp Content-Length: 228 v=0 o=Clarent 155866 155867 IN IP4 65.20.69.72 s=Clarent CallManager c=IN IP4 65.20.69.72 t=0 0 m=audio 45168 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Invite from Kamailio to Phone INVITE sip:31313004@65.20.67.118;lhst=180.211.119.50:25759;lm=midreg SIP/2.0 Record-Route: <sip:65.20.67.118;lr;ftag=GR52RWG346-34> Via: SIP/2.0/UDP 65.20.67.118;branch=z9hG4bK6cc3.dad7580d3e28f55cbb749dbb82f0c9eb.0 Via: SIP/2.0/UDP 65.20.69.72:5060 ;received=65.20.69.72;rport=5060;branch=z9hG4bKd6ffff9d46ceb899c245ece204e51c87 From: "R31313005 N31313005" <sip:31313005@65.20.69.72:5060 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com:5060> Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 CSeq: 1 INVITE Contact: <sip:65.20.69.72:5060> max-forwards: 69 Allow: PUBLISH, SUBSCRIBE, MESSAGE, ACK, NOTIFY, OPTIONS, REFER, INFO, BYE, CANCEL, INVITE Content-Type: application/sdp Content-Length: 228 v=0 o=Clarent 155866 155867 IN IP4 65.20.69.72 s=Clarent CallManager c=IN IP4 65.20.69.72 t=0 0 m=audio 45168 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 200 OK from Phone to Kamailio SIP/2.0 200 OK Via: SIP/2.0/UDP 65.20.67.118;received=65.20.67.118;branch=z9hG4bK6cc3.dad7580d3e28f55cbb749dbb82f0c9eb.0 Via: SIP/2.0/UDP 65.20.69.72:5060 ;rport=5060;received=65.20.69.72;branch=z9hG4bKd6ffff9d46ceb899c245ece204e51c87 Record-Route: <sip:65.20.67.118;lr;ftag=GR52RWG346-34> Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 From: "R31313005 N31313005" <sip:31313005@65.20.69.72 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com >;tag=4ecc1f21f1544fd783965f27ff6d95d2 CSeq: 1 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Contact: <sip:31313004@180.211.119.50:57935;ob> Supported: replaces, 100rel, timer, norefersub Content-Type: application/sdp Content-Length: 322 v=0 o=- 3860150297 3860150298 IN IP4 180.211.119.50 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4016 RTP/AVP 0 101 c=IN IP4 180.211.119.50 b=TIAS:64000 a=rtcp:4017 IN IP4 180.211.119.50 a=sendrecv a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:1461220511 cname:3b657c275d2a43f6 200 OK from kamailio to asterisk SIP/2.0 200 OK Via: SIP/2.0/UDP 65.20.69.72:5060 ;rport=5060;received=65.20.69.72;branch=z9hG4bKd6ffff9d46ceb899c245ece204e51c87 Record-Route: <sip:65.20.67.118;lr;ftag=GR52RWG346-34> Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 From: "R31313005 N31313005" <sip:31313005@65.20.69.72 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com >;tag=4ecc1f21f1544fd783965f27ff6d95d2 CSeq: 1 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Contact: <sip:31313004@180.211.119.50:57935;ob> Supported: replaces, 100rel, timer, norefersub Content-Type: application/sdp Content-Length: 322 v=0 o=- 3860150297 3860150298 IN IP4 180.211.119.50 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4016 RTP/AVP 0 101 c=IN IP4 180.211.119.50 b=TIAS:64000 a=rtcp:4017 IN IP4 180.211.119.50 a=sendrecv a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:1461220511 cname:3b657c275d2a43f6 ACK from phone to Kamailio ACK sip:31313004@180.211.119.50:57935;ob SIP/2.0 Via: SIP/2.0/UDP 65.20.69.72:5060 ;rport;branch=z9hG4bK111270de2729ade9e048afa0f9fbb8df Route: <sip:65.20.67.118;lr;ftag=GR52RWG346-34> From: "R31313005 N31313005" <sip:31313005@65.20.69.72:5060 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com >;tag=4ecc1f21f1544fd783965f27ff6d95d2 Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 CSeq: 1 ACK Contact: <sip:65.20.69.72:5060> max-forwards: 70 Allow: PUBLISH, SUBSCRIBE, MESSAGE, ACK, NOTIFY, OPTIONS, REFER, INFO, BYE, CANCEL, INVITE This ACK is failing on transaction check and not routing correctly to phone. Any help? Thanks

2 3

Modify session name in SDP
by ZZ Wave 28 Apr '22

28 Apr '22

Hello. Kamailio 5.2.1, Debian 10. I need to change session name (s=) in SDP before relaying it to next hop, and for unknown reason I can't do it with virtually any TEXTOPS function, everything replace*, subst*, *body*... For example this from TEXTOPS documentation: subst_body('/^s=(.*)/s=root/') just before 'final' t_relay(). Either Kamailio just adds "s=root" to SDP leaving first "s=" intact, or adds just "root", or does nothing. Also I've tried msg_apply_changes() before and after these manipulations, still no result. Is it possible to make this in Kamailio without source code modification?

1 0

Jump to page:

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