sr-users

sr-users@lists.kamailio.org

28 participants
37382 discussions

ACK received instead of Status Code
by Waqar 40 26 Dec '22

26 Dec '22

Dear All, Attached in this email, is the screenshot of Kamailio logs for a call that did not originate. When Kamailio sends the call to the media destination which is an asterisk server, it should start sending status codes 100, 183, and 180 but instead, it sends ACK and the call did not originate. This happens only for some calls and I want to know why this is happening. Also, I want to identify these cases and do some further logic like trying some other media destination. How can I do that? [image: image.png] Regards, Vicky

1 0

Re: Call drops after 1 minute
by James Browne 23 Dec '22

23 Dec '22

Hi Christian I read your trace. There's no ACK after the SIP-200 response. It's cumbersome to read the trace because the client and server are at the same IP address, but I did it anyway. There's no ACK after the SIP-200 response, so it looks like the client (213.52.37.107) either doesn't sent it, or sends it directly to the server (213.52.37.107, the same IP address) without properly using the RR header field in the SIP-200 response. If you can set up a similar test and have a different host set up for the client and server (instead of 213.52.37.107 for both), and if you then trace the traffic again at all hosts, then you may find the rogue ACK request or be able to prove that the client never sent it (which might prove a broken client). When you use the client and server at the same IP address, it's not always straightforward to trace any traffic that might go directly from client to server, because it won't leave any network interface. Also I find strange that your call ends after "about a minute or so". I expect that they should end after about 31.5 seconds. It's almost certainly a SIP problem, and not any RTP/rtpproxy problem, so I recommend that you focus on the SIP. (I wrote this message before noticing that the thread is two weeks old.) James On Wed, 7 Dec 2022 at 08:41, Henning Westerholt <hw(a)gilawa.com> wrote: > > Hello, > > > > it looks that the 200 OK is not properly transmitted, as they seem to be retransmits. > > Maybe you should read a bit about SIP if you have not done it yet. It will help you debugging this problem (and probably others in the future). 😉 > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > From: Christian B Wiik <cbw(a)itf-as.no> > Sent: Wednesday, December 7, 2022 9:13 AM > To: Henning Westerholt <hw(a)gilawa.com> > Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > Subject: Re: [SR-Users] Call drops after 1 minute > > > > Link to entire trace: > > > > https://docs.google.com/document/d/1yWFJ_Cv13p5cYk-d8m5HMBSeLalkutV0cKZHjHf… > > > > -- > > Regards > > Christian > > > > > > ons. 7. des. 2022 kl. 08:57 skrev Henning Westerholt <hw(a)gilawa.com>: > > Hi Christian, > > > > this ACK is the reply to the 407 and not the relevant one for the dialog. > > > > Please have a look to the full SIP dialog. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > From: Christian B Wiik <cbw(a)itf-as.no> > Sent: Wednesday, December 7, 2022 8:14 AM > To: Henning Westerholt <hw(a)gilawa.com> > Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > Subject: Re: [SR-Users] Call drops after 1 minute > > > > Thanks Henning. > > > > These are the first 3 packets filtering on my user. I see the ACK but I'm not able to spot the error. > > > > U 213.52.37.107:50336 -> 10.1.2.10:5060 #1 > INVITE sip:kmm@sip2.itf-as.com SIP/2.0..Via: SIP/2.0/UDP 213.52.37.107:35270;rport;branch=z9hG4bKPj398365dc9 > 706413f868bdd222cadbed8..Max-Forwards: 70..From: <sip:cbwlap@sip2.itf-as.com>;tag=4183d760c26e4531a7a39f45d1 > 4fb4c6..To: <sip:kmm@sip2.itf-as.com>..Contact: <sip:cbwlap@213.52.37.107:35270;ob>..Call-ID: b3dd380f0c1d4e > 0ebdd7fc223710d938..CSeq: 23860 INVITE..Route: <sip:sip2.itf-as.com;lr>..Allow: PRACK, INVITE, ACK, BYE, CAN > CEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS..Supported: replaces, 100rel, timer, norefersu > b..Session-Expires: 1800..Min-SE: 90..User-Agent: MicroSIP/3.21.3..Content-Type: application/sdp..Content-Le > ngth: 345....v=0..o=- 3879388988 3879388988 IN IP4 213.52.37.107..s=pjmedia..b=AS:84..t=0 0..a=X-nat:0..m= > audio 35276 RTP/AVP 8 0 101..c=IN IP4 213.52.37.107..b=TIAS:64000..a=rtcp:35277 IN IP4 213.52.37.107..a=send > recv..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=ssrc > :1053777612 cname:28d400de4b7d5918.. > # > U 10.1.2.10:5060 -> 213.52.37.107:50336 #2 > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP 213.52.37.107:35270;rport=50336;branch=z9hG4bKPj > 398365dc9706413f868bdd222cadbed8;received=213.52.37.107..From: <sip:cbwlap@sip2.itf-as.com>;tag=4183d760c26e > 4531a7a39f45d14fb4c6..To: <sip:kmm@sip2.itf-as.com>;tag=9dd61ff61e802d8e2bef5f14621ef3c2.f003010a..Call-ID: > b3dd380f0c1d4e0ebdd7fc223710d938..CSeq: 23860 INVITE..Proxy-Authenticate: Digest realm="sip2.itf-as.com", no > nce="Y5A72WOQOq3afsXxs6AD2ihlmLAlgNOe"..Server: kamailio (5.6.2 (x86_64/linux))..Content-Length: 0.... > # > U 213.52.37.107:50336 -> 10.1.2.10:5060 #3 > ACK sip:kmm@sip2.itf-as.com SIP/2.0..Via: SIP/2.0/UDP 213.52.37.107:35270;rport;branch=z9hG4bKPj398365dc9706 > 413f868bdd222cadbed8..Max-Forwards: 70..From: <sip:cbwlap@sip2.itf-as.com>;tag=4183d760c26e4531a7a39f45d14fb > 4c6..To: <sip:kmm@sip2.itf-as.com>;tag=9dd61ff61e802d8e2bef5f14621ef3c2.f003010a..Call-ID: b3dd380f0c1d4e0eb > dd7fc223710d938..CSeq: 23860 ACK..Route: <sip:sip2.itf-as.com;lr>..Content-Length: 0.... > > > > -- > > Regards > > Christian > > > > > > ons. 7. des. 2022 kl. 07:51 skrev Henning Westerholt <hw(a)gilawa.com>: > > Hello, > > > > as you’ve guessed, this can be a common problem related to the routing of the ACK message. > > > > Have a look e.g. with ngrep or sngrep to the SIP signalisation on the server side and check if everything is correct in the SIP messages. > > > > > > From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Christian B Wiik > Sent: Wednesday, December 7, 2022 7:43 AM > To: sr-users(a)lists.kamailio.org > Subject: [SR-Users] Call drops after 1 minute > > > > Greetings! > > > > I have a CentOS setup in AWS where all my calls are dropped after about a minute or so. I realize this typically is a NAT problem, but I can't see where my error is. > > Sound is fine both ways. > > > > Kamailio is set with WITH_NAT and I use rtpproxy like this: > > OPTIONS="-l 10.1.2.10 -s udp:127.0.0.1:7722 -d INFO:LOG_LOCAL5 -m 35010 -M 35110 -A 54.171.168.48" > > (10.1.2.10 is the local IP for CentOS) > > > > Tested with MicroSIP and Linphone and tried numerous configurations. It seems the receiving client is not able to verify the call has been set up, and disconnects. MicroSIP has the status "Connecting..." until it disconnects. > > > > All tips appreciated. Will post configuration and logs if needed. > > Kamailio version 5.6.2 from rpm and rtpproxy 2.1.0 compiled from source. > > > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > sr-users(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender! > Edit mailing list options or unsubscribe: > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

1 0

Kamailio Lagging or Unreachable in Asterisk Peer
by Waqar 40 23 Dec '22

23 Dec '22

Dear All, I have three Kamailio in my production environment and I have written some code in Kamailio.cfg using SqlOps to insert data into the database on another remote server for every call. I deployed the code in one of the Kamailio and it inserted data perfectly fine into the database but as soon as I deployed it in the other two Kamailios. All three Kamailio's become unreachable or lagging in asterisk. I don't know if it has anything to do with SqlOps or queries being stuck somewhere as I am receiving logs consistently for every call in Kamailios. How can I identify if the queries are being stuck somewhere and that is why Kamailio is unreachable or lagging? Calls are not dependent on that database, this I know because even if I stop the mysql service calls will still be dialed. If it is due to the SqlOps, is there any other way to save information on every call without Kamailio being stuck? Regards VIcky

2 1

Dockerized VoIP Stack
by Terrance Devor 22 Dec '22

22 Dec '22

Hello Everyone, Does anyone have experience in deploying Kamailio, Asterisk and RTPProxy to a dockerized environment with K8s? In short, we are looking to deploy the following applications to our Kubernetes environment to support a SIP based PBX for our company: - Kamailio (Sip Proxy with DID, Outbound, edge routing and LB capabilities) - Asterisk Realtime (PBX, IVR) - RTPProxy (Media Relay) Has anyone been successful, or failed, in doing this? I would love to hear from you. Terrance

8 21

Re: sr-users Digest, Vol 211, Issue 47
by Luke Escudé 22 Dec '22

22 Dec '22

It's not easy and takes a long time to perfect, but our entire VoIP infrastructure is Dockerized, and composed of Asterisk, MySQL, Redis, NodeJS and Kamailio+RTPEngine (not rtpproxy, since rtpproxy isn't maintained anymore). No docker-level port forwarding required anywhere, since the entire system is designed to be volatile (see below). We have over 500 Asterisk docker containers running, supporting many thousands of users across the world at this point, and it works quite well, so it can be done. The concept behind the Asterisk containers is designing everything to be completely volatile: Outages happen, even in datacenters, so assume a container will reboot at some point on some random node at some random datacenter location. You don't know Asterisk's private IP, you don't even know where it might pop back up in the cluster. If you can ensure service continuity in that scenario, then you've built a solid setup. Our uptime has been 100% for over 4 years now (this is 3rd-party monitored and validated, in addition to our internal monitoring systems) so I assure you it is very possible. I also HIGHLY recommend not using a cloud provider for any of the core infrastructure. We tried this, with AWS and GCP, and the voip quality was... meh. The cloud outages were frequent, although customers generally don't notice them when you're using lightweight containers to run everything. So we are fully operating on our own hardware across multiple colo locations, and only using cloud for file storage (eFaxes, voicemails, greetings/recordings, MMS content, phone LCD background images for provisioning, etc). I am unable to help with your project, but I can at least provide the above pointers/experiences in case they get you in the right direction. An alternative to building your own infrastructure might be reselling (white label) an existing service provider as well, in case the decision to build your own infrastructure is still up in the air. Luke Escudé 972.600.1150 support(a)primevox.net Schedule a meeting!<https://outlook.office365.com/owa/calendar/PrimeVOXCommunications@primevox.…> View the PrimeVOX R&D Roadmap here<https://trello.com/b/pzpoyn8m/primevox-engineering> View the PrimeVOX Status Page here<https://status.primevox.net/> ________________________________ From: sr-users-request(a)lists.kamailio.org <sr-users-request(a)lists.kamailio.org> Sent: Thursday, December 22, 2022 9:44 AM To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org> Subject: sr-users Digest, Vol 211, Issue 47 Send sr-users mailing list submissions to sr-users(a)lists.kamailio.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to sr-users-request(a)lists.kamailio.org You can reach the person managing the list at sr-users-owner(a)lists.kamailio.org When replying, please edit your Subject line so it is more specific than "Re: Contents of sr-users digest..." Today's Topics: 1. Re: Dockerized VoIP Stack (Terrance Devor) 2. Re: Dockerized VoIP Stack (Terrance Devor) 3. Re: Dockerized VoIP Stack (Terrance Devor) ---------------------------------------------------------------------- Message: 1 Date: Thu, 22 Dec 2022 09:31:33 -0500 From: Terrance Devor <ter.devor(a)gmail.com> Subject: [SR-Users] Re: Dockerized VoIP Stack To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Message-ID: <CA+w+2f8CtdwkiDtz+Md-pZz5xA4-59gv768b_vq4bkdjf2V3hw(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="000000000000398ece05f06b87af" I did see the CyCore project and tried to connect with Laurel Lauson and Sean McCord on LinkedIn On Wed, Dec 21, 2022 at 9:18 PM Fred Posner <fred(a)palner.com> wrote: > On Dec 21, 2022, at 8:41 PM, Terrance Devor <ter.devor(a)gmail.com> wrote: > > > Does anyone have experience in deploying Kamailio, Asterisk and RTPProxy > to a dockerized environment with K8s? > > > Check out some past Kamailio World and Astricon presentations, including > some from Sean McCord. He even has a GitHub demo: > > * https://github.com/CyCoreSystems/asterisk-k8s-demo > > -- Fred > The Palner Group, Inc. > +1 (212) 937-7844 > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: >

2 1

Which KEMI-language has the lowest runtime overhead?
by Дилян Палаузов 22 Dec '22

22 Dec '22

Hello, KEMI can be programmed in Java, JavaScript, Lua(sr), Squirrel, Mono, Perl, Python(2,3,3s), Ruby. Which language binding has the lowest runtime overhead in CPU-terms? How about lowest overhead in terms of RAM? Kind regards Дилян

4 3

IMS integration with AS
by Oleg Belousov 22 Dec '22

22 Dec '22

Hi. Can you please advise if existing ims implementation supports integration with ims AS (Application Server), in particular for the third party registration: - upon UE registration is completed, S-CSCF constructs Register message (which keeps all details of subscriber register message) and submits it to AS server as regular SIP-message (TS 24.229 5.4.1.7 Notification of Application Servers about registration status). S-CSCF obtains AS address from SAA (Server Assignment Answer) diameter message, received from HSS upon successful registration. -- obelousov.tel

2 2

How to make a branch trigger persistent (still being active after failure route is triggered)?
by Benoît Panizzon 20 Dec '22

20 Dec '22

Hi List Some time ago, during my learning curve with kamailio, I learned that a branch route is where you make modifications to callerId's. So I extensively re-engineered the config to move as much as possible of callerid modification into branch routes. But now I discovered, when a call is dispatched via dispatch group with multiple destinations and one destination fails, therefore the failure route is triggered, the branch route is not being called on the second attempt, thus callerid being in the wrong format. Example: dispatcher.lst As an example, consider having dispatcher group 2001 for national traffic over two dedicated links and Dispatcher group 2002 for international traffic. 2001 sip:192.168.1.1:5060 0 0 name="Carrier1" 2001 sip:192.168.2.1:5060 0 0 name="Carrier1" 2002 sip:192.168.1.3:5060 0 0 name="Carrier2" request_route { # We determine where we want to send the call # and choose dispatch group 2001, the 'national' one. # But there are are other dispatch groups and branch triggers # set this way and routed to DISPATCHCALL $avp(dispgroup) = 2001; t_on_branch("BR_TO_NATIONAL"); route(DISPATCHCALL); } route[DISPATCHCALL] { t_set_fr(120000,1500); # Fast Failover t_set_max_lifetime(300000,0); t_set_retr(200,800); if (ds_select_dst("$avp(dispgroup)", "6")) { if (ds_is_from_list(-1,0,"$du")) { t_on_failure("DISPATCH_FAILURE"); route(RELAY); } } } branch_route[BR_TO_NATIONAL] { # Here I make sure, all CallerId and Header are correct for the # national Carrier } failure_route[DISPATCH_FAILURE] { if (t_check_status("(5[0-9][0-9])") or (t_branch_timeout() and !t_branch_replied())) { # Try next DS. if (ds_next_dst()) { xlog("L_INFO", " --> retargeting request\n"); t_on_failure("DISPATCH_FAILURE"); route(RELAY); #### RIGHT HERE! exit; } } # We fail xlog("L_ERROR", "Call Failed\n"); } My issue is not, that if the call is routed after the first path failed (marked with #### RIGHT HERE!) then the appropriate branch route is not triggered again and the headers are wrong. But I can not set t_on_branch within route[DISPATCHCALL] or route[DISPATCH_FAILURE] because this is called with a different pre-set branch trigger, depending on the target dispatch group. Is there a way to make a branch trigger more persistent? -- 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 ______________________________________________________

4 7

Topoh module not decoding the BYE received from the callee
by Michel Pelletier 20 Dec '22

20 Dec '22

Hello, I am using the topoh module and it works fine except for the BYE requests coming from the callee (the person receiving the call). When a BYE is received from the destination of the call, then Kamailio relays it to the dummy IP 127.0.0.8. This is exemplified in the topoh:msg-outgoing and topoh:msg-sending events where the $sndto(ip) is set to 127.0.0.8. I am using all default modparams with topoh. The only modparam I have is for setting the event_callback. I am using Kamailio 5.6.2 with Kemi using python3. Michel Pelletier

2 3

dialog_vars accumulating in database?
by Benoit Panizzon 20 Dec '22

20 Dec '22

Hi List I noticed that the database is accumulating entries on dialog_vars. I don't know when and why this is happening. Are there any special measures that have to be taken like making sure to unset variables after using them to prevent this? Or is this something which is supposed to happen when kamailio is restarted? Mit freundlichen Grüssen -Benoît Panizzon- -- 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 ______________________________________________________

2 5

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