- sr-users - kamailio.org

Location / Registrar, TCP: Use existing TCP connection
by Benoit Panizzon 09 Mar '23

09 Mar '23

Hi List CPE behind Firewall, registering to Kamailio via TCP (or TLS). When a call is sent to the CPE, kamailio attemts to open a new TCP connection and is blocked by Firewall. Is there an option to tell kamailio to use the existing registered TCP connection? 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 2

Call recovery for HA with sems
by Patrick Karton 09 Mar '23

09 Mar '23

1 0

TLS -> UDP ReInvite
by Social Boh 08 Mar '23

08 Mar '23

hello, I'm configuring Kamailio to permite calls like: UDP -> UDP TLS -> TLS UDP -> TLS TLS -> UDP Until now all is ok; the only problem is with Microsip SoftPhone. When make a call from Microsip TLS to another phone UDP, when the callee answer, Microsip send a new INVITE and Kamailio don't delete all references to SRTP so the call happens but without audio. I know I have to process the reINVITE where I do has_totag stuff but I don't know how. Regards -- --- I'm SoCIaL, MayBe

1 0

Re: sr-users Digest, Vol 213, Issue 52
by Mohamed SADIK 08 Mar '23

08 Mar '23

Hello, Thank you for your reply! I've used your suggestion to accomplish some amazing things. However, I'm having an issue when calling the *"sl.stats"* or any other procedures. I've noticed that the number of "200" responses gets incremented by 2, which is not the case when using the `*kamcmd*` tool. I suspect that this may be due to jsonrpc using *http/https*, which is causing Kamailio to treat it as a "200" response code. Could you advise on how to avoid this issue? Is there any further configuration that needs to be done? Best regards. On Sat, Feb 25, 2023 at 12:00 PM <sr-users-request(a)lists.kamailio.org> wrote: > 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. Kamailio RPC configuration (sadik.oualla.mohamed(a)gmail.com) > 2. Re: Kamailio RPC configuration (Alex Balashov) > > > > ---------- Forwarded message ---------- > From: sadik.oualla.mohamed(a)gmail.com > To: sr-users(a)lists.kamailio.org > Cc: > Bcc: > Date: Fri, 24 Feb 2023 17:07:33 -0000 > Subject: [SR-Users] Kamailio RPC configuration > Dear Kamailio community, > > I am a newbie in Kamailio and I am currently working on a project that > involves communicating with Kamailio using Python. I have been exploring > the Kamailio documentation and I have come across RPC, JSONRPCS..., which I > believe can help me achieve my goal. > > However, I am not sure about the steps to follow in the Kamailio > configuration file to create my own script to communicate with Kamailio > using Python (the script is on an other machine on the same LAN). I would > be grateful if someone could guide me through the process. > > I have already set up Kamailio (builed it from the source code 5.5.5) and > Python on my machines and I have basic knowledge of Kamailio configuration. > I just need some guidance on how to set up the RPC module in Kamailio and > how to create a Python script to communicate with it. I found that I can > use RPyC library of python. > > I would appreciate any help or suggestions from the Kamailio community. > Thank you in advance for your time and assistance. > > Best regards, > Wild Coder. > > > > ---------- Forwarded message ---------- > From: Alex Balashov <abalashov(a)evaristesys.com> > To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> > Cc: > Bcc: > Date: Fri, 24 Feb 2023 13:22:16 -0500 > Subject: [SR-Users] Re: Kamailio RPC configuration > Hi, > > The easiest way to communicate with the JSONRPCS module is probably to use > HTTP, in the form of the `xhttp` module: > > https://kamailio.org/docs/modules/5.6.x/modules/xhttp.html > > You will need... > > 1) To enable the HTTP transport in the `jsonrpcs` module; > > 2) A TCP or TLS listener (listen= config directive) to accept the traffic; > > 3) An xhttp `event_route[xhttp:request]` route, as detailed in that > module's docs: > > > https://kamailio.org/docs/modules/5.6.x/modules/xhttp.html#xhttp.f.xhttp_re… > > 4) Probably some measure of security / authentication for #3. > > The example from jsonrpc_dispatch() is perfectly sufficient to get you > started: > > > https://kamailio.org/docs/modules/5.6.x/modules/jsonrpcs.html#jsonrpcs.f.js… > > You should then be able to do things like: > > # curl \ > -X POST \ > -d '{"jsonrpc": "2.0", "id": "abc123", "method": "ul.dump"}' \ > http://${KAMAILIO_IP}:5060/RPC <http://${kamailio_ip}:5060/RPC> > > -- Alex > > > On Feb 24, 2023, at 12:07 PM, sadik.oualla.mohamed(a)gmail.com wrote: > > > > Dear Kamailio community, > > > > I am a newbie in Kamailio and I am currently working on a project that > involves communicating with Kamailio using Python. I have been exploring > the Kamailio documentation and I have come across RPC, JSONRPCS..., which I > believe can help me achieve my goal. > > > > However, I am not sure about the steps to follow in the Kamailio > configuration file to create my own script to communicate with Kamailio > using Python (the script is on an other machine on the same LAN). I would > be grateful if someone could guide me through the process. > > > > I have already set up Kamailio (builed it from the source code 5.5.5) > and Python on my machines and I have basic knowledge of Kamailio > configuration. I just need some guidance on how to set up the RPC module in > Kamailio and how to create a Python script to communicate with it. I found > that I can use RPyC library of python. > > > > I would appreciate any help or suggestions from the Kamailio community. > Thank you in advance for your time and assistance. > > > > Best regards, > > Wild Coder. > > __________________________________________________________ > > 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: > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 e > > _______________________________________________ > sr-users mailing list -- sr-users(a)lists.kamailio.org > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org >

1 0

Using jsonrpc_dispatch in xhttp:request - is it possible to restrict the RPC that can be invoked ?
by Chaigneau, Nicolas 07 Mar '23

07 Mar '23

Hello, I'm using jsonrpc_dispatch in a "xhttp:request" section (with xhttp and jsonrpcs modules), e.g.: event_route[xhttp:request] { if ($hu =~ "^/RPC") { jsonrpc_dispatch(); exit; } xhttp_reply("404", "Not Found", "", ""); exit; } This works, but I would like to restrict the RPC functions that can be invoked this way. Any advice on how I could do that ? The xhttp module provides "url_skip" and "url_match" but this is not useful because in the URL I only have something like "RPC". And the method is in the JSON body. I could parse the JSON body before calling jsonrpc_dispatch, but it's a bit complicated (I don't know if it's feasible in Kamailio script ?), and seems redundant because jsonrpc_dispatch already does that... Maybe somehow this could be checked from the "void *" second argument passed to the RPC function ? Thanks. Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

2 4

Info: Kamailio World 2023 - Announcing First Group Of Speakers
by Daniel-Constantin Mierla 06 Mar '23

06 Mar '23

Hello, it's now like 3 months till the start of the next Kamailio World Conference (taking place in Berlin, Germany, during June 5-8, 2023) and the first group of speakers has just been published, the details are available at: - https://www.kamailioworld.com/k2023/speakers/ Not all proposals were reviewed and Call for Speakers is still open, therefore if you want to share your interesting experiences or knowledge in the RTC space, submit it via: - https://www.kamailioworld.com/k2023/call-for-speakers/ All together, expect another edition of Kamailio World conference with great content covering topics such as RTC scalability, security, cloud-based deployments and elasticity, NG112/911, IoT, WebRTC, VoLTE and 4G/5G. Looking forward to meeting many of you in Berlin! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 0

Remove silo extra_hdrs before store
by Dr. Barabás Péter 06 Mar '23

06 Mar '23

Hi, I’m using kamailio’s silo module to store offline messages in it. I set extra_hdrs modparam to e.g. : ‘Resent-from-silo’ so the clients get information that the message has arrived directly (immediatelly) from the sender or it was stored offline and comes from silo. So the problem is the following: * if receiver’s socket is broken (e.g. airplane mode on mobile) and kamailio ‘thinks’ it is registered, server tries to send the message * message will be timed out and based on config it will be stored in silo. * the next step is to check if receiver is registered or not (since the client can re-register during 30sec until the message has timed out) * If client is registered, kamailio tries to send the message immediately with m_dump(). * If the receiver’s connection is still broken, the message will be timed out and store in silo. * In every store, a new ‘resent’ extra_hdrs value is appended. When extra_hdrs length reaches 1024 bytes, the m_dump will fail and it blocks the dumping of messages to the given receiver. Question: can extra_hdrs value be removed before store? Or what can be the solution not to duplicate the extra_hdrs value in some bad network situation? Peter

1 0

How to access rtpengine rtcp-metrics?
by Benoit Panizzon 06 Mar '23

06 Mar '23

Hi all I'm trying to incorporate rtcp data from rtpengine into our CDRS. So trying with the first interesting value, the average mos. modparam("rtpengine", "mos_average_pv", "$avp(mos_average)") If I understood right, to get this variable set, I need to call rtpengine_manage() on the message that terminates the call. So on an established call, that is either BYE or the 200 OK to the BYE. Right? if ($rm == "BYE") { rtpengine_manage(); xlog("L_INFO", "$cfg(route): $rm: MOSS: $avp(mos_average)\n"); } onreply_route[MANAGE_REPLY] { [...] rtpengine_manage(); xlog("L_INFO", "$cfg(route): $rm reply MOS: $avp(mos_average)\n"); } Messages pass those blocks, $avp(mos_average) is 'null' no mater what. What am I missing? In the syslog output of rtpengine I see there is rtcp data. 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 ______________________________________________________

3 2

tcp_set_connection_lifetime => in respect to 'idle' connection?
by Benoit Panizzon 06 Mar '23

06 Mar '23

Hi List Digging further into my tcp/tls issues... Upon successful authentication I call: tcp_keepalive_enable("60", "5", "5"); tcp_set_connection_lifetime("120"); I tought, this would do to keep the connection alive. I noticed, despite keepalive packets being exchanged, kamailio is closing the connection after a bit more than 2 minutes. I am right at assuming, that tcp_set_connection_lifetime is not related to how long the connection is idle, but is counted from the SYN, no matter if keepalives were successfully exchanged? Does calling tcp_set_connection_lifetime() again restart the lifetime like for 2 more minutes like in this example? Or would I have to keep increase the value of the lifetime on each successful re-register to keep it open? 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 ______________________________________________________

1 0

Kamailio v5.6.3 Released
by Daniel-Constantin Mierla 05 Mar '23

05 Mar '23

Hello, Kamailio SIP Server v5.6.3 stable release is out. This is a maintenance release of the latest stable branch, 5.6, that includes fixes since the release of v5.6.2. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.6.x. Deployments running previous v5.6.x versions are strongly recommended to be upgraded to v5.6.3. For more details about version 5.6.3 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/01/kamailio-v5-6-3-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

5 10

Kamailio v5.5.6 Released
by Daniel-Constantin Mierla 02 Mar '23

02 Mar '23

Hello, Kamailio SIP Server v5.5.6 stable release is out. This is a maintenance release of the stable branch 5.5 that includes fixes since the release of v5.5.5. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.5.x. Deployments running previous v5.5.x versions are strongly recommended to be upgraded to v5.5.6. Note that 5.5 is the second last stable branch, still officially maintained by Kamailio development team. The latest stable branch is 5.6, with v5.6.4 being release out of it. For more details about version 5.5.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/03/kamailio-v5-5-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 0

Releasing Kamailio v5.5.6
by Daniel-Constantin Mierla 02 Mar '23

02 Mar '23

Hello, I am considering to release Kamailio v5.5.6 soon, branch on branch 5.5, likely on Thursday or Wednesday next week (Mar 2/3, 2023). This is the usual heads up notification to see if anyone is aware of issues not yet reported to bug tracker and if yes, do it as soon as possible to give them a chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 1

Websocket closing
by David Villasmil 01 Mar '23

01 Mar '23

Hello guys, We're seeing corner cases where the following happens: On proxy-ws - IP1:PORT1 connects via websocket from Client1 - Registration happens on an upstream kamailio - for any reason, the TCP socket closes or times out. - IP1:PORT1 (same IP:PORT combination) connects via websocket from Client2 - Registration happens on an upstream kamailio Now a call comes in to Client1. Because the first connection was never cleaned up, it is sent to the proxy-ws and the proxy will send it to the IP1:PORT1 where Client2 is connected. Short story, proxy-ws doesn't check the IP1:PORT1 where it is sending the INVITE is the actual client it is supposed to be sending... It seems that when a socket is closed, the mapping IP:PORT to Address (i.e.: sip:d4f27e34@994f31243be9.invalid;transport=ws) doesn't seem to be cleared... is this by design? Thanks! Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

3 6

Kamailio stops processing the calls - restart fixes it.
by Muhammad Danish Moosa 01 Mar '23

01 Mar '23

Hi, I have a very simple proxy (stateful) where kamailio acts as a proxy between 2 endpoints. Everything works fine for weeks and suddenly I see kamailio stops responding. From pcap I can see kamailio is not proxying the session progress and bombarding invites to one endpoint without any reason. Even that invite was stripped on the Body part. Restarting kamailio fixes it immediately. Unfortunately I could not take bt full yet. Version is kamailio 5.5.3 (x86_64/linux) 473cef configuration is very simple , routing is based on tm.t_relay ( based on KEMI). Any help will be welcome. Danish -- Muhammad Danish Moosa

3 5

Kamailio v5.6.4 Released
by Daniel-Constantin Mierla 27 Feb '23

27 Feb '23

Hello, Kamailio SIP Server v5.6.4 stable release is out. This is a maintenance release of the latest stable branch, 5.6, that includes fixes since the release of v5.6.3. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.6.x. Deployments running previous v5.6.x versions are strongly recommended to be upgraded to v5.6.4. For more details about version 5.6.4 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/02/kamailio-v5-6-4-released/ RPM, Debian/Ubuntu packages will be available soon as well. An additional note to say that call for speakers and registration for Kamailio World Conference 2023 are now open, more details at: * https://www.kamailioworld.com Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 0

Kamailio MS Teams TLS Issue
by iliusha.md＠gmail.com 27 Feb '23

27 Feb '23

Hello, We have one Kamailio Instance connected with MS Teams (based on this instruction: https://skalatan.de/en/blog/kamailio-sbc-teams), which worked fine for a while until recently we noticed that calls from teams are not working anymore. When I looked through the logs I found that Microsoft cannot establish a TLS connection to our server because of the cipher: TLS accept:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (sni: sbc.example.com - domain is obfuscated). Certificate is valid, the configuration is below: [server:default] method = TLSv1.2+ verify_certificate = no require_certificate = no private_key = /usr/local/etc/kamailio/certs/example.net/sbc1-teams_example_net.key certificate = /usr/local/etc/kamailio/certs/example.net/sbc1-teams_example_net.crt server_name = sbc1-teams.example.net ca_list = /usr/local/etc/kamailio/certs/sectigo_ca.pem #ca_list=/etc/ssl/certs/ca-bundle.crt [client:default] method = TLSv1.2+ verify_certificate = no require_certificate = no private_key = /usr/local/etc/kamailio/certs/example.net/sbc1-teams_example_net.key certificate = /usr/local/etc/kamailio/certs/example.net/sbc1-teams_example_net.crt ca_list = /usr/local/etc/kamailio/certs/sectigo_ca.pem #ca_list=/etc/ssl/certs/ca-bundle.crt We use a certificate from Sectigo, but I've tried with Let's Encrypt - and it's the same. Any idea what could be the reason?

5 7

Releasing v5.6.4
by Daniel-Constantin Mierla 27 Feb '23

27 Feb '23

Hello, I am considering to release Kamailio v5.6.4 (out of branch 5.6) next week (likely on Monday or Tuesday, Feb 27/28, 2023). If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 1

Kamailio RPC configuration
by sadik.oualla.mohamed＠gmail.com 24 Feb '23

24 Feb '23

Dear Kamailio community, I am a newbie in Kamailio and I am currently working on a project that involves communicating with Kamailio using Python. I have been exploring the Kamailio documentation and I have come across RPC, JSONRPCS..., which I believe can help me achieve my goal. However, I am not sure about the steps to follow in the Kamailio configuration file to create my own script to communicate with Kamailio using Python (the script is on an other machine on the same LAN). I would be grateful if someone could guide me through the process. I have already set up Kamailio (builed it from the source code 5.5.5) and Python on my machines and I have basic knowledge of Kamailio configuration. I just need some guidance on how to set up the RPC module in Kamailio and how to create a Python script to communicate with it. I found that I can use RPyC library of python. I would appreciate any help or suggestions from the Kamailio community. Thank you in advance for your time and assistance. Best regards, Wild Coder.

2 1

OT: MS Teams source IP address ranges
by Jon Bonilla (Manwe) 24 Feb '23

24 Feb '23

Hi Sorry for the OT but I think here's the place where I an find a lot of Ms teams integrations I've been working on MS teams direct routing integration for PekePBX. It works. I guess I've done it as everybody else, using Henning's guide as base and extending it for multitenant setup (thanks Henning!) What I've realized is that the source IP address of calls coming from MS are not always matching dispatcher hosts. Sometimes they come from another source IP and failover to the dispatcher hosts when they receive no response. That makes some of the calls to have an additional latency Searching in the MS doc I see that they document these nets as source of their signaling: 52.112.0.0/14 52.120.0.0/14 But I've seen IP addresses outside of this range as source. In this blog https://erwinbierens.com/microsoft-teams-direct-routing-ip-addresses/ The ranges are listed as 52.112.0.0/16 52.113.0.0/16 52.114.0.0/16 52.115.0.0/16 52.120.0.0/16 52.121.0.0/16 52.122.0.0/16 52.123.0.0/16 which looks better but scares me out. Having no auth is it secure to bind so many ranges to MS? Do you use anything else than certificate verification for these calls? cheers, Jon -- PekePBX, the multitenant PBX solution https://pekepbx.com

4 6

Dispatcher failover when SRV failover is on?
by Jon Bonilla (Manwe) 23 Feb '23

23 Feb '23

Hi Again, fighting with MS Teams but this time it's a kamailio question. I have MSteams hosts in the dispatcher for OPTIONS and for destination. Acording to MS you need to try sip.pstnhub.foo then sip2.pstnhub.foo and sip3.pstnhub.foo 2 | sip:sip.pstnhub.microsoft.com;transport=tls | 0 | 1 2 | sip:sip2.pstnhub.microsoft.com;transport=tls | 0 | 2 2 | sip:sip3.pstnhub.microsoft.com;transport=tls | 0 | 3 I was going to implement dispatcher failover as usual ds_select_domain (alg 8) with failure routes but checking the SRV of the first domain I see it already includes 4 hosts: host -t srv _sips._tcp.sip.pstnhub.microsoft.com _sips._tcp.sip.pstnhub.microsoft.com has SRV record 10 0 5061 sip.pstnhub.microsoft.com. _sips._tcp.sip.pstnhub.microsoft.com has SRV record 20 0 5061 sip2.pstnhub.microsoft.com. _sips._tcp.sip.pstnhub.microsoft.com has SRV record 30 0 5061 sip3.pstnhub.microsoft.com. _sips._tcp.sip.pstnhub.microsoft.com has SRV record 40 0 5061 sip4.pstnhub.microsoft.com. So... If I have dns srv failover enabled in kamailio... what would be the point of the dispatcher failover? In case I only want failover in case 408 or 5XX wouldn't the tm module do it for me? cheers, Jon -- PekePBX, the multitenant PBX solution https://pekepbx.com

3 2

What does l_username in UAC do?
by Дилян Палаузов 23 Feb '23

23 Feb '23

Hello, the uac module-registrations have the fields l_uuid - user for Contact: in REGISTER (before @). Described at https://kamailio.org/docs/db-tables/kamailio-db-5.6.x.html#idm9037 as “Local unique id used to build and match contact addresses.”. Described at https://www.kamailio.org/docs/modules/devel/modules/uac#idm700 as “local unique user id, e.g.,: 12345678” l_username - Described at https://kamailio.org/docs/db-tables/kamailio-db-5.6.x.html#idm9037 as “Local username”. Described at https://www.kamailio.org/docs/modules/devel/modules/uac#idm700 as “local user name, e.g.,: test ”. For me there is no difference between “local unique id” (as for l_uuid) and “local username“ (here). l_domain - used for Contact: in REGISTER (after @), described at https://kamailio.org/docs/db-tables/kamailio-db-5.6.x.html#idm9037 as “local domain” When is l_username used, what is it purpose? Does it solely serve as possible filter criterion for the RPC commands: uac.reg_info l_username abc uac.reg_enable l_username abc uac.reg_disable l_username abc, and uac.reg_unregister l_username abc Do I see correctly, that via UAC-RPC an unREGISTER can be triggered, but there is no way to trigger a REGISTER over UAC-RPC? Thanks for the clarifications Дилян

2 2

change default 477 response code per case
by Patrick Karton 22 Feb '23

22 Feb '23

Hello , i would like to know if there is a way to change the default 477 response code generated by kamailio in some cases. for example if kamalio generates 477 because its not able to reach a peer i would like to change it to another code before to forward it. Thanks.

2 1

Call History
by Anthony Wittig 21 Feb '23

21 Feb '23

Hello, I'd like to start tracking a call history/log as soon as I receive a call. I'd like the customer to be able to see that there's an incoming call to one of their numbers in real time. I'm thinking of using the RABBITMQ Module to manually emit an event from my main route when I receive an INVITE. Is that a bad idea? What if the broker isn't located on the same host (latency/availability)? I don't want to negatively affect the call processing. I was looking at the Dialog Module and it has three event routes: * event_route[dialog:start] * event_route[dialog:end] * event_route[dialog:failed] It's really close to what I want, but I'd like to capture the dialog before it starts (Unconfirmed or Early). Maybe another option is to scan the Dialog table with an external process and emit events from there. Has anyone had success in creating a realtime call history? Is there a better way to go about doing so? Thanks! -- Anthony Wittig Mango Voice Developer

7 7

Info: Registration to Kamailio World 2023 is open!
by Daniel-Constantin Mierla 21 Feb '23

21 Feb '23

Hello, a quick note to the community forums to announce that the registration for the next Kamailio World Conference (June 5-7, 2022, in Berlin, Germany) is now open! The event returns to an in-person conference format, at the same wonderful location in the city center of Berlin! More details are available at: * https://www.kamailioworld.com/k2023/registration/ Call for presentations is also open, there is already a group of very interesting submissions, we aim to publish details about them in the near future. Looking forward to meeting many of you in Berlin! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

2 2

topos breaking route set on hairpin calls?
by Benoît Panizzon 20 Feb '23

20 Feb '23

Hi Having this situation while elaborating topos in lab. * Kamailio Registration Instance with topos enabled where customers are registered. * Kamailio Core Instance with Dialogue enabled and handling interconnections. Calls in transit from customer to IC work flawlessly, topos does what it should, hides and restores headers needed on the core. But I have run into an issue with customer calling another customer on same registrar instance. To generate a CDR with diaglogue and for decision where to route the calls to (registrar is kept simple and only handles registrations and locations), those calls are also routed via core. This works as long as PRACK is disabled. When PRACK is enabled and CPE B is requesting 100rel, the PRACK send from CPE A has no route set (it was removed by topos). Therefore the PRACK only makes it to the core who then does not know where to route that PRACK. It looks like topos on the REG only restores ONE Route pointing to the core (maybe because the 2nd one pointed to itself?) header when restoring them. I have attempted to spam more record_route() here and there in the config of the core and the registrar to try to force creation of route headers, but failed. Is this a known limitation of using topos? -- 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 ______________________________________________________

2 4

Re: OT: MS Teams source IP address ranges
by Henning Westerholt 20 Feb '23

20 Feb '23

Hi Jon, you could of course try to add some heuristic, in the end the used IPs are a smaller sub-set. But to just quote from the official docs, it seems to be pretty clear: "You need to open ports for all these IP address ranges in your firewall to allow incoming and outgoing traffic to and from the addresses for signaling." Cheers, Henning ________________________________ From: Jon Bonilla (Manwe) Sent: Monday, February 20, 2023 15:49 To: Henning Westerholt; Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] OT: MS Teams source IP address ranges El Mon, 20 Feb 2023 13:06:30 +0000 Henning Westerholt <hw(a)gilawa.com> escribió: > Hello, > > correct me if I am wrong, but the second group of addresses ("/16") is > included in the first group ("/14"), right? > > Regarding the large IP scope, this is the way Microsoft designed it, > unfortunately. There is not that much what you can do about. > > Right. Didn't check the masks. they all were 16 in my mind :) So, if I add those ranges in the permissions table my only way of avoiding spoofed calls is certificate validation? I'm already doing that and also checking the company domain and ms account email address. Just wanted to be sure that nothing "essential" was missing. -- PekePBX, the multitenant PBX solution https://pekepbx.com

1 0

sendig 4 byte udp nat pings
by Bernd Krueger-Knauber 18 Feb '23

18 Feb '23

Hi, maybe I'm stupid, but I can not find out how to send 4 byte UDP NAT packets to the sip server. loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 15) modparam("nathelper|registrar", "received_avp", "$avp(s:rcv)") I'm a absolute beginner with kamailio and the page about the nathelper Module is not really helpful. At the moment no pings are sendet. But I receive 4 byte packets from the sip server. After 15 minutes my calls are cancelled because of the missing pings. Without proxy, the phone send the pings directly to the sip server and the call stays alive. When I experiment with some other nathelper settings, kamailo start results in errors. Any help would be appreciated. Best regards, Bernd

3 11

enable topology hiding on one side or dynamic ip in topoh module Contact and Via Header
by Patrick Karton 17 Feb '23

17 Feb '23

Hello , im using kamailio with two interfaces external and internal. i need a way either to : * enable topoh hiding only when outgoing interface is external ( mask contact and Via ip only when ougoing interface is external * or if it is not possible to enable it only in one direction.i want to know how to configure dynamic(for example in xavp or avp) ip to put in Contact and Via when topoh is enabled. i see that the 'mask_ip' parameter of topoh module is a string. so we can not set a dynamic value here unfortunately. Thanks

4 8

Calling uac_replace multiple times?
by Benoît Panizzon 17 Feb '23

17 Feb '23

Hey all I have started using the uac module to be able to mirror username changes on both legs of a call. But now I found an issue: Assume this situation: Call IC => Customer IC is e164, Customer wants 'local' numbers. IC From: +41991234567 => Customer From: 0991234567 uac_replace_from("sip:" + $avp(from_local) + "@" + $(fu{uri.host})); Customer is absent, after timeout in failure_route call is dispatched to Voicemail Server, which is configured for e164 numbers: uac_replace_from("sip:" + $avp(from_e164) + "@" + $(fu{uri.host})); But then uac complains: replace_uri(): Already called uac_replace for this dialog Why isn't just the most from version kept and used? -- 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 ______________________________________________________

2 1

TLS version and cipher from WSS
by Michal Hajek 17 Feb '23

17 Feb '23

Hi, I can log incoming SIPS TLS version and cipher with PV $tls_version and $tls_cipher_info. How can I log these variables on incoming HTTP/WebSocket. Thanks Michal H.

2 2

Identify error in log
by Евгений Мастратов 16 Feb '23

16 Feb '23

Hello colleagues. I'm starting to use Kamailio for educational purposes, as an IMS test zone. Registration of subscribers, calls go successfully, but the following errors are constantly pouring into the log: Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:1378]: int_intop2(): rv div by 0 Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:1378]: int_intop2(): rv div by 0 Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:2381]: rval_expr_eval(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:2381]: rval_expr_eval(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/lvalue.c:386]: lval_assign(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/lvalue.c:386]: lval_assign(): rval expression evaluation failed (735,15-735,55) Apparently they don’t carry anything critical, but they clog the log, natively I can’t understand the meaning of the errors. Please tell me what they mean and how to eliminate their cause? If necessary, I will provide the pcscf config.

2 1

uac reg reload frequency
by Dmytro M 16 Feb '23

16 Feb '23

When you do "kamcmd uac.reg_reload" frequently enough, you'll get an error: # kamcmd uac.reg_reload error: 500 - Failed to shift records - check log messages Logs: ERROR: uac [uac_reg.c:416]: uac_reg_ht_shift(): shifting in-memory table is not possible in less than 150 secs What is the reason behind 150 sec limitation for how frequent reloads can be done? Is it configurable in any way? Use case: Remote app needs to disable uac registration. It deletes record in DB and calls kamcmd uac.reg_reload to activate the change. With 150 sec limit it can't apply DB changes immediately. Please advise. Thanks, Dmytro

2 2

ACK on RE-Invite is send to UAC NATed Internal port instead of public port
by Angelo Sipper 15 Feb '23

15 Feb '23

Hi, My setup has: (TLS)UAC 77.1.1.1 -> (TLS)Kamailio 17.17.17.211 (UDP) -> (UDP)Kamailio 17.17.17.181 (UDP) -> Carrier(UDP) Both Kamailio are 4.3 with minor modifications on default cfg, and Topoh and TLS modules are used. I am having an issue on some outbound calls from nated UACs. On these calls our SBC sometimes receives reverse invites from the carrier side within the call. When this happens, my SBC(17.17.17.211) sends the invite to UAC and the UAC sends back 200 OK (SDP). Unfortunately my SBC(17.17.17.211) sends back the ACK not to the correct UAC public port but instead to the UAC internal port making the call to crash with several retries from my SBC to send 200 OK as ACK was never received from UAC! If you look the below traces of reverse invite past within the call, the reinvite has port private 20125 and alias the public port 2314 of UAC but the ACK bellow is send to 20125 and not to 2314 2023/01/26 09:48:30.668634 17.17.17.181:5060 -> 17.17.17.211:5060 INVITE sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:30.679743 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0;rport=5060 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:30.740803 17.17.17.211:5060 -> 77.1.1.1:2314 INVITE sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 68 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.893512 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Content-Length: 0 2023/01/26 09:48:31.026742 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.093656 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 276 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 14.1.1.28 s=3cxPS Audio call c=IN IP4 14.1.1.28 t=0 0 m=audio 13278 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=sendrecv a=rtcp:13279 2023/01/26 09:48:31.254591 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.260901 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.e8fb34e79623843d516ae77257014e2d.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Any help will be much appreciated. Thank you! Regards, Angelo

2 5

SCA Presence : Record-Route Filed Not Update in sca_subscriptions Table
by Vinayak Makwana 14 Feb '23

14 Feb '23

Hello all, I am using the sca module in kamailio script.so when i subscribe with my ip phone for SCA Presence i get all the information in a sca_subscriptions table for the first time. When I reboot the device I get a new record-route header in trace but It does not update *record-route *Filed in sca_subscriptions table. Can anyone help me out with this issue ? *Here's modparam configuration * modparam("sca", "db_update_interval", 10 ) modparam("sca", "db_url", DBURL_LOCAL) modparam( "sca", "line_seize_max_expires", 30) modparam( "sca", "purge_expired_interval", 1800) -- -- * <https://www.ecosmob.com/itexpo/> * *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

3 8

SCA Feature:: Record-route query.
by satyaprakash ch 13 Feb '23

13 Feb '23

Hello I have a query regarding the record-route field update in DB for SCA SUBSCRIBE. Here are my test cases *Initial SCA subscription,* We got the below SUBSCRIBE packet in kamailio SUBSCRIBE sip:1234.xyz.com:5060 SIP/2.0 Via: SIP/2.0/UDP kam-ip:5060;branch=z9hG4bK2sansay1081381rdb66 *Record-Route* : <sip:sansay1081381rdb66spid17urcvjtr139807186744464nat0@kam-ip:5060;lr;transport=udp> To: <sip:372427@1234.xyz.com:6060> From: "708" <sip:372427@1234.xyz.com:6060>;tag=CFFBAF19-19A68CBC Call-ID: bd4b50d9384523c14ea05c532d895bf2 CSeq: 2 SUBSCRIBE Contact: < sip:372427@192.168.1.3> Expires: 3600 Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER Event: call-info User-Agent: PolycomVVX Accept-Language: en Max-Forwards: 69 Content-Length: 0 also in the sca_subscriptions table record-route header is updated as per Initial SUBSCRIBE record-route. *record_route: <sip:sansay1081381rdb66spid17urcvjtr139807186744464nat0@kam-ip:5060;lr;transport=udp> * But After rebooting the device, we got a new record-route in SUBSCRIBE Packet but in DB Record-route Field not updated after getting an updated record-route in Trace. *Kamailio Trace *SUBSCRIBE sip:1234.xyz.com:5060 SIP/2.0 Via: SIP/2.0/UDP kam-ip:5060;branch=z9hG4bK2sansay1081415rdb48 *Record-Route*: <sip:sansay1081415rdb48spid17urcvjtr139807186744464nat0@kam-ip:5060;lr;transport=udp> To: <sip:372427@1234.xyz.com:6060> From: "708" <sip:372427@1234.xyz.com:6060>;tag=35852031-CF749E20 Call-ID: 41fa031d79e35fae4a61c61984895bf2 CSeq: 2 SUBSCRIBE Contact: < sip:372427@192.168.1.3> Expires: 3600 Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER Event: call-info User-Agent: PolycomVVX Accept-Language: en Max-Forwards: 69 Content-Length: 0 as per logic it should update the record-route field in sca_subscriptions table . but it didn't update it : record_route: <sip:sansay1081381rdb66spid17urcvjtr139807186744464nat0@kam-ip:5060;lr;transport=udp> So can you suggest to us how we can update the record-route field as per SUBSCRIBE's packet new record-route ?

2 1

Issues matching regex
by Nathan Stratton 11 Feb '23

11 Feb '23

I am having an issue matching toll-free. I tested my regex on regex101.com, and it looks good, but it does not match my if statement. Am I doing something wrong? if (method=="INVITE") { xlog("L_INFO", "Checking Routes $rU"); if ($rU=~"^(\+?1)?(8(00|44|55|66|77|88)[2-9]\d{6})$") { xlog("L_INFO", "Tollfree call"); }; }; Logs show "<script>: Checking Routes +18002211212" so I don't get why it does not match. ><> Nathan Stratton Founder, CTO Vocinity, Inc. <https://www.vocinity.com/gabbi>

2 1

kemi equivalent config
by mohsen khashei 11 Feb '23

11 Feb '23

2 1

KEMI Equivalent of script
by mohsen khashei 10 Feb '23

10 Feb '23

Hi I have an existing kamailio config and I want to migrate to kemi. I want to know what is the equivalent of this code in kemi javascript ? $avp(s:contact) = $hdr(Contact); $avp(s:contact_fix) = $hdr(Contact); avp_subst("$avp(s:contact_fix)", "/@([0-9]+).([0-9]+).([0-9]+).([0-9]+)/@$sel(cfg_get.kamailio.ss_ip)/gi"); remove_hf("Contact"); append_hf("Contact: $avp(s:contact_fix)\r\n"); t_on_reply("REG_FIX"); thanks for your attention.

1 0

Return value from lua/python/js/bash/etc... function
by Dmytro M 10 Feb '23

10 Feb '23

What is the simplest way to return values from external application into Kamailio config and assign it to a variable? I'm looking for the most light weight mechanism to do it and to offload some logic to external app. Something like this would be ideal: $var(myVar), $var(err) = lua_run("lua_func1", "$rU"); OR $var(encString) = exec_cmd("echo 'abc $rU' | base64"); There is this method: http_client_query("http://...", "", "", "$var(result)"); but there is an overhead of networking and HTTP protocol. Please advise. Thanks, Dmytro

3 4

ACK on Reverse Invite is send to NATed Internal port instead of public port
by Angelo Sipper 09 Feb '23

09 Feb '23

Hi, I am having an issue on some outbound calls from nated UAC. On these calls our SBC receive reverse invites from the carrier side within the call. When this happens, my SBC(Kamailio1) sends the invite to UAC and the UAC sends 200 OK (SDP). Unfortunately my SBC(Kamailio1) sends back the ACK not to the correct UAC public port but instead to UAC internal port making the call to crash! My setup has: (TLS)UAC -> (UDP)Kamailio1(UDP) -> (UDP)Kamailio2(TLS) -> Carrier(UDP) Bellow you can find the trace and you can see the ACK send to wrong port on 2023/01/26 09:48:31.254591 Your help will be much appreciated! 2023/01/26 09:48:23.225326 77.1.1.1:2314 -> 17.17.17.211:5060 INVITE sip:300987654321@17.17.17.211:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport Max-Forwards: 70 Contact: <sip:301234567890@77.1.1.1:20125> To: <sip:300987654321@17.17.17.211:5060> From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Remote-Party-ID: <sip:301234567890>;party=called Content-Length: 283 v=0 o=3cxPS 792019937001472 2393157908037633 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:23.240310 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314;received=77.1.1.1 To: <sip:300987654321@17.17.17.211:5060> From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:23.301454 17.17.17.211:5060 -> 17.17.17.181:5060 INVITE sip:300987654321@sip.mydomain.com:5060 SIP/2.0 Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Max-Forwards: 69 Contact: <sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1> To: <sip:300987654321@sip.mydomain.com> From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 300 P-Asserted-Identity: <sip:301234567890@sip.mydomain.com> v=0 o=3cxPS 792019937001472 2393157908037633 IN IP4 14.1.1.28 s=3cxPS Audio call c=IN IP4 14.1.1.28 t=0 0 m=audio 13278 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=sendrecv a=rtcp:13279 2023/01/26 09:48:23.302899 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0;rport=5060 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 To: <sip:300987654321@sip.mydomain.com> From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:24.077941 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 183 Session Progress From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:24.138348 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 183 Session Progress From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:24.139050 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 183 Session Progress From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:24.200575 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 183 Session Progress From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.115324 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 200 OK From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Require: timer Supported: timer Session-Expires: 600;refresher=uac Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:30.336507 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 200 OK From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Require: timer Supported: timer Session-Expires: 600;refresher=uac Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.432457 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 200 OK From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Require: timer Supported: timer Session-Expires: 600;refresher=uac Content-Length: 242 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 194.154.142.193 s=SIP Media Capabilities c=IN IP4 194.154.142.196 t=0 0 m=audio 10764 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=maxptime:20 2023/01/26 09:48:30.433017 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 200 OK From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Require: timer Supported: timer Session-Expires: 600;refresher=uac Content-Length: 242 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 194.154.142.193 s=SIP Media Capabilities c=IN IP4 194.154.142.196 t=0 0 m=audio 10764 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=maxptime:20 2023/01/26 09:48:30.457268 77.1.1.1:2314 -> 17.17.17.211:5060 ACK sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---5ff61b7097f10965;rport Max-Forwards: 70 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:301234567890@77.1.1.1:20125> To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 ACK User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:48:30.481470 17.17.17.211:5060 -> 17.17.17.181:5060 ACK sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bKc2d8.44ee18452b274c8de283aa3c27549f4e.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---5ff61b7097f10965;rport=2314 Max-Forwards: 69 Contact: <sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1> To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 From: "My, User"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 ACK User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:48:30.555470 77.1.1.1:2314 -> 17.17.17.211:5060 ACK sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---5ff61b7097f10965;rport Max-Forwards: 70 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:301234567890@77.1.1.1:20125> To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 ACK User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:48:30.557824 17.17.17.211:5060 -> 17.17.17.181:5060 ACK sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bKc2d8.44ee18452b274c8de283aa3c27549f4e.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---5ff61b7097f10965;rport=2314 Max-Forwards: 69 Contact: <sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1> To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 From: "My, User"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 ACK User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:48:30.668634 17.17.17.181:5060 -> 17.17.17.211:5060 INVITE sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:30.679743 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0;rport=5060 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:30.740803 17.17.17.211:5060 -> 77.1.1.1:2314 INVITE sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 68 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.893512 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Content-Length: 0 2023/01/26 09:48:31.026742 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.093656 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 276 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 14.1.1.28 s=3cxPS Audio call c=IN IP4 14.1.1.28 t=0 0 m=audio 13278 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=sendrecv a=rtcp:13279 2023/01/26 09:48:31.254591 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.260901 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.e8fb34e79623843d516ae77257014e2d.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.530836 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.531333 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.609667 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.6cff4a8159c123f434b422c73e17a08c.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.612312 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.63edf375f6b899dfa9d2d9a2dcee4dfd.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.6cff4a8159c123f434b422c73e17a08c.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:32.536512 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:32.536839 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:32.623207 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.48a5467fc248682a755e70a672268f79.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:32.641928 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.745a55762e847bc3cf56d27926f7e62d.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.48a5467fc248682a755e70a672268f79.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:34.540735 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:34.541310 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:34.590013 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.6c3274e7b34c3b780cfbe9180a4d5eb1.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:34.595763 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.6c6654fa1c2f4b1991d5b6d792f2f081.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.6c3274e7b34c3b780cfbe9180a4d5eb1.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:38.561756 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:38.562039 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:38.599703 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.ef7afaa26d39ee76ce9000b1203574e7.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:38.603466 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.e022b4e31f8266525e62f213dc4dd8ae.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.ef7afaa26d39ee76ce9000b1203574e7.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:42.584025 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:42.584257 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:42.622809 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.03eec221779917d79f0daa500f7a0cc6.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:42.626545 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.0e211693731e67705c85dd4844e42ce8.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.03eec221779917d79f0daa500f7a0cc6.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:46.629501 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:46.629961 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:46.676968 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.701d02748c09dee63b88ca1e96a4e371.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:46.682458 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.cc80042ad9e1838346f4cf6d66a4c13f.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.701d02748c09dee63b88ca1e96a4e371.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:50.636998 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:50.637287 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:50.675272 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.041bbf55bf3941bfbd16df0f3ca92cf1.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:50.681861 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.be45a1f76f0fcd5ce85292397ff68acc.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.041bbf55bf3941bfbd16df0f3ca92cf1.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:54.677049 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:54.677633 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:54.721399 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.6ce35eaf9a5805bf47c868cd80c09478.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:54.729950 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.365607f0beb6e7e5dcb047c1ad6fcf5f.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.6ce35eaf9a5805bf47c868cd80c09478.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:58.681010 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:58.681307 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:58.723730 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.abb70cc570d323c867c112765ec50432.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:58.731143 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.12bbae879e42215b50512c04c4fc0214.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.abb70cc570d323c867c112765ec50432.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:49:02.684483 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:49:02.684985 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:49:02.727999 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.c2b81601667ffb2a688deba47abd85ef.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:49:02.732652 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.fb4ff819be250670479341711417a554.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.c2b81601667ffb2a688deba47abd85ef.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:49:03.028200 77.1.1.1:2314 -> 17.17.17.211:5060 BYE sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---7c113301b578bb42;rport Max-Forwards: 70 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:301234567890@77.1.1.1:20125> To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 2 BYE User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:49:03.090194 17.17.17.211:5060 -> 17.17.17.181:5060 BYE sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK92d8.6e9f4e9b390a591c1c54d79389ba087d.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---7c113301b578bb42;rport=2314 Max-Forwards: 69 Contact: <sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1> To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 From: "My, User"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 2 BYE User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:49:03.261453 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 200 OK From: "My, User"<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 2 BYE Content-Length: 0 Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bK92d8.6e9f4e9b390a591c1c54d79389ba087d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---7c113301b578bb42;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:49:03.261941 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 200 OK From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 2 BYE Content-Length: 0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---7c113301b578bb42;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Thank you! Regards, Angelo

2 4

DB_CLUSTER failure with carrierroute (and others?)
by Kaufman 08 Feb '23

08 Feb '23

All, I've been trying to chase down an issue with db_cluster and permissions in combination with something else, where with my full configuration using the same cluster in multiple modules has failures. I've been trying to create a simplified configuration to consistently reproduce the problem without much success, however I did stumble upon THIS particular problem. The configuration here works fine as is - avpops uses the cluster URL, and carrierroute uses the direct SQLite URL. If I define WITH_DBCLUSTER, then carrierroute fails fetching rows using the cluster connection. Note that AVPOPS is only used as a general test to see if the cluster config works. If I remove references to avpops , carrierroute still fails loading from the cluster URL. Thoughts? #!KAMAILIO loadmodule "db_sqlite" loadmodule "pv" loadmodule "db_cluster" loadmodule "carrierroute" loadmodule "avpops" modparam("db_cluster", "connection", "db1=>sqlite:////etc/db.sqlite") modparam("db_cluster", "cluster", "cl1=>db1=9s9s") modparam("db_cluster", "inactive_interval", 30) #!ifdef WITH_DBCLUSTER modparam("carrierroute", "db_url", "cluster://cl1") #!else modparam("carrierroute", "db_url", "sqlite:////etc/db.sqlite") #!endif modparam("carrierroute", "config_source", "db") modparam("avpops", "db_url", "cluster://cl1") modparam("avpops", "avp_table", "usr_preferences") request_route { exit; } Failure log: 0(1) ERROR: carrierroute [cr_db.c:345]: load_route_data_db(): Fetching rows failed 0(1) ERROR: carrierroute [cr_data.c:179]: reload_route_data(): could not load routing data 0(1) ERROR: carrierroute [carrierroute.c:240]: mod_init(): could not prepare route data 0(1) ERROR: <core> [core/sr_module.c:942]: init_mod(): Error while initializing module carrierroute (/usr/lib/kamailio/modules/carrierroute.so) Kaufman

3 5

Drops on async_route with delay
by Alex Balashov 07 Feb '23

07 Feb '23

Hi, Some percentage of requests processed with async_route("REQ_PROCESS", "5") seem to end up with a resumed transaction, though most do. Not sure what the exact percentage is. The ones that don't Is this due to excessive requests? Is there a limit on internal IPC queue depth? Is it conceptually similar to a generic shared blocking queue internally, along the lines of 'mqueue'? Is there any reasonable way to troubleshoot this? Thanks! -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

3 3

Dispatcher + ENUM
by Jawaid Bazyar 07 Feb '23

07 Feb '23

Hi, Can DISPATCHER be used in conjunction with ENUM? E.g., to avoid sending requests to SIP destinations that are returned by ENUM, but, which DISPATCHER knows are down? Thanks, Jawaid

2 1

nating private uas to public ip addr
by Jack Murphy 06 Feb '23

06 Feb '23

I have a multi-homed kam with a uas behind one private interface and a public interface for the uac+sip provider. When the uac initiates a call, kam sends the invite to the private uas which sets up a b-leg call back to kam with a Contact header that has the uas' private ip address. I want to change that private ip address to be Kamailio's advertised/public ip address before it gets forwarded to the sip provider. I am rewriting Contact in a route from request_route like this: > if ($rP != $null) { > $var(ct) = ";transport=" + $rP; > }else{ > $var(ct) = ""; > } > $var(cr) = "<sip:" + $fU + "@" + $RAi + ":" + $RAp + $var(ct) + ">"; > > remove_hf("Contact"); > append_hf("Contact: $var(cr)\r\n"); This seems to work fine for the INVITE going to the provider. There's also the 200 OK that the uas sends for the uac (a-leg) with a private ip address in Contact -- I want to rewrite that before sending it to the UAC, too. Using the same method as above (but inside onreply_route), what happens is the UAC receives the modified OK and sends back an ACK with the modified Contact (kam's public ip addr) in the ACK r-uri, and kam gets in a loop of sending an ACK from its private ip address to its public ip address and replying to itself. call flows: https://imgur.com/a/Yj2DJpn Is there a right way to do this?

2 2

htable: autoexpire vs updatedelete
by Дилян Палаузов 06 Feb '23

06 Feb '23

Hello, https://www.kamailio.org/docs/modules/devel/modules/htable#htable.p.htable says for modparam('htable', 'htable', '…autoexpire … updateexpire…') autoexpire -time in seconds to delete an item from a hash table if no update was done to it. If is missing or set to 0, the items won't expire. updateexpire - if set to 1 (default), the time until expiration of an item is reset when that item is updated. Certain uses of htable may dictate that updates should not reset the expiration timeout, however, in which case this attribute can be set to 0. My reading is that, when a value is updated and autoexpire is positive, autoexpire will reset the timer, but updateexpire may or may not reset the same timer. That is: modparam('htable', 'htable', 'a=>autoexpire=5;updatedelete=1') modparam('htable', 'htable', 'b=>autoexpire=5;updatedelete=0') If b was not updated for 5s, will it be removed, as the documentation for autoxpire suggests, irrespective of updatedelete? Greetings Dilyan

2 2

Depending on topoh.mask_key Kamailio either cannot parse RURIs or reads invalid data
by Дилян Палаузов 06 Feb '23

06 Feb '23

Hello, when I use dns_try_naptr=on corelog=-1 debug=-1 enable_tls=yes use_dns_cache=off dns_cache_init=off modparam("topoh", "mask_key", "TEAI32l)- eauiDEUIA!?()") and run Kamailio under valgrind, Kamailio logs: 20(21) ERROR: kemix [kemix_mod.c:229]: ki_kx_get_ruri_attr(): failed to parse the R-URI 20(21) ERROR: rr [loose.c:1011]: loose_route_mode(): failed to parse Request URI The workflow is: I start Kamailio. A UDP-client registers. Then a websocket client calls the UDP-client. Finally the websocket client hangs up. Valgrind does not report anything suspicious. When I use instead modparam("topoh", "mask_key", "TEAI32l") for the same workflow, with the same configuration, valgrind logs: ==14== Invalid read of size 4 ==14== at 0x4867E5: atomic_cmpxchg_int (atomic_x86.h:224) ==14== by 0x486830: futex_get (futexlock.h:99) ==14== by 0x490CE4: dns_hash_get (dns_cache.c:673) ==14== by 0x4972A6: dns_get_entry (dns_cache.c:2001) ==14== by 0x499288: dns_srv_get_he (dns_cache.c:2455) ==14== by 0x597AAD: no_naptr_srv_sip_resolvehost (resolve.c:1599) ==14== by 0x598332: naptr_sip_resolvehost (resolve.c:1675) ==14== by 0x5983C5: _sip_resolvehost (resolve.c:1707) ==14== by 0x49943B: dns_srv_sip_resolvehost (dns_cache.c:2516) ==14== by 0x49B3DD: dns_sip_resolvehost (dns_cache.c:2738) ==14== by 0x59846A: sip_hostport2su (resolve.c:1727) ==14== by 0x4CB951: forward_request (forward.c:515) ==14== by 0x99993CD: t_relay_to (t_funcs.c:300) ==14== by 0x99EBA32: _w_t_relay_to (tm.c:1764) ==14== by 0x99F4DEB: ki_t_relay (tm.c:2917) ==14== by 0xA80A94B: sr_kemi_lua_exec_func_ex (app_lua_api.c:1022) ==14== by 0xA81237D: sr_kemi_lua_exec_func (app_lua_api.c:1706) ==14== by 0xA81B93F: sr_kemi_lua_exec_func_209 (app_lua_kemi_export.c:1717) ==14== by 0xA8383C0: luaD_precall (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA84C4CA: luaV_execute (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA838C90: luaD_callnoyield (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA837029: luaD_rawrunprotected (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA8391DF: luaD_pcall (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA8333DE: lua_pcallk (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA806F0C: app_lua_run_ex (app_lua_api.c:773) ==14== by 0xA825F06: sr_kemi_config_engine_lua (app_lua_mod.c:119) ==14== by 0x5048BE: sr_kemi_route (kemi.c:3784) ==14== by 0x588909: receive_msg (receive.c:502) ==14== by 0xA609ADF: ws_frame_receive (ws_frame.c:644) ==14== by 0x4BCAAB: sr_event_exec (events.c:299) ==14== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==14== ==14== ==14== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==14== Access not within mapped region at address 0x0 ==14== at 0x4867E5: atomic_cmpxchg_int (atomic_x86.h:224) ==14== by 0x486830: futex_get (futexlock.h:99) ==14== by 0x490CE4: dns_hash_get (dns_cache.c:673) ==14== by 0x4972A6: dns_get_entry (dns_cache.c:2001) ==14== by 0x499288: dns_srv_get_he (dns_cache.c:2455) ==14== by 0x597AAD: no_naptr_srv_sip_resolvehost (resolve.c:1599) ==14== by 0x598332: naptr_sip_resolvehost (resolve.c:1675) ==14== by 0x5983C5: _sip_resolvehost (resolve.c:1707) ==14== by 0x49943B: dns_srv_sip_resolvehost (dns_cache.c:2516) ==14== by 0x49B3DD: dns_sip_resolvehost (dns_cache.c:2738) ==14== by 0x59846A: sip_hostport2su (resolve.c:1727) ==14== by 0x4CB951: forward_request (forward.c:515) ==14== by 0x99993CD: t_relay_to (t_funcs.c:300) ==14== by 0x99EBA32: _w_t_relay_to (tm.c:1764) ==14== by 0x99F4DEB: ki_t_relay (tm.c:2917) ==14== by 0xA80A94B: sr_kemi_lua_exec_func_ex (app_lua_api.c:1022) ==14== by 0xA81237D: sr_kemi_lua_exec_func (app_lua_api.c:1706) ==14== by 0xA81B93F: sr_kemi_lua_exec_func_209 (app_lua_kemi_export.c:1717) ==14== by 0xA8383C0: luaD_precall (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA84C4CA: luaV_execute (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA838C90: luaD_callnoyield (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA837029: luaD_rawrunprotected (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA8391DF: luaD_pcall (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA8333DE: lua_pcallk (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA806F0C: app_lua_run_ex (app_lua_api.c:773) ==14== by 0xA825F06: sr_kemi_config_engine_lua (app_lua_mod.c:119) ==14== by 0x5048BE: sr_kemi_route (kemi.c:3784) ==14== by 0x588909: receive_msg (receive.c:502) ==14== by 0xA609ADF: ws_frame_receive (ws_frame.c:644) ==14== by 0x4BCAAB: sr_event_exec (events.c:299) The stacktrace with the values of the variables is available at https://github.com/kamailio/kamailio/issues/3350 . Or at least these things seem very similar to me. Any idea? I can share the OCI-image and the full configuration. Greetings Дилян

3 4

topoh: th_mask_decode (th_mask_encode (x)) ≠ x
by Дилян Палаузов 06 Feb '23

06 Feb '23

Hello, after receiving INVITE sip:test-gnome-calls@bapha.be SIP/2.0 Via: SIP/2.0/WSS bapha.be;branch=z9hG4bK974100 Max-Forwards: 70 To: <sip:test-gnome-calls@bapha.be> From: "Online https://sip.bapha.be" <sip:online@bapha.be>;tag=12q2efc423 Call-ID: fkhe8faq0fh80glmq59i CSeq: 5622 INVITE Contact: <sip:4q5ne5no@bapha.be;transport=ws;ob> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound User-Agent: SIP.js/0.7.8 Content-Type: application/sdp Content-Length: 1964 v=0 o=mozilla...THIS_IS_SDPARTA-99.0 8263261229339246488 0 IN IP4 0.0.0.0 s=- … kamailio calls th_mask_encode( char *in = "sip:test-gnome-calls@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562;alias=87.118.146.153~60722~2>;+sip.instance=\"<urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562>";+org.linphone.specs=\"conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime\n"\ "Content-Type: application/sdp and so on", int ilen = 107, str prefix = { .len = 23, .s ="sip:127.3.4.84;line=sr-" }, int *olen). It returns olen=167, and the string "sip:127.3.4.84;line=sr- if7s1mg7i36PNf0AbdwPpfzlbqWEpLzsSGItpLwyN39ZMY4t1mCTSd6DNo4LWdIOpfpPp5FLpUQscX63Kd47W5EPWO6sNL90pLgoW5p-1fzlSdzO25n3KoIk1vHkWXptc5wOeopsWO9-eo9*". Then Kamailio forwards (sends): Contact: <sip:127.3.4.84;line=sr-if7s1mg7i36PNf0AbdwPpfzlbqWEpLzsSGItpLwyN39ZMY4t1mCTSd6DNo4LWdIOpfpPp5FLpUQscX63Kd47W5EPWO6sNL90pLgoW5p- 1fzlSdzO25n3KoIk1vHkWXptc5wOeopsWO9-eo9*>;+sip.instance="<urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562>";+org.linphone.specs="conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime" which at some point leads to ACK sip:127.3.4.84;line=sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p- 1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0 and BYE sip:127.3.4.84;line=sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p- 1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0 Below you can find th_test.c . The functions th_mask_encode() and th_mask_decode() there are identical to the same functions in src/modules/topoh/th_mask.c . main() provides some tests: Passing «sip:test-gnome-calls@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562;alias=87.118.146.153~60472~2>;+sip.instance="<urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562>";+org.linphone.specs="conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime» to th_mask_encode() returns sip:127.3.4.84;line=sr-if7s1mg7i36PNf0AbdwPpfzlbqWEpLzsSGItpLwyN39ZMY4t1mCTSd6DNo4LWdIOpfpPp5FLpUQscX63Kd47W5EPWO6sNL90pLgoW5p- 1fzlSdzO25n3KoIk1vHkWXptc5wOeopsWXi-eo9* (this is what Kamailio does send out). Passing the last string to th_mask_decode() returns sip:test-gnome-calls@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50-740fb9bdc562;alias=87.118.1 the ;alias= is incomplete, compared to the origin. The above ACK leads to passing "sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p-1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0\n"\ "Route: <sip:Q+L06HX94DMPtQWQTI5OE8SQTI5O4MY=@144.76.142.78;transport=ws;r2=on;lr;nat=yes>\n"\ "Route: <sip:127.3.4.84;line=sr-if7s17IB5XEfVzn0WIgWwqggCTzwV5C2g5R5wCg4WwrQ5CuZ6XIQWvH3WUHkWX9tWOnyMq4RbmWsb34Q2YgoiXP-coTAboPlioPtpY6Z8dCO>\n"\ to th_mask_decode() and the result is callub.p.b;rn:s.d2lQg#cfa=bA07beQ7R409bcQ62;alac=87718*1P.15#~60R22~2 with the dots being unprintable characters. (result is garbage). I have seen that callub.p.b in the unparsable R-URI reports from Kamailio. That is an indication that th_mask_decode() does not decode the Contact encoded by th_mask_encode() correctly. Valgrind does not report improper memory usage. Greetings Dilyan gcc -g -o th-test ./th-test.c && ./th-test th-test.c #include <stdio.h> #include <stdlib.h> #include <string.h> #define TH_EB64I \ "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.-" char _th_EB64[65] = "EFvXIzGq94xKcW126gV5wCdYpNSbiM8enRUou7LmhajBlPtAsk-OQTf3H0DyrZ.J"; int _th_DB64[256]; char *_th_PD64 = "*"; struct str_ { char* s; /**< Pointer to the first character of the string */ int len; /**< Length of the string */ }; typedef struct str_ str; str prefix = { .len = 23, .s ="sip:127.3.4.84;line=sr-" }; char* th_mask_encode(char *in, int ilen, const str *prefix, int *olen); char* th_mask_decode(char *in, int ilen, const str *prefix, int extra, int *olen); char* th_mask_encode(char *in, int ilen, const str *prefix, int *olen) { char *out; int left; int idx; int i; int r; char *p; int block; *olen = (((ilen+2)/3)<<2) + ((prefix!=NULL&&prefix->len>0)?prefix->len:0); out = (char*)malloc((*olen+1)*sizeof(char)); if(out==NULL) { fprintf(stderr, "malloc error\n"); *olen = 0; return NULL; } memset(out, 0, (*olen+1)*sizeof(char)); if(prefix!=NULL&&prefix->len>0) memcpy(out, prefix->s, prefix->len); p = out + (int)((prefix!=NULL&&prefix->len>0)?prefix->len:0); for(idx=0; idx<ilen; idx+=3) { left = ilen - idx - 1 ; left = (left>1)?2:left; block = 0; for(i=0, r=16; i<=left; i++, r-=8) block += ((unsigned char)in[idx+i]) << r; *(p++) = _th_EB64[(block >> 18) & 0x3f]; *(p++) = _th_EB64[(block >> 12) & 0x3f]; *(p++) = (left>0)?_th_EB64[(block >> 6) & 0x3f]:_th_PD64[0]; *(p++) = (left>1)?_th_EB64[block & 0x3f]:_th_PD64[0]; } return out; } char* th_mask_decode(char *in, int ilen, const str *prefix, int extra, int *olen) { char *out; int n; int block; int idx; int i; int j; int end; char c; for(n=0,i=ilen-1; in[i]==_th_PD64[0]; i--) n++; *olen = (((ilen-((prefix!=NULL&&prefix->len>0)?prefix->len:0)) * 6) >> 3) - n; if (*olen<=0) { return NULL; } out = (char*)malloc((*olen+1+extra)*sizeof(char)); if(out==NULL) { fprintf(stderr, "malloc error\n"); *olen = 0; return NULL; } memset(out, 0, (*olen+1+extra)*sizeof(char)); end = ilen - n; i = (prefix!=NULL&&prefix->len>0)?prefix->len:0; for(idx=0; i<end; idx+=3) { block = 0; for(j=0; j<4 && i<end ; j++) { c = _th_DB64[(int)in[i++]]; if(c<0) { free(out); *olen = 0; return NULL; } block += c << (18 - 6*j); } for(j=0, n=16; j<3 && idx+j< *olen; j++, n-=8) out[idx+j] = (char)((block >> n) & 0xff); } return out; } int main() { //this is from th_mask_init for(int i=0; i<256; i++) _th_DB64[i] = -1; for(int i=0; i<64; i++) _th_DB64[(int)_th_EB64[i]] = i; int olen, o2; char *end; char *input = "sip:test-gnome-calls@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562;alias=87.118.146.153~60472~2>;+sip.instance=\"<urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562>\";+org.linphone.specs=\"conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime\""; printf("input=[%s]\n", input); char* middle = th_mask_encode (input, 107, &prefix, &olen); printf("olen = %i, middle=[%s]\n", olen, middle); end = th_mask_decode(middle, 147, &prefix, 0, &o2); printf("o2 = %i, end=[%s]\n", o2, end); char * b1 = "sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p- 1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9*"; o2 = 0; end = th_mask_decode(b1, 147, &prefix, 0, &o2); printf("o2 = %i, end=[%s]\n", o2, end); char* b2 = "sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p-1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0\n"\ "Route: <sip:Q+L06HX94DMPtQWQTI5OE8SQTI5O4MY=@144.76.142.78;transport=ws;r2=on;lr;nat=yes>\n"\ "Route: <sip:127.3.4.84;line=sr-if7s17IB5XEfVzn0WIgWwqggCTzwV5C2g5R5wCg4WwrQ5CuZ6XIQWvH3WUHkWX9tWOnyMq4RbmWsb34Q2YgoiXP-coTAboPlioPtpY6Z8dCO>\n"\ "Via: SIP/2.0/WSS bapha.be;branch=z9hG4bK9069155\n"\ "Max-Forwards: 70\n"\ "To: <sip:test-gnome-calls@bapha.be>;tag=Pn4npAj\n"\ "From: \"Online https://sip.bapha.be\" <sip:online@bapha.be>;tag=12q2efc423\n"\ "Call-ID: fkhe8faq0fh80glmq59i\n"\ "CSeq: 5623 ACK\n"\ "Supported: outbound\n"\ "User-Agent: SIP.js/0.7.8\n"\ "Content-Length: 0\n"\ "\n"; o2 = 0; end = th_mask_decode(b2, 147, &prefix, 0, &o2); printf("o2 = %i, end=[%s]\n", o2, end); return 0; }

2 1

no autocomplete for kamcmd for latest debian packages
by Ovidiu Sas 04 Feb '23

04 Feb '23

Hello, The latest debian packages are built without autocomplete for kamcmd. Do we have the libreadline-dev package installed on the build machine? I know that we have kamctl rpc and kamcli, but if we are still shipping kamcmd, it should have the autocomplete feature enabled. Regards, Ovidiu Sas -- VoIP Embedded, Inc. http://www.voipembedded.com

3 2

Sip messages responses counters per interface
by Patrick Karton 02 Feb '23

02 Feb '23

2 1

rtpengine - SRTP <> RTP
by kdrewicz+kamailio＠cludo.pl 01 Feb '23

01 Feb '23

I try to workout if - currently it would work, or - where and how to debug more: I face - 2 interfacec - public internet (so, TLS + sRTP) is desired and private - old infrastructure - i mus only use plain RTP 172.23.9.70 - private ip - from this endpoint of kamailio and rtpengine should send only basic RTP 172.23.210.75:5060 private - target for kamailio 1.2.3.24 obfuscated public IP (TLS + sRTP required) kamailio 5.4.4 (x86_64/linux) rtpengine -v Version: 11.1.1.4-1~bpo11+1 all i do is: if (proto==TLS) { rtpengine_manage("RTP/AVP ICE=remove replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding direction=external direction=internal record-call=on"); } else if ($ru =~ "transport=tls") { rtpengine_manage("DTLS=on SRTP AVPF ICE=remove replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding direction=internal direction=external record-call=on media-address=1.2.3.24"); } # 1.2.3.24 obfuscated public IP 172.23.210.75:5060 is in dispatch.cfg, as '11' route[SBC_CORE] { append_hf("X-My-SRTP: removed31337\r\n"); ### i see this text in invtes from kamailio 172.23.9.70 towards 172.23.210.75:5060 ### i see only RTP, so as expected if (!ds_select_dst("11", "0")) { xwarn("I:$var(i) DROP(DOWN!) FWD:$rm [$fU->$tU] [SBCVIP] to $du\n"); sl_send_reply("503", "Destination down"); exit; } what i did: certificate is a paid one (the public party needs it) TLS works i deleted - entries in (not kamailo) cryptosuite that caused this: 13:08:05 localhost rtpengine[15140]: ERR: [51ad8758-b64d-4d2f-9fd0-41d03a38f74d]: [core] Failed to parse a=crypto attribute, ignoring: unknown crypto suite Tried to search for any "ready" examples for this - only found old threads and - that this should be possible, but - no example for woking config. what i see: Jan 19 19:00:57 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000038 sec Jan 19 19:00:58 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000036 sec Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Closing call due to timeout Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Redis delete_async=0 Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Final packet stats: Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag 'JVR5LTs', created 60:00 ago for branch '' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscribed to '' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscription for '' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] ------ Media #1 (audio over RTP/SAVP) using unknown codec Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 1.2.3.24:30136 <> 52.129.106.28:17030, SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 1.2.3.24:30137 <> 52.129.106.28:17031 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag '', created 60:00 ago for branch '' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscribed to 'JVR5LTs' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscription for 'JVR5LTs' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 172.23.9.70:30014 <> :0 , SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 172.23.9.70:30015 <> :0 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Moved metadata file "/var/spool/rtpengine/tmp/rtpengine-meta-c17bab16-5eea-492e-b1c4-ac9387f3e265-7003946f152c6c8d.tmp" to "/var/spool/rtpengine/metadata" Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000828 sec Jan 19 19:01:00 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000053 sec route(SBC_CORE); maybe any hint or - someone has working exmaple of kamailio config + rtpengine settings ? i use only userspace daemon rtp forwarding (this is a test, dont need any performance here) Thanks,

5 9

transport=ws causing kamailio to use wrong listen socket
by nathan.bruning＠talksome.com 31 Jan '23

31 Jan '23

Hi all, We're hitting an issue while integrating secure websockets in our existing SIP infrastructure using Kamailio. When the registration comes in, it causes an entry in our AOR table, with ";transport=ws" appended. When we want to send a message to this client (using t_relay), kamailio seems to take 'ws' as being *unsecure* websockets. In turn, this makes Kamailio try to send out the message using a TCP listener - while it should have picked the TLS listener. There are some remarks in the sources about ws vs. wss, so i'm struggling to figure out where things go wrong. I've also created github issue #3340 with more details. Any help would be appreciated. If this turns out to be a Kamailio bug, i'm happy to provide a patch.

6 7

How can I setup Kamailio for failover on LCR ?
by scramatte 31 Jan '23

31 Jan '23

Hello, How can I setup Kamailio for failover on LCR ? Currently my Kamailio 4.x works with lcr but doesn’t care about gateway status. I mean that if a gateway match rule , it sends the call through without check if the gateway is available an never try the next one if the first fail. I’ve tried to implement inactivate_gw() But I received error that lcr_id_avp is not defined. I’ve added the parameters to lcr module for Ping and enable defunc but I’m unable to get it working. By the way I ‘ve trad that defunct is not a good practice as hacker sending malformed sip header can throw down the gateway. So what is the good and working way to setup outbound call failover ? Regards Sebastien

1 0

Evapi Dispatcher 100% cpu.
by Sebastian Sastre 30 Jan '23

30 Jan '23

Hello We are currently using EVAPI to push messages into kamailio from a go app. For the most part ift works without problems, messages get delivered into the event route and we use it to update presence status. Recently we started noticing delays on the evapi processing. After 500 requests x min the pid corresponding to the EVAPI dispatcher gets pegged at 100% CPU and processing of requests starts slowing down until in some cases the connection just drops and we have to reconnect. After that pid drops, the dispatcher goes back to working. Unfortunately the error we get back is very generic and is not telling us much logger.go:39: ERR Handler returned error (write tcp 127.0.0.1:48448->127.0.0.1:8228: write: broken pipe) This only happens on prod servers and with high load which makes it hard to debug. There is no other slowness or increase of traffic or drop SIP traffic, only evapi dispatcher at 100% and the EVAPI workers on idle. Curious if anyone has run into this issue. We've tried different versions (5.4 , 5.5 and 5.6) and it happens on all of them. Any feedback appreciated ! Thanks !

2 1

Is preloading openssl_mutex_shared necessary for Kamailio 5.6 or is it not necessary?
by Дилян Палаузов 30 Jan '23

30 Jan '23

Hello, https://www.kamailio.org/docs/modules/devel/modules/tls says: For OpenSSL (libssl) v1.1.x, it is required to preload 'openssl_mutex_shared' library shipped by Kamailio. For more details see 'src/modules/tls/utils/openssl_mutex_shared/README.md'. 'src/modules/tls/utils/openssl_mutex_shared/README.md says: **IMPORTANT: the workaround of using this preloaded shared library is no longer needed starting with Kamailio v5.3.0-pre1 (git master branch after September 14, 2019). The code of this shared library has been included in the core of Kamailio and the same behaviour is now achieved by default.** This is a shared library required as a short term workaround for using Kamailio with OpenSSL (libssl) v1.1. It has to be pre-loaded before starting Kamailio. In v1.1, libssl does not allow setting custom locking functions, using internally pthread mutexes and rwlocks, but they are not initialized with process shared option (PTHREAD_PROCESS_SHARED), which can result in blocking Kamailio worker processes. Is preloading openssl_mutex_shared necessary for Kamailio 5.6 or is it not necessary? If it is not necessary, why isn’t it removed from the source code? Greetings Дилян

1 0

Websocket-answers sent by K. log unparseable errors
by Дилян Палаузов 29 Jan '23

29 Jan '23

Hello, when I connect to Kamailio over websocket, according to the websocket protocol K. sends “HTTP/1.1 101 Switching Protocols” and K. logs: 17(18) DEBUG: websocket [ws_handshake.c:179]: ws_handle_handshake(): found Upgrade: websocket 17(18) DEBUG: websocket [ws_conn.c:195]: wsconn_add(): connection id [14] 17(18) DEBUG: websocket [ws_conn.c:213]: wsconn_add(): new wsc => [0x7fcad6e10160], ref => [0] 17(18) DEBUG: websocket [ws_conn.c:233]: wsconn_add(): added to conn_table wsc => [0x7fcad6e10160], ref => [1] 17(18) DEBUG: sl [sl.c:310]: send_reply(): reply in stateless mode (sl) 17(18) DEBUG: <core> [core/msg_translator.c:162]: check_via_address(): (22.222.222.222, 22.222.222.222, 0) 17(18) DEBUG: <core> [core/tcp_main.c:1644]: _tcpconn_find(): found connection by id: 14 17(18) DEBUG: <core> [core/tcp_main.c:2528]: tcpconn_send_put(): send from reader (18 (17)), reusing fd 17(18) DEBUG: <core> [core/tcp_main.c:2763]: tcpconn_do_send(): sending... 17(18) DEBUG: <core> [core/tcp_main.c:2796]: tcpconn_do_send(): after real write: c= 0x7fcad6da7b38 n=238 fd=9 17(18) DEBUG: <core> [core/tcp_main.c:2797]: tcpconn_do_send(): buf= 17(18) DEBUG: <core> [core/parser/parse_fline.c:255]: parse_first_line(): bad request first line 17(18) DEBUG: <core> [core/parser/parse_fline.c:258]: parse_first_line(): at line 0 char 22: 17(18) DEBUG: <core> [core/parser/parse_fline.c:264]: parse_first_line(): parsed so far: HTTP/1.1 101 Switching 17(18) ERROR: <core> [core/parser/parse_fline.c:271]: parse_first_line(): parse_first_line: bad message (offset: 22) 17(18) DEBUG: <core> [core/parser/msg_parser.c:675]: parse_msg(): invalid message 17(18) ERROR: <core> [core/parser/msg_parser.c:749]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols Sia: SIP/2.0/TLS 22.222.222.222:33776 Sec-WebSocket-Protocol: sip Upgrade: websocket Connection: upgrade Sec-WebSocket-Accept: NeswoJX5ZQp7ER8hTKM5B3a3HDQ= Content-Length: 0 > 17(18) ERROR: <core> [core/msg_translator.c:3256]: build_sip_msg_from_buf(): parsing failed 17(18) DEBUG: app_lua [app_lua_api.c:1924]: sr_kemi_lua_exit(): script exit call 17(18) DEBUG: app_lua [app_lua_api.c:789]: app_lua_run_ex(): ksr error call from Lua: ~~ksr~exit~~ 17(18) DEBUG: app_lua [app_lua_mod.c:164]: sr_kemi_config_engine_lua(): execution of route type 513 with name [ksr_xhttp_event] returned 1 22.222.222.222 is my public address (the address of my router). It is not the IP-address of Kamailio. While the returned address is not parseable in terms of SIP, it is a valid Websocket-answer message. This valid condition triggers logging an error, but does not represent an error condition. How can I avoid that the above non-error is logged as an error? Thanks for your feedback Дилян

1 0

Locally generated BYE sent to private IP
by James Lipski 27 Jan '23

27 Jan '23

Hi all, I'm doing some experimenting with kamailio -- currently looking for a replacement of our existing (aging) SIP infrastructure. One of the experiments that I'm doing is testing the dialog module's dlg_set_timeout function. The issue that I'm having is while I do see that kamailio is generating a BYE, and sends it out to the B-leg of the call properly, the BYE goes to a private address on the A-leg. To Note: - kamailio is behind a NAT (on AWS) - both UA endpoints are remote and are both behind a NAT - Not sure if this matters, but I do have the topos module enabled, though I see the same behavior regardless if it's enabled or not. - Have set nathelpers (fix_nated_register, fix_nated_contact,etc...) which helps calls between endpoints and the endpoints themselves are able to send/receive BYEs when they generate them; however doesn't seem to help if kamailio locally generates the BYE. The only thing I do see within my logs is when the BYE is being generated by kamailio, it uses the private IP of my UA and not public for the caller. Callee, the public address is referenced. If more information is needed, please let me know (just didn't want to spam my script/ logs). Thanks. Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:399]: send_bye(): sending BYE to caller Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:458]: t_uac_prepare(): next_hop=<sip:1000@10.0.0.47:38606;line=9k4wsgc9> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 40484 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): SIP Request: Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): method: <BYE> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): uri: <sip:1000@10.0.0.47:38606;line=9k4wsgc9> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:684]: parse_msg(): version: <SIP/2.0> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK42e9.4a962087000000000000000000000000.0>; state=16 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=ueisi99vbf Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [61]; uri=[sip:1000@fakedomain.com] Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (44)[<sip:1000@fakedomain.com>], to tag (10)[ueisi99vbf] Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <BYE> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Content-Length] type 12 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1132060721 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:1013]: tps_request_sent(): handling outgoing request (1, 1) Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:417]: tps_pack_message(): compacted headers - x_via1: [SIP/2.0/UDP <KAMAILIO PUBLIC IP>:5060;branch=z9hG4bK42e9.4a962087000000000000000000000000.0](85) - x_via2: [](0) - x_vbranch1: [z9hG4bK42e9.4a962087000000000000000000000000.0](46) Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:539]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [](0) - s_rr: [](0) Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:544]: tps_pack_message(): compacted headers - as_contact: [](0) - bs_contact: [](0) Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:1027]: tps_request_sent(): no x-uuid header - nothing to do Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/msg_translator.c:1799]: check_boundaries(): no multi-part body Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [topos_mod.c:567]: tps_msg_sent(): new outbound buffer generated Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:686]: send_prepared_request_impl(): uac: 0x7f22f94448e8 branch: 0 to 10.0.0.47:38606 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/onsend.c:50]: run_onsend(): required parameters are not available - ignoring Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:432]: send_bye(): BYE sent to caller Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:399]: send_bye(): sending BYE to callee Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:458]: t_uac_prepare(): next_hop=<sip:1001@<UA PUBLIC IP>:5066>Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 40482

3 3

Kamailio not responding after stress test
by Igor Olhovskiy 27 Jan '23

27 Jan '23

Hello, I'm continuing investigations on Kamailio and stress test. Got it again in the state where it's not accepting any new TCP/TLS connections (UDP still works though), but all looks good from lsof/netnstat part, like system is not reporting any zombie connections. Restart of Kamailio process helps This time I got output of kamctl trap Put it here: https://pastebin.com/iYrNZ8U9 kamailio --version version: kamailio 5.6.2 (x86_64/linux) 54a9c1 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 54a9c1 compiled on 14:01:01 Oct 18 2022 with gcc 4.8.5 It's statically linked with tlsa pointing on openssl-1.1.1q Settings related to TLS are: fork=yes children=4 tcp_children=12 enable_tls=yes tcp_accept_no_cl=yes tcp_max_connections=63536 tls_max_connections=63536 tcp_accept_aliases=no tcp_async=yes tcp_connect_timeout=10 tcp_conn_wq_max=63536 tcp_crlf_ping=yes tcp_delayed_ack=yes tcp_fd_cache=yes tcp_keepalive=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=10 tcp_linger2=30 tcp_rd_buf_size=80000 tcp_send_timeout=10 tcp_wq_blk_size=2100 tcp_wq_max=10485760 open_files_limit=63536 Can you please help to read gdb output and understand where I missed in config? Thanks in advance! -- Best regards, Ihor (Igor)

3 7

Kamailio 5.6 on AlmaLinux 8 TLS crash
by Ihor Olkhovskyi 27 Jan '23

27 Jan '23

Hello! Currently testing Kamailio on Almalinux 8 (stated to be RHEL 8 binary compatible) and got this while trying to get TLS working: /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: ca_path='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:361]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:365]: ksr_tls_fill_missing(): TLSc<default>: require_certificate=1 /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:372]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:379]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:383]: ksr_tls_fill_missing(): TLSc<default>: verify_certificate=1 /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:386]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:389]: ksr_tls_fill_missing(): TLSc<default>: verify_client=0 /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:736]: set_verification(): TLSc<default>: Server MUST present valid certificate /usr/sbin/kamailio[32862]: ERROR: rtpengine [rtpengine.c:3070]: send_rtpp_command(): can't send command "ping" to RTPEngine <udp: 127.0.0.1:19999> /usr/sbin/kamailio[32862]: ERROR: rtpengine [rtpengine.c:2919]: rtpp_test(): proxy did not respond to ping /usr/sbin/kamailio[32883]: INFO: snmpstats [snmpstats.c:519]: spawn_sysUpTime_child(): A snmpVersion parameter was not provided. Defaulting to 3 /usr/sbin/kamailio[32883]: ERROR: snmpstats [snmpstats.c:561]: spawn_sysUpTime_child(): snmpget failed to run. Did you supply the snmpstats module with a proper snmpgetPath parameter? The kamailioSIPServiceStartTime is defaulting to zero /usr/sbin/kamailio[32881]: INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) /usr/sbin/kamailio[32870]: CRITICAL: <core> [core/mem/q_malloc.c:145]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(0, abcdefed)[0x7fe8375d3820:0x7fe8375d3858]! Memory allocator was called from tls: tls_init.c:293. Fragment marked by tls: tls_init.c:293. Exec from core/mem/q_malloc.c:391. /usr/sbin/kamailio[32870]: CRITICAL: <core> [core/mem/q_malloc.c:153]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten [0x7fe8375d3790:0x7fe8375d37c8] - fragment marked by tls: tls_init.c:293 systemd[1]: Started Process Core Dump (PID 32923/UID 0). systemd-coredump[32924]: Process 32870 (kamailio) of user 0 dumped core.#012#012Stack trace of thread 32870:#012#0 0x00007fe841786aff raise (libc.so.6)#012#1 0x00007fe841759ea5 abort (libc.so.6)#012#2 0x00000000006eec2f qm_debug_check_frag (kamailio)#012#3 0x00000000006f09a6 qm_malloc (kamailio)#012#4 0x00000000006fc930 qm_shm_malloc (kamailio)#012#5 0x00007fe83b5b9c31 ser_malloc (tls.so)#012#6 0x00007fe83fa4090d CRYPTO_zalloc (libcrypto.so.1.1)#012#7 0x00007fe8364b8163 sc_hash_type (libnetsnmp.so.35)#012#8 0x00007fe8364b49df hash_engineID (libnetsnmp.so.35)#012#9 0x00007fe8364b4b11 search_enginetime_list (libnetsnmp.so.35)#012#10 0x00007fe8364b4f8e set_enginetime (libnetsnmp.so.35)#012#11 0x00007fe8364b4885 init_snmpv3_post_config (libnetsnmp.so.35)#012#12 0x00007fe8364b9c92 snmp_call_callbacks (libnetsnmp.so.35)#012#13 0x00007fe836f3601b register_with_master_agent (snmpstats.so)#012#14 0x00007fe836f37f14 run_alarm_check (snmpstats.so)#012#15 0x0000000000531cde compat_old_handler (kamailio)#012#16 0x000000000053284e slow_timer_main (kamailio)#012#17 0x000000000042e3e1 main_loop (kamailio)#012#18 0x0000000000438d14 main (kamailio)#012#19 0x00007fe841772d85 __libc_start_main (libc.so.6)#012#20 0x000000000041cfce _start (kamailio) /usr/sbin/kamailio[32915]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 24 /usr/sbin/kamailio[32858]: ALERT: <core> [main.c:774]: handle_sigs(): child process 32870 exited by a signal 6 ... version: kamailio 5.6.3 (x86_64/linux) fe0c4d flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: fe0c4d compiled on 11:02:26 Jan 19 2023 with gcc 8.5.0 Same config is starting without issues on CentOS 7. OpenSSL version is 1.1.1k Kamailio is installed from official RPM repos. Is core dump would be useful here or best to compile from source and redo? -- Best regards, Ihor (Igor)

3 6

topos vs topoh, any reason for putting a private IP in the Contact header?
by Benoit Panizzon 27 Jan '23

27 Jan '23

Hi I'm trying to work around Route-Header and Via Issues with the two topology hiding modules topoh and topos and trying to figure out, which one works better for our environment. My conclusion so far: topos creates very clean header, but needs a database or redis. I'm always reluctant in adding more components which could fail or cause load. topoh also works, but it worries me a bit that according to the manual: https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask… a private IP is used to mask the contact header. I have come across a CPE which, as far as I see, is misbehaving by ALWAYS sending a PRACK to the Hostname or IP found in the Contact header, and ignoring Route and Via Header. So why using a private IP as 'mask' and not the IP or Hostname of the actual kamailio instance? 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 ______________________________________________________

3 6

Re: [sr-dev] Is there any Function or parameter to check Initial Invite Response on Kamailio
by Henning Westerholt 25 Jan '23

25 Jan '23

(removed sr-dev from CC) Hello, you can do that with the reply_route and/or onreply_route, for an example check out example cfg or this: https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_on_reply Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: HimaBindu G <himabindu.garadareddy(a)gmail.com> Sent: Tuesday, January 24, 2023 3:16 PM To: sr-users(a)lists.kamailio.org; sr-dev(a)lists.kamailio.org Subject: [sr-dev] Is there any Function or parameter to check Initial Invite Response on Kamailio Hi All, Can you please suggest any function or parameter to check Initial Invite Response from the backend. Thanks & Regards, Hima Bindu.

1 0

RTPengine multiple setID sockets
by John Hardiman 24 Jan '23

24 Jan '23

Hi All, Hope you are all well? I am hoping you can help with a bit of syntax I am struggling to get working in the intended way. (We are using Kamailio 5.5.3 and using Kemi/python.) The scenario is in AWS where we have separate Kamailio and RTPengine instances, with a cluster of FreeSWITCH EC2's on private addresses only. In the current setup, all RTP routes via the NAT gateway and back to the private IP of the selected FreeSWITCH (and vice versa). This works in the current config, but I would want this traffic not going via the NAT gateway and use the private address and route internally on the VPC. (These EC'2 have only 1 network interface and that cannot be changed for this work.) So anything between FreeSWITCH and Kamailio/RTPengine uses the private IP's for media, the rest use public IP's. It is good to note that the RTPengine's are the same in each set (3 total RTPengine's), just using the public/private IP's based on set ID. My first aim is to use KSR.permissions.allow_source_address() to check if the source address is from the FreeSWITCH cluster and set the rtpengine setID based on this. I have used this method for different parts of the config and it works. I am failing at this first step it seems, as no matter what I use in the function (below) it defaults and uses the public IP's in SDP. (No matter if I use the same setID in each set) kamailio.cfg snippet: # ----- rtpengine params ----- modparam("rtpengine", "setid_avp", "$avp()") # Public IP's ID 1: modparam("rtpengine", "rtpengine_sock", "1 == udp:5.5.5.5:2223 udp:6.6.6.6:2223 udp:7.7.7.7:2223") # Internal IP's ID 2: modparam("rtpengine", "rtpengine_sock", "2 == udp:10.0.0.1:2223 udp:10.0.0.2:2223 udp:10.0.0.3:2223") Kemi file snippet: # RTPengine Options for different SetID def ksr_route_rtpengine(self, msg): if KSR.textops.has_body_type("application/sdp") > 0 : # Source address is private subnet - use RTPengine set 2 (private IP's) if KSR.permissions.allow_source_address(400) == 1: KSR.rtpengine.set_rtpengine_set(2) KSR.rtpengine.rtpengine_manage( "RTP/AVP replace-session-connection replace-origin port-latching ICE=remove") else: # Source address is NOT private - use RTPengine set 1 (public) KSR.rtpengine.set_rtpengine_set(1) KSR.rtpengine.rtpengine_manage( "RTP/AVP replace-session-connection replace-origin port-latching ICE=remove") KSR.xlog.xlog("L_INFO", "RTPengine handling Block") return 1 Group 400 is the private subnet of the FreeSWITCH clusters we have behind on private addresses and the list contains the subnet of private IP's. Using the above, the Kamailio starts fine and understands/loads each set of RTPengine's and calls work with audio. but regardless of the set number used (even only using set 2 in both) it defaults to public IP's in the SDP. (This is the only place in the config where this function is defined) My SDP from FreeSWITCH egress to Kamailio/RTPengine has private IP's in the SDP. The only thing I do not fully understand is the setid_avp - specifically $avp() block and if this needs to stay empty, or be duplicated with the set ID in each one. Any help would be greatly appreciated in understanding where I am going wrong here. Thanks, John.

3 2

[SR-Users]: Port number in To: field
by Olivier 24 Jan '23

24 Jan '23

Hello, While trunking with an Oracle SBC, I was lately required to include a port number in INVITE To: field. Would you qualify this as a "legal requirement" (according to SIP Standards) ? Best regards

4 3

dialog: db_mode => 1, enable_dmq => 1 but entries not replicated to 2nd node DB
by Benoit Panizzon 24 Jan '23

24 Jan '23

Hi I am struggling with DMQ and dialog DB storage leading to orphan or duplicate entries in database and not loading all dialog information upon restart. usrloc on the other side, also using local db storage and dmq, works flawlessly even when restarting one node. All location information is replicated between the databases via DMQ. So trying to find what is different. usrloc module: modparam("usrloc", "db_url", DBLOCAL) modparam("usrloc", "db_mode", 2) modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "sync", 1) dialog module: modparam("dialog", "db_url", DBLOCAL ) modparam("dialog", "db_mode", 1 ) modparam("dialog", "db_skip_load", 0) modparam("dialog", "enable_dmq", 1) via kamcmd dlg.list I see that dialog information is being replicated between the two nodes. But I can only find the dialog in the local database of the node which is handling the call. Is this the expected behavior? I also just found how to create duplicate entries in the database... * Run a call on Node A, verify the dialog information is store in the local database and replicated to node B via DMQ. * Restart Kamailio on Node A. There I suspect, node A is restoring Dialog Information via DMQ from Node B and loading the same information from database, leaving duplicates in dialog_vars. 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 ______________________________________________________

1 0

Kamailio World 2023 - Call For Presentations
by Daniel-Constantin Mierla 23 Jan '23

23 Jan '23

Hello, I would like to announce that Call for Presentations at Kamailio World 2023 is now open. You can submit your proposal or see more details at: - https://www.kamailioworld.com/k2023/call-for-speakers/ The 11th edition of the conference returns to Berlin, Germany, during June 5-7, 2023, as an in-person event. Expect a large range of participants, developers and community members as well as representatives of other popular open source VoIP projects such as Asterisk or FreeSwitch. Looking forward to meeting many of you there! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 0

Performances issue when freeing shared memory in custom module (Kamailio 5.5.2)
by Chaigneau, Nicolas 23 Jan '23

23 Jan '23

Hello, I'm encountering performance issues with Kamailio (5.5.2). I'm using a custom Kamailio module that loads routing data in memory, using Kamailio shared memory. This routing data is very large. It can be fully reloaded through a Kamailio RPC command (which is done once each day). When reloading, two sets of data are maintained, one "loading" and another "current" (the latter being used to handle SIP requests). When loading of the new data is finished, it is swapped to "current". Then, memory of the old (now unused) data is freed. I've noticed that when Kamailio is freeing the old data, there is a very significant performance impact on SIP requests. This is surprising to me, because the SIP requests do not use this old data. This is not a CPU issue, idle CPU% is at about 99% at that moment. I'm using the following functions : - shm_mallocxz - shm_free From what I understand, shm_free is actually "qm_shm_free" defined in "src\core\mem\q_malloc.c" (the default shared memory manager being "qm"). I've noticed that there is also a variant shm_free_unsafe ("qm_free"), which does not perform locking. I'm wondering if the lock could be the cause of my performances issues ? (But I'm not sure how this could be possible, because although the SIP requests need to access the shared memory allocated, they do not use directly the functions from the share memory manager.) If the performances issues are causes by the lock, could I use the unsafe version "safely" ? (considering that it is guaranteed that the old data cannot be used by anyone else) Thanks for your help. Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

2 6

dialog.dlg_filter_mode has ambiguous definition with double negation
by Дилян Палаузов 23 Jan '23

23 Jan '23

Hello, https://www.kamailio.org/docs/modules/devel/modules/dialog#dialog.p.dlg_fil… says for dialog.dlg_filter_mode (int) Set dialog fitering mode, which can specify what dialogs are processed. Its value can be a combination (the sum) of following flags: 1 - do not send keepalives and do not execute timeout function if dialog is not local (if the associated bind address is not a local socket). Default value is “0”. As you can see, the definition of 1 is a double negation and there is no definition for 0. What means 0: - do not send keepalives and do not execute timeout function if dialog is local - send keepalives and execute timeout function if dialog is not local - send keepalives and execute timeout function if dialog is local

1 0

Does tm.t_relay() create a transaction?
by Дилян Палаузов 20 Jan '23

20 Jan '23

Hello, the documentation for tm.t_newtran() says „This is the only way a script can add a new transaction in an atomic way.“ Moreover tm.t_send_reply() “creates the transaction if it does not exist (executing internally t_newtran()) and sends a stateful reply (executing internally t_reply())”. This means that only t_newtrans() and t_send_reply() can create transactions in an atomic way. The documentation of tm.t_relay() does not say whether the function creates a transaction. It also does not say what happens if t_reply() is not called after t_newtrans(). But for tm.t_set_retr() and tm.t_set_retr() is written “If the transaction is already created (e.g called after t_relay() or in an onreply_route) …” This suggests that tm.t_relay() does create atomically or not-atomically a transaction. - What does it mean to create a transaction in a non-atomic way? - Does tm.t_relay() create a transaction? Greetings Dilyan

2 2

sslmode in db_postgres
by Centelles Martin, Joel 20 Jan '23

20 Jan '23

Hello everybody, I'm working on a kamailio instance as a basic registrar service and I thought to use db_postgres to connect a postgres service only allowing SSl connections. I see that that module doesn't provide any parameters to select sslmode and I was wondering if this module actually supports TLS connections. Does anybody know if this is supported and, if so, how to enable it? or should that support be added into db_postgres module code? Thank you very much in advance. BR, Joel Centelles RTC Lead Engineer | Care Communications R&D joel_centellesmartin(a)baxter.com<mailto:joel_centellesmartin@baxter.com> | baxter.com<https://baxter.com/> [cid:9ee6bcbd-9c30-45ec-bb43-8f439f19f724]<https://baxter.com>

1 0

[core/tcp_main.c:617]: _wbufq_add(): (1244714 bytes): write queue full or timeout
by Benoît Panizzon 20 Jan '23

20 Jan '23

Hi I'm trying to get dlg.list on a busy system via jsonrpc and xhttp. I already increased: tcp_conn_wq_max=2048 tcp_wq_max=20480 modparam("ctl", "binrpc_max_body_size", 2048) modparam("ctl", "binrpc_struct_max_body_size", 2048) But it looks like the tcp write queue overflows up at shy over 1MB reply no matter what I change. Any ideas what else to toggle? -- 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 9

What are extended flags?
by Дилян Палаузов 20 Jan '23

20 Jan '23

Hello, The corex module manages extended flags with functions the setxflag(), isxflagset(), and resetxflag(). tmx.t_flush_xflags() does “flush the extended flags from the current SIP message into the already created transaction. It makes sense only in routing block if the transaction was created via t_newtran() and the extended flags have been altered since. It is not needed to execute this function when using t_relay() (or similar tm relay functions, xflags are synchronized automatically in that case).” The documentation of the tm module does not say anything about extended flags - in particular it does not say that t_relay() synchronizes them. Moreover, while the corex module utilizes the extended flags, the documentation of tm and tmx do not state, that they depend on the corex module. So, what are extended flags? Greetings Дилян

1 0

SIP Trunk with multiple phone numbers for account
by Carlos Escalona 19 Jan '23

19 Jan '23

Hello all! I have a question. In my system we use a series of VoIP providers to receive external calls to our telephone numbers, for the same provider we have several registered numbers and we need our providers to send that information in some way, so far it does not seem that there is a common way to do it (report the number that was dialed by the person who made the call). From what I understand, SIP does not have a place for that information because there are no things like phone numbers in the specification, my question is, is there a correct place to send such information, or is it entirely up to each provider? (Now, the most common is to have in the RURI and To header, the id of the trunk registered in the uacreg table) I have seen a couple of options that seem to me the most “correct”: send the information in the To header or send in a custom header. I really appreciate any help you can provide. Atenciosamente, [image: photo] <https://www.techer.com.br/> *Carlos Escalona* IT - Development 41 3073-0091 | R 1011 www.techer.com.br -- O conteúdo desta mensagem é confidencial. Se você não se encontra na lista de destinatários ou tenha recebido por engano, não a copie, imprima, envie, ou utilize, de qualquer forma, seu conteúdo. Neste caso, destrua a mensagem e, por favor, notifique o remetente.

3 3

Setting socket_workers does not work if using interface name
by Kaufman 19 Jan '23

19 Jan '23

At a quick glance it looks like using socket_workers when the listen parameter uses the interface name does not work. For example: children = 4 socket_workers=2 listen=udp:10.10.10.10:5060 Gives two listeners on udp:10.10.10.10:5060 children = 4 socket_workers=2 listen=udp:eth0:5060 Gives four listeners on the socket. Note this is just a quick cursory observation. Is it by design or a design limitation? Kaufman

3 3

RTC/Kamailio dinner at Fosdem 2023
by Daniel-Constantin Mierla 17 Jan '23

17 Jan '23

Hello, Fosdem 2023 returns to Brussels, Belgium, for a physical event and I'm writing to see if there are many people from the community going to the event and want to organize again the usual RTC/Kamailio dinner on Saturday evening (Feb 4, 2023). Each person should pay for himself, likely to be some price increase comparing with the last one. If there is enough interest, Torrey will help to book a place to accommodate us (first choice could be the same restaurant like in the past, if available). Reply if you want to join the dinner and say how many other people are joining you. Note that RTC Devroom got at this edition a half a day room allocation, on the afternoon of Feb 5, 2023 (Sunday). Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

7 8

Re: rtp lost package in 300 concurrent calls and above
by Henning Westerholt 16 Jan '23

16 Jan '23

Hello, please keep the list in CC. Ok, the machine seems to not really using all its cores. Regarding playing a file, this can be also done with rtpengine: https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.… Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Mohammad Reza Keshavarzianpoor <keshavarzianpoorm(a)gmail.com> Sent: Monday, January 16, 2023 3:35 PM To: Henning Westerholt <hw(a)gilawa.com> Subject: Re: [SR-Users] rtp lost package in 300 concurrent calls and above thanks for your reply my kamailio server has 8GB of ram and 4core*2.6 on esxi(dedicated)Ubuntu 22.04.1 LTS. is it low? htop on server shows load average 1.04 at max and I didn't see more than 10% load on any core of the server. I've selected rtp media server because of playback of a voice file over incoming calls in the future usage On Mon, Jan 16, 2023 at 5:45 PM Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> wrote: Hello, do you observe (too) high load on the system with the standard system management tools? If you want to just proxy calls, my recommendation would be to use rtpengine. Here you should be able to achieve higher concurrent calls rates, if you have a few CPUs on a decent machine. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Mohammad Reza Keshavarzianpoor <keshavarzianpoorm(a)gmail.com<mailto:keshavarzianpoorm@gmail.com>> Sent: Monday, January 16, 2023 2:50 PM To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] rtp lost package in 300 concurrent calls and above Hi, I've installed last version of kamailio over ubuntu. I need to broadcast machine calls to destinations. my concurrent call should be around 300(my pstn channels), so I start calls with cps around 20, because my calls contains a less than 30 second and if destination answer the call it will hanged up in less than or equal to 30 seconds. My problem is: to test my kamailio config, I'm using startrinity sip tester over an win server 2019 on local network. and it shows about 20% lost package on rtp and a jitter about 500ms. what should I do? my config is based on rtp media server module. Is there a complete working sample config for kamailio with rtp media server module? I tried rtpproxy and rtp engine in past and the same problem happened. Thanks for any help you can provide Best regards

4 10

rtp lost package in 300 concurrent calls and above
by Mohammad Reza Keshavarzianpoor 16 Jan '23

16 Jan '23

Hi, I've installed last version of kamailio over ubuntu. I need to broadcast machine calls to destinations. my concurrent call should be around 300(my pstn channels), so I start calls with cps around 20, because my calls contains a less than 30 second and if destination answer the call it will hanged up in less than or equal to 30 seconds. My problem is: to test my kamailio config, I'm using startrinity sip tester over an win server 2019 on local network. and it shows about 20% lost package on rtp and a jitter about 500ms. what should I do? my config is based on rtp media server module. Is there a complete working sample config for kamailio with rtp media server module? I tried rtpproxy and rtp engine in past and the same problem happened. Thanks for any help you can provide Best regards

4 5

Authenticated ACK: $au not set?
by Benoit Panizzon 16 Jan '23

16 Jan '23

Hi Gang I have this code snipplet: if (has_credentials("$fd")) { xlog("L_INFO", "$cfg(route): got $rm with credentials. Validate them!\n"); if ($aU == $null) { xlog("L_INFO", "$cfg(route): no auth user, send challenge\n"); } auth_challenge("$fd", "0"); exit; } } Please don't ask if this makes sense, it's a constructed snipplet to show the situation. If $rm is INVITE, this works fine, no challenge is being sent, $au is populated. If $rm is ACK (some CPE seem to send the Credentials with each message) then $au is $null, auth_challenge is called and fails. 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 1

Parallel call forking with call authorization
by Mathias Schneuwly 13 Jan '23

13 Jan '23

Hi As a first notice; I already wrote to the mailing list, but without registration. I read afterwards that I should register first because of spam reasons. If this is a duplicate, then I'm sorry. I'm new to mailing lists... I've an issue with parallel call forking together with call authentication. I hope somebody can give me some hints about what the problem could be and how I could solve this problem. I'm using Kamailio 5.5.4 with the python KEMI binding. Kamailio is in front of an Asterisk, which requires call authorization. RTPEngine is also inplace which does SRTP to RTP bridging. Simple calls from and to Asterisk through Kamailio and RTPEngine work without any issue. So the basic setup seems to work fine. The problem starts when I do parallel call forking where both calls are sent to Asterisk. If I use "KSR.tm.t_on_failure("trunk_authentication")" for authentication, the first branch is authenticating and the device rings, but the second branch does not authenticate. Well, that's not 100% true, if the SIP timeout appears on the first branch, I can see in the log, that the second branch enters the trunk_authentication method, but then, the call is already terminated. Call forking to two devices (not behind Asterisk and without call authentication) works also as expected. I made some trials with "KSR.tm.t_on_branch_failure("trunk_authentication")" but in this case, the behavior is strange. Then the authentication for both branches work and both devices are ringing. If a device hooks up, the second device does not stop ringing. And after a few seconds, the first device cancels the call, because it did not get the ACKs. I can also see that the CANCEL is sent from Kamailio to Asterisk, but Asterisk does not react to it. For trunk authentication, I'm using the implementation from the well known examples plus a few own stuff. Btw, NAT is not enabled...: def trunk_authentication(self, msg): scode = KSR.pv.get("$T_reply_code") self.log('notice', 'trunk_authentication {}'.format(scode)) if WITH_NAT and self.ksr_route_natmanage(msg) == -255: return 1 # Call manage_rtp_engine to destroy RTPEngine if it has been used. call_context = self.get_call_context(msg=msg) callee_object = call_context.callee.get_callee_object() if callee_object.connection_type: call_context.manage_rtp_engine() if KSR.tm.t_is_canceled() > 0: return 1 if scode in [401, 407]: KSR.pv.sets('$avp(auser)', KSR.pv.get('$sel(cfg_get.asterisk.trunk_username)')) KSR.pv.sets('$avp(apass)', KSR.pv.get('$sel(cfg_get.asterisk.trunk_password)')) if KSR.uac.uac_auth(): # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if KSR.is_method_in('IBSU'): if KSR.tm.t_is_set("branch_route") < 0: KSR.tm.t_on_branch("ksr_branch_manage") self.log('notice', 'Authentication Asterisk trunk') if KSR.tm.t_relay() < 0: KSR.sl.sl_reply_error() return 1 Any ideas? Best regards Mathias

3 6

src/modules.lst - difference between skipping a module from compile list and excluding a module from compile list
by Дилян Палаузов 13 Jan '23

13 Jan '23

Hello, the generated src/modules.lst file contains: # the list of modules to skip from compile list skip_modules= … # the list of modules to exclude from compile list exclude_modules= … For me excluding a module from the compile list and skipping the module when compiling is the same. Please describe what is the difference between skipping and excluding, either in modules.lst, at https://www.kamailio.org/wikidocs/devel/makefile-system/ or at https://kamailio.org/docs/tutorials/devel/kamailio-install-guide-git/ . Thanks Дилян

2 1

Newbie question
by Joao Paulo Vaz 12 Jan '23

12 Jan '23

Hello masters, I am a newbie who recently got to know Kamailio. I have a scenario and I would like to know if this tool would suit: a central asterisk server with all user accounts and three remote units with Kamailio acting as a proxy. Is there any module or configuration that if the central asterisk server fails to respond, would the remote proxies act in survival mode, allowing local communication by users until the central asterisk server returns a response? Att, Joao Paulo

3 4

unsubscribe.pls
by Stanly Levyy 11 Jan '23

11 Jan '23

*** THIS E-MAIL MESSAGE AND ANY DOCUMENTS ATTACHED IS/ARE INTENDED ONLY FOR THE USE OF THE INDIVIDUAL(S) OR ENTITY TO WHICH IT IS ADDRESSED; AND MAY CONTAIN INFORMATION THAT IS LEGALLY PRIVILEGED, CONFIDENTIAL AND/OR EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW, including the Electronic Communications Privacy Act, 18 U.S.C. Secs 2510-2521 *** On Wednesday, January 11, 2023, 01:36:44 AM PST, <sr-users-request(a)lists.kamailio.org> wrote: 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: Performing async_http calls on stateless Loadbalancers (Julius Flohr) 2. Re: Releasing v5.6.3 (Daniel-Constantin Mierla) 3. Performing async_http calls on stateless Load balancers (Lewis Hutchinson) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Jan 2023 18:50:44 +0100 From: Julius Flohr <flohr(a)sipgate.de> Subject: [SR-Users] Re: Performing async_http calls on stateless Loadbalancers To: Henning Westerholt <hw(a)gilawa.com> Cc: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>, Alles wird besser <alleswirdbesser(a)sipgate.de> Message-ID: <34C7487C-0900-4C49-BBB4-49A0291D83E6(a)sipgate.de> Content-Type: multipart/alternative; boundary=Apple-Mail-0AF7C672-1C85-4A98-9DDC-EED95FFB4B7E A message part incompatible with plain text digests has been removed ... Name: not available Type: text/html Size: 7117 bytes Desc: not available ------------------------------ Message: 2 Date: Wed, 11 Jan 2023 08:30:17 +0100 From: Daniel-Constantin Mierla <miconda(a)gmail.com> Subject: [SR-Users] Re: Releasing v5.6.3 To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>, "Kamailio (SER) - Devel Mailing List" <sr-dev(a)lists.kamailio.org> Message-ID: <454ae3b5-a810-f393-4196-e71c4482e9d3(a)gmail.com> Content-Type: text/plain; charset=UTF-8 Hello, the usual note that preparing the release of Kamailio v5.6.3 starts soon, therefore any commits to branch 5.6 should be announced first on sr-dev mailing list and wait for the ack before pushing to repo. Once the announcement is out, commits can go in the branch directly. Cheers, Daniel On 06.01.23 16:44, Daniel-Constantin Mierla wrote: > Hello, > > I am considering to release Kamailio v5.6.3 (out of branch 5.6) next > week (likely on Wednesday, Jan 11, 2023). If anyone is aware of > issues not yet on the bug tracker, report them there asap in order to > have a better chance to be fixed. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com ------------------------------ Message: 3 Date: Wed, 11 Jan 2023 09:20:28 +0000 From: Lewis Hutchinson <lewis.hutchinson(a)missionlabs.co.uk> Subject: [SR-Users] Performing async_http calls on stateless Load balancers To: "sr-users(a)lists.kamailio.org" <sr-users(a)lists.kamailio.org> Cc: "flohr(a)sipgate.de" <flohr(a)sipgate.de>, "alleswirdbesser(a)sipgate.de" <alleswirdbesser(a)sipgate.de> Message-ID: <CWXP265MB2517CB6E3E8188F3E3BB5B2AC5FC9(a)CWXP265MB2517.GBRP 265.PROD.OUTLOOK.COM> Content-Type: text/plain; charset="us-ascii" Hi Julius If I have understood this correctly, I think you can achieve this using KEMI Python leveraging aiohttp & asyncio i.e async with aiohttp.ClientSession() as session: This can be done outside of REQUEST_ROUTE Requires a rewrite from Native to KEMI so might be a bit excessive but would work. Regards Lewis ------------------------------ Subject: Digest Footer _______________________________________________ sr-users mailing list -- sr-users(a)lists.kamailio.org To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org ------------------------------ End of sr-users Digest, Vol 212, Issue 33 *****************************************

1 0

Performing async_http calls on stateless Load balancers
by Lewis Hutchinson 11 Jan '23

11 Jan '23

Hi Julius If I have understood this correctly, I think you can achieve this using KEMI Python leveraging aiohttp & asyncio i.e async with aiohttp.ClientSession() as session: This can be done outside of REQUEST_ROUTE Requires a rewrite from Native to KEMI so might be a bit excessive but would work. Regards Lewis

1 0

Releasing v5.6.3
by Daniel-Constantin Mierla 11 Jan '23

11 Jan '23

Hello, I am considering to release Kamailio v5.6.3 (out of branch 5.6) next week (likely on Wednesday, Jan 11, 2023). If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 1

Help with rtpengine_delete()
by Jose Figueroa 10 Jan '23

10 Jan '23

Hello everyone! I've been struggling with a kamailio scenario with the rtpengine_delete. My scenario is the following: I've setup a Kamailio multihomed, since some of my vendors has provided us a direct link using a different local subnet in eth2 and I have my public IP in eth1. The kamailio i've been working on is using app_lua module. SIP A <---------> 200.XXX.XXX.14 (eth1) [Kamailio 5.6] (eth2) 10.203.5.8 <------> Vendor 10.203.5.20 100.XXX.XXX.22 Basically, I receive a call from public IP eth1 and according to the logic from the vendor I forward statefully the call to 10.203.5.20 in second branch. I've been reading a lot of issues and documentation such as:[#840 rptengine], [#875 rtpengine] and [#2222 kamailio], but I don't really get working the rtpengine_delete() correctly, since I go to netstat -plan|grep rtpengine and I see some sessions still that are not freed. My second case is the following when I receive a 503 from another GW: SIP A <---------> 200.XXX.XXX.14 (eth1) [Kamailio 5.6] (eth1) 200.XXX.XXX.14 <-----------> Vendor GW 233.XXX.XXX.19 100.XXX.XXX.22 In that case I still see the rtpengine ports, mostly with my public IP 200.XXX.XXX.14 but some of them with the LAN 10.203.5.8 IP. Also, something curious I see on my 2nd use case is the following: https://pastebin.com/raw/B4vCgExX So, it would be great if someone can point me to the right direction, how and when I should use rtpengine_delete in order to finish the rtpengine sessions correctly and the ports can be freed up. Any help will be great! [840] https://github.com/sipwise/rtpengine/issues/840 [875] https://github.com/sipwise/rtpengine/issues/875 [2222] https://github.com/kamailio/kamailio/issues/2222 -- Regards, Jose Figueroa

3 2

Why do htable Keys have two colons?
by Noah Mehl 10 Jan '23

10 Jan '23

Hey everyone, Whenever I read documentation for htable usage, and other examples of other scripts in Kamailio, htable keys are typically named: something::something Examples are: $au::auth_count, $ci::srcip, join::$rU Why are there two colons (as opposed to a | )? Is this just a standard semantic thing in Kamailio? Is there something about that double character that’s unusual and easy to parse with SIP values? Or is it just what people do, and that’s a good choice to continue for all other Kamailio script writers to have understanding? Any insight would be appreciated. Thanks! ~Noah

3 6

Kamailio Crypto module and 3rd party openssl
by Arsenijs Kabihno 10 Jan '23

10 Jan '23

Hello, I am trying to make use of crypto module. The scenario is the following: 1. Encrypt plaintext passwords on kamailio side using crypto_aes_encrypt function of crypto module 2. Decrypt them outside of kamailio using 3rd party tools, such as PHP openssl_decrypt Crypto module parametrs are the following: modparam("crypto", "salt", "") modparam("crypto", "key_derivation", 0) If encryption and decription are handled by kamailio, the initial password matches the decrypted string (initial password -> encrypted string -> decrypted string) For example: sql_query("ds_dburl", "select secret from kamailio_sip_buddies where username='$au'", "secret"); $avp(secret_plain) = $dbr(secret=>[0,0]); //value: 'kamailio' crypto_aes_encrypt("$avp(secret_plain)", "YUZySHVtdlVTYjI0TGJNd3JTeVV0MlRaRWFraFNBRlM=", "$var(encrypted)"); //value: 'qfOqTMoJMgGAherGCqLRRQc4zTlqsEj3MEtcORurFf0=' crypto_aes_decrypt("$avp(secret_plain)", "YUZySHVtdlVTYjI0TGJNd3JTeVV0MlRaRWFraFNBRlM=", "$var(decrypted)"); //value: 'kamailio' But in case I try to decrypt the value of $var(encrypted) using PHP openssl_decrypt or online tool like https://www.devglan.com/online-tools/aes-encryption-decryption, I am getting the result 'kamailio' prepended by 16 random bytes, like: 6“¤›¿Ð+IÊ\ñžïZkamailio or 6��+I\��Zkamailio I believe this 16 bytes are actually random initialization vector in some encoding. Possibly kamailio is trimming them from result here: https://github.com/kamailio/kamailio/blob/master/src/modules/crypto/crypto_… Moreover, if secret was encrypted using crypto_aes_encrypt and random IV, you can use any IV while decrypting and get 16 different bytes+result Please advice if someone have used crypto module in similar way and what are the possible ways to acheive results consistency

2 5

pkg memory leak when acc module cdr_enabled
by Juha Heinanen 10 Jan '23

10 Jan '23

In latest stable K release, we noticed pkg memory leak (pgk memory usage increases by each processed call). It turned out that the leak goes away if acc module cdr_enable is not enabled. Could be a bug in dialog or acc module. Any debug instructions if the bug is not obvious? -- Juha

4 14

wrong char / bad PVE format
by Nathan Stratton 09 Jan '23

09 Jan '23

Trying to rename rtpengine files with: exec_msg("mv /var/spool/rtpengine/rtpengine-recording/$ci* /var/spool/rtpengine/rtpengine-recording/$ci.wav"); But get this error: Jan 06 13:59:19 proxy1 /usr/sbin/kamailio[2929]: ERROR: <core> [core/pvapi.c:924]: pv_parse_spec2(): error searching pvar "ci.wav" Jan 06 13:59:19 proxy1 /usr/sbin/kamailio[2929]: ERROR: <core> [core/pvapi.c:1127]: pv_parse_spec2(): wrong char [v/118] in [$ci.wav] at [6 (0)] Jan 06 13:59:19 proxy1 /usr/sbin/kamailio[2929]: ERROR: <core> [core/sr_module.c:1157]: fix_param(): bad PVE format: "mv /var/spool/rtpengine/rtpengine-recording/$ci* /var/spool/rtpengine/rtpengine-recording/$ci.wav" Jan 06 13:59:19 proxy1 /usr/sbin/kamailio[2929]: ERROR: <core> [core/mod_fix.c:564]: fixup_spve_null(): Cannot convert function parameter 1 to space Any ideas? ><> Nathan Stratton Founder, CTO Vocinity, Inc. <https://www.vocinity.com/gabbi>

3 2

RABBITMQ and AWS
by Fred Posner 06 Jan '23

06 Jan '23

Has anyone had any success connecting to RabbitMQ via a TLS 1.2 connection (such as the AWS MQ product)? Fred Posner https://pgpx.io

3 3

TypeError exception in Kemi with python3
by Michel Pelletier 06 Jan '23

06 Jan '23

Hello, I am using Kemi with Python3. I am getting a TypeError exception when using the following: KSR.presence.handle_subscribe() 40(208) INFO: PY3 {SUBSCRIBE}: app_python3 [apy_kemi.c:1839]: sr_apy_kemi_exec_func(): alert - action KSR.presence.handle_subscribe(...) took too long [2004761 ms] (file:(null) func:(null) line:733) 40(208) ERROR: PY3 {SUBSCRIBE}: app_python3 [python_support.c:156]: python_handle_exception(): apy_exec: ksr_request_route((null)): Unhandled exception in the Python code: TypeError: expected bytes, str found The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/etc/kamailio/kamailio.py", line 152, in ksr_request_route if self.ksr_route_presence(msg) == -255: File "/etc/kamailio/kamailio.py", line 733, in ksr_route_presence KSR.presence.handle_subscribe() SystemError: <built-in function handle_subscribe> returned a result with an error set Using the following appears to be a good workaround, as it does not exhibit the issue at all: KSR.presence.handle_subscribe_uri(KSR.pv.get("$fu")) Cheers, Michel Pelletier

1 0

Call drop when reinvite is proceed
by nathan.castillo＠snapcom.fr 05 Jan '23

05 Jan '23

Hello all, I'm trying to figure out one problem on my Kamailio server. When kamailio receive a reinvite from the infra, I get the error message "477 - Unforunately error on sending to next hop" and the call drop. I don't understand why this message appears as the first invite is well answered and the call is going well. Any ideas how to resolve this issue ? Thanks in advance for your help. Regards, Nathan

6 6

Too many 200:OK sip responses
by Waqar 40 05 Jan '23

05 Jan '23

Dear All, For a normal call, Kamailio receives 200:OK sip response for the method invite only once but for some calls, it receives 200:OK too many times around 6 to 7. And I also do not receive BYE or any other packets for this kind of call. How can I detect such calls in Kamailio and cancel them? I am inserting data of the calls in the database when the call occurs and deleting it when BYE is received but for these calls as I don't receive BYE so I am unable to delete the record of such calls. Is there a way to detect such calls? Like How can I count if the number of 200:OK responses is more than one or anything like that? Regards Vicky

4 4

How to have Kamailio retry backends
by Unai Rodriguez 04 Jan '23

04 Jan '23

Dear List, We’re using Kamailio to load balance MRCP requests to multiple backend groups with a configuration as follows: # kamailio.cfg ... ... route[DISPATCH] { if($ua=="mrcp_backend_1") { if(!ds_select_dst("1", "4")) { send_reply("404", "No destination"); exit; } } if($ua=="mrcp_backend_2") { if(!ds_select_dst("2", "4")) { send_reply("404", "No destination"); exit; } } xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } ... ... # dispatcher.list 1 sip:mrcp01.server.int:8060;transport=tcp 1 sip:mrcp02.server.int:8060;transport=tcp 2 sip:mrcp03.server.int:8060;transport=tcp 2 sip:mrcp04.server.int:8060;transport=tcp With this configuration, Kamailio load balances the initial SIP INVITE among the MRCP servers. After the INVITE, the service communicates directly to the MRCP servers via SIP (for hanging up the call), MRCPv2 (for sending speech control messages), and RTP (for sending audio). We would like to implement a configurable number of retries, so that if a particular backend times out, Kamailio would retry X times to other backend(s). In short, something equivalent to HAProxy’s retries, but for Kamailio. This probably implies having Kamailio always as part of our communication (not just load balancing the initial SIP INVITE). I haven’t been able to find much information about this, could someone provide some pointers? Thank you so much With best wishes, Unai Rodriguez

3 6

Recover call in ringing state
by Devang Dhandhalya 04 Jan '23

04 Jan '23

Hello All I have below setup : SBC -> kamailio -> Media server(remote) -> web-client Call comes from sbc to kamilio and it relays to Remote server to end user, In Ringing state if remote server goes down then in kamailio there is any way to Recover that ringing call like we can generate new invite for other Remote server which is active state, for relaying call i am using dispatcher module.. I tried with tm.cancel RPC command but it works only if the remote server is running , when I crash the remote server at that time tm.cancel is not generating cancel to remote server. Please suggest if there is any other way to generate INVITE. Regards Devang Dhandhalya -- * <https://www.ecosmob.com/> * *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

2 3

Job offer Kamailio/VoIP developer
by Henning Westerholt 03 Jan '23

03 Jan '23

Hello and Happy New Year, we are looking for a new Kamailio & VoIP developer colleague to join and grow our international team. More detail about the position can be found at: https://gilawa.com/en/about/careers If you are interested, please send me a (direct) email. Please include the information described in the linked job description. Best regards, Henning Westerholt -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

1 0

Localy generate BYE message from ims_charging
by masoud96＠mail.ru 03 Jan '23

03 Jan '23

Hello! I have a problem with writing the BYE message from the ACC module to the database, because the messages are generated locally by the ims_charging module at the end of the credit and the flag will not work. You can help catch such local messages and make a record in the database.

2 2

Question about UAC and PUA modules routing behavior
by Jean-Francois Lemieux 03 Jan '23

03 Jan '23

Hello, I have some trouble to figure out how routing works when the request coming from the kamailio itself (used as a user agent per example) .I try to use presence PUA... modules. The issue I have is the NOTIFY requests aren't sent to the good destination; it doesn't seems to obey to the contact or other informations when the device did a SUBSCRIBE. I don't want to ask to troubleshoot the presence module directly I just want to know how Kamailio deals with request coming from Kamailio itself (in the case of a NOTIFY generated by PUA_... modules My mains questions are: Does the pua modules when generating request like NOTIFY will pass through request_route ? Does the pua modules when generating request like NOTIFY will be sent only when t_relay() is used or UA kamailio based request bypass all the logic of the Kamailio proxy behavior ? I'm trying to understand if I can modify the NOTIFY request to change destination before the "routing decision" is made by Kamailio Kamailio 5.6.0 used as : -proxy to remote pbx for call dialog -registrar/location server -media relaying and nat management -...and I try to use it as a presence server instead to use the pbx behind kamailio

3 2

Steering egress on replies
by Alex Balashov 03 Jan '23

03 Jan '23

Hi, Happy New Year! From what I understand, replies are always sent back out of the listener on which they were received, though `reply_to_via` (off by default) can override this and cause the exit listener to be recalculated based on a real-time assessment of the best way to reach the last Via hop. Two questions arise: 1) If turning `mhomed` off, can `$fs` be used to override the exit interface of locally generated replies, too? If so, where should it be done? In a request_route prior to a send_reply() / sl_send_reply() / t_reply() call? Or should it be done inside a local reply route or onsend_route? 2) Does this differ for locally generated replies vs. relayed replies, either statefully or statelessly? Thanks! -- Alex -- 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

Registration Proxy
by nutxase 02 Jan '23

02 Jan '23

Hi Guys, can someone point me in the right direction as to how i can use kamailio as a registration proxy similar to how opensips does mid_registrar? i want to proxy all sip registrations through kamailio to asterisk or freeswitch Sent with [Proton Mail](https://proton.me/) secure email.

3 2

Happy New Year 2023!
by Daniel-Constantin Mierla 01 Jan '23

01 Jan '23

A Happy, Peaceful And Prosperous Year 2023 to everyone using Kamailio and helping to improve the project! Looking forward to meeting many of you around this world during 2023 and collaborating in a friendly environment! Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 0

Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST)
by Lewis Hutchinson 30 Dec '22

30 Dec '22

Hi Brandon Apologies if you have provided this but do you have a PCAP of the INVITE / 400 Bad Request rather than the Pastebin of the INVITE The last time I had this was because of a missing /r/n on the SDP granted it was not with teams but still difficult to track down. Also, what is the MTU Size, have you checked to see if the is causing packet fragmentation and manifesting in a Bad Request. Are there any clues in the Teams - Call Analytics. Regards Lewis -----Original Message----- From: sr-users-request(a)lists.kamailio.org <sr-users-request(a)lists.kamailio.org> Sent: 29 December 2022 20:17 To: sr-users(a)lists.kamailio.org Subject: sr-users Digest, Vol 211, Issue 67 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: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) (Brandon Armstead) 2. Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) (Brandon Armstead) ---------------------------------------------------------------------- Message: 1 Date: Thu, 29 Dec 2022 12:15:16 -0800 From: Brandon Armstead <brandon(a)cryy.com> Subject: [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) To: Henning Westerholt <hw(a)gilawa.com> Cc: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Message-ID: <CABAX3EoF+hfruLiV2Nh_g117_q8diaKxVEyp5hMFO=wyKbQidQ(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="0000000000005692d905f0fd2538" Henning, There was no reply (reason) available in my case. - Brandon On Thu, Dec 29, 2022 at 11:48 AM Henning Westerholt <hw(a)gilawa.com> wrote: > Hello, > > > > as mentioned before, have a look to the 400 reply reason phrase. This > was done quite good from their side, better than many other vendors. > > Usually, Teams is not too bad if you are using a defined > infrastructure that do not introduce too many variables. We are > usually using a B2BUA in our customer projects for that purpose. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt - > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskal > atan.de%2Fblog%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=QU%2BzOgPdbmRYh51a9PvptIvVjnTZrGxT8z1G7b2RRGQ%3D&reserved=0 > > Kamailio services - > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgila > wa.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7C0% > 7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PuDqkZ > QCj2IlxvRsLQGoKFv19K3uVE5RBxvcPKPODwQ%3D&reserved=0 > > > > *From:* Brandon Armstead <brandon(a)cryy.com> > *Sent:* Thursday, December 29, 2022 7:52 PM > *To:* Kamailio (SER) - Users Mailing List > <sr-users(a)lists.kamailio.org> > *Subject:* [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 > BAD > REQUEST) > > > > Alex & Kaufman, > > > > Appreciate the feedback. The pastebin is one example of about > 1000+ iterations literally of changes. So I'm finally reaching out > :). I haven't tested the socket attribute in record-route change, I > will try this now. As for the angle brackets I've tried with and > without, etc (already) to no effect. The SDP unknown media type seems > to be a Poly thing, so I > *want* to rule this out as its not in my other SDP's and still receive > 400 bad request. > > One more iteration here we go... please feel free to let me know if > you have any other thoughts on the matter :). > > > > Thanks! > > > > - Brandon > > > > On Thu, Dec 29, 2022 at 8:08 AM Alex Balashov > <abalashov(a)evaristesys.com> > wrote: > > Yeah, the grammar says that rr-params are just generic-params, in > which case it's not. I didn't see that -- nicely spotted! > > I think that may be the basis of the 400 Bad Request. I'd be shocked > if it weren't. > > The broken clock of "Microsoft SIP" can still be right twice a day. > > > On Dec 29, 2022, at 10:31 AM, Kaufman <bkaufman(a)bcmone.com> wrote: > > > > In your top Record-Route you have: > > > > socket=; > > > > Not sure if that is legal. > > > > Kaufman > > > > -----Original Message----- > > From: Alex Balashov <abalashov(a)evaristesys.com> > > Sent: Thursday, December 29, 2022 9:02 AM > > To: Kamailio (SER) - Users Mailing List > > <sr-users(a)lists.kamailio.org> > > Subject: [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 > > BAD > REQUEST) > > > > Sorry to hear you're having to interoperate with Teams. It's a > > unique > form of sadism I wouldn't wish upon anyone. > > > > A few theories: > > > > 1) Microsoft doesn't like the "bare" Contact header-value here: > > > > Contact: > sip:+MY_FROM_PHONE_NUMBER_HERE@MY_FQDN_WAS_HERE:5061;transport=tls > > > > Unlike the careted one right above: > > > > P-Asserted-Identity: > > <sip:+MY_FROM_PHONE_NUMBER_HERE@MY_FQDN_WAS_HERE> > > > > A bare URI absent other header-params is of course completely legal, > > but > I'm really trying to get inside the imaginary world of antisocial > "Microsoft SIP" here. > > > > 2) Could it be that antisocial "Microsoft SIP" sends 400 as a way of > objecting to something in the SDP, e.g. where a non-demented SIP stack > would send "488 Not Acceptable Here" or "415 Unsupported Media Type"? > > > > I know you've said you tried multiple clients to rule that out, but > > I > wonder if the thing it's objecting to hasn't been ruled out that way. > > > > 3) I saw this media line in the SDP: > > > > m=application 41356 <unknown media type> > > > > What's that? > > > > -- Alex > > > >> On Dec 29, 2022, at 9:51 AM, Brandon Armstead <brandon(a)cryy.com> wrote: > >> > >> Outbound calls from my SBC into Teams (Polycom -> SBC -> Teams) > >> always > result in a 400 BAD REQUEST. > >> Example invite below: > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fn > >> am11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%25 > >> 2Fpast&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > >> 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7 > >> C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA > >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda > >> ta=5v20CvNnmdiHwfWMBX6tgjMlE1i2aKpFgTnuVFfpyl0%3D&reserved=0 > >> ebin.com%2FF1G1Ce59&data=05%7C01%7Cbkaufman%40bcmone.com%7C55672dbf > >> 739 > >> a4ff447f008dae9b0c9b2%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C > >> 638 > >> 079242759152531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > >> iV2 > >> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Cbff6B4g > >> Nr8 > >> A9zs89smJ129y8IyNM9%2B3zVkGhlzpa54%3D&reserved=0 > >> I've taken care to make sure numbers are all E.164 format in > From/To/Contact. I've also taken care to make sure that FQDN is used > in Contact and Record-Route header. > >> I've tried many different variations and have followed the SIP > information here: > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fn > >> am11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%25 > >> 2Flear&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > >> 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7 > >> C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA > >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda > >> ta=ELk0UD1Pleq%2FG9j1%2BT18tiuFe0yjflimR9ztnW%2F7oPM%3D&reserved=0 > >> n.microsoft.com%2Fen-us%2Fmicrosoftteams%2Fdirect-routing-protocols > >> -si > >> p&data=05%7C01%7Cbkaufman%40bcmone.com%7C55672dbf739a4ff447f008dae9 > >> b0c > >> 9b2%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638079242759152531 > >> %7C > >> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > >> k1h > >> aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GO26A9FOOoS42yMCWPPGo5PkKo > >> 75c > >> kjSJSkjAeYRsU0%3D&reserved=0 I've also tried several different > >> clients (Bria, Polycom CCX 600, Grandstream, etc) to see if maybe > >> it was > something in the SDP or otherwise causing an issue. > >> SIP Transport is TLS, RTP is SRTP > >> I might also add that OPTION pings are active and Direct Routing > Endpoint is active, so this is successful. I also am able to receive > calls FROM teams to my IP phone(s) without issue. It is only when I > try and call INTO teams (INVITE -> Microsoft Teams) that I always > receive a 400 BAD REQUEST to my INVITE. > >> Any help is appreciated, thank you! > >> > >> - Brandon > >> > >> __________________________________________________________ > >> 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: > > > > -- > > Alex Balashov | Principal | Evariste Systems LLC > > > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > > Web: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e > varistesys.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=hbww6wEEztE85YqxcN92bpMR%2BkiI9%2BE3jF1i6fQpjEk%3D&reserved=0, > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c > srpswitch.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7 > Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7 > C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =4E7a5ZxSvttBiMxl1VTtolmTvS4T5VGZHA00CsbPR2c%3D&reserved=0 > > > > __________________________________________________________ > > 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: > > __________________________________________________________ > > 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: > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e > varistesys.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=hbww6wEEztE85YqxcN92bpMR%2BkiI9%2BE3jF1i6fQpjEk%3D&reserved=0, > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c > srpswitch.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7 > Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7 > C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =4E7a5ZxSvttBiMxl1VTtolmTvS4T5VGZHA00CsbPR2c%3D&reserved=0 > > __________________________________________________________ > 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: > >

1 0

Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST)
by Brandon Armstead 29 Dec '22

29 Dec '22

Outbound calls from my SBC into Teams (Polycom -> SBC -> Teams) always result in a 400 BAD REQUEST. Example invite below: https://pastebin.com/F1G1Ce59 I've taken care to make sure numbers are all E.164 format in From/To/Contact. I've also taken care to make sure that FQDN is used in Contact and Record-Route header. I've tried many different variations and have followed the SIP information here: https://learn.microsoft.com/en-us/microsoftteams /direct-routing-protocols-sip I've also tried several different clients (Bria, Polycom CCX 600, Grandstream, etc) to see if maybe it was something in the SDP or otherwise causing an issue. SIP Transport is TLS, RTP is SRTP I might also add that OPTION pings are active and Direct Routing Endpoint is active, so this is successful. I also am able to receive calls FROM teams to my IP phone(s) without issue. It is only when I try and call INTO teams (INVITE -> Microsoft Teams) that I always receive a 400 BAD REQUEST to my INVITE. Any help is appreciated, thank you! - Brandon

5 9

Remove all Via Header or create custome Via Header
by Benoit Panizzon 27 Dec '22

27 Dec '22

Hi out there! While experimenting with the listen and adverize 'hostname' option I came across a voice switch, which I suppose fails if the Via header is not an IPv4 address. There is a record_route_advertised_address(address) in the RR module, to set a customer Record-Route Header. Is there something similar for the Via header so I could try if having an IP address instead of a hostname in the top-most Via would solve the issue? Or is there a way to remove all via header? Remove_hf("Via") in the branch route trigger garbles the From: HF. 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 ______________________________________________________

3 4

Proxy edge
by Giovanni Iamonte 26 Dec '22

26 Dec '22

Dear List We have configured kamailio to work as a proxy edge and register. As a proxy edge cfg file we have used the example *edge_websocket.cfg.** * We are developing two different client the first one based on *PJSIP* and the other one based *JsSIP*. Client PJSIP (no websockets) everything work perfectly, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INVITE Client JsSIP (with websockets) The REGISTER, SUBSCRIBE works, the NOTIFY does not work. In more in details we have: Browser Proxy Edge Register Client JsSIP Websocket | | | | | | | ----------Register-----------> | -----------Register----------> | | <----------200 OK ----------- | <----------200 OK ----------- | | | | | ----------Subscribe----------> | -----------Subscribe---------> | | <----------200 OK ----------- | <----------200 OK ----------- | | | | | X<--- | <----------NOTIFY ----------- | | | | As you can see the NOTIFY start from Register and reach the proxy, beloe the Register log file and the sip messages. Could somebody put me in the right direction. Thanks Bye *Log File* Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/tcp_read.c:1533]: tcp_read_req(): content-length=0 Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 2 (reply(status)) flags 1 Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/msg_parser.c:689]: parse_msg(): SIP Reply (status): Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/msg_parser.c:690]: parse_msg(): version: <SIP/2.0> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/msg_parser.c:692]: parse_msg(): status: <478> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/msg_parser.c:694]: parse_msg(): reason: <Unresolvable destination (478/SL)> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 *Sip Messages* *REGISTER* sip:sip-register.quintetto.it SIP/2.0 Via: SIP/2.0/WSS 13569868356.invalid;branch=z9hG4bK7825787 Max-Forwards: 69 To: <sip:quintetto00@sip-register.quintetto.it> From: "quintetto00" <sip:quintetto00@sip-register.quintetto.it>;tag=2tnuk9btmp Call-ID: unrnseei8924hf67khoi3g CSeq: 2 REGISTER Authorization: Digest algorithm=MD5, username="quintetto00", realm="sip-register.quintetto.it", nonce="Y6GUq2Ohk3//HTza7ZYMfd85XMdavgnc", uri="sip:sip-register.quintetto.it", response="c9cc56d2d5e36b0a68873c1d5258d062" Contact: <sip:quintetto00@13569868356.invalid;transport=ws>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:64e71c57-fd55-4868-be2b-a4a3fa546ac8>";expires=3600 Expires: 3600 Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY,SUBSCRIBE,PUBLISH Supported: path,gruu,outbound User-Agent: JsSIP 3.10.0 Content-Length: 0 SIP/2.0 *200 OK* Via: SIP/2.0/WSS 13569868356.invalid;rport=37566;received=192.168.100.192;branch=z9hG4bK7825787 To: <sip:quintetto00@sip-register.quintetto.it>;tag=2b789d0fa67ad6c2da65f0cce35dd60b.71a84df9 From: "quintetto00" <sip:quintetto00@sip-register.quintetto.it>;tag=2tnuk9btmp Call-ID: unrnseei8924hf67khoi3g CSeq: 2 REGISTER Contact: <sip:quintetto00@13569868356.invalid;transport=ws>;expires=3600;+sip.instance="<urn:uuid:64e71c57-fd55-4868-be2b-a4a3fa546ac8>";reg-id=1 Server: kamailio (5.6.2 (x86_64/linux)) Content-Length: 0 *SUBSCRIBE* sip:quintetto03@sip-register.quintetto.it SIP/2.0 Via: SIP/2.0/WSS 13569868356.invalid;branch=z9hG4bK3648599 Max-Forwards: 69 To: <sip:quintetto03@sip-register.quintetto.it> From: "quintetto00" <sip:quintetto00@sip-register.quintetto.it>;tag=o261bh2uh7 Call-ID: 4beh90hur8hdhptnbjt8 CSeq: 5813 SUBSCRIBE Proxy-Authorization: Digest algorithm=MD5, username="quintetto00", realm="sip-register.quintetto.it", nonce="Y6GU+mOhk86y3fnrMzoKgiVAdkaTvBId", uri="sip:quintetto03@sip-register.quintetto.it", response="04ca6d83661ac338810baa95ffaa568b" Event: presence Expires: 3600 Accept: application/pidf+xml, application/xpidf+xml Contact: <sip:quintetto00@13569868356.invalid;transport=ws> Content-Type: application/pidf+xml Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY,SUBSCRIBE,PUBLISH Supported: outbound User-Agent: JsSIP 3.10.0 Content-Length: 35 SIP/2.0 *200 OK* Record-Route: <sip:192.168.100.24:15006;transport=tcp;r2=on;lr> Record-Route: <sip:192.168.100.24:16005;transport=ws;r2=on;lr> Via: SIP/2.0/WSS 13569868356.invalid;rport=37566;received=192.168.100.192;branch=z9hG4bK3648599 To: <sip:quintetto03@sip-register.quintetto.it>;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec From: "quintetto00" <sip:quintetto00@sip-register.quintetto.it>;tag=o261bh2uh7 Call-ID: 4beh90hur8hdhptnbjt8 CSeq: 5813 SUBSCRIBE Expires: 3600 Contact: <sip:192.168.100.23:15006;transport=tcp> Server: kamailio (5.6.2 (x86_64/linux)) Content-Length: 0 *NOTIFY*.sip:quintetto00@13569868356.invalid;transport=ws.SIP/2.0 Via:.SIP/2.0/TCP.1 92.168.100.23:15 006;branch=z9hG4bK28ad.a5d3bdf6000000000000000000000000.0 To: <sip:quintetto00@sip-register.quintetto.it>;tag=o261bh2uh7 From: <sip:quintetto03@sip-register.quintetto.it>;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec CSeq : 2 NOTIFY Call-ID:.4beh90hur8h dhptnbjt8 Route : <sip:192.168.1 00.24:15006;transport=tcp;r2=on;lr>,.<sip:192.16 8.100.24:16005;transport=ws;r2=on;lr> Content-Length:.0 User-Agent: kamailio.(5.6.2.(x86_64/li nux)) Max-Forwards:.70 Event: presence Contact:.<sip:192.168.100.23:15006;transport=tcp> Subscription-State: active;expires= 3600 SIP/2.0.478.Unresolvable.destination.(478/SL) Via: SIP/2.0/TC P.192.168.100.23 :15006;branch=z9hG4bK28ad.a5d3bdf6000000000000000000000000.0;rport=38019 To:.<sip:quintetto00@s ip-register.quintetto.it>;tag=o261bh2uh7 From: <sip:quintetto03 @sip-register.quintetto.it>;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec CSeq: 2 NOTIFY Call-ID: 4beh90hur8hdhptnbjt8 Server :.kamailio.(5.6.2.(x86_64/linux)) Content-Length: 0 SIP/2.0.478.Unresolvable.destination.(478/TM) Via: SIP/2.0/TC P.192.168.100.23:15006;branch=z9hG4bK28ad.a5d3bdf6000000000000000000000000.0;rport=38019 To: <sip:quintetto00@s ip-register.quintetto.it>;tag=o261bh2uh7 From: <sip:quintetto03 @sip-register.quintetto.it>;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec CSeq: 2 NOTIFY Call-ID: 4beh90hur8hdhptnbjt8 Server : kamailio.(5.6.2.(x86_64/linux)) Content-Length: 0 -- ------------------------------------------------------------------------ Ing. Giovanni Iamonte Developments and technologies area Quintetto Srl Via Monte Navale, 1 10015 - Ivrea (TO)  mobile: +39 393 9196310  tel: +39 0165 1845290  e-mail: giovanni.iamonte(a)quintetto.it  web: www.quintetto.it

3 4

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

How to unset_dlg_profile in request_route or react more quickly to CANCEL?
by Benoit Panizzon 20 Dec '22

20 Dec '22

Hi List Testing failure situations, I discovered unset_dlg_profile can not be used in request_route: I count the channels per customer in a dlg_profile to know when they are busy. Residential POTS customer have 1 channel. Now this situation (Trying to mimik POTS behavior) Kamailio <=> CPE of 'John-Doe' => INVITE set_dlg_profile of John-Doe is 0: Not busy set_dlg_profile of John-Doe +1 <= 100 trying <= 180 ringing == LINK to CPE DISRUPTED == X<= 200 OK (not reaching kamailio) CPE is sending 200 a couple of times and fails. Caller is still hearing ringing tone as it never got 200 OK. The caller does not want to wait longer and hangs up =>X CANCEL (NOT reaching CPE) This is the moment, on which I would like to unset_dlg_profile of John-Doe to mark his channel available again. But the CPE is never going to acknowledge this CANCEL with 487. Unfortunately: unset_dlg_profile(): dialog delete profile cannot be used in request route Only when kamailio has sent CANCEL a couple of times and the failure_route for this CANCEL is triggered, I can remove the call from the dlg_profile of that customer within failure_route. If I am unlucky, in the meantime other calls get 'busy' instead of being re-routed to the configured backup number of that customer. Agreed, after a couple of seconds, the call goes to the failure route and the dialogue is ending thus calls work as expected. But wouldn't it be nice to be able to unset the dlg_profile upon receiving the CANCEL instead on when the CANCEL transaction is successful? 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 2

DNS Host-Names in Via and Record-Route for more redundancy?
by Benoit Panizzon 20 Dec '22

20 Dec '22

Hi Folks We use two 'core' instances and two 'registrar' instances. The pairs sync their information (Dialogues + Locations) via DMQ. But I noticed that they record the Via and Record-Routes by IP addresses. So I guess if one fails, signaling would not automatically switch to the remaining host as the IP of the failed one is in the header, right? So, is there a way to put a DNS resolvable host-name in the Via and Record-Route header, so that DNS round-robin would make sure requests reach the available server if one of the pairs fails? 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 ______________________________________________________

3 6

Multiple websocket connections with the same port
by Benjamín Visón 19 Dec '22

19 Dec '22

Hello! I'm examining the WebSocket module and I am wondering how it handles multiple connections from the same port. For context, imagine the following scenario: UA1 ==> Load Balancer:41914 ==> Kamailio (WS) UA2 ==> Load Balancer:41914 ==> Kamailio (WS) Now, imagine Kamailio perceives UA1 from port 41914. What happens if that UA1 suddenly drops and another UA2 comes in from the same port? (before the connection closed event is fired for UA1) I understand by looking at the source code that `wsconn_add` is called and that this new connection is added to the list. But what happens with the previous UA entry? does it gets overwritten or does it stays there? The reason for my question is: I am perceiving the above scenario like this: Let's say UA1 is *sip:d3315cf8@9a431b1f90e5.invalid;transport=ws SIP/2.0* and UA2 is *sip:asd08a08@555343439666.invalid;transport=ws. *If UA2 comes in and takes over the port that UA1 was using, and I send an INVITE to UA1 UA2 ends up receiving the invite (obviously because it now has that port allocated). So what I am thinking is that both *d3315cf8(a)9a431b1f90e5.invalid *and *asd08a08(a)555343439666.invalid *are mapped to the same port for a short period of time. Thoughts? Saludos, [image: Twitter] <https://twitter.com/benjaminvison>[image: Instagram] <https://instagram.com/bvisonl/> Benjamín Visón / IT Engineer / Software Developer bvisonl(a)gmail.com / (829)-664-5163 https://www.linkedin.com/in/bvisonl/

3 2

auth_challenge() and async
by Alex Balashov 19 Dec '22

19 Dec '22

Hi, Is there any good solution for the scenario of an auth_challenge() with two separate transaction suspensions? To clarify (simplified): request_route { ... t_newtran(); if(!is_present_hf("Authorization") && !is_present_hf("Proxy-Authorization")) { auth_challenge("$fd", "1"); exit; } # TM suspend/continue t_newtran(); async credentials query("RESUME_AUTH"); } route[RESUME_AUTH] { # Credentials received into PVs. if(!pv_auth_check("...")) { auth_challenge("$fd", "1"); exit; } # Create transaction shell if not exists already from auth query. if(!t_lookup_request()) t_newtran(); # TM suspend/continue async route query("RESUME_ROUTING"); } route[RESUME_ROUTING] { # Unmarshal etc. t_relay(); # etc. } What happens here is that the first auth_challenge() results in a retransmission of its 407 challenge without absorbing the negative ACK. This is despite the ostensibly stateful behaviour of auth_challenge() without "force_stateless_reply" enabled. In this case, it eclipses the second, unrelated 407 challenge from the subsequent routing query (407 challenge with +1 CSeq): -- Alex -- 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/

3 17

Dealing with failed SRV peers
by Sebastian Damm 17 Dec '22

17 Dec '22

Hi, we have some Kamailios working as outboundproxy. So they get requests from internal systems and send them to different providers. From time to time, one provider returns a server as primary resource which is currently unavailable. I guess if the internal systems connected directly to the target, they would remember the failed server and remember to always use the server with second priority at least until DNS refresh time. In our setup, since every request is "new" for Kamailio, it doesn't remember, which host is reachable or not. Example: target: example.com _sip._udp.example.com SRV resolves to: 10 192.0.2.42 5060 20 198.51.100.42 5060 30 203.0.113.42 5060 192.0.2.42 is unavailable. Still, Kamailio uses it for every new request and failover to 198.51.100.42 occurs only after timeouts hit. Is there a best practice for solving this? I have played around with the dst_blocklist settings, but that caused even more trouble because Kamailio started blocking requests to peers that have only one server in the record having a short hickup. Thanks in advance for every input, as this is causing trouble every time we run into such a situation. Regards, Sebastian

4 7

Redundancy
by Jawaid Bazyar 16 Dec '22

16 Dec '22

Hi, I am exploring different redundancy / load-balancing models for a Kamailio cluster. When I say cluster, I mean, a number (N) of Kamailio nodes acting as stateful proxies. Each node is configured the same as the others, and all have access to the same lookup data to make routing decisions. I would appreciate any advice or experience any of you can share on these different models. Overall model: Direct to proxies Redirect servers first, which redirect to proxies Selecting the first node to talk to. Each model could use either type of selection. DNS-based (SRV or NAPTR, client makes call to dns name) Anycast with ECMP (equal-cost multi-path routing) Cluster with a mobile IP and service-down detection (this would just provide 1:1 protection) Have clients make calls through the proxy using a DNS record containing an SRV record for each node (or, alternatively, done with NAPTR). Would rely on the client to switch nodes in the event of a node failure mid-call. (Is that even possible?) Anycast would only work with UDP signaling. Use Anycast to find the first proxy, then use stateful responses to direct client back to same node for subsequent messages in a dialog. So for anyone who has tried any of these methods, I would love to hear the pros and cons.. Thanks in advance! Jawaid

2 4

Must openssl_mutex_shared.so be preloaded?
by Дилян Палаузов 16 Dec '22

16 Dec '22

Hello, The documentation on using openssl_mutex_shared.so is contradicting. https://github.com/kamailio/kamailio/blob/master/src/modules/tls/README#L293 says: > For OpenSSL (libssl) v1.1.x, it is required to preload 'openssl_mutex_shared' library shipped by Kamailio. For more details see 'src/modules/tls/openssl_mutex_shared/README.md'. https://github.com/kamailio/kamailio/blob/master/src/modules/tls/utils/open… says: > IMPORTANT: the workaround of using this preloaded shared library is no longer needed starting with Kamailio v5.3.0-pre1 (git master branch after September 14, 2019). The code of this shared library has been included in the core of Kamailio and the same behaviour is now achieved by default. It is unclear, if openssl_mutex_shared.so must be preloaded. In case the library is not needed anymore, it shall not be compiled and installed. Kind regards Дилян

1 1

Logs suddenly inundated with qm_malloc errors
by George Diamantopoulos 16 Dec '22

16 Dec '22

Hello all, I'm testing out release 5.6.2 on one production kamailio instance, and today our monitoring system triggered an alarm for lack of disk space on /. Indeed, kamailio.log started growing at an alarming rate at some point. At about the same time disk space started being depleted, the following line was frequently logged in the logs (no instances of it before that time): qm_malloc(): qm_malloc(0x7f5ade9c0010, 536) called from rtpengine: bencode.c: __bencode_piece_new(79), module: rtpengine; Free fragment not found! They don't only concern rtpengine, core has produced similar "free fragment not found" errors as well. There's additional multiple "had header field", "bad header" and "invalid header name" errors appearing after that too, but I'm guessing that's only a symptom of the qm_malloc issue? kamailio is started with -m 2048 -M 16 and there's another instance with almost identical traffic and configuration, but running on 5.6.1, which has never exhibited such failures in several months uptime. So I'm wondering, is there anything in 5.6.2 that could explain this? Thanks! Best regards, George

3 4

NAT issues with Kamailio + Asterisk with 2 NICs
by Sergio Charrua 15 Dec '22

15 Dec '22

Hi all! Got a random issue with NAT which I really have no clue how to solve. Setup is as follows: - Client A sends SIP INVITE through Public IP 1.2.3.4, where a Cisco Firewall forwards NATed data to a Kamailio instance (acting as a SIPProxy with dispatcher) listening with internal address 192.168.0.1 on port 5060. RTPEngine is in the same server and address too. - Kamailio will forward the invite to Asterisk NIC 1 (192.168.0.2) which will do some provisioning and accounting stuff and redirect the call (if authorized) to Client B's public IP address (all clients are outside the network, reachable via WWW) using NIC 2 (192.168.1.2) and public address 4.3.2.1. The issue is that from time to time, calls will not have audio. Here is what I have found: - when Client A sends INVITE, Asterisk NIC 1 will reply SIP 183 with SDP IP Address set to the internal IP of NIC 1 (192.168.0.2) - when Asterisk forwards call to Client B public IP address the SDP IP address is 192.168.1.2 (NIC 2) And I think the issue is the SDP address is wrong: when Asterisk forwards call to Client B, the SDP address should be the public IP 4.3.2.1 but it sends 192.168.1.2. And when Asterisk replies to Kamailio the SDP is 192.168.0.1. Correct me if I am wrong but i think the solution should be: - when Kamailio receives a reply from Asterisk to be forwarded to Client A, it should modify the SDP address to public IP 1.2.3.4 - when Asterisk forwards call to Client B, the sip.conf should have the parameter externip set to the public IP 4.3.2.1 Questions: - are my analysis & solution correct? - is there an example of the above setup where I could get some ideas? - how do I set Kamailio to modify the SDP address for me? Any examples? Thanks in advance. *Sérgio Charrua*

2 1

kamailio.org server maintenance - Dec 14, 2022 (tomorrow)
by Daniel-Constantin Mierla 15 Dec '22

15 Dec '22

Hello, not that tomorrow, Dec 14, 2022 starting after 09:00UTC (10:00Berlin), is planned some maintenance work on kamailio.org server. It will be unavailable from time to time, hopefully not for long time. Affected services: - web site - mailing lists - wiki site (alternative use the github repo: https://github.com/kamailio/kamailio-wiki) - html version of modules' documentation (text variant README is every module folder of git clones or on github.org repository) Short notifications will be sent when it starts and ends. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 2

Failover - how does it work?
by Jawaid Bazyar 15 Dec '22

15 Dec '22

I have the following basic script: request_route{ record_route(); $var(enumres) = enum_query(); switch( $var(enumres) ) { case -1: xlog("enum_query lookup failure - To URI $tU"); sl_reply("503", "Temporary lookup failure"); return(0); case 1: break; # uri replaced } xlog("INVITE ENUM query - To URI $tU"); t_relay(); I have the following ENUM records for a test setup: ;; ANSWER SECTION: x.x.x.1.5.1.8.3.0.3.1.e164.arpa. 60 IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:+13038151xxx@10.20.20.198!" . x.x.x.1.5.1.8.3.0.3.1.e164.arpa. 60 IN NAPTR 110 10 "U" "E2U+sip" "!^.*$!sip:+13038151xxx@10.20.20.75!" . What happens is the following: tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes 17:57:19.961041 IP (tos 0x10, ttl 64, id 59648, offset 0, flags [none], proto UDP (17), length 1481) 10.20.20.40.5060 > 10.20.20.198.5060: SIP, length: 1453 INVITE sip:+13038151xxx@10.20.20.198 SIP/2.0 … 17:57:19.961058 IP (tos 0x10, ttl 64, id 24143, offset 0, flags [none], proto UDP (17), length 1480) 10.20.20.40.5060 > 10.20.20.75.5060: SIP, length: 1452 INVITE sip:+13038151xxx@10.20.20.75 SIP/2.0 … These basically go out at the same time. Eventually I get a ICMP Port Unreachable on the .198 one because that’s a dummy I just set up for testing. My question is, with this kind of setup, is there a way to tell Kamailio to respect the NAPTR order value (note, 100, 110 above) and only try the 2nd route if the first fails? Thanks, Jawaid

2 5

testing mailing list
by Daniel-Constantin Mierla 14 Dec '22

14 Dec '22

after mailing list service upgrade - ignore!! -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

None
by None 14 Dec '22

14 Dec '22

ACK messages SER keeps sending the 487 Request cancelled message as if the ACK didn't match. Any suggestion of what it can be? I'm using as the endpoint an ATA186, v2.15, and ser version 0.8.11. Best Regards, Alejandro _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ------=_NextPart_000_0009_01C322CD.41C9F360 Content-Type: text/plain; name="remote.ata.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="remote.ata.txt" interface: eth0 (200.75.73.0/255.255.255.0) filter: ip and ( port 5060 ) # U 200.75.73.22:5060 -> 200.75.91.137:5060 INVITE sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..M ax-Forwards: 10..Record-Route: <sip:2001@200.75.73.22;branch=0>..Via: SIP/2.0/UDP 200.75.73.22;branch=z9hG4bK6258.c171e2f6.0..Via: SIP/2.0/U DP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=9 28411572..To: <sip:2001@vozsobreip.biz;user=phone>..Call-ID: 329755117 1@192.168.0.15..CSeq: 1 INVITE..Contact: <sip:1010@200.75.73.22:5061;u ser=phone;transport=udp>..User-Agent: Cisco ATA 186 v2.15 ata18x (030 122a)..Expires: 300..Content-Length: 245..Content-Type: application/sd p....v=0..o=1010 8066 8066 IN IP4 192.168.0.15..s=ATA186 Call..c=IN IP 4 200.75.73.22..t=0 0..m=audio 20002 RTP/AVP 4 8 0 101..a=rtpmap:4 G72 3/8000/1..a=rtpmap:8 PCMA/8000/1..a=rtpmap:0 PCMU/8000/1..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. # U 200.75.91.137:5060 -> 200.75.73.22:5060 SIP/2.0 100 Trying..Via: SIP/2.0/UDP 200.75.73.22;branch=z9hG4bK6258.c 171e2f6.0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobr eip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=p hone>;tag=3742565922..Call-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE ..Server: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.91.137:5060 -> 200.75.73.22:5060 SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 200.75.73.22;branch=z9hG4bK6258. c171e2f6.0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsob reip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user= phone>;tag=3742565922..Call-ID: 3297551171@192.168.0.15..CSeq: 1 INVIT E..Server: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . # U 200.75.73.22:5060 -> 200.75.91.137:5060 CANCEL sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..M ax-Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=z9hG4bK6258.c171 e2f6.0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip .biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phon e>..Call-ID: 3297551171@192.168.0.15..CSeq: 1 CANCEL..User-Agent: Cisc o ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Max- Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928 411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360 b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..U ser-Agent: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . # U 200.75.91.137:5060 -> 200.75.73.22:5060 SIP/2.0 200 OK..Via: SIP/2.0/UDP 200.75.73.22;branch=z9hG4bK6258.c171e 2f6.0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip. biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone >;tag=3742565922..Call-ID: 3297551171@192.168.0.15..CSeq: 1 CANCEL..Se rver: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.91.137:5060 -> 200.75.73.22:5060 SIP/2.0 487 Request Cancelled..Via: SIP/2.0/UDP 200.75.73.22;branch=z9 hG4bK6258.c171e2f6.0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1 010(a)vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip .biz;user=phone>;tag=3742565922..Call-ID: 3297551171@192.168.0.15..CSe q: 1 INVITE..Server: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Le ngth: 0.... # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Via: SIP/2.0/UDP 200.75.73.22;branch=z9hG4bK6258.c171e2f6.0..From: <sip:10 10(a)vozsobreip.biz;user=phone>;tag=928411572..Call-ID: 3297551171(a)192.1 68.0.15..To: <sip:2001@vozsobreip.biz;user=phone>;tag=3742565922..CSeq : 1 ACK..User-Agent: Sip EXpress router(0.8.10 (i386/linux))..Content- Length: 0.... # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Max- Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928 411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360 b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..U ser-Agent: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Max- Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928 411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360 b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..U ser-Agent: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Max- Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928 411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360 b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..U ser-Agent: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Max- Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928 411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360 b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..U ser-Agent: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Max- Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928 411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360 b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..U ser-Agent: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Max- Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928 411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360 b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..U ser-Agent: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . # U 200.75.73.22:5060 -> 200.75.91.137:5060 ACK sip:2001@200.75.91.137:5060;user=phone;transport=udp SIP/2.0..Max- Forwards: 10..Via: SIP/2.0/UDP 200.75.73.22;branch=0..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928 411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360 b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..U ser-Agent: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0... . exit ------=_NextPart_000_0009_01C322CD.41C9F360 Content-Type: text/plain; name="local.ata.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="local.ata.txt" interface: eth1 (192.168.0.0/255.255.255.0) filter: ip and ( port 5060 ) # U 192.168.0.15:5061 -> 200.75.73.22:5060 INVITE sip:2001@vozsobreip.biz;user=phone SIP/2.0..Via: SIP/2.0/UDP 19 2.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411 572..To: <sip:2001@vozsobreip.biz;user=phone>..Call-ID: 3297551171@192 .168.0.15..CSeq: 1 INVITE..Contact: <sip:1010@200.75.73.22:5061;user=p hone;transport=udp>..User-Agent: Cisco ATA 186 v2.15 ata18x (030122a) ..Expires: 300..Content-Length: 245..Content-Type: application/sdp.... v=0..o=1010 8066 8066 IN IP4 192.168.0.15..s=ATA186 Call..c=IN IP4 200 .75.73.22..t=0 0..m=audio 20002 RTP/AVP 4 8 0 101..a=rtpmap:4 G723/800 0/1..a=rtpmap:8 PCMA/8000/1..a=rtpmap:0 PCMU/8000/1..a=rtpmap:101 tele phone-event/8000..a=fmtp:101 0-15.. # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 1 92.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=92841 1572..To: <sip:2001@vozsobreip.biz;user=phone>..Call-ID: 3297551171@19 2.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress router (0.8.10 (i386/l inux))..Content-Length: 0..Warning: 392 200.75.73.22:5060 "Noisy feedb ack tells: pid=32747 req_src_ip=192.168.0.15 in_uri=sip:2001@vozsobrei p.biz;user=phone out_uri=sip:2001@200.75.91.137:5060;user=phone;transp ort=udp via_cnt==1".... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip:10 10(a)vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip. biz;user=phone>;tag=3742565922..Call-ID: 3297551171@192.168.0.15..CSeq : 1 INVITE..Server: Cisco ATA 186 v2.15 ata18x (030122a)..Content-Len gth: 0.... # U 192.168.0.15:5061 -> 200.75.73.22:5060 CANCEL sip:2001@vozsobreip.biz;user=phone SIP/2.0..Via: SIP/2.0/UDP 19 2.168.0.15:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411 572..To: <sip:2001@vozsobreip.biz;user=phone>..Call-ID: 3297551171@192 .168.0.15..CSeq: 1 CANCEL..User-Agent: Cisco ATA 186 v2.15 ata18x (03 0122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 200 cancelling..Via: SIP/2.0/UDP 192.168.0.15:5061..From: <sip :1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobre ip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 CANCEL..Server: Sip EXpress router ( 0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73.22:506 0 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_uri=sip: 2001(a)vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5060;use r=phone;transport=udp via_cnt==1".... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 487 Request cancelled..Via: SIP/2.0/UDP 192.168.0.15:5061..Fro m: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@v ozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..C all-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress r outer (0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73 .22:5060 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_u ri=sip:2001@vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5 060;user=phone;transport=udp via_cnt==1".... # U 192.168.0.15:5061 -> 200.75.73.22:5060 ACK sip:2001@vozsobreip.biz:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.1 5:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e50 79b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..User-Agent: C isco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 487 Request cancelled..Via: SIP/2.0/UDP 192.168.0.15:5061..Fro m: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@v ozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..C all-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress r outer (0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73 .22:5060 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_u ri=sip:2001@vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5 060;user=phone;transport=udp via_cnt==1".... # U 192.168.0.15:5061 -> 200.75.73.22:5060 ACK sip:2001@vozsobreip.biz:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.1 5:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e50 79b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..User-Agent: C isco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 487 Request cancelled..Via: SIP/2.0/UDP 192.168.0.15:5061..Fro m: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@v ozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..C all-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress r outer (0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73 .22:5060 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_u ri=sip:2001@vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5 060;user=phone;transport=udp via_cnt==1".... # U 192.168.0.15:5061 -> 200.75.73.22:5060 ACK sip:2001@vozsobreip.biz:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.1 5:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e50 79b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..User-Agent: C isco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 487 Request cancelled..Via: SIP/2.0/UDP 192.168.0.15:5061..Fro m: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@v ozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..C all-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress r outer (0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73 .22:5060 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_u ri=sip:2001@vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5 060;user=phone;transport=udp via_cnt==1".... # U 192.168.0.15:5061 -> 200.75.73.22:5060 ACK sip:2001@vozsobreip.biz:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.1 5:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e50 79b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..User-Agent: C isco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 487 Request cancelled..Via: SIP/2.0/UDP 192.168.0.15:5061..Fro m: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@v ozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..C all-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress r outer (0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73 .22:5060 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_u ri=sip:2001@vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5 060;user=phone;transport=udp via_cnt==1".... # U 192.168.0.15:5061 -> 200.75.73.22:5060 ACK sip:2001@vozsobreip.biz:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.1 5:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e50 79b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..User-Agent: C isco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 487 Request cancelled..Via: SIP/2.0/UDP 192.168.0.15:5061..Fro m: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@v ozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..C all-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress r outer (0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73 .22:5060 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_u ri=sip:2001@vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5 060;user=phone;transport=udp via_cnt==1".... # U 192.168.0.15:5061 -> 200.75.73.22:5060 ACK sip:2001@vozsobreip.biz:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.1 5:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e50 79b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..User-Agent: C isco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 487 Request cancelled..Via: SIP/2.0/UDP 192.168.0.15:5061..Fro m: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@v ozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..C all-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress r outer (0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73 .22:5060 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_u ri=sip:2001@vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5 060;user=phone;transport=udp via_cnt==1".... # U 192.168.0.15:5061 -> 200.75.73.22:5060 ACK sip:2001@vozsobreip.biz:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.1 5:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e50 79b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..User-Agent: C isco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... # U 200.75.73.22:5060 -> 192.168.0.15:5061 SIP/2.0 487 Request cancelled..Via: SIP/2.0/UDP 192.168.0.15:5061..Fro m: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@v ozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e5079b-f4f8..C all-ID: 3297551171@192.168.0.15..CSeq: 1 INVITE..Server: Sip EXpress r outer (0.8.10 (i386/linux))..Content-Length: 0..Warning: 392 200.75.73 .22:5060 "Noisy feedback tells: pid=32746 req_src_ip=192.168.0.15 in_u ri=sip:2001@vozsobreip.biz;user=phone out_uri=sip:2001@200.75.91.137:5 060;user=phone;transport=udp via_cnt==1".... # U 192.168.0.15:5061 -> 200.75.73.22:5060 ACK sip:2001@vozsobreip.biz:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.1 5:5061..From: <sip:1010@vozsobreip.biz;user=phone>;tag=928411572..To: <sip:2001@vozsobreip.biz;user=phone>;tag=0a96755a1d32d0360b3e454593e50 79b-f4f8..Call-ID: 3297551171@192.168.0.15..CSeq: 1 ACK..User-Agent: C isco ATA 186 v2.15 ata18x (030122a)..Content-Length: 0.... exit ------=_NextPart_000_0009_01C322CD.41C9F360--

1 0

None
by None 14 Dec '22

14 Dec '22

ACK messages SER keeps sending the 487 Request cancelled message as if the ACK didn't match. Any suggestion of what it can be? I'm using as the endpoint an ATA186, v2.15, and ser version 0.8.11. Best Regards, Alejandro

1 0

None
by None 14 Dec '22

14 Dec '22

/bin/sh -c 'cd /usr/local/mysql ; ./bin/safe_mysqld --user=mysql &' Gary Goodloff KALG Communications, LTD T: 402-898-4152 C: 402-208-5183 F: 413-294-3404 -----Original Message----- From: serusers-admin(a)iptel.org [mailto:serusers-admin@lists.iptel.org] On Behalf Of Todd Sent: Wednesday, May 21, 2003 5:05 PM To: Sip Questions List Subject: [Serusers] Mysql Connection Errors Ok..I have setup SER according to the guide on the iptel site. Here is a copy of what's in my ser.cfg _________________________________________ # # $Id: ser.cfg,v 1.12 2002/10/21 02:40:06 jiri Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/ser_fifo" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database loadmodule "//usr/lib/ser/modules/mysql.so" loadmodule "//usr/lib/ser/modules/sl.so" loadmodule "//usr/lib/ser/modules/tm.so" loadmodule "//usr/lib/ser/modules/rr.so" loadmodule "//usr/lib/ser/modules/maxfwd.so" loadmodule "//usr/lib/ser/modules/usrloc.so" loadmodule "//usr/lib/ser/modules/registrar.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "//usr/lib/ser/modules/auth.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- #modparam("usrloc", "db_mode", 0) # Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2) # -- auth params -- # Uncomment if you are using auth module # #modparam("auth", "secret", "alsdkhglaksdhfkloiwr") modparam("auth", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # modparam("auth", "password_column", "password") # ------------------------- request routing logic ------------------- # main routing logic route{ # initial sanity checks -- messages with # max_forwars==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) { sl_send_reply("513", "Message too big"); break; }; # Do strict routing if pre-loaded route headers present rewriteFromRoute(); # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri=~"computergeeks.hopto.org") { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication if (!www_authorize("computergeeks.hopto.org", "subscriber")) { www_challenge("computergeeks.hopto.org", "0"); break; }; save("location"); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; # forward to current uri now if (!t_relay()) { sl_reply_error(); }; } _________________________________________________ The modules are all where they say they are but when I try to start SER I get this in my messages log file May 21 18:58:45 computergeeks ser: ser startup succeeded May 21 18:58:45 computergeeks /usr/sbin/ser[13089]: connect_db(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) May 21 18:58:45 computergeeks /usr/sbin/ser[13089]: db_init(): Error while trying to connect database May 21 18:58:45 computergeeks /usr/sbin/ser[13089]: mod_init(): Error while connecting database May 21 18:58:45 computergeeks /usr/sbin/ser[13089]: init_modules(): Error while initializing module usrloc Can someone please tell me what I'm doing wrong? I've searched all over the net for information on this...I'm sure it's something simple..but I'm overlooking it. If I disable the Mysql integration is works perfect, so I'm thinking it has something to do with the mysql.so module?!? Thanks Todd ------=_NextPart_000_00B1_01C31FBD.C81364A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DProgId content=3DWord.Document> <meta name=3DGenerator content=3D"Microsoft Word 10"> <meta name=3DOriginator content=3D"Microsoft Word 10"> <link rel=3DFile-List href=3D"cid:filelist.xml@01C31FBD.C730CCD0">  <style>  </style>  </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple = style=3D'tab-interval:.5in'> <div class=3DSection1> Those SQL = Errors:<o:p></o:p> <o:p> </o:p> May 21 18:58:45 computergeeks ser: ser startup succeeded May 21 18:58:45 = computergeeks /usr/sbin/ser[13089]: connect_db(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) May 21 18:58:45 = computergeeks /usr/sbin/ser[13089]: db_init(): Error while trying to connect = database May 21 18:58:45 = computergeeks /usr/sbin/ser[13089]: mod_init(): Error while connecting = database May 21 18:58:45 = computergeeks /usr/sbin/ser[13089]: init_modules(): Error while initializing = module usrloc<o:p></o:p> <o:p> </o:p><= /p> This means that the mysql daemon is either not running or is not running on the default = port.<o:p></o:p> <o:p> </o:p><= /p> On freebsd – this is how I start my sql daemon:<o:p></o:p> From /etc/rc.local<o:p></o:p> /bin/sh = -c 'cd /usr/local/mysql ; ./bin/safe_mysqld = --user=3Dmysql &'<o:p></o:p> <o:p> </o:p> <div> Gary Goodloff KALG Communications, LTD T: 402-898-4152 C: 402-208-5183 F: 413-294-3404 <o:p></o:p> </div> -----Original = Message----- From: = serusers-admin(a)lists.iptel.org [mailto:serusers-admin@lists.iptel.org] On = Behalf Of Todd Sent: Wednesday, May 21, = 2003 5:05 PM To: Sip Questions = List Subject: [Serusers] Mysql Connection Errors <o:p> </o:p> Ok..I have setup SER according to the guide on the iptel site. Here is a copy of what's in my ser.cfg _________________________________________ # # $Id: ser.cfg,v 1.12 = 2002/10/21 02:40:06 jiri Exp $ # # simple quick-start = config script # # ----------- global = configuration parameters ------------------------ debug=3D3       &= nbsp;  # debug level (cmd line: -dddddddddd) fork=3Dyes = log_stderror=3Dno # (cmd = line: -E) check_via=3Dno # (cmd. = line: -v) dns=3Dno       &n= bsp;   # (cmd. line: -r) rev_dns=3Dno      # (cmd. line: -R) port=3D5060 = children=3D4 = fifo=3D"/tmp/ser_fifo" # ------------------ = module loading ---------------------------------- # Uncomment this if you = want to use SQL database loadmodule "//usr/lib/ser/modules/mysql.so" loadmodule "//usr/lib/ser/modules/sl.so" loadmodule "//usr/lib/ser/modules/tm.so" loadmodule "//usr/lib/ser/modules/rr.so" loadmodule "//usr/lib/ser/modules/maxfwd.so" loadmodule "//usr/lib/ser/modules/usrloc.so" loadmodule "//usr/lib/ser/modules/registrar.so" # Uncomment this if you = want digest authentication # mysql.so must be loaded = ! loadmodule "//usr/lib/ser/modules/auth.so" # ----------------- = setting module-specific parameters --------------- # -- usrloc params = -- #modparam("usrloc", "db_mode",   0) # Uncomment this if you = want to use SQL database # for persistent storage = and comment the previous line modparam("usrloc", "db_mode", 2) # -- auth params = -- # Uncomment if you are = using auth module # #modparam("auth", "secret", "alsdkhglaksdhfkloiwr") modparam("auth", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), = # uncomment also the = following parameter) # modparam("auth", "password_column", "password") # = -------------------------  request routing logic ------------------- # main routing = logic route{ # initial sanity checks -- = messages with # max_forwars=3D=3D0, or = excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) = { sl_send_reply("513", "Message too big"); break; }; # Do strict routing if = pre-loaded route headers present rewriteFromRoute(); # if the request is for = other domain use UsrLoc # (in case, it does not = work, use the following command # with proper names and = addresses in it) if (uri=3D~"computergeeks.hopto.org") { if = (method=3D=3D"REGISTER") { # Uncomment this if you = want to use digest authentication if (!www_authorize("computergeeks.hopto.org", = "subscriber")) { www_challenge("computergeeks.hopto.org", "0"); break; }; save("location"); break; }; # native SIP destinations = are handled using our USRLOC DB if = (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; # forward to current uri = now if (!t_relay()) = { sl_reply_error(); }; } _________________________________________________ The modules are all where they say they are but when I try to start SER = I get this in my messages log file May 21 18:58:45 = computergeeks ser: ser startup succeeded May 21 18:58:45 = computergeeks /usr/sbin/ser[13089]: connect_db(): Can't connect to local MySQL server = through socket '/var/lib/mysql/mysql.sock' (2) May 21 18:58:45 = computergeeks /usr/sbin/ser[13089]: db_init(): Error while trying to connect = database May 21 18:58:45 = computergeeks /usr/sbin/ser[13089]: mod_init(): Error while connecting = database May 21 18:58:45 = computergeeks /usr/sbin/ser[13089]: init_modules(): Error while initializing module = usrloc Can someone please tell me what I'm doing wrong?  I've searched all = over the net for information on this...I'm sure it's something simple..but = I'm overlooking it. If I disable the Mysql integration is works perfect, so I'm thinking it = has something to do with the mysql.so module?!? Thanks Todd <o:p></o:p> </div> </body> </html> ------=_NextPart_000_00B1_01C31FBD.C81364A0--

1 0

None
by None 14 Dec '22

14 Dec '22

stream, for such cases, is it possible? Any pointers would be great. -- Michael Vasilenko

1 0

None
by None 14 Dec '22

14 Dec '22

fgets failed: Illegal seek. It happens when 2 end points try to set up a session and one of them cancels it before any end-to-end connection is established. Has anyone found this problem before? (See attached file: cancelsegdump.tar.gz) Jaime --0__=PnXC9kr0ykdwrnb6uT2PR1PNFM05c9HrUcAPjHVL7TjiDE1fTDc3v998 Content-type: application/octet-stream; name="cancelsegdump.tar.gz" Content-Disposition: attachment; filename="cancelsegdump.tar.gz" Content-transfer-encoding: base64 H4sIAAseXj4AA+0da3PaSDKfqcp/mMuHjX0HRKM32Lg2cew912adLezsfkilVIM0Aq2FRPSI7b3a /e3XM5KwhAQIG5LYqykbBOrumenp6ackTOKZ1A3p2Iqns250Ez3bfhOwIKiy/ExIWvEdCyLGyjNB U0VNxqqkSAAvYVl5hoQdjKXU4jAiAULPAt9fOfd15x9pQ8IeliRR3keuTyzHG6Opb8UuRd1XyUH4 anobfnaT127ot2pghC781YSdBY4XJa81MaIp/NWEjcPA9c30rSZOEMBfXVg6dsIoIMHdUU1MEkcT /lJ31vQm8mfz95pY9Iaa/KU2fMT+a0Lb5oz9F6Ftx7OMGQnI1KA3Mz+I+sj2Y89Ch9bIAEx6hBwv o5UsDPq4fMU+1SIdOVMaGCBDNPhC3F30AIOPg69EmYlFnm5eVko0F6iBDDpmZAR+HBU4HQR5ipmM r6VGvhSpZFJeIFa5CdaRdn3/Kp7tiHjoGiGFrwM6c2/zfcCJ9OhjWV+towpspS4p0IumeUKZaqox PD4ygwaBH9xrfGyB2aaMyAiAhX7uFIIdTAOPZKQMk7juXm5ExiwKDoUbWRAUiyjC0d2p/QN098Gx UQ5rSqOJb919Hgzujl8MT346u7g8Gb7IkUL/u8+QsNjT7PyQ2ugF7CYSOb73YslArcCf5YhFtzN6 uHRWfyHm7+QH91f+NN84OWK4Yc7mzKkLt1SecV6ei6w+f3+5h+7HPN3UN2TejqnvP1giBFnTtIVu ZUF+Ufji3I/QKdM8X0NGtrVaWCuK+n3XZTWd7awAWdpBw9nHwNmcsvn99fD87PynPoomFE0JWGZu qRf0kxMiOp1Ft605uOeDcQ+umB2neXpvT958gNOO50Rswn3EA6kWf0Ud/r1DXOdPoL0Ka+4XtCBe jSh4BeFa7MRhAr/YdmzfMKdAxqPXyPSnUwJeyB5zkoBYuD+HpFaZyi9vFQRLZMYu9AskdF0eybKs WKomSpaiYtNSsCjII6rrKu7hVbPgYR50agEzW/zDBiyIprmzl78sYHa73c05EBkxMQ3LHa9mwXoy ExJOVtMAW3BlzAdMky/uZsDtBGK5iOh+I1i1ksev3707e7vQWR8pljgSbAntudQb6PslBGEgpCDr pULs2VhUZL0nyqps2aIiyRbGPcvSpNFIF/X1FCRZ7umarPQI0BJFVZAUSkmvJ5o6ljFRV4lGEnFt zra41g6oQSWYboGEYfpeRMzowaRYLu/BRGw3XifTNagQy3owjXDiX6/hTVWQ9TcLrENqcI2dj7ES 3ftxWYZrXfDG6DLR2zJJ0/XDbQ/zc0yD2y3TDMj1TujaAaU7Iex4IQ22vVoWmOBo28sVzyxyb6IA wcVyb7+P3hIQegIOD+waj5rctvgz6lELhbFpgvNgx+7tKo0aBK0hNf3AQkMWy21gpudpmm+Sovmb adJMpcSWzzy4BybtKnpIRMqIA86i7dNPpGt39Md0h4Pnns7OWB97u6UfAOth5+yOPZnspAZtd8Kz sw649OyMeqIEt9BBSTOxDHrjMzQ+Q+Mz7NYulyP3pGbZSt83cCZY6bLFXjbAsc1ZC/6XY1RXo4hl RNOHl3bmzkc0NUcPJ5eWnIzI3xqtbRBK0ybbGdOCnD2IkHHtRBNj5FtbIemEzJspFpTvS4tZTXCL vdBwLOpF2yCZlFC3R8/2g2sSWIbne8S8qklRYNRuWGq0XF5G+Wr0UuDKCi9ipecUJYxHU9jdXNGz 8CYERWpG4A7QoJ26CW2YjBPQsP25zfLJjtU2Q/oZ2YE/RVkZBm04goS9y5AyzYcKCnMZdMYylG7C OlRzJeIU/Oz89H0fxdaMOxN9dPHeGB7/9ubDKUtIp9rOvUWqokhKipKqxzucKLhlXc5R+whLWNCE InxIo6gAdsC+GiSg7S80cOzbQRXiqo5EVcRyvY4S0FUdlRDRhIQsDU9tG6Rjk+lLGOs1p89AHz6q lesIe5OvYkYe802rspx3n0fxXPuydFnykXXHPvEM+Bw4HQ87gUD0Zq/CNMeWJgLavFIxkCWYuciR tGxcHGoW+CxPkKSkoQvOJ1HLAS8YXsOcOK6F9sT9JFW/CJdsSyOMbRD6Purwsz/intjFqt5Vu1iR 6hHPkr11YIOgDFdKPGNLUmVRo6Rnij3J1LAqE1EaCRLVqKXJ9XpKgos6kOAE1QNkjsxSPycDFPYX KiMr2C0vsrsO8RK7L06GJTnkIgMSBjsDxTNEoqLMVRZnqjoLgjLc5utVp6eFYHAFJF+vOoDF9bo4 +xUNKdisMCpcnJNcKtJH6DC7LuQofzoOHDgH7TB0Zn0CHKR/0K4PjsOYdk2/G18VwIHhIS/mHEJ/ r8SukD87IwHEshNKLICC8blkHA7yBTowW8i3UQKBAkrMCdMMvMQ4UJZT+s0hidfQriC6ABtNmG0K eT3VdoIwQl8ckgN/bYO3nCJNw4U63gxsIAl43dVHQezNy7ChGTizKFyArpqvqKh1Z9wrrzPz2iYW k2LqwqIdXoIf/lGSPx2whRp8ZGv0B3Gm9MeqlfpUUQiGeTDvFH08XI179LyVd9gWxsGdm8PjC/r5 CAaFj6qFaWEOvN8+ywlH4DAaLvXG0WQg5N1C7gkWeLToNPIlTBw65oqd+2mCOOV6QiKHlPcAGcLl BObK5MHLMP97um4JO3nxGsWw4bJyEKN4DKsIigEdJ18BvX523E92EdbEroi7oPc0vY9VTZeODj4P hK4gHKRu4wCLgvC8tdFAQHLMK1bgAvxwL99HGxU/CfnaakBN6nzhsg5r4VLCDXi8meq4+PDm4nh4 9uZkhe6YkuCqWrQaBfKtFYiUVyBLF2q9/li+xhuqj0qBeoT6I4nZGOBLxpuXiF37lgwLotnSdQJP Y5eHzTb/Pre5vLjNq1eq3j5fssrNRufMefo7fUZnS1zFZqN/641esOdLF2r9Pl++xv/QbR5cB04C OKTskC11upU6H4ZniKX70cs56wqevqQIgvCyguVskzu2R6/7CAQMOdZARm00dv0RcbNvBPjmEvke zJ5l7U06EG7stG2kVioh1DyX54n8INURSdINhZQE5oTn3tj1pQNVkQW5Dbx6ffxzYZnSefGUHbXS zQE7pTM8PZZEFSNedyDJdUBTEnGiVXxZHAesSR51cS1TvOmVAV3f3PaR5bPO355fpOp5Ie/zJs1L jYh5xS/YRhJMx0ISY/LCFX3r2XZPfZ0OGvCMyDci4riGbxv8BsKP8qc+Em5kURwRXa7gcCWSkENS 8he68kQZu5ixwMNr62VhorXtB7sKHe0xxRSH+/3aOh8lGMzKYKF4BrRdyNBAi/Gs+PZMxRNTnPzm GcTv3kzkVpTENjocMcUwOUIDdPhnb/KTPPrZ1Gy7q2Msi5rK1uEg5QeubXK+ByOb7KyQujbqJB+Y SDowZD+MBgMmTFgaDLCEfvgBoY+FpPIndu/bwlcFi5KUGHltKys9zouMbRhRGLLOkpsuYI2diuRr ZPBBzbW3kulurskvE/W5gb7GWlUfSfktU5eJDkZcByOXjKiLVFkRRNzTVJQIAqrQGGUyycz4Z2qh vctBqjs0Qd//12ZzVWCuIEw5ClX4vpdx2w/G3VQdoJiEA6ENbyYoMLB2vM4N705oON4XsLmDgtbs HGUNXRomqxwBMui25BgUS7nn5MKFtOuEQwyJ1XXZOz9dNJWrtKy2TDU3+bTG/27yaU0+rcmnPf1t 3uTTmnxak0/7B2z0xxEWPsJt/pXyaXopn6b88/Jpnu91gHQW69VJuJWybQsB4mI2jYWXHIddH5uG Wp4fTbINPT/ZKNhGwTYK9uko2F5JweqNgm0UbKNgGwXbKNhtKFgslDRsr9Gw372GXbz/hRcPUpVA +1o7cgd3VQTk0ZtosOc57n4Zc95xyLSnMSGe5QIpdoLPFN7ZbV+s470oN8E2mu80BLoH5UmvrqIo gpQfRrlarvBquXxXLS+PuUbJJX9L0VJZnUNslsWZo2XPRfvyeQrjCfkTr5J3dv8Tm1b1+Pmj1tgw qdVFo9gGxupCz1YVvY9S84UUYCtMajKl05TvIwnnz6/mosC5iCuuOchuneG3dLjUjkoWu6nBfzNT 1dTgv+saPMa5wjQYz6ddhS/OFj+wDg+Kf16Jh+PNa/GcwNOpxp+d/3Z2uSrwWXHb1PYin1q+MRZr 6+MKoajWx+IW7i5bjbqhPi6vx3pl/PoYK7Isn+j6Gz35vY9TqXeqvVV6x1oHS/9+rHp56+HmY4qo yjfS1QymxFIwBUrzu4umdE36ni6vnV8/muy/jZhyz+JrPbe9bFuYMYVoKEIgXXm/3ZZyfjku+e2m kPfbK5TvPCKEfeCElRHoN7r6OO39jNvnLrpIn/vAHjzEoFnk9/DlqHet8kg1N79WeaRa/5xrlWvH Dj1V6gpUtrUeVprQ4WuFDlLemRYfGjo8At9Eq7fyIQVv01pY+tz25nMEFDIeCLhn2kQxOzKR9A7G ltbpgbXqwNxUZSSbGJujulMR62YONGnnnuoD/dRKaal4QsiSOBMcgjTKxJKq97CERWEbYeZI0euF mYWdIRXCTEZjszATVOrKC77x6iCTo3/NIBMvM1Zf0wzpy8zQEPps7NCTskPy4m5r7FBjhxo7tLgz 5C3aITh+sCXS72uJ8njIdy2UBLxST+Pks49SfvMljx+CMM5gz5Y0QGrYB5YXnDk0o+AHzrivi5xK H4mYdcgCfgkrjKWD1jzk1QWUGpLnLdif82D41Ye3v6Jy7fogncpazfG8dQrD66OVdZkDtmM7mt7r abqiAM6ln2As3wcHdTf589YxxNqds7d9pMuioEuiJohgzVQ40gtVeYCEvQO2IM1zPG99gI47r8cQ lvfR745n+dchGl4ev8JdGONxkoDtvOMJWPAQnrcKD25aV0q8f0pik1Ji7QTCjjyfVen149fnxyfv vnV6/YnmysvMfQR+wGPJlT/py5XunVxXysl1uUmu13t2RYb3Hiw2e+7uZf9u4Ix/3P1iTLxlTlgt fJPx2wVfoOJKqLzbVaWSFqmx38GasV8NKAz9ET1Hw1RrGz0hh6RVGAAqst+KZLzlxymfc5LzHRZI Nq2n1HAx5s/hPRkO3w+TR+8a6aN3bdCMoLGArexBuWdAfQxKIaT06hHiJQ+jDp0xbAQESi71ffIs +IVOfdiZaWyxN7sasyzP/DQwPTvFfT+qm0IBgCn5GffZBwgLsorF/NOw2QPmLXZCBylgx//xYfBM qAaShsGGs58fgWBEFmVml+/wpuSGw6O9Ocb+AEmanH+WNPuRPqZkYLXZv29eMT/VDsh4CmsdFobJ m9BF5wilEps6s6Kso2T8klhCwFUI2goEsQqBZAhyTy1hyBUYsrm8C1w1CVWp7iLjEGMzch3wPfiP NaI8a7hpSeY6Zx2o/m7izYoVkGJtSLUmJJa0Skicg+ysaq137CdDvNTktFChFXJgiymxfl8RQMG+ dh1wXUHRpQ4s/xZVebPJmVb6S0ppxmzhl1LOch/ufs4tBW6xB2cvQXzWtKY1rWlNa1rTmta0pjWt aU1rWtOa1rSmNa1pTWta05rWtG/d/g/YEn7NAKAAAA== --0__=PnXC9kr0ykdwrnb6uT2PR1PNFM05c9HrUcAPjHVL7TjiDE1fTDc3v998-- ------<80256CDA.004DFAC0.00@ruddick> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* ------<80256CDA.004DFAC0.00@ruddick>

1 0

None
by None 14 Dec '22

14 Dec '22

Please give me an example of their interaction. Could I use B2BUA without SER(and without any SIP proxy)? Thanks Igor Vasiliev >

1 0

Re: [SR-Users] sr-users Digest, Vol 211, Issue 8
by Pooja Yadav 13 Dec '22

13 Dec '22

Hi Daniel and Everyone, Thanks for the inputs. We understand that Kamailio is a SIP signalling server irrespective of any core. But we have seen a thread in Open5Gs community where they established the call with Kamailio IMS. Below thread is for your reference. https://open5gs.org/open5gs/docs/tutorial/02-VoLTE-setup/ If you have any inputs on this it is most welcome. We just want to check the feasibility of establishing voice/video call with 5G core. Your inputs will be appreciated. Thanks and regards Pooja Yadav > On 09-Dec-2022, at 4:33 PM, sr-users-request(a)lists.kamailio.org wrote: >

2 1

Delays sending over WSS
by Alex Balashov 12 Dec '22

12 Dec '22

Hi, I’ve run into stubbornly persistent problems with packets not reaching WSS clients until some seconds (5-6s or more!) after they were supposedly sent. The symptom is that Kamailio logs the event as sent at 20:00:00, including in the onsend_route, but in actual reality it takes quite a bit longer to send at the OS network stack level. This happens occasionally and quite universally, with no discernible pattern tied to particular endpoints, networks, etc. For a long time, I’ve just assumed this was a receive delay, since Kamailio logged an expectedly prompt relay time. I figured it was an application or browser execution delay and had nothing to do with networking. Based on what we know about the capriciousness of browsers and their internal task scheduling, this seemed rather plausible. However, I’ve since been able to ascertain that this is not the right understanding of the problem, because a parallel and unrelated WS keepalive, going from a different backend to the same application/browser tab/event loop, is consistently replied to in a timely manner. Anyway, I’m curious what else can be done to debug and/or fix this. I did turn up the size of my write buffers — tcp_wq_conn_max and the global one — quite a lot, some time ago and for unrelated reasons. I wonder if this might actually make the problem worse, since it leads to more bytes queued to send to an endpoint on the other side that could, conceivably, not be reading them fast enough. But I also wonder if this is tied up in some low-level TLS or WS parameters unrelated to more general TCP configuration. Thanks much! — Alex — Sent from mobile, apologies for brevity and errors.

2 2

Kamailio SIP client registration issue
by Shiva Shankar Chittallu 09 Dec '22

09 Dec '22

Hi Team, I have installed kamailio sip server 5.5.5 version in ubuntu 20.04 in AWS instance with public IP. When im trying to register an device im getting below error in the syslog. Thanks & Regards Shiva 9100663346

2 1

Does Kamailio supports Voice and Video call support for 5G Core
by Pooja Yadav 09 Dec '22

09 Dec '22

Hi Kamailio community, We just want to check does Kamailio IMS supports the functionality of Voice and Video call support (Vo5G) with 5G core? If yes, please share the document reference. Else, please guide us when it will be available. Any plans in upcoming release to support HTTP2 based SBI interface between P- CSCF and PCF. Your inputs will be highly appreciated. Thanks & Regards, Pooja Yadav

4 4

Next online devel meeting - Thu, Dec 8, 2022, 15:00UTC
by Daniel-Constantin Mierla 08 Dec '22

08 Dec '22

Hello, to summarize what happened at the devel meeting in Dusseldorf a few weeks ago and plan the next steps for the project, we are planning an online development meeting on Thu, Dec 8, 2022, 15:00UTC. As usual, one of the targets is to sketch the roadmap to next major release so the developers and community members can syncronize and plan what should be done till Kamailio v5.7 (or 6.0) will be out as well as discuss about current state of the project, look for new ideas to improve collaboration within the community, a.s.o. The meeting will be done on a matrix chat room. More details are in the wiki page of the event, available at: * https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings… Feel free to add there topics that you want to be discussed. The proposed date is Thursday, December 08, 2022, at 15:00UTC (15:00 London/Dublin, 16:00 most of West Europe, 10:00 New York), but other dates can be proposed if they suit for more participants. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

1 3

Outgoing SIP/TLS connection error (msg_send_buffer(): tcp_send failed)
by Denys Pozniak 08 Dec '22

08 Dec '22

Hello! We use trunk with Twilio through a SIP/TLS. They establish incoming calls from random ports, like: (Twilio)3.3.3.3:54321 --> (Kamailio)2.2.2.2:5061 In case of sending in-dialog requests to them, Kamailio should establish an outgoing connection to the dst port 5061 (as per Route), like: (Kamailio)2.2.2.2 --> (Twilio)3.3.3.3:5061 But as per tcpdump traces and logs, Kamailio does not even try to establish an outgoing connection to Twilio. There should be no problems with routes and the network on that server, as regular telnet to Twilio shows that 5061 is open. What could be the reason and how to debug? *Script:* onsend_route { xlog("L_ERR","[$cfg(route)]*RELAY ONSEND* $rm / $du / $fs / $fsn / [$ci]\n"); } *Syslog:* DEBUG <core> [core/resolve.c:1259]: srv_sip_resolvehost(): 3.3.3.3:5061 proto=3 DEBUG <core> [core/resolve.c:1371]: srv_sip_resolvehost(): returning 0x55acd63a63c0 (3.3.3.3:5061 proto=3) ERROR <script>: [DEFAULT_SEND]*RELAY ONSEND* REFER / sip:3.3.3.3:5061;transport=tls / tls:10.1.1.1:5061 / sip_wan_tls / [123] DEBUG tm [../../core/forward.h:277]: msg_send_buffer(): sending to: 3.3.3.3:5061, force_socket=4, send_sock=0x7f090049b8e8 DEBUG tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed DEBUG tm [t_fwd.c:1568]: t_send_branch(): send to 3.3.3.3:5061 (3) failed WARNING: tm [t_fwd.c:1588]: t_send_branch(): sending request on branch 0 failed DEBUG tm [t_funcs.c:335]: t_relay_to(): t_forward_nonack returned error -1 (-477) DEBUG tm [t_funcs.c:353]: t_relay_to(): -477 error reply generation delayed DEBUG sl [sl_funcs.c:558]: sl_run_callbacks(): execute callback for event type 1 *Software:* - Kamailio is listening on (+udp, +tcp): tls: 10.1.1.1:5061 name sip_wan_tls advertise 2.2.2.2:5061 - OS is Debian 11.5 - # kamailio -v version: kamailio 5.6.2 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 - # dpkg -l | grep ssl ii libssl1.1:amd64 1.1.1n-0+deb11u3 amd64 Secure Sockets Layer toolkit - shared libraries ii openssl 1.1.1n-0+deb11u3 amd64 Secure Sockets Layer toolkit - cryptographic utility -- BR, Denys Pozniak

2 2

KAMCTL error
by Govind Swamy 08 Dec '22

08 Dec '22

[image: Error in KAMCTL.png] Hi am unable to create using kamctl

3 2

Re: [SR-Users] uac_req_send() multi-process synchronization problem
by Henning Westerholt 08 Dec '22

08 Dec '22

Hello, please keep the list in CC. Not sure what you mean by multi-process safe. The functions are safe to use in a kamailio multi-process context, relevant sections should be protected by internal locks etc.. Regarding query location manually by SQL client, its better to use the provided functions from the usrloc/registrar module instead. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: riffs(a)sina.cn <riffs(a)sina.cn> Sent: Thursday, December 1, 2022 10:47 AM To: Henning Westerholt <hw(a)gilawa.com> Subject: Re: Re: [SR-Users] uac_req_send() multi-process synchronization problem To confirm that. Are reg_fetch_contacts and unregister_ruid multi-process safe? ________________________________ riffs(a)sina.cn<mailto:riffs@sina.cn> From: riffs(a)sina.cn<mailto:riffs@sina.cn> Date: 2022-12-01 16:35 To: Henning Westerholt<mailto:hw@gilawa.com> Subject: Re: RE: [SR-Users] uac_req_send() multi-process synchronization problem Hello Thank you for your reply very much. My LOCATION is stored in the MYSQL database, and I also set the event_callback parameter of TCPOPS. modparam("tcpops", "event_callback", "ksr_tcpops_event") At the same time.I also deleted the contact inside the function function ksr_tcpops_event(evname) local tcpconnid = KSR.pv.get("$conid") or "0" if (evname == "tcp:reset" or evname == "tcp:closed") and (tonumber(tcpconnid) ~= 0) then local sql = string.format("select * from location where tcpconnid=%s", tcpconnid) local count, rows = execute_select(sql) if count > 0 then KSR.registrar.unregister_ruid("location", rows[1].contact, rows[1].ruid) end end return 1 end When I use use_req_send(), I use the following sql statement to query location string.format("select * from location where username='%s'", reciever) I think because the query sql is executed before the execution of unregister_ruid completes, the location of user A can still be queried. If unregister_ruid and reg_fetch_contacts are multi-process safe. I use reg_fetch_contacts query location to avoid this problem. Is that so? thanks very much ________________________________ riffs(a)sina.cn<mailto:riffs@sina.cn> From: Henning Westerholt<mailto:hw@gilawa.com> Date: 2022-11-30 18:18 To: Kamailio (SER) - Users Mailing List<mailto:sr-users@lists.kamailio.org> CC: 刘建峰<mailto:riffs@sina.cn> Subject: RE: [SR-Users] uac_req_send() multi-process synchronization problem Hello, not sure if I fully understand the problem. But regarding another user is registered with the same IP address as a previous user, there are several mitigations. To give two options: you could choose a really short re-registration time, you could use TCP and when you lose the connection you delete the contact. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of ??? Sent: Wednesday, November 30, 2022 2:57 AM To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] uac_req_send() multi-process synchronization problem When I use uac_req_send() to send a MESSAGE to the client. Will the following occur? The result of the message sent to user A is that B has received it. From the logs, the address of user A in the location table is the same as the IP address and port of user B, and the information of user A in the location table is not deleted in time. I took the address of user A directly from the location table without using KSR.registrar.reg_fetch_contacts(). If I use KSR.registrar.reg_fetch_contacts() can this be avoided. This is a multi-process synchronization problem, after user A registers, the IP port information in the address is 172.16.22.222:12345, and then user A disconnects the link because of some abnormal conditions, but it is not normal to cancel the registration, the socket link has failed, but it has not had time to delete the location, at this time user B registers, whether will it get the same IP port information as user A 172.16.22.222 : 12345, if possible? User A's location still exists, Using KSR.registrar.reg_fetch_contacts() TO query user A's location, and then using uac_req_send() to send a message to user A, User B will receive the MESSAGE. Whether this problem occurs? 从 Windows 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>发送

2 2

Fosdem 2023 - CfP
by Daniel-Constantin Mierla 07 Dec '22

07 Dec '22

Hello, should anyone be interested to present or just go to FOSDEM 2023, note that it is going to take place in Brussels during February 4-5, 2023. With a increasing demand on topics to be covered, many more devrooms were accepted and Real Time Communication devroom has half a day available on the afternoon of February 5, 2023. The RTC Devroom call for presentations is open, more details at; - https://lists.fosdem.org/pipermail/fosdem/2022q4/003479.html Check also the other accepted devrooms, maybe one suits better for your work with open source nowadays and you can submit proposals to them: - https://fosdem.org/2023/news/2022-11-07-accepted-developer-rooms/ Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

Call drops after 1 minute
by Christian B Wiik 07 Dec '22

07 Dec '22

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. -- Regards Christian B. Wiik

2 4

How to configure Kamailio to send only DNS A query
by Arun Kumar 07 Dec '22

07 Dec '22

Hello All, I have a setup where the DNS server is configured with only A record. When the Kamailio receives the request it performs a DNS SRV query for which it receives a response with "no such name". But later a DNS A query is sent which gets resolved and the request is forwarded. I would like to know that is there any configuration that can be done in Kamailio so that it will perform only DNS A query directly instead of SRV query? If so could you please help me know how to do it Thanks and Regards Arun

2 1

outbound Edge Proxy
by Giovanni Iamonte 06 Dec '22

06 Dec '22

Dear List In the last week I try to figure out how I can put in place a configuration that use an edge proxy and a register by using kamailio 5.6, but i am facing some issues. Scenario: We are using on ubuntu 20.04, HAproxy and Kamailio 5.6. We have configured a Kamailio register that, in the following case, perfectly works. ______ __ __________ TLS | | TLS | | Client ------------------ > | NAT |-----------> | Kamalio | in |_HAProxy | out in | Register | |_________| | | |________ _| Now we want to put a kamailio edge proxy before the kamailio Register, please take a look to the below picture ______ ______ __ _________ ___________ TLS | | TLS | | TCP | | Client ------------------ > | NAT |-----------> | Kamalio | -------------> | Kamailio | in |_HAProxy | out in | Edge | out in | Register | |_________| | Proxy | | | |_________| |___________| HAproxy -> sip-test.example.com Kamailio edge proxy -> 192.168.58.1 Kamailio Register -> 192.168.58.15 The kamailio Edge has been configured as indicated in the outbound module example. When a transaction such as REGISTER or SUBSCRIBE reach the "Kamailio Register" the Record-Route and Via headers are correct and it works. When the transaction such as MESSAGE or INVITE reach the "Kamailio Register" it does not work and below you can see the message and the error. Note that the Record-Route and Via headers are the same as the previous message REGISTER and SUBSCRIBE. Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: INFO: {1 40742 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} <script>: SIPMessage-in-request = 192.168.58.1:53606-sip:s-user.02@sip-dev.example.com-MESSAGE sip:s-user.02@sip-dev.example.com SIP/2.0 Record-Route: <sip:192.168.58.1:15006;transport=tcp;r2=on;lr> Record-Route: <sip:sip-test.example.com:16005;transport=tls;r2=on;lr> Via: SIP/2.0/TCP 192.168.58.1:15006;branch=z9hG4bKa257.add27f134dd83c78aef13ca7798f87ca.0;i=6 Via: SIP/2.0/TLS 192.168.58.1:39592;received=192.168.58.1;rport=39592;branch=z9hG4bKPjajkY.0NlW2AFuz3.BRaKH4EdvdmQTs9L;alias Max-Forwards: 69 From: <sip:s-user.03@sip-dev.example.com>;tag=VnOekkKsq4tLhFAywXzbxLXxIesWscn3 To: <sip:s-user.02@sip-dev.example.com> Call-ID: YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET CSeq: 40742 MESSAGE Accept: text/plain, application/im-iscomposing+xml Content-Type: text/plain Content-Length: 59 ################## MESSAGE ################### Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: INFO: {1 40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} <script>: SIPMessage-in-request = 192.168.58.1:53606-sip:s-user.02@sip-dev.example.com-MESSAGE sip:s-user.02@sip-dev.example.com SIP/2.0 Record-Route: <sip:192.168.58.1:15006;transport=tcp;r2=on;lr> Record-Route: <sip:sip-test.example.com:16005;transport=tls;r2=on;lr> Via: SIP/2.0/TCP 192.168.58.1:15006;branch=z9hG4bKb257.83b972054df1675806975159ae1f1e43.0;i=6 Via: SIP/2.0/TLS 192.168.58.1:39592;received=192.168.58.1;rport=39592;branch=z9hG4bKPjfan-Tte.vtL8brkWb20wm.5b8iuVEtQV;alias Max-Forwards: 69 From: <sip:s-user.03@sip-dev.example.com>;tag=VnOekkKsq4tLhFAywXzbxLXxIesWscn3 To: <sip:s-user.02@sip-dev.example.com> Call-ID: YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET CSeq: 40743 MESSAGE Accept: text/plain, application/im-iscomposing+xml Proxy-Authorization: Digest username="s-user.03", realm="sip-dev.example.com", nonce="Y48hMWOPIAW7JeSQ7/a+cuJ1gKwT8hrC", uri="sip:s-user.02@sip-dev.example.com", response="3b7c34476443e5f1125fa460a4981180", cnonce="3AT-ZMwyfpgaMwlulh5cq5vJHi75-wnz", qop=auth, nc=00000001 Content-Type: text/plain Content-Length: 59 Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: WARNING: {1 40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} <core> [core/forward.c:228]: get_send_socket2(): protocol/port mismatch (forced tcp:192.168.58.15:15006, to tls:192.168.58.1:60982) Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: ERROR: {1 40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} tm [ut.h:315]: uri2dst2(): no corresponding socket found for "192.168.58.1" af 2 (tls:192.168.58.1:60982) Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: ERROR: {1 40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} tm [t_fwd.c:471]: prepare_new_uac(): can't fwd to af 2, proto 3 (no corresponding listening socket) Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: ERROR: {1 40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} tm [t_fwd.c:1754]: t_forward_nonack(): failure to add branches Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: ERROR: {1 40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} sl [sl_funcs.c:372]: sl_reply_error(): stateless error reply used: I'm terribly sorry, server error occurred (7/SL) based on what we have understood in the message headers "Via" and Record-Route" there are the right information to reach back the proxy Edge, but looking to the error message it seems that the kamailio register try to reach back the proxy edge through the TLS instead of using the TCP. Could someone put me in the right direction. Thanks Regards -- ------------------------------------------------------------------------ Ing. Giovanni Iamonte Developments and technologies area Quintetto Srl Via Monte Navale, 1 10015 - Ivrea (TO)  mobile: +39 393 9196310  tel: +39 0165 1845290  e-mail: giovanni.iamonte(a)quintetto.it  web: www.quintetto.it

2 4

Packet processing order
by Jawaid Bazyar 06 Dec '22

06 Dec '22

Hi, I have experienced out of order packet processing when testing a simple Kamailio config. The configuration is as follows, basically: request_route{ record_route(); enum_query(); xlog("INVITE ENUM query - To URI $tU"); forward(); } I saw this thread from 2020: https://www.mail-archive.com/sr-users@lists.kamailio.org/msg11786.html The issue seems to be that kamailio process scheduling is naïve – i.e., incoming SIP packets are processed without regard to whether packets received before this one, are currently being processed. This means any packets after the initial INVITE that require more processing, can get reordered. In my test lab I have: SIPp – UAC Kamailio Proxy SIPp – UAS The proxy uses enum NAPR lookups to route calls to +13038151000 to the UAS. Now, if I do SIPp UAC o SIPp UAS directly, I have no problems – no out of order packets. It is only when I introduce Kamailio in the middle that I get OOO packets. See the images attached: uac-to-proxy, proxy, and proxy-to-uas. In this example, Kamailio OOO causes SIPp UAC to fail to “generate audio” – because UAC does not see packets in the correct order, I never turns on the simulated audio. Calls that have in-order dialogs, work fine, and SIPP UAC “pauses” 10 seconds to simulate a phone call. So far, the error rate runs from 1/1000 to around 1/200 – pretty bad. In the thread, a few things were suggested. Have fewer kamailio processes than cores: Did not resolve issue. Try route_locks_size = 256 Did not resolve issue. Though, it did alter it somewhat. But, it is not clear to me how this works – would this setting restrict the number of open calls to 256? Have only one kamailio process: (“children=1”) This works. “Works”, I should say, because this would greatly restrict total platform scalability to a point where it is probably useless for my application. I saw the same issue discussed in the OpenSIPS mailing list from 2010, and the response was “this is not a bug”. Well, I respectfully beg to differ with both OpenSIPS and Kamailio – it IS a bug. I don’t think a proxy should reorder packets involved in a call in a non-deterministic way. In the Kamailio list thread, Alex Balashov discusses the contortions he has to go through to avoid repercussions from this issue. Kamailio as-is probably works fine for relatively low-volume operations. And a lot of the feedback is “why are out of order packets a problem?” OK, sure, in the very specific example given in the 2020 thread, maybe who cares. But in my thinking, there is absolutely nothing preventing Kamailio from generating much more serious OOO scenarios that would cause calls to fail. In my example, Kamailio OOO causes SIPp to fail to “generate audio”. Who knows how other SIP stacks will behave? But the more one will try to scale Kamailio, the more significantly this out of order processing issue will become. The solution to this seems very simple and straightforward – put packets to be processed into a queue PER Call-ID, or something along those lines. In short, the parallelism should be by call, not by packet. What say ye? Have I misunderstood something here? Cheers, Jawaid

4 11

Database Failure Detection at runtime
by Waqar 40 06 Dec '22

06 Dec '22

Hello Everyone, I am using Kamailio sqlops module to write to a remote database which is not the database of Kamailio. It is working fine. But for redundancy purpose, if this database goes down, I want the Kamailio to detect the failure at runtime and write the data to another database (standby database). Is it possible? Can anybody please guide me on this asap? Regards, Vicky

3 3

ds_is_from_list not matching dispatcher listed with hostname
by Benoît Panizzon 03 Dec '22

03 Dec '22

Hi On our devevelpment system, we have this dispatcher list: 3200 sip:reg1.dev.example.com:5060 0 0 name="Registrar01"; 3200 sip:reg2.dev.example.com:5060 0 0 name="Registrar02"; The names or course are in the DNS: A,AAAA and PTR. ds_is_from_list() returns the groupId 3200 Now I have started building the production system... 3200 sip:reg1.prod.example.com:5060 0 0 name="Registrar01"; 3200 sip:reg2.prod.example.com:5060 0 0 name="Registrar02"; DNS ist set up the same. I have double-checked: Names and IP addresses do resolve as they should. ds_is_from_list() returns nothing. I have also sniffed the connection. The ip addresses in the packets are the ones I expect. modparam("dispatcher", "ds_ping_from", "sip:survivability@sip.example.com") pings the machines and is getting answers. What else could cause this not to match? -- 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 ______________________________________________________

2 2

imc sends all messages with Content-Type: text/plain
by Joey Golan 02 Dec '22

02 Dec '22

Hello, I'm checking the imc module and it appears that imc sends all messages with hard-coded content type header so if client sends an application/im-iscomposing+xml message, other clients receives the message with content-type text/plain which is very confusing. I think the right behavior is to take the content-type header from the original message and use it in the messages imc sends. Is there a workaround that might help me achieve that?

3 3

RLS is not sending Notify on resource list updated
by Lewis Hutchinson 01 Dec '22

01 Dec '22

Have you confirmed if the NOTIFY is sent? Attempted to be sent? Noticed you said "but no NOTIFY is received" -----Original Message----- From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of sr-users-request(a)lists.kamailio.org Sent: 19 November 2022 11:00 To: sr-users(a)lists.kamailio.org Subject: sr-users Digest, Vol 210, Issue 19 Send sr-users mailing list submissions to sr-users(a)lists.kamailio.org To subscribe or unsubscribe via the World Wide Web, visit https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kam… or, 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. RLS is not sending Notify on resource list updated (Joey Golan) ---------------------------------------------------------------------- Message: 1 Date: Fri, 18 Nov 2022 21:33:29 +0200 From: Joey Golan <joeygo(a)gmail.com> To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Subject: [SR-Users] RLS is not sending Notify on resource list updated Message-ID: <CAAOPBYfHikYXKSRga5Mnf+fgUisrDk5PgHoCZ7anMgqqAmnU-w(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, I'm using Kamailio v5.6.2 with presence, presence_xml, xcap_server, and rls modules. I pushed 2 documents to the xcap server: 1. urn:ietf:params:xml:ns:resource-lists <?xml version="1.0" encoding="UTF-8" standalone="no"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="friends"> <entry uri="sip:1001@example.com"> <display-name>1001</display-name> </entry> <entry uri="sip:1002@example.com"> <display-name>1002</display-name> </entry> </list> </resource-lists> 2. urn:ietf:params:xml:ns:rls-services <?xml version="1.0" encoding="UTF-8" standalone="no"?> <rls-services xmlns="urn:ietf:params:xml:ns:rls-services" xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi=" https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org…"> <service uri="sip:1000+presence@example.com"> <resource-list> https://kamailio:5061/xcap-root/resource-lists/users/sip:1000@example.com/i… "friends"]</resource-list> <packages> <package>presence</package> </packages> </service> </rls-services> I'm subscribing to presence event on rls-service SUBSCRIBE sip:1000+presence@example.com SIP/2.0 Via: SIP/2.0/TLS 10.255.0.3:33883 ;rport;branch=z9hG4bKPjbe079f60-d0e0-4f1e-9f93-b18e467be5e8;alias Max-Forwards: 70 From: "1000" <sip:1000@example.com>;tag=97ef0748-da39-442f-9a02-468b67134ad6 To: <sip:1000+presence@example.com> Contact: <sip:20416583@10.255.0.3:5061;transport=tls> Call-ID: 9773a68c-b001-49f0-9ffa-093beb3d8e36 CSeq: 18636 SUBSCRIBE Event: presence Expires: 600 Supported: 100rel, replaces, norefersub, gruu Accept: multipart/related, application/rlmi+xml, application/pidf+xml Allow-Events: presence Supported: eventlist User-Agent: sipsimple 5.2.6 Content-Length: 0 The RLS sends a NOTIFY immediately upon accepting the subscription according to RFC 4662 and also the RLS is virtually subscribing to the presence event on the 2 resources in the friends list NOTIFY sip:20416583@10.255.0.3:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS joey-local-proxy.example.com:5061 ;branch=z9hG4bKa93d.b63e0697000000000000000000000000.0 To: <sip:1000@example.com>;tag=97ef0748-da39-442f-9a02-468b67134ad6 From: <sip:1000+presence@example.com >;tag=e02a02cb113b2bdb8ebdb022d767e6d2-a1677c19 CSeq: 1 NOTIFY Call-ID: 9773a68c-b001-49f0-9ffa-093beb3d8e36 Content-Length: 468 Max-Forwards: 70 Event: presence Contact: <sip:kamailio@example.com:5060> Subscription-State: active;expires=600 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml";start="<1668755827.sip:1000+presence@example.com.1700642067 >";boundary="1W1NaaaIIq6dOtLRXODFwqmC" --1W1NaaaIIq6dOtLRXODFwqmC Content-Transfer-Encoding: binary Content-ID: <1668755827.sip:1000+presence@example.com.1700642067> Content-Type: application/rlmi+xml;charset="UTF-8" <?xml version="1.0"?> <list uri="sip:1000+presence@example.com" xmlns="urn:ietf:params:xml:ns:rlmi" version="1" fullState="true"> <resource uri="sip:1001@example.com"/> <resource uri="sip:1002@example.com"/> </list> --1W1NaaaIIq6dOtLRXODFwqmC-- Now I?m changing the resource list using XCAP. I?m sending a PUT request with a new document and I see that the change is pushed to the DB but user 1000 is not receiving a NOTIFY with the updated list. This is the updated document: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="friends"> <entry uri="sip:1001@example.com"> <display-name>1001</display-name> </entry> <entry uri="sip:1002@example.com"> <display-name>1002</display-name> </entry> <entry uri="sip:1003@example.com"> <display-name>1003</display-name> </entry> </list> </resource-lists> I see that Kamailio is virtually subscribing on 1003 (The newly added user) but NOTIFY is not received. Also tried to subscribe on xcap-diff event, and the subscription was accepted successfully but no NOTIFY is received. Am I missing something? Thanks, Joey

1 0

Unable to install kamailio-mysql on CentOS 9
by Shailendra Paliwal 01 Dec '22

01 Dec '22

Hello, I'm trying to set up kamailio on a Cent OS 9 server but I'm unable to install the kamailio-mysql module. Can someone suggest any possible solutions here, Tried to setup kamdbctl after changing the configuration to use mysql, ➜ ~ kamdbctl create ERROR: could not load the script in /usr/lib64/kamailio//kamctl/kamdbctl.mysql for database engine MYSQL ERROR: database engine not loaded - tried 'MYSQL' Contents of /usr/lib64/kamailio/kamctl/, I'm not sure why there's a double slash in the message above ➜ ~ ls /usr/lib64/kamailio/kamctl/ dbtextdb kamctl.base kamctl.ctlbase kamctl.dbtext kamctl.rpcfifo kamctl.ser kamctl.sqlbase kamdbctl.base kamdbctl.dbtext I'm unable to install kamailio-mysql ➜ ~ dnf install kamailio-mysql Last metadata expiration check: 0:00:23 ago on Thursday 01 December 2022 03:53:45 AM. Error: Problem: conflicting requests - nothing provides libmysqlclient.so.21()(64bit) needed by kamailio-mysql-5.6.2-0.el9.centos.x86_64 - nothing provides libmysqlclient.so.21(libmysqlclient_21.0)(64bit) needed by kamailio-mysql-5.6.2-0.el9.centos.x86_64 - nothing provides mysql-libs needed by kamailio-mysql-5.6.2-0.el9.centos.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) I've checked that I do have the following repolists, ➜ kamctl dnf repolist repo id repo name appstream CentOS Stream 9 - AppStream baseos CentOS Stream 9 - BaseOS epel Extra Packages for Enterprise Linux 9 - x86_64 epel-next Extra Packages for Enterprise Linux 9 - Next - x86_64 extras-common CentOS Stream 9 - Extras packages kamailio Kamailio - latest - Packages for the Kamailio latest release mariadb-main MariaDB Server mariadb-maxscale MariaDB MaxScale mariadb-tools MariaDB Tools tailscale-stable Tailscale stable This is after a fresh installation of CentOS 9. I believe that I might have a missing repolist or probably have something incorrect in the configuration.

5 7

Re: [SR-Users] kamctl cr reload doesn't reload all routes
by Henning Westerholt 30 Nov '22

30 Nov '22

Hello Igor, yes - you can use a RPC command, I think its in corex module. Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/> From: Igor Potjevlesch <igor.potjevlesch(a)gmail.com> Sent: Wednesday, November 30, 2022 5:14 PM To: Henning Westerholt <hw(a)gilawa.com> Subject: RE: [SR-Users] kamctl cr reload doesn't reload all routes Hello Henning, Not really. I just place a call to the prefix and I can see that the route is still the previous one, not the one updated in DB. Can I set INFO loglevel without restarting? Regards, Igor. De : Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Envoyé : mercredi 30 novembre 2022 15:03 À : Igor Potjevlesch <igor.potjevlesch(a)gmail.com<mailto:igor.potjevlesch@gmail.com>>; 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Objet : RE: [SR-Users] kamctl cr reload doesn't reload all routes Hello Igor, Strange. If not already done, you can try to set INFO loglevel to get maybe a bit more information. How do you verify the routes, but looking to RPC output probably? Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/> From: Igor Potjevlesch <igor.potjevlesch(a)gmail.com<mailto:igor.potjevlesch@gmail.com>> Sent: Wednesday, November 30, 2022 2:58 PM To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Subject: RE: [SR-Users] kamctl cr reload doesn't reload all routes Hi Henning, The problem is still there on the concerned instance. I tried to reload again, and I didn't see the error but the routes are not updated. Regards, Igor. De : Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Envoyé : mercredi 30 novembre 2022 14:44 À : Igor Potjevlesch <igor.potjevlesch(a)gmail.com<mailto:igor.potjevlesch@gmail.com>>; 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Objet : RE: [SR-Users] kamctl cr reload doesn't reload all routes Hi Igor, ok, might be some issue with the DB, if it does not happen anymore. You probably notice when it happens again and can investigate then. Regarding the table, just note that there is also a fourth table involved, domain_name: https://kamailio.org/docs/db-tables/kamailio-db-5.5.x.html#idm812 Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/> From: Igor Potjevlesch <igor.potjevlesch(a)gmail.com<mailto:igor.potjevlesch@gmail.com>> Sent: Wednesday, November 30, 2022 2:35 PM To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Subject: RE: [SR-Users] kamctl cr reload doesn't reload all routes Hello Henning, I tried to review all the routes. Unfortunately, I didn't have access to the logs of the last reboot and its not easy to reboot the instance. I tried to copy the same tables (carrierroute, carrierfailureroute and carrier_name) on another instance and cr reload has been executed without any issue. Not easy to highlight where the problem comes from. Regards, Igor. De : Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Envoyé : mardi 29 novembre 2022 21:13 À : Igor Potjevlesch <igor.potjevlesch(a)gmail.com<mailto:igor.potjevlesch@gmail.com>>; 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Objet : RE: [SR-Users] kamctl cr reload doesn't reload all routes Hello Igor, This is usually caused from wrong or incomplete routing data in the DB. Review if you e.g. have some missing domains or carrier entries in the respective tables. Also look for some errors or warnings related to carrierroute at a restart. Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/> From: Igor Potjevlesch <igor.potjevlesch(a)gmail.com<mailto:igor.potjevlesch@gmail.com>> Sent: Tuesday, November 29, 2022 6:08 PM To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Subject: RE: [SR-Users] kamctl cr reload doesn't reload all routes Hello Henning, That's a good point. I tried again and I could see this: ERROR: carrierroute [cr_rpc.c:60]: cr_rpc_reload_routes(): failed to load routing data Nothing more precise. Regards, Igor. De : Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Envoyé : mardi 29 novembre 2022 16:12 À : Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Cc : Igor Potjevlesch <igor.potjevlesch(a)gmail.com<mailto:igor.potjevlesch@gmail.com>> Objet : RE: [SR-Users] kamctl cr reload doesn't reload all routes Hello, any error message in the logs from carrierroute reload? Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/> From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of Igor Potjevlesch Sent: Tuesday, November 29, 2022 4:04 PM To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] kamctl cr reload doesn't reload all routes Hello! I'm facing a problem with one of my Kamailio instance: "kamctl cr reload" returns OK, but, finally, the route I modified, or I added are not takes. I'm still on a previous route. If I completely reboot Kamailio it's okay. So, the last time, I rebooted with more memory, and I was thinking that it could fix the problem, but not. Do you have any idea? Regards, Igor. [Das Bild wurde vom Absender entfernt.]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Sans virus.www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>

1 0

kamctl cr reload doesn't reload all routes
by Igor Potjevlesch 30 Nov '22

30 Nov '22

Hello! I'm facing a problem with one of my Kamailio instance: "kamctl cr reload" returns OK, but, finally, the route I modified, or I added are not takes. I'm still on a previous route. If I completely reboot Kamailio it's okay. So, the last time, I rebooted with more memory, and I was thinking that it could fix the problem, but not. Do you have any idea? Regards, Igor. -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

2 7

Removing the dmq list entry in version 5.4.7.
by satyaprakash ch 30 Nov '22

30 Nov '22

Hi Team, I need a help to remove the dmq list entry from the kamailio, I have executed the command *kamcmd dmq.list_nodes, below is the output*{ host: xx.xx.xx.xx port: 5080 resolved_ip: xx.xx.xx.xx status: active last_notification: 0 local: 0 } { host: yy.yy.yy.yy port: 5060 resolved_ip: yy.yy.yy.yy status: active last_notification: 0 local: 0 } I need to remove the *yy.yy.yy.yy.Note: I have used to remove the node with below command but it is not able to delete the entry.* kamctl rpc dmq.remove sip:yy.yy.yy.yy:5060

1 0

redis template config for topos module
by Patrick Karton 30 Nov '22

30 Nov '22

Hello not a usual question but i would like to know if somebody using topos module with redis backend can provide me an optimized redis conf for redis for using it topos module. and possibly also when using it with dialog module. Thanks.

2 3

Re: [SR-Users] uac_req_send() multi-process synchronization problem
by Henning Westerholt 30 Nov '22

30 Nov '22

Hello, not sure if I fully understand the problem. But regarding another user is registered with the same IP address as a previous user, there are several mitigations. To give two options: you could choose a really short re-registration time, you could use TCP and when you lose the connection you delete the contact. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of ??? Sent: Wednesday, November 30, 2022 2:57 AM To: sr-users(a)lists.kamailio.org Subject: [SR-Users] uac_req_send() multi-process synchronization problem When I use uac_req_send() to send a MESSAGE to the client. Will the following occur? The result of the message sent to user A is that B has received it. From the logs, the address of user A in the location table is the same as the IP address and port of user B, and the information of user A in the location table is not deleted in time. I took the address of user A directly from the location table without using KSR.registrar.reg_fetch_contacts(). If I use KSR.registrar.reg_fetch_contacts() can this be avoided. This is a multi-process synchronization problem, after user A registers, the IP port information in the address is 172.16.22.222:12345, and then user A disconnects the link because of some abnormal conditions, but it is not normal to cancel the registration, the socket link has failed, but it has not had time to delete the location, at this time user B registers, whether will it get the same IP port information as user A 172.16.22.222 : 12345, if possible? User A's location still exists, Using KSR.registrar.reg_fetch_contacts() TO query user A's location, and then using uac_req_send() to send a message to user A, User B will receive the MESSAGE. Whether this problem occurs? 从 Windows 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>发送

1 0

uac_req_send() multi-process synchronization problem
by 刘建峰 30 Nov '22

30 Nov '22

When I use uac_req_send() to send a MESSAGE to the client. Will the following occur? The result of the message sent to user A is that B has received it. From the logs, the address of user A in the location table is the same as the IP address and port of user B, and the information of user A in the location table is not deleted in time. I took the address of user A directly from the location table without using KSR.registrar.reg_fetch_contacts(). If I use KSR.registrar.reg_fetch_contacts() can this be avoided. This is a multi-process synchronization problem, after user A registers, the IP port information in the address is 172.16.22.222:12345, and then user A disconnects the link because of some abnormal conditions, but it is not normal to cancel the registration, the socket link has failed, but it has not had time to delete the location, at this time user B registers, whether will it get the same IP port information as user A 172.16.22.222 : 12345, if possible? User A's location still exists, Using KSR.registrar.reg_fetch_contacts() TO query user A's location, and then using uac_req_send() to send a message to user A, User B will receive the MESSAGE. Whether this problem occurs? 从 Windows 版邮件发送

1 0

[Users] checking route return codes
by Candida Benge 29 Nov '22

29 Nov '22

1 0

Starting with Kamailio
by Clint Crabtree 29 Nov '22

29 Nov '22

Hello, I’m a DIY entrepreneurial developer beginning to build a system and I stumbled upon Kamailio. I’ve installed asterisk and kamailio in hopes of setting up an IVR to collect voice to speech information from incoming calls. I’m skilled with PHP to Javascript application development. In my research of PBX and discovery of Asterisk I have found enough information online to begin developing with Asterisk ARI; however, somewhere in my discovery process was the suggestion that Kamailio can offer close to real time voice recognition streaming whereas Asterisk is more of a record, pause, translate, respond process. In an AstriCon presentation by Fred Posner I saw recommendations for new applications the suggestion to develop with Kamailio: https://www.youtube.com/watch?v=IaYOboZQEw0?t=23m10s I’m a newbie to SIP, but it seems really promising, can you help point me in the right direction for aforementioned use-case for Kamailio? or am I misunderstanding some if its capability? Regards, Clint Crabtree

4 3

Setting package memory from core config
by Alex Balashov 29 Nov '22

29 Nov '22

Hi, There is a way to set the shared memory pool size from core config instead of external CLI arguments: https://www.kamailio.org/wikidocs/cookbooks/5.6.x/core/#shm_mem_size Is there something analogous for package memory (-M)? I could not find it. Thanks! -- Alex -- 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

db_mysql_new_connection(): driver error: Can't connect to MySQL server
by Denys Pozniak 29 Nov '22

29 Nov '22

Hello! We use Kamailio in conjunction with the cloud Azure Database for MySQL 5.7. It has been noticed that Kamailio does not always start after restarting. It happens to restart a couple of times and everything starts normally. >From the pickup trace I collect on our side, it can be seen that Kamailio connects to MySQL, requests and gets data, and then sends a Request Quit. On another server with a different configuration (slightly different set of modules) and connected to the same database, this issue is not reproduced. How to determine the source of the problem? Below, the logs are filtered by PID of processes in which an error occurred: ERROR: db_mysql [km_my_con.c:163]: db_mysql_new_connection(): driver error: Can't connect to MySQL server on '10.1.128.4' (110) 11(588460) DEBUG: <core> [core/pt.c:308]: fork_process(): seeding PRNG with 893384711 11(588460) DEBUG: <core> [core/rand/cryptorand.c:36]: cryptorand_seed(): seeding cryptorand generator with 893384711 11(588460) DEBUG: <core> [core/rand/fortuna/random.c:175]: sr_add_entropy(): additional 4 bytes entropy added to cryptographic PRNG 11(588460) DEBUG: <core> [core/pt.c:313]: fork_process(): test random numbers 289569343 1482836098 4036842274 2495827489 11(588460) DEBUG: <core> [core/sr_module.c:926]: init_child(): initializing PROC_RPC with rank -2 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: jsonrpcs [DMQ WORKER] 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: kex [DMQ WORKER] 11(588460) DEBUG: kex [kex_mod.c:155]: child_init(): rank is (-2) 11(588460) DEBUG: <core> [core/utils/sruid.c:121]: sruid_init(): root for sruid is [srid-6380d27f-8faac-] (0 / 20) 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: corex [DMQ WORKER] 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: tm [DMQ WORKER] 11(588460) DEBUG: tm [callid.c:136]: child_init_callid(): callid: ' 558fadb265b2cc20-588460(a)10.1.15.12' 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: tmx [DMQ WORKER] 11(588460) DEBUG: tmx [tmx_mod.c:262]: child_init(): rank is (-2) 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: sl [DMQ WORKER] 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: usrloc [DMQ WORKER] 11(588460) DEBUG: <core> [core/utils/sruid.c:121]: sruid_init(): root for sruid is [ulcx-6380d27f-8faac-] (0 / 20) 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: registrar [DMQ WORKER] 11(588460) DEBUG: <core> [core/utils/sruid.c:121]: sruid_init(): root for sruid is [uloc-6380d27f-8faac-] (0 / 20) 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: ctl [DMQ WORKER] 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: dmq [DMQ WORKER] 11(588460) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 11 rank -2: auth_db [DMQ WORKER] 11(588460) DEBUG: <core> [db.c:315]: db_do_init2(): connection 0x 7f96e7d58880 not found in pool 11(588460) DEBUG: db_mysql [km_my_con.c:110]: db_mysql_new_connection(): opening connection: mysql://xxxx:xxxx@10.1.128.4/kamailio 11(588460) ERROR: db_mysql [km_my_con.c:163]: db_mysql_new_connection(): driver error: Can't connect to MySQL server on '10.1.128.4' (110) 11(588460) ERROR: <core> [db.c:319]: db_do_init2(): could not add connection to the pool 11(588460) ERROR: auth_db [auth_db_mod.c:161]: child_init(): unable to connect to the database 11(588460) ERROR: <core> [core/sr_module.c:882]: init_mod_child(): error while initializing module auth_db (/usr/lib/x86_64-linux-gnu/kamailio/modules/auth_db.so) (idx: 11 rank: -2 desc: [DMQ WORKER]) 11(588460) ERROR: <core> [core/pt.c:338]: fork_process(): init_child failed for process 11, pid 588460, "DMQ WORKER" 11(588460) ERROR: dmq [dmq.c:314]: child_init(): failed to fork worker process 0 11(588460) ERROR: <core> [core/sr_module.c:882]: init_mod_child(): error while initializing module dmq (/usr/lib/x86_64-linux-gnu/kamailio/modules/dmq.so) (idx: 11 rank: 0 desc: [DMQ WORKER]) 11(588460) ERROR: <core> [main.c:1842]: main_loop(): error in init_child 17(588466) DEBUG: <core> [core/pt.c:308]: fork_process(): seeding PRNG with 2018260302 17(588466) DEBUG: <core> [core/rand/cryptorand.c:36]: cryptorand_seed(): seeding cryptorand generator with 2018260302 17(588466) DEBUG: <core> [core/rand/fortuna/random.c:175]: sr_add_entropy(): additional 4 bytes entropy added to cryptographic PRNG 17(588466) DEBUG: <core> [core/pt.c:313]: fork_process(): test random numbers 1395463366 918020172 18663197 531231393 17(588466) DEBUG: <core> [core/sr_module.c:926]: init_child(): initializing PROC_TIMER with rank -1 17(588466) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 17 rank -1: jsonrpcs [Dialog Clean Timer] 17(588466) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 17 rank -1: kex [Dialog Clean Timer] 17(588466) DEBUG: kex [kex_mod.c:155]: child_init(): rank is (-1) 17(588466) DEBUG: <core> [core/utils/sruid.c:121]: sruid_init(): root for sruid is [srid-6380d27f-8fab2-] (0 / 20) 17(588466) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 17 rank -1: corex [Dialog Clean Timer] 17(588466) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 17 rank -1: tm [Dialog Clean Timer] 17(588466) DEBUG: tm [callid.c:136]: child_init_callid(): callid: ' 558fadb265b2cc20-588466(a)10.1.15.12' 17(588466) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 17 rank -1: tmx [Dialog Clean Timer] 17(588466) DEBUG: tmx [tmx_mod.c:262]: child_init(): rank is (-1) 17(588466) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 17 rank -1: sl [Dialog Clean Timer] 17(588466) DEBUG: <core> [core/sr_module.c:878]: init_mod_child(): idx 17 rank -1: usrloc [Dialog Clean Timer] 17(588466) DEBUG: <core> [core/utils/sruid.c:121]: sruid_init(): root for sruid is [ulcx-6380d27f-8fab2-] (0 / 20) 17(588466) DEBUG: <core> [db.c:315]: db_do_init2(): connection 0x 7f96e7d58880 not found in pool 17(588466) DEBUG: db_mysql [km_my_con.c:110]: db_mysql_new_connection(): opening connection: mysql://xxxx:xxxx@10.1.128.4/kamailio 17(588466) ERROR: db_mysql [km_my_con.c:163]: db_mysql_new_connection(): driver error: Can't connect to MySQL server on '10.1.128.4' (110) 17(588466) ERROR: <core> [db.c:319]: db_do_init2(): could not add connection to the pool 17(588466) ERROR: usrloc [usrloc_mod.c:485]: child_init(): child(-1): failed to connect to database 17(588466) ERROR: <core> [core/sr_module.c:882]: init_mod_child(): error while initializing module usrloc (/usr/lib/x86_64-linux-gnu/kamailio/modules/usrloc.so) (idx: 17 rank: -1 desc: [Dialog Clean Timer]) 17(588466) ERROR: <core> [core/pt.c:338]: fork_process(): init_child failed for process 17, pid 588466, "Dialog Clean Timer" 17(588466) ERROR: dialog [dialog.c:782]: child_init(): failed to start clean timer routine as process 17(588466) ERROR: <core> [core/sr_module.c:882]: init_mod_child(): error while initializing module dialog (/usr/lib/x86_64-linux-gnu/kamailio/modules/dialog.so) (idx: 17 rank: 0 desc: [Dialog Clean Timer]) 17(588466) ERROR: <core> [main.c:1842]: main_loop(): error in init_child 17(588466) CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f96e2f84650), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring 17(588466) CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f96e2f84900), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_malloc(293) - ignoring 17(588466) CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f96e2fd50b0), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring 17(588466) CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f96e2f820e0), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring - Debian 11.5 - libmariadb version 3.1.16 -modules: auth_db, permissions, domain, rtpengine, dispatcher, dialog, uac, carrierroute, topos, acc - kamailio 5.6.2 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 -- BR, Denys Pozniak

3 3

Info: Dates for next Kamailio World Conference in Berlin: June 5-7, 2023
by Daniel-Constantin Mierla 28 Nov '22

28 Nov '22

Hello, the next year Kamailio World Conference is planed to return in Berlin for an in-person event at the usual location in the city center. For the moment, we would like to announce the dates, respectively June 5-7, 2023. If nothing unexpected happens meanwhile, the call for speakers and registrations will be open at the beginning of 2023. We aim for a similar structure like the past in-person events, with first day starting around noon and targeting to be tutorial-oriented, followed by 2 days of conference presentations. More details soon! Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

3 2

Turn off transaction accouting but keep dialog cdr accounting?
by Benoit Panizzon 28 Nov '22

28 Nov '22

Hi Team Inserts require resources, especially on high load situations and if there are a couple of indexes on the table. As I use the dialogue module to create CDR, I would like to disable the normal transaction based accounting. I have attempted by not calling: setflag(FLT_ACC) setflag(FLT_ACCFAILED) but I still get both, CDR and Transaction entries created in the corresponding database tables. How could I turn off transaction accounting? 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 2

Regex not capturing as required for subst_hf
by Salvinder Parhar 28 Nov '22

28 Nov '22

Hi, I'm trying to capture and substitute the host IP of contact header using the subst_hf but it's not working as expected. I tested my regex in a tester and it works fine there but not in Kamailio config. *Regex:* @(.+?)> *Substitution:* @PUBLIC_IP:5060> *Three contact headers that I'm trying to match;* Contact:<sip:0065*7766@199.48.100.166:5060 >;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER" Contact: <sip:0065*7788@172.16.1.216 ;transport=udp>;expires=3600;reg-id=1;+sip.instance="<urn:uuid:03660bc5-bb70-4784-8ac5-000413B108BA>" Contact: <sip:0925*0007@199.48.100.166:5060> *Outcome I'm expecting for the three contact headers;* Contact:<sip:0065*7766*@PUBLIC_IP:5060>* ;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER" Contact: <sip:0065*7788*@PUBLIC_IP:5060>* ;expires=3600;reg-id=1;+sip.instance="<urn:uuid:03660bc5-bb70-4784-8ac5-000413B108BA>" Contact: <sip:0925*0007*@PUBLIC_IP:5060>* This regex in Kamailio works fine for the first and third contact header but for the second contact header it matches all the way to the end of the contact header excluding the quote (") sign. I've tried so many other combinations [like *(a)(.+?)>;?* ] of regex but nothing seems to work. Is there a way to accomplish this with one regex? Thanks, Sal

2 2

Re: [SR-Users] To stop automatic creation of RabbitMQ queues by kazoo module
by Luis Azedo 25 Nov '22

25 Nov '22

your expectation is wrong, that's how it works, all channels are bi-directional and for that they use a queue. > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 24 Nov 2022 12:48:58 +0530 > From: Sharmila Sundar <sharmila.sundar(a)ecosmob.com> > To: sr-users(a)lists.kamailio.org > Subject: [SR-Users] To stop automatic creation of RabbitMQ queues by > kazoo module > Message-ID: > <CACcTecP1CfjuKdu33jEvZWUK2bE5ZSK37m-6xE1iEB= > 9XwUCgg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello Team, > > I run into a problem with Kazoo module. > > We noticed that , amqp_max_channels parameter creates automatic queues in > Rabbitmq-server based on the channel number provided. > Expecting that , it should create only channels not queues. > > This is the modparam I added > modparam("kazoo", "amqp_max_channels", 12) > > Can any one help on this issue as why the kazoo module creates an automatic > queue based on amqp_max_channels param ? > > Please find the screenshot attached from rabbitmq server > > Regards > SharmilaS > >

1 0

db_extra fields cannot be integer
by Jose Figueroa 24 Nov '22

24 Nov '22

Hello everyone, According to this old thread, the db_extra fields in the acc module cannot be integer: https://lists.kamailio.org/pipermail/sr-users/2015-February/087053.html Does this answer is still valid or is there another form to represent an integer? since in my acc table I added an integer value field. -- Jose Figueroa

3 2

kamcmd autocompletion
by Antoine DEBARRE 24 Nov '22

24 Nov '22

Hi, I just installed kamailio v5.5 via deb.kamailio.org packages (debian 11). Seems that kamcmd autocompletion doesn't work at all. It is OK for v5.4 via official debian packages (packages.debian.org/bullseye/kamailio) Best regards, -- <https://app.livestorm.co/comdata-group/metaverse-what-will-cx-look-like-in-…>

3 3

To stop automatic creation of RabbitMQ queues by kazoo module
by Sharmila Sundar 24 Nov '22

24 Nov '22

Hello Team, I run into a problem with Kazoo module. We noticed that , amqp_max_channels parameter creates automatic queues in Rabbitmq-server based on the channel number provided. Expecting that , it should create only channels not queues. This is the modparam I added modparam("kazoo", "amqp_max_channels", 12) Can any one help on this issue as why the kazoo module creates an automatic queue based on amqp_max_channels param ? Please find the screenshot attached from rabbitmq server Regards SharmilaS -- * <https://www.ecosmob.com/> * *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

1 0

RLS is not sending Notify on resource list updated
by Joey Golan 23 Nov '22

23 Nov '22

Hello, I'm using Kamailio v5.6.2 with presence, presence_xml, xcap_server, and rls modules. I pushed 2 documents to the xcap server: 1. urn:ietf:params:xml:ns:resource-lists <?xml version="1.0" encoding="UTF-8" standalone="no"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="friends"> <entry uri="sip:1001@example.com"> <display-name>1001</display-name> </entry> <entry uri="sip:1002@example.com"> <display-name>1002</display-name> </entry> </list> </resource-lists> 2. urn:ietf:params:xml:ns:rls-services <?xml version="1.0" encoding="UTF-8" standalone="no"?> <rls-services xmlns="urn:ietf:params:xml:ns:rls-services" xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"> <service uri="sip:1000+presence@example.com"> <resource-list> https://kamailio:5061/xcap-root/resource-lists/users/sip:1000@example.com/i… "friends"]</resource-list> <packages> <package>presence</package> </packages> </service> </rls-services> I'm subscribing to presence event on rls-service SUBSCRIBE sip:1000+presence@example.com SIP/2.0 Via: SIP/2.0/TLS 10.255.0.3:33883 ;rport;branch=z9hG4bKPjbe079f60-d0e0-4f1e-9f93-b18e467be5e8;alias Max-Forwards: 70 From: "1000" <sip:1000@example.com>;tag=97ef0748-da39-442f-9a02-468b67134ad6 To: <sip:1000+presence@example.com> Contact: <sip:20416583@10.255.0.3:5061;transport=tls> Call-ID: 9773a68c-b001-49f0-9ffa-093beb3d8e36 CSeq: 18636 SUBSCRIBE Event: presence Expires: 600 Supported: 100rel, replaces, norefersub, gruu Accept: multipart/related, application/rlmi+xml, application/pidf+xml Allow-Events: presence Supported: eventlist User-Agent: sipsimple 5.2.6 Content-Length: 0 The RLS sends a NOTIFY immediately upon accepting the subscription according to RFC 4662 and also the RLS is virtually subscribing to the presence event on the 2 resources in the friends list NOTIFY sip:20416583@10.255.0.3:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS joey-local-proxy.example.com:5061 ;branch=z9hG4bKa93d.b63e0697000000000000000000000000.0 To: <sip:1000@example.com>;tag=97ef0748-da39-442f-9a02-468b67134ad6 From: <sip:1000+presence@example.com >;tag=e02a02cb113b2bdb8ebdb022d767e6d2-a1677c19 CSeq: 1 NOTIFY Call-ID: 9773a68c-b001-49f0-9ffa-093beb3d8e36 Content-Length: 468 Max-Forwards: 70 Event: presence Contact: <sip:kamailio@example.com:5060> Subscription-State: active;expires=600 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml";start="<1668755827.sip:1000+presence@example.com.1700642067 >";boundary="1W1NaaaIIq6dOtLRXODFwqmC" --1W1NaaaIIq6dOtLRXODFwqmC Content-Transfer-Encoding: binary Content-ID: <1668755827.sip:1000+presence@example.com.1700642067> Content-Type: application/rlmi+xml;charset="UTF-8" <?xml version="1.0"?> <list uri="sip:1000+presence@example.com" xmlns="urn:ietf:params:xml:ns:rlmi" version="1" fullState="true"> <resource uri="sip:1001@example.com"/> <resource uri="sip:1002@example.com"/> </list> --1W1NaaaIIq6dOtLRXODFwqmC-- Now I’m changing the resource list using XCAP. I’m sending a PUT request with a new document and I see that the change is pushed to the DB but user 1000 is not receiving a NOTIFY with the updated list. This is the updated document: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="friends"> <entry uri="sip:1001@example.com"> <display-name>1001</display-name> </entry> <entry uri="sip:1002@example.com"> <display-name>1002</display-name> </entry> <entry uri="sip:1003@example.com"> <display-name>1003</display-name> </entry> </list> </resource-lists> I see that Kamailio is virtually subscribing on 1003 (The newly added user) but NOTIFY is not received. Also tried to subscribe on xcap-diff event, and the subscription was accepted successfully but no NOTIFY is received. Am I missing something? Thanks, Joey

2 1

Create new listener on the fly
by H Yavari 23 Nov '22

23 Nov '22

Hi Kamailio community, I am running an IPsec server beside Kamailio, so I am interested to know if there is any method to create a SIP listener on a specific port on the fly. I mean, when I create the IPsec SAs through the IPsec server, I ask Kamailio to create a listener/handler for that port too.This case might be very rare, but it is always good to hear community ideas. Thank you. Regards,Hossein

5 9

ims ipsec connectivity
by Oleg Belousov 23 Nov '22

23 Nov '22

Hi. Working on ims integration with the actual handset, have got a problem with ipsec establishment to complete registration. Initial steps are fine, including diameter exchange and 401 (with security server details) toward UE. On the next step UE and kamailio should establish ipsec connection, and UE to submit the next register with a response. As per trace UE is trying to establish the same (can see initial TCP SYN encapsulated onto ESP), using port-s, provided in Security-Server, but get an ICMP packet from server with destination/protocol unreachable. No more info either in P-SCSF log, no in kern.log. Proxy is listening to that port, it is tcp and available over telnet, so should not be a connectivity issue. Please let know if any ideas how to troubleshoot that further, -- obelousov.tel

4 6

Problem with update/retrigger a htable
by Bernd Krueger-Knauber 21 Nov '22

21 Nov '22

Hi members, I run into a problemm with htable. For user push notifications I need a loop. So I did the following for a first test: modparam("htable", "htable", "user=>size=3;autoexpire=5") ... event_route[htable:mod-init] { xinfo("htable init"); $sht(user=>testkey) = "testvalue"; } event_route[htable:expired:user] { xinfo("Record expired $shtrecord(key) => $shtrecord(value)"); $sht(user=>$shtrecord(key)) = $shtrecord(value); } I see the htable init, and I reach Record expired, but only once. The 'new' entry $sht(user=>$shtrecord(key)) = $shtrecord(value); seams not to be re-added, because I never reach the expired event again. I expected to see cyclic expired events. Also strange: expire is set to 5 seconds I get: Nov 21 08:34:50 xxx /usr/sbin/kamailio[254662]: INFO: <script>: htable init ... Nov 21 08:35:10 xxx /usr/sbin/kamailio[254671]: INFO: <script>: Record expired testkey => testvalue If I'm right, this are 20 seconds and not 5. Any ideas what's wrong? Best regards

2 3

Interconnecting two Kamailio IMS Networks
by Derek OSS 18 Nov '22

18 Nov '22

Hi, I have P-CSCF, I-CSCF, and S-CSCF instances of Kamailio running with rtpengine. I can have a VoLTE call over a 4G network (using Open5GS) using Kamailio with two phones on the same IMS network, no problem. I have leveraged the docker_open5gs project to do this. For Kamailio, I have some IMS-related questions for when the Called-Party is not within the IMS network as I'm interested in what may be required to interconnect two Kamailio IMS networks. - Does Kamailio (or anyone you may know) have example configuration files for instances of a BGCF, IBCF, or TrGW? - If the S-CSCF determines that the Called-Party is not within the IMS network, is there an example configuration file of where the S-CSCF can forward the SIP INVITE to a BGCF / contact the IBCF directly? - If "no" to the above, are the BGCF, IBCF, and TrGW instances necessary to facilitate a call between two networks? Can Kamailio emulate multiple networks and instead have the S-CSCF of the originating network simply send the SIP request to the I-CSCF of the destination network (selected via DNS lookup) and use the single rtpengine instance between the two networks rather than using a BGCF, IBCF, and TrGW? Thank you very much for your help, Derek

1 0

lcr related crash
by Juha Heinanen 18 Nov '22

18 Nov '22

We noticed lcr related crash with pretty recent 5.6. Core dump is below. Weird thing is that some of the values in matched_gw table make no sense. For example, there does not exist rule_id = 1426245171 in lcr_rule table and some prefix_len and priority values are far too big. Any ideas? -- Juha #0 0x00007efda9ea7486 in ki_load_gws_furi (_m=0x7efdaa5846f0, lcr_id=1, ruri_user=0x7fff30444b90, from_uri=0x7fff30444ba0) at lcr_mod.c:2330 2330 lcr_mod.c: No such file or directory. (gdb) bt full #0 0x00007efda9ea7486 in ki_load_gws_furi (_m=0x7efdaa5846f0, lcr_id=1, ruri_user=0x7fff30444b90, from_uri=0x7fff30444ba0) at lcr_mod.c:2330 request_uri = 0x7efdaa5849d0 i = 1421936895 j = 21897 gw_index = 0 now = 1668672386 dex = 32509 val = {n = 0, s = {s = 0x0, len = -1436245347}, re = 0x0} matched_gws = {{gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 2, duplicate = 0}, {gw_index = 0, rule_id = 1426245171, prefix_len = 21897, priority = 0, weight = 32, duplicate = 0}, {gw_index = 45104, rule_id = 32509, prefix_len = 17040, weight = 3201662253, duplicate = 17040}, {gw_index = 32767, rule_id = 1423653555, prefix_len = 21897, priority = 0, weight = 2857912048, duplicate = 32509}, {gw_index = 44720, rule_id = 32767, prefix_len = 0, priority = 0, weight = 32509, duplicate = 0}, { gw_index = 0, rule_id = 2868544968, prefix_len = 32509, priority = 0, weight = 809780304, duplicate = 32767}, {gw_index = 18160, rule_id = 32509, prefix_len = 44720, priority = 12356, weight = 32767, duplicate = 7864}, {gw_index = 32509, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 56064}, {gw_index = 32045, rule_id = 2858027016, prefix_len = 32509, priority = 0, weight = 2867938768, duplicate = 32509}, {gw_index = 0, rule_id = 0, prefix_len = 6048, priority = 43762, weight = 32509, duplicate = 32}, {gw_index = 0, rule_id = 2992943152, prefix_len = 32509, priority = 0, weight = 809779984, duplicate = 32767}, {gw_index = 62282, rule_id = 21897, prefix_len = 47520, priority = 43666, weight = 32509, duplicate = 13}, {gw_index = 32767, rule_id = 0, prefix_len = 0, priority = 0, weight = 2298403584, duplicate = 32045}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 2, duplicate = 0}, {gw_index = 0, rule_id = 1426245171, prefix_len = 21897, priority = 0, weight = 32, duplicate = 0}, {gw_index = 45104, rule_id = 32509, prefix_len = 17408, priority = 12356, weight = 32767, duplicate = 2303}, {gw_index = 21897, rule_id = 0, prefix_len = 0, priority = 0, weight = 1426245171, duplicate = 21897}, {gw_index = 32, rule_id = 0, prefix_len = 45104, priority = 45668, weight = 32509, duplicate = 17408}, {gw_index = 32767, rule_id = 2857912048, prefix_len = 32509, priority = 0, weight = 2868551680, duplicate = 32509}, {gw_index = 44720, rule_id = 32767, prefix_len = 29136, priority = 34846, weight = 32509, duplicate = 56064}, {gw_index = 1, rule_id = 2868544960, prefix_len = 32509, priority = 0, weight = 809780304, duplicate = 32767}, {gw_index = 0, rule_id = 0, prefix_len = 44720, priority = 12356, weight = 32767, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 2867512936, duplicate = 1}, {gw_index = 50792, rule_id = 32509, prefix_len = 18160, priority = 43608, weight = 32509, duplicate = 44720}, {gw_index = 32767, rule_id = 809780296, prefix_len = 32767, priority = 0, weight = 2862001424, duplicate = 22}, {gw_index = 25472, rule_id = 21897, prefix_len = 0, priority = 0, weight = 0, duplicate = 44628}, {gw_index = 32509, rule_id = 19, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 44642, priority = 43670, weight = 32509, duplicate = 56064}, {gw_index = 32045, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 2}, {gw_index = 0, rule_id = 0, prefix_len = 56064, priority = 35070, weight = 3201662253, duplicate = 32}, { gw_index = 0, rule_id = 0, prefix_len = 2, priority = 0, weight = 0, duplicate = 0}, {gw_index = 50739, rule_id = 21897, prefix_len = 32, priority = 0, weight = 0, duplicate = 45104}, {gw_index = 32509, rule_id = 809781904, prefix_len = 32767, priority = 0, weight = 1421876076, duplicate = 21897}, {gw_index = 17504, rule_id = 32767, prefix_len = 18160, priority = 43608, weight = 32509, duplicate = 2528}, {gw_index = 32509, rule_id = 2857912048, prefix_len = 32509, priority = 0, weight = 2868551952, duplicate = 32509}, {gw_index = 44720, rule_id = 32767, prefix_len = 0, priority = 0, weight = 0, duplicate = 1}, {gw_index = 1, rule_id = 0, prefix_len = 0, priority = 0, weight = 2298403584, duplicate = 32045}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 809780432, duplicate = 32767}, {gw_index = 41793, rule_id = 32509, prefix_len = 0, priority = 0, weight = 0, duplicate = 18600}, {gw_index = 32767, rule_id = 2866689544, prefix_len = 32509, priority = 0, weight = 2857912048, duplicate = 32509}, {gw_index = 0, rule_id = 1, prefix_len = 25492, priority = 21787, weight = 21897, duplicate = 53760}, {gw_index = 32509, rule_id = 2298403584, prefix_len = 32045, priority = 48853, weight = 809780624, duplicate = 32767}, {gw_index = 60669, rule_id = 21897, prefix_len = 0, priority = 0, weight = 0, duplicate = 18600}, {gw_index = 32767, rule_id = 2866689520, prefix_len = 32509, priority = 0, weight = 2857912048, duplicate = 32509}, {gw_index = 35600, rule_id = 32509, prefix_len = 0, priority = 0, weight = 32509, duplicate = 35600}, {gw_index = 32509, rule_id = 2298403584, prefix_len = 32045, priority = 48853, weight = 0, duplicate = 0}, { gw_index = 0, rule_id = 2, prefix_len = 0, priority = 0, weight = 0, duplicate = 50739}, {gw_index = 21897, rule_id = 32, prefix_len = 0, priority = 0, weight = 2298403584, duplicate = 32045}, {gw_index = 18160, rule_id = 32767, prefix_len = 0, priority = 0, weight = 2, duplicate = 0}, {gw_index = 0, rule_id = 1426245171, prefix_len = 21897, priority = 0, weight = 32, duplicate = 0}, {gw_index = 45104, rule_id = 32509, prefix_len = 18080, priority = 12356, weight = 32767, duplicate = 4205}, {gw_index = 21897, rule_id = 2866712944, prefix_len = 32509, priority = 0, weight = 2857912048, duplicate = 32509}, {gw_index = 2528, rule_id = 32509, prefix_len = 34240, priority = 43770, weight = 32509, duplicate = 18592}, {gw_index = 32767, rule_id = 0, prefix_len = 65535, priority = 65535, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 32767, prefix_len = 0, priority = 0, weight = 2, duplicate = 53890}, {gw_index = 55846, rule_id = 0, prefix_len = 0, priority = 0, weight = 1426245171, duplicate = 21897}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 809781424, prefix_len = 32767, priority = 0, weight = 2298403584, duplicate = 32045}, {gw_index = 18216, rule_id = 32767, prefix_len = 0, priority = 0, weight = 22, duplicate = 25472}, {gw_index = 21897, rule_id = 0, prefix_len = 0, priority = 0, weight = 32, duplicate = 0}, {gw_index = 19, rule_id = 32509, prefix_len = 18400, priority = 12356, weight = 32767, duplicate = 36949}, {gw_index = 21897, rule_id = 32, prefix_len = 0, priority = 0, weight = 2298403584, duplicate = 32045}, {gw_index = 18400, rule_id = 32767, prefix_len = 0, priority = 0, weight = 2, duplicate = 0}, {gw_index = 0, rule_id = 1426245171, prefix_len = 21897, priority = 0, weight = 32, duplicate = 0}, {gw_index = 56064, rule_id = 3201662253, prefix_len = 18528, priority = 12356, weight = 32767, duplicate = 0}, {gw_index = 2, rule_id = 0, prefix_len = 0, priority = 0, weight = 1426245171, duplicate = 21897}, {gw_index = 32, rule_id = 0, prefix_len = 45104, priority = 45668, weight = 32509, duplicate = 18240}, {gw_index = 32767, rule_id = 2832509560, prefix_len = 32509, priority = 0, weight = 809781140, duplicate = 32767}, {gw_index = 18592, rule_id = 22, prefix_len = 25472, priority = 21787, weight = 21897, duplicate = 0}, {gw_index = 0, rule_id = 2866689512, prefix_len = 32509, priority = 0, weight = 1, duplicate = 0}, {gw_index = 25492, rule_id = 21897, prefix_len = 56064, priority = 35070, weight = 3201662253, duplicate = 18272}, {gw_index = 32767, rule_id = 2832509702, prefix_len = 32509, priority = 0, weight = 809781140, duplicate = 32767}, {gw_index = 0, rule_id = 0, prefix_len = 18352, priority = 12356, weight = 32767, duplicate = 41793}, {gw_index = 32509, rule_id = 3631862402, prefix_len = 55846, priority = 22694, weight = 809782152, duplicate = 32767}, { gw_index = 28360, rule_id = 32509, prefix_len = 18160, priority = 43608, weight = 32509, duplicate = 32}, {gw_index = 1, rule_id = 1427858324, prefix_len = 21897, priority = 0, weight = 2866211776, duplicate = 32509}, {gw_index = 46912, rule_id = 32509, prefix_len = 18160, priority = 43608, weight = 32509, duplicate = 44720}, {gw_index = 32767, rule_id = 0, prefix_len = 0, priority = 0, weight = 809782152, duplicate = 32767}, {gw_index = 18936, rule_id = 32509, prefix_len = 19400, priority = 12356, weight = 32767, duplicate = 44840}, {gw_index = 32509, rule_id = 2857912048, prefix_len = 32509, priority = 0, weight = 809781424, duplicate = 32767}, {gw_index = 51007, rule_id = 32509, prefix_len = 19400, priority = 12356, weight = 32767, duplicate = 44840}, {gw_index = 32509, rule_id = 2857912824, prefix_len = 32509, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 2868540824, duplicate = 32509}, {gw_index = 19228, rule_id = 32767, prefix_len = 18160, priority = 43608, weight = 32509, duplicate = 44720}, {gw_index = 32767, rule_id = 2868539048, prefix_len = 32509, priority = 0, weight = 0, duplicate = 0}, {gw_index = 18160, rule_id = 32509, prefix_len = 56064, priority = 35070, weight = 3201662253, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 2, priority = 0, weight = 0, duplicate = 0}, {gw_index = 50739, rule_id = 21897, prefix_len = 32, priority = 0, weight = 0, duplicate = 45104}, {gw_index = 32509, rule_id = 809781616, prefix_len = 32767, priority = 0, weight = 2832519634, duplicate = 32509}, {gw_index = 0, rule_id = 0, prefix_len = 19400, priority = 12356, weight = 32767, duplicate = 44840}, {gw_index = 32509, rule_id = 2857912048, prefix_len = 32509, priority = 0, weight = 3743011458, duplicate = 55846}, {gw_index = 53890, rule_id = 206181164, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, { gw_index = 0, rule_id = 0, prefix_len = 0, priority = 0, weight = 2298403584, duplicate = 32045}, {gw_index = 0, rule_id = 0, prefix_len = 56064, priority = 35070, weight = 3201662253, duplicate = 0}, {gw_index = 0, rule_id = 0, prefix_len = 2, priority = 0, weight = 0, duplicate = 0}, {gw_index = 19400, rule_id = 32767, prefix_len = 46952, priority = 43654, weight = 32509, duplicate = 18160}, {gw_index = 32509, rule_id = 0, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, {gw_index = 44720, rule_id = 32509, prefix_len = 56064, priority = 35070, weight = 3201662253, duplicate = 18992}, {gw_index = 32767, rule_id = 1423240445, prefix_len = 21897, priority = 0, weight = 2868540816, duplicate = 32509}, {gw_index = 19400, rule_id = 32767, prefix_len = 46928, priority = 43654, weight = 32509, duplicate = 18160}, {gw_index = 32509, rule_id = 809782144, prefix_len = 32767, priority = 0, weight = 1424974825, duplicate = 21897}, {gw_index = 18928, rule_id = 32767, prefix_len = 57360, priority = 43603, weight = 32509, duplicate = 32}, {gw_index = 0, rule_id = 2857623568, prefix_len = 32509, priority = 0, weight = 809781808, duplicate = 32767}, {gw_index = 54047, rule_id = 32509, prefix_len = 0, priority = 0, weight = 0, duplicate = 0}, { gw_index = 0, rule_id = 134217728, prefix_len = 0, priority = 0, weight = 122341296, duplicate = 0}, {gw_index = 44784, rule_id = 0, prefix_len = 14416, priority = 181, weight = 0, duplicate = 46560}, {gw_index = 0, rule_id = 16, prefix_len = 0, priority = 0, weight = 296, duplicate = 0}, {gw_index = 56064, rule_id = 3201662253, prefix_len = 19040, priority = 12356, weight = 32767, duplicate = 38381}, {gw_index = 21897, rule_id = 0, prefix_len = 0, priority = 0, weight = 80, duplicate = 5}, { gw_index = 47600, rule_id = 32509, prefix_len = 0, priority = 0, weight = 32509, duplicate = 19232}, {gw_index = 32767, rule_id = 1424954698, prefix_len = 21897, priority = 0, weight = 32, duplicate = 0}, {gw_index = 57360, rule_id = 32509, prefix_len = 32, priority = 0, weight = 0, duplicate = 7}, {gw_index = 32509, rule_id = 2857623568, prefix_len = 32509, priority = 0, weight = 2861742528, duplicate = 32509}, {gw_index = 0, rule_id = 0, prefix_len = 50739, priority = 21762, weight = 21897, duplicate = 32}, { gw_index = 0, rule_id = 2992943152, prefix_len = 32509, priority = 0, weight = 809782320, duplicate = 32767}, {gw_index = 18160, rule_id = 32509, prefix_len = 41232, priority = 43770, weight = 32509, duplicate = 44720}, {gw_index = 32767, rule_id = 1216, prefix_len = 0, priority = 0, weight = 1423251666, duplicate = 21897}, {gw_index = 31872, rule_id = 32509, prefix_len = 19336, priority = 12356, weight = 32767, duplicate = 19232}} rules = 0x7efd86889f60 rule = 0x3837333334313030 pl = 0x7efd8793d120 gws = 0x7efd86d47500 t = 0x7fff30444070 furi = {user = {s = 0x7efdaa92b9d4 "+xxx@xxx", len = 13}, passwd = {s = 0x0, len = 0}, host = {s = 0x7efdaa92b9e2 "xxxx", len = 13}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = { s = 0x0, len = 0}, port_no = 0, proto = 0, type = SIP_URI_T, flags = 0, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = { s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = { s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}} avp = 0x7efdaa64a29d st = {flags = 0, id = 0, name = {n = 0, s = {s = 0x0, len = 0}, re = 0x0}, avp = 0x0} __func__ = "ki_load_gws_furi" #1 0x00007efda9eaac2a in load_gws (_m=0x7efdaa5846f0, argc=3, argv=0x5589550fb710 <mod_f_params+48>) at lcr_mod.c:2519 ruri_user = {s = 0x7efdaa92b9a0 "+xxx", len = 13} from_uri = {s = 0x7efdaa92b9d0 "sip:+xxxxxxxxxx@xxx.xx.xx.xxx", len = 31} lcr_id = 1 tmp = 0x7efdaa869f11 "" __func__ = "load_gws" #2 0x0000558954c0bd9b in do_action (h=0x7fff3044aeb0, a=0x7efdaa86a610, msg=0x7efdaa5846f0) at core/action.c:1181 ret = -5 v = 1 dst = {send_sock = 0x7efdaa5846f0, to = {s = {sa_family = 44720, sa_data = "D0\377\177\000\000(\001\000\000\000\000\000"}, sin = {sin_family = 44720, sin_port = 12356, sin_addr = {s_addr = 32767}, sin_zero = "(\001\000\000\000\000\000"}, sin6 = { sin6_family = 44720, sin6_port = 12356, sin6_flowinfo = 32767, sin6_addr = {__in6_u = {__u6_addr8 = "(\001", '\000' <repeats 13 times>, __u6_addr16 = {296, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {296, 0, 0, 0}}}, sin6_scope_id = 809783872}, sas = { ss_family = 44720, __ss_padding = "D0\377\177\000\000(\001", '\000' <repeats 14 times>, "@RD0\377\177\000\000\355\225\310T\211U", '\000' <repeats 11 times>, "\333\376\210-}վ\240\340S\252\375~\000\000\000\000\000\000\002", '\000' <repeats 11 times>, "\322\030\325T\211U\000\000 \000\000\000\000\000\000\000\320RD0\377\177\000\000pSD0\377\177\000\000\211\366\315T\211U\000", __ss_align = 139627952720888}}, id = -1434074608, send_flags = {f = 32509, blst_imask = 0}, proto = -16 '\360', proto_pad0 = 70 'F', proto_pad1 = -21928} tmp = 0x7efdb264b030 <__syslog> "H\201\354", <incomplete sequence \330> new_uri = 0x200000000 <error: Cannot access memory at address 0x200000000> end = 0x200000000 <error: Cannot access memory at address 0x200000000> crt = 0x7fff30444ed0 "" cmd = 0x7efdaa5a2cd0 len = 0 user = 0 uri = {user = {s = 0x558954ef1321 <split_frag+201> "\270", len = 128}, passwd = {s = 0x7efd8b863760 "\200", len = -1996563712}, host = {s = 0x7efd8b863760 "\200", len = 0}, port = {s = 0x0, len = 1426245171}, params = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, sip_params = {s = 0x7fff30445090 "\260QD0\377\177", len = 1421936895}, headers = {s = 0x35aa84bae8 <error: Cannot access memory at address 0x35aa84bae8>, len = 1025}, port_no = 0, proto = 34386, type = 32509, flags = (unknown: 0x8b863760), transport = {s = 0x3a70697300000000 <error: Cannot access memory at address 0x3a70697300000000>, len = -1437055248}, ttl = {s = 0x7efdaa85ec60 "\320\t", len = 809783504}, user_param = { s = 0x1 <error: Cannot access memory at address 0x1>, len = -2041403312}, maddr = {s = 0x7fff30445038 "\030̅\252\375~", len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, transport_val = {s = 0x7fff30444fd0 "\300PD0\377\177", len = 1424983377}, ttl_val = {s = 0x72 <error: Cannot access memory at address 0x72>, len = 809783280}, user_param_val = { s = 0x40000000000020 <error: Cannot access memory at address 0x40000000000020>, len = -1434679252}, maddr_val = {s = 0x7fff304450c0 "", len = 1424795871}, method_val = {s = 0x7efdaa92b370 "sip:+xxxxxxx@xxx.xx.xxx;transport=TCP", len = 53}, lr_val = {s = 0x7efdaa7c882d "request_uri)", len = 11}, r2_val = {s = 0x7efdaa584a18 "\202\263\222\252\375~", len = 809784016}, gr_val = {s = 0x7efdaa85cc18 "", len = -1437055248}} next_hop = {user = {s = 0x7fff304450e0 "", len = -1462450242}, passwd = {s = 0x7fff304452d0 "", len = -1434072040}, host = {s = 0x7efdaa5849f8 "t\263\222\252\375~", len = -1437055248}, port = { s = 0x7fff00000035 <error: Cannot access memory at address 0x7fff00000035>, len = -1996563712}, params = {s = 0x7fff304450ac "\375~", len = 0}, sip_params = {s = 0x0, len = 1426245171}, headers = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, port_no = 20912, proto = 12356, type = 32767, flags = (URI_USER_NORMALIZE | unknown: 0x54c1106c), transport = {s = 0x0, len = -1437055248}, ttl = {s = 0x7efdaa85ec60 "\320\t", len = 809807536}, user_param = {s = 0x0, len = 0}, maddr = { s = 0x0, len = -1}, method = {s = 0x200000000 <error: Cannot access memory at address 0x200000000>, len = -208022910}, lr = {s = 0x0, len = 1426245171}, r2 = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr = { s = 0x58a6da26ccb9d282 <error: Cannot access memory at address 0x58a6da26ccb9d282>, len = 1514263170}, transport_val = {s = 0x7efd00000000 <error: Cannot access memory at address 0x7efd00000000>, len = 53}, ttl_val = {s = 0x7efdaa7c882d "request_uri)", len = 11}, user_param_val = {s = 0x0, len = -1996563712}, maddr_val = {s = 0x1000000000 <error: Cannot access memory at address 0x1000000000>, len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, r2_val = {s = 0x7fff30445260 "pSD0\377\177", len = -1462314118}, gr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}} u = 0x558954c1106d <run_actions_safe+169> port = 0 dst_host = 0x58a6da26c9d9d282 i = 3 flags = 0 avp = 0x7efdaafc9330 st = {flags = 1424947432, id = 21897, name = {n = -1954138112, s = {s = 0x7efd8b863800 "\020", len = -2041446400}, re = 0x7efd8b863800}, avp = 0x7efdaac78198} sct = 0x100000000 sjt = 0x0 rve = 0x7efdaafa7c80 mct = 0x7efdaafcb790 rv = 0x7efdaa86b748 rv1 = 0x7efdaa5846f0 c1 = {cache_type = 809784048, val_type = 32767, c = {avp_val = {n = 1423653555, s = { s = 0x558954db3ab3 <rval_get_int+341> "\205\300\017\237\300\017\266\320H\213\205\370\376\377\377\211\020H\213\205\b\377\377\377\213@\004\203\340\371\211\302H\213\205\b\377\377\377\211P\004\351y\006", len = 1}, re = 0x558954db3ab3 <rval_get_int+341>}, pval = {rs = {s = 0x558954db3ab3 <rval_get_int+341> "\205\300\017\237\300\017\266\320H\213\205\370\376\377\377\211\020H\213\205\b\377\377\377\213@\004\203\340\371\211\302H\213\205\b\377\377\377\211P\004\351y\006", len = 1}, ri = -1437055248, flags = 32509}}, i2s = "\202\263\222\252\375~\000\000\000\000\000\000\000\000\000\000x텪\375~"} s = {s = 0x7efdaa92b9d0 "sip:xxx@xxx", len = 31} srevp = {0x7fff304452d0, 0xbed57d2d88fedb00} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #3 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa86a610, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa86a610 ret = -1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809784496 __func__ = "run_actions" #4 0x0000558954bfdb07 in do_action (h=0x7fff3044aeb0, a=0x7efdaa860940, msg=0x7efdaa5846f0) at core/action.c:703 ret = -5 v = 0 dst = {send_sock = 0x7efdaa5846f0, to = {s = {sa_family = 44720, sa_data = "D0\377\177\000\000\020\253\247\000\000\000\000"}, sin = {sin_family = 44720, sin_port = 12356, sin_addr = {s_addr = 32767}, sin_zero = "\020\253\247\000\000\000\000"}, sin6 = { sin6_family = 44720, sin6_port = 12356, sin6_flowinfo = 32767, sin6_addr = {__in6_u = {__u6_addr8 = "\020\253\247\000\000\000\000\000\260\063\265\000\000\000\000", __u6_addr16 = {43792, 167, 0, 0, 13232, 181, 0, 0}, __u6_addr32 = {10988304, 0, 11875248, 0}}}, sin6_scope_id = 13940192}, sas = {ss_family = 44720, __ss_padding = "D0\377\177\000\000\020\253\247\000\000\000\000\000\260\063\265\000\000\000\000\000\340\265\324\000\000\000\000\000\000\333\376\210-}վ,\001\000\000\002\000\000\000\000\333\376\210-}վ`*[\252\375~\000\000\030\r\202\252\375~\000\000\000\000\000\000\000\000\000\000\063\306\002U\211U\000\000 \000\000\000\000\000\000\000\060\260d\262\375~\000\000\260ZD0\377\177\000\000\306\017\333T\211U\000", __ss_align = 32}}, id = -1434317544, send_flags = {f = 32509, blst_imask = 0}, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0} tmp = 0x130445be0 <error: Cannot access memory at address 0x130445be0> new_uri = 0x15 <error: Cannot access memory at address 0x15> end = 0x400000000 <error: Cannot access memory at address 0x400000000> crt = 0x7efdaa81ca60 "\340.\202\252\375~" cmd = 0x7efdaa8205a8 len = -1996563712 user = -1093305043 uri = {user = {s = 0x7efdaa54a1f5 "", len = -1437294091}, passwd = {s = 0x7efd88e7bd30 "", len = 0}, host = {s = 0x7fff30445740 "\360WD0\377\177", len = -1462943338}, port = {s = 0x0, len = 809785192}, params = {s = 0x7fff30445770 "\021\001", len = 809785392}, sip_params = {s = 0x7efd8b863550 "", len = 0}, headers = {s = 0x0, len = 0}, port_no = 22512, proto = 12356, type = 32767, flags = (URI_USER_NORMALIZE | unknown: 0xa8cc7f80), transport = {s = 0x7fff30445830 "\340\241T\252\375~", len = -1437055248}, ttl = { s = 0x4 <error: Cannot access memory at address 0x4>, len = -1996563712}, user_param = {s = 0x111 <error: Cannot access memory at address 0x111>, len = -1434319555}, maddr = {s = 0x7efd00000014 <error: Cannot access memory at address 0x7efd00000014>, len = -1954139248}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = -1996563712}, r2 = {s = 0x0, len = -1996563712}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 1426245171}, ttl_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, user_param_val = {s = 0x7fff304458c0 "P_D0\377\177", len = -1462992004}, maddr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}, method_val = {s = 0x7efdaa822f10 "\340.\202\252\375~", len = -1437055248}, lr_val = { s = 0x558954eef8e8 <qm_insert_free+59> "\005\363\003", len = 809786344}, r2_val = {s = 0x7efdaa54a1e0 "xxx", len = 21}, gr_val = {s = 0x40100000020 <error: Cannot access memory at address 0x40100000020>, len = 0}} next_hop = {user = {s = 0x7efd8652a068 "", len = 1424974825}, passwd = {s = 0x7fff304458a0 "", len = -1437343728}, host = {s = 0x7efd8b863540 "P", len = -1437343728}, port = {s = 0x7fff304458e0 "\020YD0\377\177", len = -1996563712}, params = { s = 0x7efd8b8635a0 "P", len = 0}, sip_params = {s = 0x0, len = 1426245171}, headers = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, port_no = 24400, proto = 12356, type = 32767, flags = (URI_SIP_USER_PHONE | unknown: 0x54c01c34), transport = {s = 0x128 <error: Cannot access memory at address 0x128>, len = -1996563712}, ttl = {s = 0x7fff30445910 "\340YD0\377\177", len = -1437055248}, user_param = {s = 0x7efdaa823350 "\356\b", len = 809787696}, maddr = {s = 0x7efdaa53ec30 "", len = 0}, method = {s = 0x7fff304459e0 "\220ZD0\377\177", len = 1424958313}, lr = {s = 0x7efdaa92b370 "sip:xxx@xxx;transport=TCP", len = -1437343728}, r2 = { s = 0x7fff30445960 "\220YD0\377\177", len = -1433226400}, gr = {s = 0x4c0 <error: Cannot access memory at address 0x4c0>, len = -1437343728}, transport_val = {s = 0x7efdaa92b330 "\020", len = -1433225152}, ttl_val = {s = 0x7fff30445990 "", len = 1424983377}, user_param_val = {s = 0x4d <error: Cannot access memory at address 0x4d>, len = -1996563712}, maddr_val = {s = 0x1a00d4b5e0 <error: Cannot access memory at address 0x1a00d4b5e0>, len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1996563712}, r2_val = {s = 0x7efdaa820d18 "\002", len = 0}, gr_val = {s = 0x0, len = 1426245171}} u = 0x7efdaa5846f0 port = 181 dst_host = 0xbed57d2d88fedb00 i = 18 flags = 0 avp = 0x7efdaa5846f0 st = {flags = 32, id = 0, name = {n = 0, s = {s = 0x200000000 <error: Cannot access memory at address 0x200000000>, len = 0}, re = 0x200000000}, avp = 0x55895502c633} sct = 0x7efdaa858190 sjt = 0x7efdaa96ae62 rve = 0x7efdaa85ed70 mct = 0x0 rv = 0x7efdaa54a1e0 rv1 = 0x7fff00000015 c1 = {cache_type = 809786000, val_type = 32767, c = {avp_val = {n = 1423642494, s = {s = 0x558954db0f7e <rval_destroy_helper+1115> "\353\005\350ۑ\342\377\220H\213E\310dH+\004%(", len = 0}, re = 0x558954db0f7e <rval_destroy_helper+1115>}, pval = {rs = { s = 0x558954db0f7e <rval_destroy_helper+1115> "\353\005\350ۑ\342\377\220H\213E\310dH+\004%(", len = 0}, ri = -1434317544, flags = 32509}}, i2s = "\340[D0\377\177\000\000\200\005\202\252\375~\000\000x[D0\377\177"} s = {s = 0x7fff304456c0 "", len = 0} srevp = {0x20, 0x7efdb264b030 <__syslog>} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #5 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa84d5f0, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa860940 ret = 1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809786592 __func__ = "run_actions" #6 0x0000558954bfdb07 in do_action (h=0x7fff3044aeb0, a=0x7efdaa824ec0, msg=0x7efdaa5846f0) at core/action.c:703 ret = -5 v = 0 dst = {send_sock = 0x7efdaa5846f0, to = {s = {sa_family = 44720, sa_data = "D0\377\177\000\000ȅx\252\375~\000"}, sin = {sin_family = 44720, sin_port = 12356, sin_addr = {s_addr = 32767}, sin_zero = "ȅx\252\375~\000"}, sin6 = {sin6_family = 44720, sin6_port = 12356, sin6_flowinfo = 32767, sin6_addr = {__in6_u = {__u6_addr8 = "ȅx\252\375~\000\000\000\000\000\000\000\000\000", __u6_addr16 = {34248, 43640, 32509, 0, 0, 0, 0, 0}, __u6_addr32 = {2860025288, 32509, 0, 0}}}, sin6_scope_id = 0}, sas = { ss_family = 44720, __ss_padding = "D0\377\177\000\000ȅx\252\375~", '\000' <repeats 14 times>, "\377\177\000\000P\256\226\252\375~", '\000' <repeats 11 times>, "\333\376\210-}վ\250H[\252\375~\000\000\000\000\000\000\002", '\000' <repeats 11 times>, "\322\030\325T\211U\000\000 \000\000\000\000\000\000\000\060cD0\377\177\000\000\320cD0\377\177\000\000\211\366\315T\211U\000", __ss_align = 139627952462296}}, id = -1434335200, send_flags = {f = 32509, blst_imask = 0}, proto = -16 '\360', proto_pad0 = 70 'F', proto_pad1 = -21928} tmp = 0x55895502c633 "INFO" new_uri = 0x1390 <error: Cannot access memory at address 0x1390> end = 0x0 crt = 0x20 <error: Cannot access memory at address 0x20> cmd = 0x7efdaa584a18 len = -1466248417 user = 32509 uri = {user = {s = 0x558900000001 <error: Cannot access memory at address 0x558900000001>, len = 128}, passwd = {s = 0x7efd8b863380 "\200", len = -1996563712}, host = {s = 0x7efd8b863380 "\200", len = 0}, port = {s = 0x0, len = 1426245171}, params = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, sip_params = {s = 0x7fff304460f0 "\020bD0\377\177", len = 1421936895}, headers = {s = 0x0, len = 1426245171}, port_no = 32, proto = 0, type = ERROR_URI_T, flags = (unknown: 0xb264b030), transport = {s = 0x7fff304460a0 "\340aD0\377\177", len = -1437055248}, ttl = {s = 0x7efdaa823350 "\356\b", len = 809787696}, user_param = {s = 0x7efdaa81ebb0 "\343\b", len = 809807536}, maddr = {s = 0x0, len = 0}, method = { s = 0x0, len = 1}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, transport_val = {s = 0x58a6da26e959d282 <error: Cannot access memory at address 0x58a6da26e959d282>, len = 1514263170}, ttl_val = {s = 0x0, len = 809787472}, user_param_val = {s = 0x407efdaa53e230 <error: Cannot access memory at address 0x407efdaa53e230>, len = -1434679252}, maddr_val = {s = 0x7fff30446120 "paD0\377\177", len = 1424795871}, method_val = { s = 0x7efdaa96ae50 "\002", len = 53}, lr_val = {s = 0x7efdaa7c882d "request_uri)", len = 11}, r2_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}, gr_val = {s = 0x72 <error: Cannot access memory at address 0x72>, len = 1426245171}} next_hop = {user = {s = 0x7efd8b863390 "@", len = -1954139232}, passwd = {s = 0x7fff30446140 " ", len = -1996563712}, host = {s = 0x7fff304461e0 "PcD0\377\177", len = 1423653555}, port = {s = 0x100000035 <error: Cannot access memory at address 0x100000035>, len = -1996563712}, params = {s = 0x7fff304462a0 "", len = 0}, sip_params = {s = 0x0, len = 1426245171}, headers = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, port_no = 25104, proto = 12356, type = 32767, flags = (URI_USER_NORMALIZE | unknown: 0x54c1106c), transport = {s = 0x0, len = -1437055248}, ttl = {s = 0x7efdaa823350 "\356\b", len = -1996563712}, user_param = {s = 0x7fff30446170 "\340F\202\252\375~", len = 0}, maddr = {s = 0x0, len = 1426245171}, method = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, lr = {s = 0x7fff30446210 "PcD0\377\177", len = 1423531231}, r2 = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1437055248}, gr = {s = 0x7efdaa8246e0 "\002", len = 809807536}, transport_val = {s = 0x100000000 <error: Cannot access memory at address 0x100000000>, len = 53}, ttl_val = {s = 0x7efdaa7c882d "request_uri)", len = 11}, user_param_val = {s = 0x0, len = -1996563712}, maddr_val = { s = 0x1000000000 <error: Cannot access memory at address 0x1000000000>, len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1996563712}, r2_val = {s = 0x7fff30446350 "\300dD0\377\177", len = 0}, gr_val = {s = 0x0, len = 1426245171}} u = 0x7efdb264b030 <__syslog> port = 43603 dst_host = 0x0 i = 16 flags = 32767 avp = 0x7fff30445ed0 st = {flags = 32, id = 0, name = {n = -1302024144, s = {s = 0x7efdb264b030 <__syslog> "H\201\354", <incomplete sequence \330>, len = 809787728}, re = 0x7efdb264b030 <__syslog>}, avp = 0x558954d92a55 <eval_elem+2278>} sct = 0x1600000001 sjt = 0x0 rve = 0xaaa5813c4 mct = 0x7fff30445ed4 rv = 0x0 rv1 = 0x558954d90420 <check_self_op+83> c1 = {cache_type = 809788240, val_type = 32767, c = {avp_val = {n = 1423653453, s = {s = 0x558954db3a4d <rval_get_int+239> "H\213\225\370\376\377\377\211\002H\213\205\370\376\377\377\213", len = -1437055248}, re = 0x558954db3a4d <rval_get_int+239>}, pval = { rs = {s = 0x558954db3a4d <rval_get_int+239> "H\213\225\370\376\377\377\211\002H\213\205\370\376\377\377\213", len = -1437055248}, ri = 809807536, flags = 32767}}, i2s = "P\256\226\252\375~\000\000\000\000\000\000\000\000\000\000\070G\202\252\375~"} s = {s = 0x0, len = 0} srevp = {0x20, 0x7efdb264b030 <__syslog>} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #7 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa824ec0, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa824ec0 ret = -1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809788688 __func__ = "run_actions" #8 0x0000558954c01b16 in do_action (h=0x7fff3044aeb0, a=0x7efdaa8250e0, msg=0x7efdaa5846f0) at core/action.c:1070 ret = 1 v = 1 dst = {send_sock = 0x7efdaa5846f0, to = {s = {sa_family = 44720, sa_data = "D0\377\177\000\000\220\005\000\000\000\000\000"}, sin = {sin_family = 44720, sin_port = 12356, sin_addr = {s_addr = 32767}, sin_zero = "\220\005\000\000\000\000\000"}, sin6 = { sin6_family = 44720, sin6_port = 12356, sin6_flowinfo = 32767, sin6_addr = {__in6_u = {__u6_addr8 = "\220\005", '\000' <repeats 13 times>, __u6_addr16 = {1424, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {1424, 0, 0, 0}}}, sin6_scope_id = 0}, sas = { ss_family = 44720, __ss_padding = "D0\377\177\000\000\220\005", '\000' <repeats 22 times>, "\322\030\325T\211U", '\000' <repeats 11 times>, "\333\376\210-}վ\230\323v\252\375~", '\000' <repeats 18 times>, "\322\030\325T\000\020\000\000\000\004\000\000\n\000\000\000@mD0\377\177\000\000\000lD0\377\177\000\000\211\366\315T\211U\000", __ss_align = 139627951675592}}, id = -1435120096, send_flags = {f = 32509, blst_imask = 0}, proto = -16 '\360', proto_pad0 = 70 'F', proto_pad1 = -21928} tmp = 0x7efda8d4ab06 <sint2str+47> "\311\303UH\211\345H\211}\350\211u\344\211U\340\213E\340H\215P\377H\213E\350H\001\320H\211E\370\353\037H\213E\370\017\266" new_uri = 0x5589551b6391 <ut_buf_int2str+17> "5000" end = 0x0 crt = 0x7fff30446684 "" cmd = 0x7fff30446680 len = 0 user = 0 uri = {user = {s = 0x0, len = 1426245171}, passwd = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1996563712}, host = {s = 0x7fff304467a0 "\300gD0\377\177", len = 0}, port = {s = 0x0, len = 1426245171}, params = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, sip_params = {s = 0x7fff30446920 "@jD0\377\177", len = 1421936895}, headers = {s = 0x5589551b6391 <ut_buf_int2str+17> "5000", len = -1996563712}, port_no = 26560, proto = 12356, type = 32767, flags = (URI_SIP_USER_PHONE | unknown: 0xa8d4ab04), transport = {s = 0x7fff304467f4 "", len = -1437055248}, ttl = {s = 0x7efdaa7807f0 "C\a", len = 809789792}, user_param = {s = 0x7fff304467f0 "", len = 809789808}, maddr = { s = 0x7efdaa771d48 "\001", len = -1437055248}, method = {s = 0x0, len = 1427858321}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 809789808}, transport_val = {s = 0x7efdaa771d30 "\017", len = -1437055248}, ttl_val = {s = 0x7fff30446870 "0iD0\377\177", len = 0}, user_param_val = {s = 0x100000000 <error: Cannot access memory at address 0x100000000>, len = 809790536}, maddr_val = {s = 0x7efdaa76d3b8 "", len = -1437055248}, method_val = { s = 0x7fff30446930 "\360FX\252\375~", len = 1423240445}, lr_val = {s = 0x0, len = 809790536}, r2_val = {s = 0x7efdaa76d3a0 "\026", len = -1996563712}, gr_val = {s = 0x7fff30446a10 "\200kD0\377\177", len = 0}} next_hop = {user = {s = 0x0, len = 1423251666}, passwd = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 809789808}, host = {s = 0x7fff30446a10 "\200kD0\377\177", len = 1423654338}, port = {s = 0x7efdaa5846f0 "jS\033", len = -1996563712}, params = {s = 0x7fff30446920 "@jD0\377\177", len = 0}, sip_params = {s = 0x0, len = 1426245171}, headers = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, port_no = 27200, proto = 12356, type = 32767, flags = (URI_USER_NORMALIZE | unknown: 0x54c1106c), transport = {s = 0x7efdaa5846f0 "jS\033", len = -1437055248}, ttl = {s = 0x7efdaa7807f0 "C\a", len = 809807536}, user_param = {s = 0x7fff30446c40 "", len = 0}, maddr = {s = 0x0, len = 1}, method = { s = 0x200000000 <error: Cannot access memory at address 0x200000000>, len = -2131111294}, lr = {s = 0x0, len = 1426245171}, r2 = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr = { s = 0x58a6da269d99d282 <error: Cannot access memory at address 0x58a6da269d99d282>, len = 1514263170}, transport_val = {s = 0x7efd00000000 <error: Cannot access memory at address 0x7efd00000000>, len = 1}, ttl_val = {s = 0x7efdaa62424d "acc_request_source)", len = -1996563712}, user_param_val = {s = 0x7fff30446a30 "\200kD0\377\177", len = -1996563712}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, r2_val = {s = 0x7fff30446b80 "\360lD0\377\177", len = 1423675477}, gr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}} u = 0x7efdaa5846f0 port = 65535 dst_host = 0x0 i = 66 flags = 0 avp = 0x7efdaa76c1e0 st = {flags = 2858662608, id = 32509, name = {n = 19, s = {s = 0x7efd00000013 <error: Cannot access memory at address 0x7efd00000013>, len = 809789416}, re = 0x7efd00000013}, avp = 0x1600000000} sct = 0x7efdaa5846f0 sjt = 0x0 rve = 0x7efdaa824730 mct = 0x7efdaa760948 rv = 0x7fff30446650 rv1 = 0x7fff304467f0 c1 = {cache_type = 809790336, val_type = 32767, c = {avp_val = {n = 1423653555, s = { s = 0x558954db3ab3 <rval_get_int+341> "\205\300\017\237\300\017\266\320H\213\205\370\376\377\377\211\020H\213\205\b\377\377\377\213@\004\203\340\371\211\302H\213\205\b\377\377\377\211P\004\351y\006", len = -1437055248}, re = 0x558954db3ab3 <rval_get_int+341>}, pval = {rs = {s = 0x558954db3ab3 <rval_get_int+341> "\205\300\017\237\300\017\266\320H\213\205\370\376\377\377\211\020H\213\205\b\377\377\377\213@\004\203\340\371\211\302H\213\205\b\377\377\377\211P\004\351y\006", len = -1437055248}, ri = 809807536, flags = 32767}}, i2s = "@lD0\377\177\000\000\000\000\000\000\000\000\000\000\350\020x\252\375~"} s = {s = 0x7fff30446788 "\377\b\301T\211U", len = 0} srevp = {0x7fff30446b80, 0xbed57d2d88fedb00} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #9 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa81c230, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa8250e0 ret = 1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809790784 __func__ = "run_actions" #10 0x0000558954bfdb07 in do_action (h=0x7fff3044aeb0, a=0x7efdaa783a40, msg=0x7efdaa5846f0) at core/action.c:703 ret = -5 v = 1 dst = {send_sock = 0x13c4, to = {s = {sa_family = 50739, sa_data = "\002U\211U\000\000 \000\000\000\000\000\000"}, sin = {sin_family = 50739, sin_port = 21762, sin_addr = {s_addr = 21897}, sin_zero = " \000\000\000\000\000\000"}, sin6 = {sin6_family = 50739, sin6_port = 21762, sin6_flowinfo = 21897, sin6_addr = {__in6_u = {__u6_addr8 = " \000\000\000\000\000\000\000\060\260d\262\375~\000", __u6_addr16 = {32, 0, 0, 0, 45104, 45668, 32509, 0}, __u6_addr32 = {32, 0, 2992943152, 32509}}}, sin6_scope_id = 809792416}, sas = {ss_family = 50739, __ss_padding = "\002U\211U\000\000 \000\000\000\000\000\000\000\060\260d\262\375~\000\000\240sD0\377\177\000\000\253f\366\250\375~\000\000\360rD0\377\177\000\000\000\333\376\210-}վ\260~[\252\375~\000\000\000\000\000\000\002", '\000' <repeats 11 times>, "\322\030\325T\211U\000\000 \000\000\000\000\000\000\000\220sD0\377\177\000\000\060tD0\377\177\000\000\211\366\315T\211U\000", __ss_align = 139627950435128}}, id = -1436358080, send_flags = {f = 32509, blst_imask = 0}, proto = -16 '\360', proto_pad0 = 70 'F', proto_pad1 = -21928} tmp = 0x200000000 <error: Cannot access memory at address 0x200000000> new_uri = 0x558954e2d2ae <cmp_hdrname_str+1259> "H\213]\310dH+\034%(" end = 0x0 crt = 0x0 cmd = 0x7efdaa5a9d30 len = 0 user = 2 uri = {user = {s = 0x558954ef1321 <split_frag+201> "\270", len = 80}, passwd = {s = 0x7efd8b862c90 "P", len = -2041446400}, host = {s = 0x7efd8b862c90 "P", len = 30624}, port = {s = 0x7efd8b862cf0 "P", len = -1954140928}, params = { s = 0x7fff30447060 "\220pD0\377\177", len = 1424954550}, sip_params = {s = 0x50 <error: Cannot access memory at address 0x50>, len = -2041446400}, headers = {s = 0xa <error: Cannot access memory at address 0xa>, len = 1025}, port_no = 0, proto = 34386, type = 32509, flags = (unknown: 0x8b862c90), transport = {s = 0x7fff30447670 "\020xD0\377\177", len = -1996563712}, ttl = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}, user_param = {s = 0x1 <error: Cannot access memory at address 0x1>, len = -2041403312}, maddr = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}, method = {s = 0x130447060 <error: Cannot access memory at address 0x130447060>, len = -2041403312}, lr = {s = 0x7fff30447060 "\220pD0\377\177", len = 1424947257}, r2 = {s = 0x0, len = -2041403312}, gr = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, transport_val = {s = 0x7fff30447090 "\200qD0\377\177", len = 1424983377}, ttl_val = {s = 0x41 <error: Cannot access memory at address 0x41>, len = 809791664}, user_param_val = {s = 0x87efdaa8e4f50 <error: Cannot access memory at address 0x87efdaa8e4f50>, len = -1436512180}, maddr_val = {s = 0x7fff30447180 "\320qD0\377\177", len = 1424795871}, method_val = {s = 0x7efdaa80e380 "30013", len = 5}, lr_val = {s = 0x7efdaa60904d "peer_in_id)", len = 10}, r2_val = {s = 0x7fff304471c0 "", len = 1422279978}, gr_val = {s = 0x41 <error: Cannot access memory at address 0x41>, len = 0}} next_hop = {user = {s = 0x7efd8b862ca0 "\b", len = -1954141008}, passwd = {s = 0x30363035304475e7 <error: Cannot access memory at address 0x30363035304475e7>, len = 0}, host = {s = 0x0, len = 1426245171}, port = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, params = {s = 0x7fff30447260 " s\001", len = -1462359849}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x7efdaa6036f0 "", len = -1996563712}, port_no = 57800, proto = 43618, type = 32509, flags = (URI_USER_NORMALIZE | unknown: 0x4), transport = {s = 0x0, len = 1426245171}, ttl = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, user_param = {s = 0x7fff304471d0 "0rD0\377\177", len = 1424796052}, maddr = { s = 0x7efdaa80e380 "30013", len = 5}, method = {s = 0x7efdaa60904d "peer_in_id)", len = 10}, lr = {s = 0x11300000000 <error: Cannot access memory at address 0x11300000000>, len = 1427857984}, r2 = {s = 0x0, len = -1954141024}, gr = { s = 0x7fff30447230 " sD0\377\177", len = 1424796326}, transport_val = {s = 0x7efdaa80e380 "30013", len = 5}, ttl_val = {s = 0x7efdaa60904d "peer_in_id)", len = 10}, user_param_val = {s = 0x0, len = 0}, maddr_val = { s = 0x1000000000 <error: Cannot access memory at address 0x1000000000>, len = 1427857984}, method_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}, lr_val = {s = 0x7fff30447320 "0tD0\377\177", len = -1462317108}, r2_val = { s = 0x7fff30447390 "", len = 0}, gr_val = {s = 0x7efdaa609000 "", len = -1437055248}} u = 0x55895502c633 port = 35070 dst_host = 0x55895502c633 i = 14 flags = 32509 avp = 0x20 st = {flags = 1424947432, id = 21897, name = {n = -1954140928, s = {s = 0x7efd8b862d00 "P", len = -2041446400}, re = 0x7efd8b862d00}, avp = 0x7efdaa5846f0} sct = 0xa00000000 sjt = 0x7fff30447020 rve = 0x7efdaa7810e0 mct = 0x7fff30446f60 rv = 0x0 rv1 = 0x558954e2cd7c <cmpi_str+154> c1 = {cache_type = 2858447024, val_type = 32509, c = {avp_val = {n = 809792400, s = {s = 0x7fff30447390 "", len = -1436512179}, re = 0x7fff30447390}, pval = {rs = {s = 0x7fff30447390 "", len = -1436512179}, ri = 10, flags = 32509}}, i2s = "\200〪\375~\000\000\005\000\000\000\000\000\000\000P~D0\377\177"} s = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 1424149884} srevp = {0x400017320, 0x300000000} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #11 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa74a9f0, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa783a40 ret = 1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 1426245171, tz_dsttime = 21897} tdiff = 0 __func__ = "run_actions" #12 0x0000558954bfdb07 in do_action (h=0x7fff3044aeb0, a=0x7efdaa6161b0, msg=0x7efdaa5846f0) at core/action.c:703 ret = -5 v = 1 dst = {send_sock = 0x7efdaa5846f0, to = {s = {sa_family = 44720, sa_data = "D0\377\177\000\000\260{D0\377\177\000"}, sin = {sin_family = 44720, sin_port = 12356, sin_addr = {s_addr = 32767}, sin_zero = "\260{D0\377\177\000"}, sin6 = {sin6_family = 44720, sin6_port = 12356, sin6_flowinfo = 32767, sin6_addr = {__in6_u = {__u6_addr8 = "\260{D0\377\177\000\000\000\000\000\000\000\000\000", __u6_addr16 = {31664, 12356, 32767, 0, 0, 0, 0, 0}, __u6_addr32 = {809794480, 32767, 0, 0}}}, sin6_scope_id = 809794848}, sas = {ss_family = 44720, __ss_padding = "D0\377\177\000\000\260{D0\377\177\000\000\000\000\000\000\000\000\000\000 }D0\377\177", '\000' <repeats 19 times>, "\333\376\210-}վ\000\000\000\000\000\000\240\356\000\000\000\000\002", '\000' <repeats 11 times>, "\322\030\325T0u\000\000=u\000\000\021\000\000\000\240}D0\377\177\000\000`|D0\377\177\000\000\211\366\315T\211U\000", __ss_align = 139627950425864}}, id = -1436367744, send_flags = {f = 32509, blst_imask = 0}, proto = -16 '\360', proto_pad0 = 70 'F', proto_pad1 = -21928} tmp = 0x200000000 <error: Cannot access memory at address 0x200000000> new_uri = 0x0 end = 0x7efdaa607130 "" crt = 0x0 cmd = 0x7fff30447740 len = 809793000 user = 32767 uri = {user = {s = 0x7fff30447c38 "", len = 809793632}, passwd = {s = 0x0, len = 1423251666}, host = {s = 0x5 <error: Cannot access memory at address 0x5>, len = 809793632}, port = {s = 0x7fff30447900 "pzD0\377\177", len = 1423656503}, params = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, sip_params = {s = 0x7fff30447980 "\240zD0\377\177", len = 0}, headers = {s = 0x7efdaa6143a8 "\a", len = 809794616}, port_no = 18160, proto = 43608, type = 32509, flags = (unknown: 0x3044aeb0), transport = {s = 0x7fff30447930 "\240Ca\252\375~", len = 0}, ttl = {s = 0x7efdaa62cfa0 "m\004", len = 809793984}, user_param = {s = 0x7fff30447860 "", len = 1426245171}, maddr = { s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x7efdaa62afb8 "", len = -1437055248}, transport_val = {s = 0x7efdaa62afb8 "", len = -1437055248}, ttl_val = {s = 0x0, len = 16}, user_param_val = {s = 0x7efdab04f2d0 "", len = -1996563712}, maddr_val = {s = 0x7fff304478f0 " ", len = -1996563712}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 1426245171}, r2_val = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr_val = {s = 0x7fff30447a70 "\340{D0\377\177", len = 1423675477}} next_hop = {user = {s = 0x7fff30447950 "\220zD0\377\177", len = -1996563712}, passwd = {s = 0x7efdaa53e010 "\001", len = 0}, host = {s = 0x7efdaa6143a0 "\001", len = 809794616}, port = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, params = { s = 0x7fff30447a90 "\300{D0\377\177", len = 0}, sip_params = {s = 0x7efdaa615188 "\001", len = 809794620}, headers = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, port_no = 31392, proto = 12356, type = 32767, flags = 0, transport = {s = 0x7fff304479d0 "", len = -1437055248}, ttl = {s = 0x0, len = 809807536}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 1}, method = {s = 0x200000000 <error: Cannot access memory at address 0x200000000>, len = -1581657470}, lr = {s = 0x0, len = 1426245171}, r2 = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr = {s = 0x58a6da26bd59d282 <error: Cannot access memory at address 0x58a6da26bd59d282>, len = 1514263170}, transport_val = { s = 0x7fff00000000 <error: Cannot access memory at address 0x7fff00000000>, len = -1996563712}, ttl_val = {s = 0x19aa53e618 <error: Cannot access memory at address 0x19aa53e618>, len = 0}, user_param_val = {s = 0x0, len = -1996563712}, maddr_val = { s = 0x1 <error: Cannot access memory at address 0x1>, len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, r2_val = {s = 0x7fff30447be0 "P}D0\377\177", len = 1423675477}, gr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}} u = 0x55895502c633 port = 0 dst_host = 0xbed57d2d88fedb00 i = 9 flags = 0 avp = 0x20 st = {flags = 0, id = 32767, name = {n = 1445170114, s = { s = 0x558956238bc2 "X-Src-Addr: xxx;udp\r\nX-Src-Peer: 30013\r\nContact: <sip:btpsh-6137d4b2-61bc-3ce509-leg1@xxx:5060;transport=tcp>\r\n\r\nv=0\r\no=- 461374211 461374211 IN IP4 xxx\r\ns=xxx\r\nc=IN"..., len = 10}, re = 0x558956238bc2}, avp = 0x7efdaa5846f0} sct = 0x7efdaa5846f0 sjt = 0x30447850 rve = 0x7fff30447860 mct = 0x7efdaa6143c8 rv = 0x7fff304476c0 rv1 = 0x558954e2cd7c <cmpi_str+154> c1 = {cache_type = 2858504576, val_type = 32509, c = {avp_val = {n = 809794620, s = {s = 0x7fff30447c3c "", len = -1437055248}, re = 0x7fff30447c3c}, pval = {rs = {s = 0x7fff30447c3c "", len = -1437055248}, ri = 809807536, flags = 32767}}, i2s = "\200\376\022V\211U", '\000' <repeats 14 times>, "\375~"} s = {s = 0x7fff304477c0 "", len = 1423240445} srevp = {0x7fff30447bc0, 0xbed57d2d88fedb00} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:+xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:+xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #13 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa616000, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa6161b0 ret = 1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809794976 __func__ = "run_actions" #14 0x0000558954c01b16 in do_action (h=0x7fff3044aeb0, a=0x7efdaa616470, msg=0x7efdaa5846f0) at core/action.c:1070 ret = 1 v = 1 dst = {send_sock = 0x0, to = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 0, __ss_padding = '\000' <repeats 38 times>, "\002", '\000' <repeats 11 times>, "\005\000\000\000h\202[\252\375~\000\000\000\000\000\000\375~\000\000\060\204D0\377\177\000\000i#\357T N\000\000=u\000\000\021\000\000\000ЅD0\377\177\000\000\250\005\003U\211U\000\000\000\333\376\210-}վ", __ss_align = 768}}, id = 2, send_flags = {f = 0, blst_imask = 0}, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0} tmp = 0x0 new_uri = 0x0 end = 0x7efdaa607130 "" crt = 0x558956238907 "sip:+xxx@xxx;transport=TCP SIP/2.0\r\nVia: SIP/2.0/TCP xxx:5060;branch=z9hG4bK2149.ed5b7b65e862f15e376ee9d226300d35.0\r\nFrom: <sip:+xxx@xxx>;tag=3d"... cmd = 0x7efdaa5ba500 len = 1424796052 user = 21897 uri = {user = {s = 0x7fff30448468 "", len = 809795728}, passwd = {s = 0x0, len = 1423251666}, host = {s = 0x5 <error: Cannot access memory at address 0x5>, len = 809795728}, port = {s = 0x7fff30448130 "\240\202D0\377\177", len = 1423656503}, params = { s = 0x8000000 <error: Cannot access memory at address 0x8000000>, len = 122344320}, sip_params = {s = 0xa7a3e0 <error: Cannot access memory at address 0xa7a3e0>, len = 0}, headers = {s = 0x7efdaa612748 "\a", len = 809796712}, port_no = 18160, proto = 43608, type = 32509, flags = (unknown: 0x3044aeb0), transport = {s = 0x7fff30448070 "@\201D0\377\177", len = 0}, ttl = {s = 0x0, len = -1426974192}, user_param = {s = 0x7fff30448090 "", len = 0}, maddr = {s = 0x7fff30448140 "\240\201D0\377\177", len = 1424958313}, method = {s = 0x7efdaa92b8a0 "\300\210\222\252\375~", len = -1437343728}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = -1437343728}, gr = {s = 0x7efdaa92b840 "0", len = -1433224624}, transport_val = {s = 0x2a0 <error: Cannot access memory at address 0x2a0>, len = -1433226400}, ttl_val = {s = 0x4c0 <error: Cannot access memory at address 0x4c0>, len = -1437343728}, user_param_val = {s = 0x7efdaa92b330 "\020", len = -1433225152}, maddr_val = {s = 0x8000000 <error: Cannot access memory at address 0x8000000>, len = -1996563712}, method_val = {s = 0xa7a800 <error: Cannot access memory at address 0xa7a800>, len = 0}, lr_val = {s = 0x0, len = 1426245171}, r2_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr_val = { s = 0x7fff304482a0 "\020\204D0\377\177", len = 1423675477}} next_hop = {user = {s = 0x7fff304481a0 "\360FX\252\375~", len = -1466248417}, passwd = {s = 0x0, len = 0}, host = {s = 0x7efdaa612740 "\001", len = 809796712}, port = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, params = { s = 0xd4b5e0 <error: Cannot access memory at address 0xd4b5e0>, len = 0}, sip_params = {s = 0x7efdaa613528 "\001", len = 809796716}, headers = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, transport = { s = 0x7efdaa53ec30 "", len = 0}, ttl = {s = 0x0, len = 1424954698}, user_param = {s = 0x400 <error: Cannot access memory at address 0x400>, len = -1437343728}, maddr = {s = 0x4 <error: Cannot access memory at address 0x4>, len = -1437055248}, method = { s = 0x7efdaa53e010 "\001", len = -1433226400}, lr = {s = 0x7efdaaf21a10 "\300\210\222\252\375~", len = 6}, r2 = {s = 0x7efda8f30010 "sl:local-response", len = 17}, gr = {s = 0x58a6da2752f9d282 <error: Cannot access memory at address 0x58a6da2752f9d282>, len = 1445170245}, transport_val = {s = 0x0, len = 1445170508}, ttl_val = {s = 0x0, len = -1996563712}, user_param_val = {s = 0x7fff304486a0 "\220\357Y\252\375~", len = -1996563712}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, r2_val = {s = 0x7fff30448410 "\200\205D0\377\177", len = 1423675477}, gr_val = {s = 0x7efdaa59ef90 "\377\377\377\377", len = 0}} u = 0x35 port = 45668 dst_host = 0xbed57d2d88fedb00 i = -2008929216 flags = 32767 avp = 0x558955111180 <buff> st = {flags = 980445555, id = 13099, name = {n = 858928436, s = {s = 0x3832323533323534 <error: Cannot access memory at address 0x3832323533323534>, len = 1769160761}, re = 0x3832323533323534}, avp = 0x7465732e69662e65} sct = 0x7efdaa5846f0 sjt = 0x0 rve = 0x7efdaa615870 mct = 0x7efdaa612768 rv = 0xd4b5e0 rv1 = 0x55890000000d c1 = {cache_type = 2858497312, val_type = 32509, c = {avp_val = {n = 809796716, s = {s = 0x7fff3044846c "", len = -1437055248}, re = 0x7fff3044846c}, pval = {rs = {s = 0x7fff3044846c "", len = -1437055248}, ri = 809807536, flags = 32767}}, i2s = "\000\000\000\000\000\000\000\000\360FX\252\375~\000\000\000\000\000\000\000"} s = {s = 0x7fff30447ff0 "0\201D0\377\177", len = 1423240445} srevp = {0x800000000, 0x7efda8b6ecea} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:+xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:+xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #15 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa616470, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa616470 ret = -1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809797072 __func__ = "run_actions" #16 0x0000558954c01b16 in do_action (h=0x7fff3044aeb0, a=0x7efdaa616690, msg=0x7efdaa5846f0) at core/action.c:1070 ret = 1 v = 1 dst = {send_sock = 0x0, to = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 0, __ss_padding = '\000' <repeats 31 times>, "\333\376\210-}վ", '\000' <repeats 12 times>, "\002", '\000' <repeats 11 times>, "\063\306\002U\211U\000\000 \000\000\000\000\000\000\000\060\260d\262\020'\000\000=u\000\000\023\000\000\000\000\216D0\377\177\000\000\300\214D0\377\177\000\000\360FX\252\375~\000", __ss_align = 139627950287840}}, id = 809807536, send_flags = {f = 32767, blst_imask = 0}, proto = 1 '\001', proto_pad0 = 0 '\000', proto_pad1 = 0} tmp = 0x558954e2b064 <unescape_user+3267> "\203\370\002\017\216 \003" new_uri = 0x0 end = 0x7efdaa607130 "" crt = 0x0 cmd = 0x0 len = 0 user = 1 uri = {user = {s = 0x7fff30448c98 "", len = 809797824}, passwd = {s = 0x0, len = 1423251666}, host = {s = 0x5 <error: Cannot access memory at address 0x5>, len = 809797824}, port = {s = 0x7fff30448960 "ЊD0\377\177", len = 1423656503}, params = { s = 0x7fff304488f0 "\200\250\247", len = -1996563712}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x7efdaa610828 "\a", len = 809798808}, port_no = 18160, proto = 43608, type = 32509, flags = (unknown: 0x3044aeb0), transport = { s = 0x7fff30448f00 "\350\353`\252\375~", len = 0}, ttl = {s = 0x7efdaac2c740 "2\023", len = 1424974825}, user_param = {s = 0x7fff304488c0 "", len = -1437055248}, maddr = {s = 0x7efdaa609b40 "\027\004", len = 809799904}, method = { s = 0x10 <error: Cannot access memory at address 0x10>, len = -1437343728}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x8000000 <error: Cannot access memory at address 0x8000000>, len = 122343136}, transport_val = { s = 0xa7a880 <error: Cannot access memory at address 0xa7a880>, len = 11874592}, ttl_val = {s = 0xd4b5e0 <error: Cannot access memory at address 0xd4b5e0>, len = 16}, user_param_val = {s = 0x131 <error: Cannot access memory at address 0x131>, len = -1996563712}, maddr_val = {s = 0x7fff30448950 " ", len = -1996563712}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 1426245171}, r2_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr_val = { s = 0x7fff30448ad0 "@\214D0\377\177", len = 1423675477}} next_hop = {user = {s = 0x10 <error: Cannot access memory at address 0x10>, len = 1}, passwd = {s = 0x7efdaa53e010 "\001", len = -1434393744}, host = {s = 0x7efdaa610820 "\001", len = 809798808}, port = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, params = { s = 0x7fff304489e0 "", len = 0}, sip_params = {s = 0x7efdaa611608 "\001", len = 809798812}, headers = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, port_no = 0, proto = 0, type = 32767, flags = 0, transport = {s = 0x0, len = 1426245171}, ttl = {s = 0x0, len = -1302024144}, user_param = {s = 0x7fff30448ad0 "@\214D0\377\177", len = -1462135749}, maddr = {s = 0x7efdaa60904d "peer_in_id)", len = 10}, method = {s = 0x7fff30448b20 "\v-\206\213\375~", len = -1436520144}, lr = { s = 0x111aa602728 <error: Cannot access memory at address 0x111aa602728>, len = 1427857984}, r2 = {s = 0x800000111 <error: Cannot access memory at address 0x800000111>, len = -1436512179}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = -1996563712}, maddr_val = {s = 0x1000000000 <error: Cannot access memory at address 0x1000000000>, len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, r2_val = {s = 0x7fff30448c40 "\260\215D0\377\177", len = 1423675477}, gr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}} u = 0x0 port = 12356 dst_host = 0xbed57d2d88fedb00 i = 0 flags = 0 avp = 0x7fff30448950 st = {flags = 0, id = 0, name = {n = 0, s = {s = 0x0, len = -2041446400}, re = 0x0}, avp = 0x7efdb264b030 <__syslog>} sct = 0x7efdaa5846f0 sjt = 0x0 rve = 0x7efdaa613c10 mct = 0x7efdaa610848 rv = 0x7fff304487d0 rv1 = 0x7fff30448c20 c1 = {cache_type = 2858489344, val_type = 32509, c = {avp_val = {n = 809798812, s = {s = 0x7fff30448c9c "", len = -1437055248}, re = 0x7fff30448c9c}, pval = {rs = {s = 0x7fff30448c9c "", len = -1437055248}, ri = 809807536, flags = 32767}}, i2s = "\v-\206\213\375~\000\000\005\000\000\000\375~\000\000\000\000\000\000\000"} s = {s = 0x7fff30448820 "`\211D0\377\177", len = 1423240445} srevp = {0x7fff30448c20, 0xfe54d4ecfd} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:+xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:+xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #17 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa616690, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa616690 ret = -1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809799168 __func__ = "run_actions" #18 0x0000558954c01b6c in do_action (h=0x7fff3044aeb0, a=0x7efdaa6167a0, msg=0x7efdaa5846f0) at core/action.c:1074 ret = 1 v = 0 dst = {send_sock = 0x7efdaa5846f0, to = {s = {sa_family = 60360, sa_data = "`\252\375~\000\000\000\000\000\000\000\000\000"}, sin = {sin_family = 60360, sin_port = 43616, sin_addr = {s_addr = 32509}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = { sin6_family = 60360, sin6_port = 43616, sin6_flowinfo = 32509, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 60360, __ss_padding = "`\252\375~", '\000' <repeats 30 times>, "\001", '\000' <repeats 12 times>, "\333\376\210-}վ", '\000' <repeats 12 times>, "\002", '\000' <repeats 35 times>, "\360\224D0\377\177\000\000J\363\315T\211U\000", __ss_align = 139627950275960}}, id = -1436517248, send_flags = {f = 32509, blst_imask = 0}, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0} tmp = 0x7fff304493c8 "" new_uri = 0x5589ffffffff <error: Cannot access memory at address 0x5589ffffffff> end = 0x0 crt = 0x7efdaa60ebe8 "\002" cmd = 0x0 len = -1437343728 user = 5 uri = {user = {s = 0x7fff30449190 "\260\221D0\377\177", len = 0}, passwd = {s = 0x7efd8b862bb0 "0", len = -1996563712}, host = {s = 0x7efd8b862bb0 "0", len = 0}, port = {s = 0x7efdaa60c380 "\001", len = 809800168}, params = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, sip_params = {s = 0x7fff30449210 "0\223D0\377\177", len = -1996563712}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = (unknown: 0x30449400), transport = {s = 0x7efdaa60f2b8 "\001", len = 809800540}, ttl = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, user_param = {s = 0x7efdaa609b40 "\027\004", len = 0}, maddr = {s = 0x7fff30449400 "", len = -1436486984}, method = {s = 0x0, len = 809807536}, lr = { s = 0x1aa607130 <error: Cannot access memory at address 0x1aa607130>, len = 0}, r2 = {s = 0x7fff304491c0 "", len = 809800648}, gr = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 809800288}, transport_val = {s = 0x7efdaa60e2b0 "\017", len = -1437055248}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x131 <error: Cannot access memory at address 0x131>, len = -1996563712}, maddr_val = {s = 0x7fff30449180 " ", len = -1996563712}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 1426245171}, r2_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr_val = {s = 0x7fff304491b0 "", len = 1423642566}} next_hop = {user = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}, passwd = {s = 0x7fff30449300 "p\224D0\377\177", len = 1423692045}, host = {s = 0x7fff30449300 "p\224D0\377\177", len = 1423656503}, port = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, params = {s = 0x7fff30449400 "", len = -1436486992}, sip_params = {s = 0x7fff3044935c "\001", len = 809800576}, headers = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, port_no = 37680, proto = 12356, type = 32767, flags = 0, transport = { s = 0x0, len = -1437055248}, ttl = {s = 0x130449260 <error: Cannot access memory at address 0x130449260>, len = 809807536}, user_param = {s = 0x1aa60f2b8 <error: Cannot access memory at address 0x1aa60f2b8>, len = -1436488760}, maddr = {s = 0x0, len = 1}, method = {s = 0x1a00000000 <error: Cannot access memory at address 0x1a00000000>, len = 809800908}, lr = {s = 0x0, len = 1426245171}, r2 = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr = { s = 0x58a6da2773b9d282 <error: Cannot access memory at address 0x58a6da2773b9d282>, len = 1514263170}, transport_val = {s = 0x0, len = -1996563712}, ttl_val = {s = 0x7efdaa5f9e0d "p-flags)", len = 0}, user_param_val = {s = 0x0, len = 1426245171}, maddr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, method_val = {s = 0x7fff30449300 "p\224D0\377\177", len = 1423642566}, lr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1436488760}, r2_val = { s = 0x7fff30449470 "\340\225D0\377\177", len = 1423678076}, gr_val = {s = 0x0, len = 1426245171}} u = 0x7efdaa5846f0 port = 21704 dst_host = 0x0 i = -1437341824 flags = 0 avp = 0x7efdaa609b40 st = {flags = 32, id = 0, name = {n = -1302024144, s = {s = 0x7efdb264b030 <__syslog> "H\201\354", <incomplete sequence \330>, len = 809799856}, re = 0x7efdb264b030 <__syslog>}, avp = 0x558954d4ecfd <pv_get_spec_value+995>} sct = 0x7fff00000015 sjt = 0x0 rve = 0x7efdaa611cf0 mct = 0x7efdaa5614c0 rv = 0x7efdaa5846f0 rv1 = 0x7fff304490e0 c1 = {cache_type = 2858482080, val_type = 32509, c = {avp_val = {n = 809800908, s = {s = 0x7fff304494cc "", len = -1437055248}, re = 0x7fff304494cc}, pval = {rs = {s = 0x7fff304494cc "", len = -1437055248}, ri = 809807536, flags = 32767}}, i2s = "`\204`\252\375~\000\000\001\000\000\000\001\000\000\000\000\000\000\000\375~"} s = {s = 0x0, len = 0} srevp = {0x7fff30449450, 0xbed57d2d88fedb00} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:+xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:+xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #19 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa6167a0, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa6167a0 ret = -1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809801264 __func__ = "run_actions" #20 0x0000558954c01b16 in do_action (h=0x7fff3044aeb0, a=0x7efdaa6168b0, msg=0x7efdaa5846f0) at core/action.c:1070 ret = 1 v = 1 dst = {send_sock = 0x7efdaa5846f0, to = {s = {sa_family = 44720, sa_data = "D0\377\177\000\000\000\000\000\000\000\000\000"}, sin = {sin_family = 44720, sin_port = 12356, sin_addr = {s_addr = 32767}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = { sin6_family = 44720, sin6_port = 12356, sin6_flowinfo = 32767, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 2}, sas = {ss_family = 44720, __ss_padding = "D0\377\177", '\000' <repeats 18 times>, "\002\000\000\000\000\000\000\000\060\260d\262\375~", '\000' <repeats 18 times>, "xX[\252\375~", '\000' <repeats 18 times>, "\360\245D0\377\177\000\000\000\000\000\000\000\000\000\000P\256\226\252\375~", '\000' <repeats 17 times>, __ss_align = 139627926641050}}, id = 12, send_flags = {f = 2, blst_imask = 0}, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0} tmp = 0x7efdaa5846f0 "jS\033" new_uri = 0x200000000 <error: Cannot access memory at address 0x200000000> end = 0x0 crt = 0x0 cmd = 0x7efdaa5a18f0 len = -1437055248 user = 32509 uri = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = -1996563712}, host = {s = 0x7efdaa96fbd8 "W\211#V\211U", len = 0}, port = {s = 0x0, len = 1426245171}, params = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, sip_params = { s = 0x7fff304498d0 "`\237D0\377\177", len = -1464683310}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = (unknown: 0xaa5846f0), transport = {s = 0x7fff30449f60 "", len = 1421876138}, ttl = {s = 0x7efdaa5db320 "g\003", len = 809802368}, user_param = {s = 0x7efdaa59f1f0 "\a", len = -1437055248}, maddr = {s = 0x7efdaa5e0260 "~\003", len = 809804096}, method = {s = 0x0, len = 1426245171}, lr = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, r2 = { s = 0x7fff30449960 "\200\231D0\377\177", len = 1422859023}, gr = {s = 0x7efdb2721180 <_IO_strn_jumps> "", len = -1437055248}, transport_val = {s = 0x7efdaa5ce0b0 "\002", len = 0}, ttl_val = {s = 0x7fff30449980 "@\232D0\377\177", len = -1465333050}, user_param_val = {s = 0x200000020 <error: Cannot access memory at address 0x200000020>, len = -1437055248}, maddr_val = {s = 0x7fff30449a40 "РD0\377\177", len = -1465331735}, method_val = {s = 0x7fff3044a540 " ", len = 0}, lr_val = { s = 0x7efdaa5cb100 "а\\\252\375~", len = -1437055248}, r2_val = {s = 0x1 <error: Cannot access memory at address 0x1>, len = 2}, gr_val = {s = 0xb00000000 <error: Cannot access memory at address 0xb00000000>, len = 0}} next_hop = {user = {s = 0x0, len = 1426245171}, passwd = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, host = {s = 0x7fff30449b30 "\240\234D0\377\177", len = 1423653453}, port = {s = 0x7fff30449f80 " ", len = -1996563712}, params = {s = 0x7efdaa4b1746 ") values (", len = 0}, sip_params = {s = 0x0, len = 1426245171}, headers = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, port_no = 41168, proto = 12356, type = 32767, flags = (URI_SIP_USER_PHONE | unknown: 0x54c01c34), transport = {s = 0x300000000 <error: Cannot access memory at address 0x300000000>, len = -1437055248}, ttl = {s = 0x0, len = -1437055248}, user_param = {s = 0x7efdaa5b4250 "Q\371\266\250\375~", len = 809804464}, maddr = {s = 0x0, len = 1}, method = {s = 0x200000000 <error: Cannot access memory at address 0x200000000>, len = 1715065474}, lr = {s = 0x0, len = 1426245171}, r2 = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = { s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, r2_val = {s = 0x7fff30449ca0 "\020\236D0\377\177", len = 1423675477}, gr_val = {s = 0x7fff3044a200 "", len = 809804096}} u = 0x45aa967650 port = 21745 dst_host = 0x55895502c633 i = 32 flags = 0 avp = 0x558900000046 st = {flags = 0, id = 0, name = {n = 0, s = {s = 0x0, len = 0}, re = 0x0}, avp = 0x0} sct = 0xbed57d2d88fedb00 sjt = 0x7efdaa5d75a0 rve = 0x7efdaa610090 mct = 0xba03000000000000 rv = 0xa30449810 rv1 = 0x7efdaa5848f0 c1 = {cache_type = 2858213632, val_type = 32509, c = {avp_val = {n = 809803000, s = {s = 0x7fff30449cf8 "", len = -1437055248}, re = 0x7fff30449cf8}, pval = {rs = {s = 0x7fff30449cf8 "", len = -1437055248}, ri = 809807536, flags = 32767}}, i2s = '\000' <repeats 20 times>, "\375~"} s = {s = 0x800000020 <error: Cannot access memory at address 0x800000020>, len = -1464429030} srevp = {0x0, 0xbed57d2d88fedb00} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:+xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:+xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #21 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa5e23a0, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa6168b0 ret = 1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809803360 __func__ = "run_actions" #22 0x0000558954bfdb07 in do_action (h=0x7fff3044aeb0, a=0x7efdaa5e11f0, msg=0x7efdaa5846f0) at core/action.c:703 ret = -5 v = 0 dst = {send_sock = 0x7efdaa5846f0, to = {s = {sa_family = 44720, sa_data = "D0\377\177\000\000\000\000\000\000\000\000\000"}, sin = {sin_family = 44720, sin_port = 12356, sin_addr = {s_addr = 32767}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = { sin6_family = 44720, sin6_port = 12356, sin6_flowinfo = 32767, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 44720, __ss_padding = "D0\377\177", '\000' <repeats 43 times>, "\333\376\210-}վ", '\000' <repeats 12 times>, "\002", '\000' <repeats 11 times>, "\322\030\325T\211U\000\000\000\000\000\000\004\000\000\000\220\246D0\377\177\000\000P\245D0\377\177\000\000\211\366\315T\211U\000", __ss_align = 139627950028216}}, id = -1436765232, send_flags = {f = 32509, blst_imask = 0}, proto = -16 '\360', proto_pad0 = 70 'F', proto_pad1 = -21928} tmp = 0x4000b264b030 <error: Cannot access memory at address 0x4000b264b030> new_uri = 0x7efdaa53e010 "\001" end = 0x0 crt = 0x7fff3044a090 "\300\240D0\377\177" cmd = 0x0 len = 1427222488 user = 13 uri = {user = {s = 0x0, len = -1996563712}, passwd = {s = 0x7fff3044a0c0 " ", len = -1996563712}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1996563712}, sip_params = { s = 0x7fff3044a270 "\220\243D0\377\177", len = 0}, headers = {s = 0x0, len = 1426245171}, port_no = 32, proto = 0, type = ERROR_URI_T, flags = (unknown: 0xb264b030), transport = {s = 0x7fff3044a220 "`\243D0\377\177", len = 1421938797}, ttl = { s = 0x7efdaa5d20c0 "P\003", len = -1437055248}, user_param = {s = 0x7efdaa5e0260 "~\003", len = 809807536}, maddr = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 0}, method = {s = 0x0, len = -1}, lr = { s = 0x200000000 <error: Cannot access memory at address 0x200000000>, len = 280613506}, r2 = {s = 0x0, len = 1426245171}, gr = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, transport_val = { s = 0x58a6da276c59d282 <error: Cannot access memory at address 0x58a6da276c59d282>, len = 1514263170}, ttl_val = {s = 0x0, len = -1460231948}, user_param_val = {s = 0x13e <error: Cannot access memory at address 0x13e>, len = -1996563712}, maddr_val = { s = 0x7fff3044a1e0 "\210\246D0\377\177", len = 1422431725}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 809805480}, r2_val = {s = 0x7fff3044a688 "\370\246D0\001", len = -1996563712}, gr_val = { s = 0x10 <error: Cannot access memory at address 0x10>, len = 0}} next_hop = {user = {s = 0x0, len = 1426245171}, passwd = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1996563712}, host = {s = 0x7fff3044a360 "ФD0\377\177", len = 1423653555}, port = {s = 0x0, len = -1996563712}, params = { s = 0x7fff3044a300 "", len = 0}, sip_params = {s = 0x7efdaa5e0378 "\004", len = 809805096}, headers = {s = 0x7efdaa5846f0 "jS\033", len = 809807536}, port_no = 41872, proto = 12356, type = 32767, flags = 0, transport = {s = 0x0, len = -1437055248}, ttl = { s = 0x0, len = -1996563712}, user_param = {s = 0x7fff3044a360 "ФD0\377\177", len = 0}, maddr = {s = 0x0, len = 1426245171}, method = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, lr = {s = 0x7fff3044a390 "p\003^\252\375~", len = 1423531231}, r2 = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1437055248}, gr = {s = 0x7efdaa5dab40 "\002", len = 809807536}, transport_val = {s = 0x0, len = 1422564395}, ttl_val = {s = 0x7fff3044a360 "ФD0\377\177", len = 809804976}, user_param_val = {s = 0x7efdaa5cb5d8 "", len = -1996563712}, maddr_val = {s = 0x7fff3044a380 " ", len = 0}, method_val = {s = 0x0, len = 1426245171}, lr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1302024144}, r2_val = {s = 0x7fff3044a4d0 "@\246D0\377\177", len = 1423675477}, gr_val = {s = 0x0, len = 1426245171}} u = 0x7efdaa5846f0 port = 43607 dst_host = 0x0 i = 3 flags = 4 avp = 0x7efdaa5e0260 st = {flags = 32, id = 0, name = {n = -1302024144, s = {s = 0x7efdb264b030 <__syslog> "H\201\354", <incomplete sequence \330>, len = 809804496}, re = 0x7efdb264b030 <__syslog>}, avp = 0x558954d925ab <eval_elem+1084>} sct = 0x7efdaa53e010 sjt = 0x0 rve = 0xffffffffaa5cfe30 mct = 0x7fff3044a000 rv = 0x20 rv1 = 0x7fff3044a140 c1 = {cache_type = 2858287984, val_type = 32509, c = {avp_val = {n = 809805096, s = {s = 0x7fff3044a528 "", len = -1437055248}, re = 0x7fff3044a528}, pval = {rs = {s = 0x7fff3044a528 "", len = -1437055248}, ri = 809807536, flags = 32767}}, i2s = "\200\021\021U\211U", '\000' <repeats 14 times>, "\375~"} s = {s = 0x0, len = 0} srevp = {0x20, 0x7efdb264b030 <__syslog>} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:+xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:+xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #23 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa5e11f0, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa5e11f0 ret = -1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = 809807536, tz_dsttime = 32767} tdiff = 809805456 __func__ = "run_actions" #24 0x0000558954c01b16 in do_action (h=0x7fff3044aeb0, a=0x7efdaa5e14b0, msg=0x7efdaa5846f0) at core/action.c:1070 ret = 1 v = 1 dst = {send_sock = 0xa79e00, to = {s = {sa_family = 56064, sa_data = "\376\210-}վ\340\265\324\000\000\000\000"}, sin = {sin_family = 56064, sin_port = 35070, sin_addr = {s_addr = 3201662253}, sin_zero = "\340\265\324\000\000\000\000"}, sin6 = { sin6_family = 56064, sin6_port = 35070, sin6_flowinfo = 3201662253, sin6_addr = {__in6_u = {__u6_addr8 = "\340\265\324\000\000\000\000\000\000\000\000\000\002\000\000", __u6_addr16 = {46560, 212, 0, 0, 0, 0, 2, 0}, __u6_addr32 = {13940192, 0, 0, 2}}}, sin6_scope_id = 0}, sas = {ss_family = 56064, __ss_padding = "\376\210-}վ\340\265\324\000\000\000\000\000\000\000\000\000\002", '\000' <repeats 11 times>, "\063\306\002U\211U\000\000L\215#V\211U\000\000Z\212#V\211U\000\000 \255D0\377\177\000\000\226\267\362T\211U\000\000\310\340S\252\375~\000\000@\035\362\252\375~\000\000L\215#V\211U\000\000O\212#V\211U\000\000\060\000\000\000\000\000\000\000\020\340S\252\375~\000", __ss_align = 328}}, id = 1445169754, send_flags = {f = 21897, blst_imask = 0}, proto = 84 'T', proto_pad0 = -118 '\212', proto_pad1 = 22051} tmp = 0x74acc90 <error: Cannot access memory at address 0x74acc90> new_uri = 0x588fedb00 <error: Cannot access memory at address 0x588fedb00> end = 0x7efdaa53ea78 "" crt = 0xa7aa30 <error: Cannot access memory at address 0xa7aa30> cmd = 0x7efdaa5a84c0 len = 0 user = 0 uri = {user = {s = 0x7fff3044a8d0 "", len = -1996563712}, passwd = {s = 0x7efd88820b80 "\264", len = 0}, host = {s = 0x0, len = 1426245171}, port = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 1424974825}, params = {s = 0x7fff3044a930 "", len = -1437343728}, sip_params = {s = 0x400000040 <error: Cannot access memory at address 0x400000040>, len = 1426677168}, headers = {s = 0x7fff3044a970 "\223\252D0\377\177", len = -1996563712}, port_no = 43616, proto = 12356, type = 32767, flags = (URI_SIP_USER_PHONE | unknown: 0x54f691b4), transport = {s = 0x8000000 <error: Cannot access memory at address 0x8000000>, len = 122346656}, ttl = {s = 0xa79ac0 <error: Cannot access memory at address 0xa79ac0>, len = 11871072}, user_param = { s = 0xd4b5e0 <error: Cannot access memory at address 0xd4b5e0>, len = 16}, maddr = {s = 0x7efdaa96fb90 "\001", len = -1434548848}, method = {s = 0x7fff3044aa93 "\005", len = 809806482}, lr = {s = 0x558956238d4c "", len = 1445169514}, r2 = { s = 0x7efdaa53e0f0 "", len = 0}, gr = {s = 0x7fff3044aa60 " \254D0\377\177", len = 1424954698}, transport_val = {s = 0x40 <error: Cannot access memory at address 0x40>, len = -1437343728}, ttl_val = {s = 0x7fff3044aa80 "L\215#V\211U", len = 4}, user_param_val = {s = 0x7efdaa53e010 "\001", len = 1445169567}, maddr_val = {s = 0x1 <error: Cannot access memory at address 0x1>, len = 3}, method_val = {s = 0x7efdaa53e010 "\001", len = -1426973392}, lr_val = { s = 0x400000040 <error: Cannot access memory at address 0x400000040>, len = 0}, r2_val = {s = 0x7fff3044aa30 "`\252D0\004", len = -1443374771}, gr_val = {s = 0x20 <error: Cannot access memory at address 0x20>, len = 809806484}} next_hop = {user = {s = 0x43044aa60 <error: Cannot access memory at address 0x43044aa60>, len = 1445169509}, passwd = {s = 0x400000000 <error: Cannot access memory at address 0x400000000>, len = 331636144}, host = { s = 0x558956238969 ";branch=z9hG4bK2149.ed5b7b65e862f15e376ee9d226300d35.0\r\nFrom: <sip:+xxx@xxx>;tag=3d63dba0-bd5f-4b46-8434-e84e5b44da90\r\nTo: <sip:+xxx@xxx>\r\nCall-ID: e393131f-4156-"..., len = 1445169513}, port = { s = 0x7fff3044ac20 "", len = 1425499403}, params = {s = 0x20 <error: Cannot access memory at address 0x20>, len = -1432945776}, sip_params = {s = 0x558956238d4c "", len = 1445169483}, headers = { s = 0x505e0f0 <error: Cannot access memory at address 0x505e0f0>, len = 0}, port_no = 0, proto = 0, type = 200, flags = (URI_USER_NORMALIZE | unknown: 0x54ef63e8), transport = {s = 0x7fff3044aaf0 "", len = -1437343728}, ttl = { s = 0xf0 <error: Cannot access memory at address 0xf0>, len = -1437343728}, user_param = {s = 0x7fff3044ab30 "`\253D0\377\177", len = -1466248417}, maddr = {s = 0x43044abf0 <error: Cannot access memory at address 0x43044abf0>, len = 0}, method = { s = 0x8000000 <error: Cannot access memory at address 0x8000000>, len = 122346720}, lr = {s = 0xa79a80 <error: Cannot access memory at address 0xa79a80>, len = 11871008}, r2 = {s = 0xd4b5e0 <error: Cannot access memory at address 0xd4b5e0>, len = 16}, gr = { s = 0x147 <error: Cannot access memory at address 0x147>, len = -1996563712}, transport_val = {s = 0x7fff3044ab60 " \254D0\377\177", len = 1422431725}, ttl_val = {s = 0x0, len = 48}, user_param_val = {s = 0x7efdaa53e320 "", len = 0}, maddr_val = { s = 0x7fff3044ac20 "", len = 1424954698}, method_val = {s = 0xf0 <error: Cannot access memory at address 0xf0>, len = -1437343728}, lr_val = { s = 0x5589562389a1 "From: <sip:+xxx@xxx>;tag=3d63dba0-bd5f-4b46-8434-e84e5b44da90\r\nTo: <sip:+xxx@xxx>\r\nCall-ID: e393131f-4156-44e3-95b0-60b5b7b9c417\r\nCSeq: 3763 INVITE\r\nAllow: OPTION"..., len = 1445169514}, r2_val = {s = 0x7efdaa96fb90 "\001", len = 1425270178}, gr_val = {s = 0x7efdaaf21d68 "\001", len = -1426973352}} u = 0xb53370 port = 12356 dst_host = 0x7efd00000000 i = 0 flags = 0 avp = 0xd4b5e0 st = {flags = 2857912048, id = 1, name = {n = -2004742920, s = {s = 0x7efd88820cf8 "", len = 809806000}, re = 0x7efd88820cf8}, avp = 0x7efda9f7c6fa <futex_release+29>} sct = 0x558954c895ed <sr_event_exec+481> sjt = 0x0 rve = 0x7efdaa5e0a60 mct = 0x7fff3044a820 rv = 0x8000000 rv1 = 0x10 c1 = {cache_type = 48, val_type = RV_NONE, c = {avp_val = {n = -1437343728, s = {s = 0x7efdaa53e010 "\001", len = 809806896}, re = 0x7efdaa53e010}, pval = {rs = {s = 0x7efdaa53e010 "\001", len = 809806896}, ri = -1466248417, flags = 32509}}, i2s = "\360\254D0\004", '\000' <repeats 14 times>, "\b\000"} s = {s = 0x7fff3044a8f0 "0\251D0\377\177", len = 1424958313} srevp = {0x7fff3044abf0, 0x7efdaa53e010} evp = {data = 0x0, obuf = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NUMBER_ST, u = {number = 3, string = 0x3 <error: Cannot access memory at address 0x3>, str = { s = 0x3 <error: Cannot access memory at address 0x3>, len = 0}, data = 0x3, attr = 0x3, select = 0x3}}, {type = STRING_ST, u = {number = 139627952774928, string = 0x7efdaa869f10 "1", str = {s = 0x7efdaa869f10 "1", len = 1}, data = 0x7efdaa869f10, attr = 0x7efdaa869f10, select = 0x7efdaa869f10}}, {type = STRING_RVE_ST, u = {number = 139627953568160, string = 0x7efdaa92b9a0 "+xxx", str = {s = 0x7efdaa92b9a0 "+xxx", len = 13}, data = 0x7efdaa92b9a0, attr = 0x7efdaa92b9a0, select = 0x7efdaa92b9a0}}, {type = STRING_RVE_ST, u = {number = 139627953568208, string = 0x7efdaa92b9d0 "sip:+xxx@xxx", str = {s = 0x7efdaa92b9d0 "sip:+xxx@xxx", len = 31}, data = 0x7efdaa92b9d0, attr = 0x7efdaa92b9d0, select = 0x7efdaa92b9d0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __func__ = "do_action" #25 0x0000558954c108ff in run_actions (h=0x7fff3044aeb0, a=0x7efdaa5ca960, msg=0x7efdaa5846f0) at core/action.c:1584 t = 0x7efdaa5e14b0 ret = 1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} tz = {tz_minuteswest = -1437055248, tz_dsttime = 32509} tdiff = 0 __func__ = "run_actions" #26 0x0000558954c11179 in run_top_route (a=0x7efdaa5ca960, msg=0x7efdaa5846f0, c=0x0) at core/action.c:1669 ctx = {rec_lev = 12, run_flags = 0, last_retcode = 1, jmp_env = {{__jmpbuf = {8589934592, 6388032982750974594, 0, 94048325125683, 32, 139628084768816, 6388032982702740098, 885541357945475714}, __mask_was_saved = 0, __saved_mask = {__val = {0, 139627368492924, 13751034671771081472, 140734003195984, 13751034671771081472, 32, 2, 0, 140734003763305, 32, 13751034671771081472, 8589934592, 8589934592, 0, 94048325125683, 32}}}}} p = 0x7fff3044aeb0 ret = 0 sfbk = 0 #27 0x0000558954d67146 in receive_msg (buf=0x558956238900 "INVITE sip:+xxx@xxx;transport=TCP SIP/2.0\r\nVia: SIP/2.0/TCP xxx:5060;branch=z9hG4bK2149.ed5b7b65e862f15e376ee9d226300d35.0\r\nFrom: <sip:+xxx@xxx>"..., len=1100, rcv_info=0x7efd87b327a8) at core/receive.c:515 msg = 0x7efdaa5846f0 ctx = {rec_lev = 0, run_flags = 0, last_retcode = 33, jmp_env = {{__jmpbuf = {8589935692, 139627368491192, 0, 94048325125683, 32, 139628084768816, 6388032982702740098, 885541357945475714}, __mask_was_saved = 0, __saved_mask = {__val = {139628085660640, 0, 13751034671771081472, 121, 2, 0, 94048325125683, 32, 139628084768816, 140734003196720, 94048323499679, 128, 2, 2214, 4095, 140734003197292}}}}} bctx = 0x0 ret = 0 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} diff = 0 inb = {s = 0x558956238900 "INVITE sip:+xxx@xxx;transport=TCP SIP/2.0\r\nVia: SIP/2.0/TCP xxx:5060;branch=z9hG4bK2149.ed5b7b65e862f15e376ee9d226300d35.0\r\nFrom: <sip:+xxx@xxx>"..., len = 1100} netinfo = {data = {s = 0x558956238900 "INVITE sip:+xxx@xxx;transport=TCP SIP/2.0\r\nVia: SIP/2.0/TCP xxx:5060;branch=z9hG4bK2149.ed5b7b65e862f15e376ee9d226300d35.0\r\nFrom: <sip:+xxx@xxx>"..., len = 1100}, bufsize = 0, rcv = 0x7efd87b327a8, dst = 0x0} keng = 0x0 evp = {data = 0x7fff3044b0a0, obuf = {s = 0x0, len = 0}, rcv = 0x7efd87b327a8, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} cidlockidx = 0 cidlockset = 0 errsipmsg = 0 exectime = 0 __func__ = "receive_msg" #28 0x0000558954ea7d39 in receive_tcp_msg ( tcpbuf=0x7efd87b32b30 "INVITE sip:+xxx@xxx;transport=TCP SIP/2.0\r\nVia: SIP/2.0/TCP xxx:5060;branch=z9hG4bK2149.ed5b7b65e862f15e376ee9d226300d35.0\r\nFrom: <sip:+xxx@xxx>"..., len=1100, rcv_info=0x7efd87b327a8, con=0x7efd87b32790) at core/tcp_read.c:1413 ret = 0 buf = 0x558956238900 "INVITE sip:+xxx@xxx;transport=TCP SIP/2.0\r\nVia: SIP/2.0/TCP xxx:5060;branch=z9hG4bK2149.ed5b7b65e862f15e376ee9d226300d35.0\r\nFrom: <sip:+xxx@xxx>"... bsize = 65535 blen = 65535 __func__ = "receive_tcp_msg" #29 0x0000558954eaa39a in tcp_read_req (con=0x7efd87b32790, bytes_read=0x7fff3044b564, read_flags=0x7fff3044b56c) at core/tcp_read.c:1604 bytes = 1100 total_bytes = 1100 resp = 1 size = 0 req = 0x7efd87b328b8 dst = {send_sock = 0x0, to = {s = {sa_family = 50739, sa_data = "\002U\211U\000\000 \000\000\000\000\000\000"}, sin = {sin_family = 50739, sin_port = 21762, sin_addr = {s_addr = 21897}, sin_zero = " \000\000\000\000\000\000"}, sin6 = {sin6_family = 50739, sin6_port = 21762, sin6_flowinfo = 21897, sin6_addr = {__in6_u = {__u6_addr8 = " \000\000\000\000\000\000\000\060\260d\262\375~\000", __u6_addr16 = {32, 0, 0, 0, 45104, 45668, 32509, 0}, __u6_addr32 = {32, 0, 2992943152, 32509}}}, sin6_scope_id = 809809184}, sas = {ss_family = 50739, __ss_padding = "\002U\211U\000\000 \000\000\000\000\000\000\000\060\260d\262\375~\000\000 \265D0\377\177\000\000\002\263\352T\211U\000\000\377\377\377\377)\000\000\000`\036\026U\211U\000\000\000\000\000\000\001 \000\000\030\204X\252\001\000\000\000\240\264D0\001\000\000\000P\273R\206.\000\000\000\001\000\000\000\000\000\000\000\000\376\207\213\375~\000\000\260\265D0\377\177\000\000\030\204X\252\375~\000", __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 41 ')', proto_pad0 = 0 '\000', proto_pad1 = 0} c = 10 '\n' ret = 0 __func__ = "tcp_read_req" #30 0x0000558954eaed62 in handle_io (fm=0x7efdaa588358, events=1, idx=-1) at core/tcp_read.c:1855 ret = 0 n = 456 read_flags = RD_CONN_SHORT_READ con = 0x7efd87b32790 s = 41 resp = 1 t = 1953053264 ee = 0x0 __func__ = "handle_io" #31 0x0000558954e991dd in io_wait_loop_epoll (h=0x558955161e60 <io_w>, t=2, repeat=0) at core/io_wait.h:1070 n = 1 r = 0 fm = 0x7efdaa588358 revents = 1 __func__ = "io_wait_loop_epoll" #32 0x0000558954eb0840 in tcp_receive_loop (unix_sock=46) at core/tcp_read.c:1976 __func__ = "tcp_receive_loop" #33 0x0000558954e8d46d in tcp_init_children (woneinit=0x7fff3044b950) at core/tcp_main.c:5227 r = 6 i = 7 reader_fd_1 = 46 pid = 0 si_desc = "tcp receiver (generic)\000\000\330\356\341T\211U\000\000\060\271D0\377\177\000\000۲\353T\000\000\000\000\240\363Y\252\000\000\000\000\273'\006U\211U\000\000\246\000D0\377\177\000\000\347\373\374T\211U\000\000\000\271D0\001\000\000\000P\273R\206\375~\000\000\000\271D0\377\177\000\000\320\003\361\210\001\000\000\000 \271D0\377\177\000\000\205\375\374T\211U\000" si = 0x0 __func__ = "tcp_init_children" #34 0x0000558954becf03 in main_loop () at main.c:1849 i = 8 pid = 1477 si = 0x0 si_desc = "udp receiver child=7 sock=xxx:5060\000\000\000\000\003\000\000\000 \000\000\000\000\333\376\210-}վ\000\000\000\000\000\000\000\000\210`\001U\211U\000\000\000\000\000\000\000\000\000\000\063\306\002U\211U\000\000 \000\000\000\000\000\000\000\060\260d\262\375~\000\000кD0\377\177\000\000ai\331T\211U\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #35 0x0000558954bf7acf in main (argc=17, argv=0x7fff3044c028) at main.c:3078 cfg_stream = 0x5589560d12a0 c = -1 r = 0 tmp = 0x7fff3044df42 "" tmp_len = 0 port = 0 proto = 7 ahost = 0x0 aport = 0 options = 0x558955018e90 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 1882048236 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x0 st = {st_dev = 23, st_ino = 862, st_nlink = 2, st_mode = 16832, st_uid = 109, st_gid = 115, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1667940516, tv_nsec = 335990872}, st_mtim = {tv_sec = 1667941120, tv_nsec = 945450055}, st_ctim = {tv_sec = 1667941121, tv_nsec = 329446417}, __glibc_reserved = {0, 0, 0}} tbuf = "\000\000\000\000\000\000\000\000\030RM0\377\177\000\000\000\000\000\000 ", '\000' <repeats 27 times>, "\001\000\000\000\000\000\000\000\366u\256\003\001", '\000' <repeats 19 times>, "\002", '\000' <repeats 319 times>... option_index = 0 long_options = {{name = 0x55895501b2b3 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x5589550164e0 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55895501b2b8 "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55895501b2be "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55895501b2c4 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55895501b2cd "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x55895501b2d7 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x55895501b2e1 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55895501b2ec "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55895501b2f5 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55895501b300 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55895501b306 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x55895501b310 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main"

2 2

RPM SPEC file differs between repo and build server
by Ryan Cloherty 17 Nov '22

17 Nov '22

Hello, When trying to install the Kamailio RPM from https://rpm.kamailio.org/centos/7/5.6/5.6.2/x86_64/Packages/k/kamailio-5.6.…, I encountered an issue due to a dependency on "libpython3.6m". It seems like the SPEC file in the repository <https://github.com/kamailio/kamailio/blob/5.6/pkg/kamailio/obs/kamailio.spe…> differs quite wildly from the SPEC file on the openSUSE Build Service <https://build.opensuse.org/package/view_file/home:kamailio:v5.6.x-rpms/kama…>. On lines 667-668 of the OBS copy, you can see the explicit dependency on "python36". Is this intentional or is this something that needs to be fixed? Thank you, Ryan C

3 13

KEMI - app_python3 - reload multiple python files
by Niklas Larsson 15 Nov '22

15 Nov '22

Hi, for the first time we tried to build all routing in kemi with app_python3, and it works well. But app_python.reload only reloads the file in: modparam("app_python3", "load", "/etc/kamailio/kemi/kamailio.py") And that is a little problem for us, since we are using multiple files to use modules etc. At the moment we have 8 files besides kamailio.py. Is there a way to reload all of them, without restarting kamailio? /niklas

4 5

Kamailio devel event starting tomorrow
by Daniel-Constantin Mierla 15 Nov '22

15 Nov '22

Hello, as some of you may know from previous announcements, a few of us meet tomorrow and the day after in Dusseldorf at sipgate.de for a Kamailio development event. Should anyone want to join remotely, we can make available a video conference bridge. Join if you want to work together to add new features to Kamailio or help improving existing tools and documentation. It is not an event for discussing about Kamailio or how to use it. Reply to this email (can be only to me this time) if you want to join remotely and eventually provide the time you think you would be around and, if you have something in mind, what you would like to work on. You can also join if you don't have already something to work on, you can become part of another team and help them. You will receive privately the details of how to join the video conference room. Tomorrow we plan to to start the day around 10:30 Berlin time zone (UTC + 1), probably wrapping up around 17:00. The schedule for Thursday will be given tomorrow once it is decided. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

USRLOC module - Not all records are written to the db with db_mode 2
by Markus Bönke 15 Nov '22

15 Nov '22

Hello NG, we are using Kamailio 5.4.2 with the USRLOC module configured with db_mode 2 (Write-Back scheme). The database is Postgres 11. Sometimes some records are not written to the database, however I can lookup them by "kamcmd ul.lookup ..." . There are no database errors (like constraint violations or value too large errors) to see in the postgres.log. Not even when I execute "kamcmd ul.flush" manually. There are also no related error messages to see in the Kamailio.log during "kamcmd ul.flush". Has anyone else seen that issue or is this might already fixed in a newer version? Thanks and regards Markus

4 4

set_dlg_profile profile name with and without value?
by Benoit Panizzon 15 Nov '22

15 Nov '22

Hi I am wondering, if a profile with value can on the same time be used as profile without value of this usages exclude each other. Like doing: set_dlg_profile("caller"); set_dlg_profile("caller","$si"); get_profile_size("caller","$var(c_total)"); get_profile_size("caller","$si","$var(c_ip)"); xlog("L_INFO", "$cfg(route): Total Caller: $var(c_total)\n"); xlog("L_INFO", "$cfg(route): Caller from $si: $var(c_ip)\n"); I fear this is not possible, as I keep getting: w_set_dlg_profile_helper(): invalid value parameter and w_get_profile_size_helper(): invalid value parameter right? 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 1

Tcp/websocket closing
by David Villasmil 14 Nov '22

14 Nov '22

Hello all, Question: Say there’s a client connecting via websocket, makes a call and then unregisters. But kamailio sends a 401 expecting the client to authenticate. If the client doesn’t, and simply stays there, at what point is the socket closed? Is it the OS timeout? Thanks! David -- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 2

About the Presence service 401 issue
by SparkleZou 14 Nov '22

14 Nov '22

Hi Sir/Madam, I'm trying to set up the presence service according to the manual http://kb.asipto.com/kamailio:presence:k31-made-simple Also refer to the doc https://kamailio.org/docs/modules/devel/modules/xcap_server.html Seems the Kamailio cfg fine. but when to get the xcap data, get the 401 response. Please see the attached log. Is there any more should be configured? Thanks! BR, Sparkle Zou

3 8

Uneven-distribution of calls
by satyaprakash ch 14 Nov '22

14 Nov '22

Hi, what would be the reason for the *Un-even* distribution of calls from kamailio proxy to freeswitches. The dispatcher lists are having the same weight. For example: If we are having 4 freeswitches, the calls are evenly distributing for 3 freeswitches but there is high calls for the 4th freeswitch. The dispatcher weight for the freeswitches are: rweight=50;weight=50;cc=1; Thanks and regards, Satya

2 7

kamcmd dlg.list => ERROR: reply too big
by Benoît Panizzon 14 Nov '22

14 Nov '22

Hi List I fear I am loosing dialogues somehow. We have implemented counting concurrent connections from customers by using set_dlg_profile. Sometimes, the concurrent channel count does not decrease, despite the dialog end being detected. Now I suppose I have maybe a dozen concurrent calls running, but kamcmd dlg.list is unable to dump the list. kamcmd dlg.dump_file generates quite a large file. I was running into SHM issues while load-testing and had to increase SHM to 1024 to accommodate all dialogues and vars. I fear this could have caused corrupted dialogues? Dialog Data is replicated via DMQ between two instances which I too care never to restart at the same time. Will completely stop and then restart the two affected instances and clear the dialog and dialog_vars tables to see if this issue is manifesting itself again. -- 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 ______________________________________________________

2 1

External script
by Володимир Іванець 11 Nov '22

11 Nov '22

Hello! I was wondering how everyone uses exec_cmd(). I'm using it to call an external script directly from a worker route which locks it for the time of execution. If all that is needed is to call it and forget, should the best option be to call the async route with exec_cmd()? Thanks a lot for any input on this topic!

3 3

Kill child process created by app_python module
by Marat Gareev 11 Nov '22

11 Nov '22

Hello! I'm trying to use app_python module to perform periodic actions. This is a simple python code def _update(): while True: _action() time.sleep(60) class noop_handler: def child_init(self, rank): return 0 def ksr_request_route(self, msg): return 1 def mod_init(): # signal.signal(signal.SIGTERM, signal.default_int_handler) proc = multiprocessing.Process(target=_update) # proc.daemon = True proc.start() ksr.notice('Forked process {} to update\n'.format(proc.pid)) return noop_handler() After killing kamailio processes with SIGTERM signal (killall kamailio) I see zombie process. And if I try to process the signal in daemon mode (see the comments in the snippet above), I get critical errors in the logs and still see processes: 0(37001) NOTICE: <core> [core/kemi.c:124]: sr_kemi_core_notice(): Forked process 37002 to update 1(37003) ERROR: <core> [core/udp_server.c:464]: udp_rcv_loop(): recvfrom:[4] Interrupted system call Process Process-1: Traceback (most recent call last): File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap self.run() File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "/tmp/script.py", line 155, in _update time.sleep(period) KeyboardInterrupt 0(37001) ALERT: <core> [main.c:774]: handle_sigs(): child process 37002 exited normally, status=1 0(37001) INFO: <core> [main.c:802]: handle_sigs(): terminating due to SIGCHLD 1(37003) ERROR: <core> [core/udp_server.c:464]: udp_rcv_loop(): recvfrom:[4] Interrupted system call 8(37014) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 4 1(37003) ERROR: <core> [core/udp_server.c:464]: udp_rcv_loop(): recvfrom:[4] Interrupted system call So, how I can kill child process by SIGTERM signal?

3 5

acc module => account register messages?
by Benoît Panizzon 11 Nov '22

11 Nov '22

Hi Is there a way to get register messages into accounting? This could come in handy while helping figure out if clients were not registered while calls attemted to reach them. -- 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 2

Mysql.sock
by satyaprakash ch 08 Nov '22

08 Nov '22

Hi Team, I want to know this reason - why kamailio only can connect to mysql using */tmp/mysql.sock <https://phonecom.atlassian.net/browse/VOIP-1760?atlOrigin=eyJpIjoiNzY1NjU4Y…>* and why it can’t use /run/mysql/mysql.sock Thanks and regards, Satya.

2 1

Mysql.sock
by Satyaprakash Chiramchetty 08 Nov '22

08 Nov '22

Hi Team, I want to know this reason - why kamailio only can connect to mysql using */tmp/mysql.sock <https://phonecom.atlassian.net/browse/VOIP-1760?atlOrigin=eyJpIjoiNzY1NjU4Y…>* and why it can’t use /run/mysql/mysql.sock Thanks and regards, Satya. -- * <https://www.ecosmob.com/> * *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

1 0

evapi:message-received and state
by Alex Balashov 07 Nov '22

07 Nov '22

Hi, I am t_continue()ing a transaction inside of event_route[evapi:message-received]. The $evapi(msg) has quite a bit of payload that will be needed by the resumed transaction. Is there a good way to inject this data into the transaction scope externally? No [X]AVPs created in the event_route persist, of course, since the route is scoped outside of the transaction. I have been using htable to pass data into the transaction, keyed by the index and label. But, this strikes me as a kind of clumsy memory synchronisation anti-pattern. Is there a better way? Cheers, — Alex -- 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 5

Kamailio Not Responding to Connections
by Carlos Escalona 07 Nov '22

07 Nov '22

Hello! I hope all of you are having a nice day. I would like some help. I recently had some troublesome events in my Kamailio setup, at a particular time of the day specifically after lunch when my platform's traffic spikes Kamailio suddenly stops responding to any connection and restarting it didn't fix the problem basically I have to restart the hardware to get out of that failed state. The only unusual log is the following: Oct 28 16:49:10 ip-172-32-16-97 /usr/sbin/kamailio[952]: ERROR: topos [tps_storage.c:615]: tps_storage_record(): failed to store Someone recently posted a problem that occurred when doing stress tests with the siptrace module active and the service that collects the traces was failing, I wonder if this may be the case because it is possible that something similar is happening in my case. Unfortunately, I don't have much more information since I had to implement a quick fix that mitigates the problem for now, but I would like to be able to go back to the previous configuration that seemed more appropriate. My plan is to test now that I have solved the problem I had with the traces service, but I wanted to know if anyone had experienced a similar situation. Atenciosamente, [image: photo] <https://www.techer.com.br/> *Carlos Escalona* IT - Development 41 3073-0091 | R 1011 www.techer.com.br -- O conteúdo desta mensagem é confidencial. Se você não se encontra na lista de destinatários ou tenha recebido por engano, não a copie, imprima, envie, ou utilize, de qualquer forma, seu conteúdo. Neste caso, destrua a mensagem e, por favor, notifique o remetente.

2 1

Serial Forking on BYE message
by Ilie Soltanici 05 Nov '22

05 Nov '22

Hello, I have a challenge here to do serial forking, not when the call is failed on the first destination, but when the call is ended. So, the first will go to one destination, will be answered, and when it's ended the BYE message should be dropped and forward the initial INVITE to another location. Is that possible?

2 1

Re: [SR-Users] $Rp variable seems to contain wrong port
by Luis Azedo 04 Nov '22

04 Nov '22

have you tried to use $T_rpl($Rp) ?

1 0

$Rp variable seems to contain wrong port
by Ross McKillop 03 Nov '22

03 Nov '22

Hi All, At the risk of possibly dragging up an old thread (https://lists.kamailio.org/pipermail/sr-users/2021-June/112791.html <https://lists.kamailio.org/pipermail/sr-users/2021-June/112791.html>) I’m seeing unusual behaviour where $Rp is still showing what I think is the ‘wrong’ behaviour, but given Daniel’s reply on the earlier thread I want to be sure this isn’t the intended behaviour. The thread above confirms that $Rp is not taken from the IP layer but is intended to give the attribute of the listen socket associated with the SIP traffic, which is fine and what I’m expecting, but in my case it doesn’t seem to be working this way. (I’ve tried with and without tcp_reuse_port=yes and tcp_connection_match=1 too just in case one of the above parameters has changed this behaviour) If Kamailio listening on multiple ports e.g. listen=tcp:10.30.22.73:7701 listen=tcp:10.30.22.73:7702 listen=tcp:10.30.22.73:7703 listen=tls:10.30.22.73:7801 listen=tls:10.30.22.73:7802 listen=tls:10.30.22.73:7803 And I use $fs to force the socket of an outbound message to one of the above before t_relay() it works as expected (with tcp_reuse_port it originates from the given port number above, without that set it will originate from a different ephemeral port even to the same destination, so $fs is working as expected) Then, in reply_route{} I have a simple line to add the port it was received on to the headers (I’ve also tried with $RAp) append_hf("X-Rcvd-Port: $Rp\r\n”); In every case, the reply seems to contain the *first* port of the protocol type (so in the above example every TCP reply irrespective of whether it is to 7701/02/03 will show $Rp 7701, and every TLS reply will show 7801) Any advice or insight anyone can offer would be much appreciated. Thanks, Ross

1 0

Siptrace and Kamailio "stress" test
by Igor Olhovskiy 03 Nov '22

03 Nov '22

Hello, Found an interesting scenario, maybe something could be done here. I have a siptrace module configured like modparam("siptrace", "duplicate_uri", "sip:<MY_HOMER_SERVER>:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "trace_mode", 1) When Kamailio is under stress test (sipflood via OPTIONS/TLS), with this settings it transfers all flood to HOMER server. At some point Kamailio just stops accepting any new TLS connections. Turning off siptrace solves this issue. As I got, siptrace module is not changing protocol of the message (means not converting TCP/UDP) or so. Could it be possible, that at some point siptrace "eats" all TCP connections (especially if remote HOMER is down or not answering) which leads Kamailio to stop processing any new connections? And is it possible to send HEP traffic only via UDP to prevent this? Yes, sure other option is to trace only "legal" traffic -- Best regards, Ihor (Igor)

3 5

Pipelimit needs restart to reload values
by Duarte Rocha 02 Nov '22

02 Nov '22

Greetings, I've been using the pipelimit module and the pl_check function to control users rates in my proxy. if (!pl_check("$var(UserID)", "TAILDROP", "$var(UserRate)")) { pl_drop(); exit; } In this case $var(UserID) is the pipe and $var(UserRate) is the maximum rate. The value of the rate is retrieved on every call via query to a DB. If I change the UserRate value to 0 CPS on the DB calls are not rejected unless they go over 1 CPS. However, if I restart Kamailio all calls are correctly rejected. Why does this happen? Can I change this behaviour? Cheers, Duarte

3 3

Appending new branches via external means
by Alex Balashov 01 Nov '22

01 Nov '22

Hi, Is there a means of appending new branches from config script for a transaction which is already proceeding in the background, without using `tsilo`? That is to say, I have an async transaction which is resumed in an async worker and is t_relay()’d away to some destination. Meanwhile, I have learned about new destinations for it to try via an incoming registration, and would like to append additional parallel forking branches to that transaction, even though it is already proceeding. ts_append() does this for me; the issue I have is that it is mediated through a registrar, but I am not a registrar. My registrar is upstream, and my proxy is just a front-end to it. So, in essence, I require something like `tsilo` at a more general level, where contacts can be populated by some other mechanism rather than being learned via callbacks out of `usrloc`. Is there a way to accomplish this? Cheers, — Alex -- 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/

3 6

consume_credentials not working on PRACK?
by Benoit Panizzon 01 Nov '22

01 Nov '22

Hi List I noticed, that one of our CPE copies the Proxy-Authorization HF in almost all messages sent. As PRACK were not authenticated, those headers were potentially sent on to the destination disclosing the authentication username and realm. So assuming, if credentials are present, the client wishes them to be validated, I added: if (has_credentials("$fd")) { xlog("L_INFO", "$cfg(route): got $rm with credentials. Validate them!\n"); route(AUTH); } and in route[AUTH] I call: pv_auth_check() which returns 1 thus success upon which I use: if(!is_method("REGISTER|PUBLISH")) consume_credentials(); If the method is INVITE: Proxy-Authorization HF is removed by consume_credentials() if the method is PRACK: Proxy-Authorization HF is still present on the outbound leg. 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 ______________________________________________________

3 5

Authentication: Is it possible to ignore realm? How to avoice unnecessary challenge because of changed realm?
by Benoit Panizzon 01 Nov '22

01 Nov '22

Hi As mentioned in the last email, we have a CPE which adds credentials to any request so I would like to validate them. We use $rd as realm. Let's use example.com as example. During the initial INVITE, this works as expected. I try to only show the headers I think are relevant to the issue I face. INVITE sip:1234@example.com SIP/2.0 Proxy-Authorization: [...] realm="example.com" Contact: <sip:9876@192.168.1.1:5060> Authentication user in realm "example.com" == $rd is validated and accepted. The connection is establised: 200 OK From: <sip:9876@example.com>;tag=1 To: <sip:1234@example.com>;tag=2 Contact: <sip:1234@192.168.7.7:5060> The caller terminates the connection: BYE: sip:1234@192.168.7.7:5060 SIP/2.0 From: <sip:9876@example.com>;tag=1 To: <sip:1234@example.com>;tag=2 Proxy-Authorization: [...] realm="example.com" Performing: $var(authres) = pv_auth_check("$rd", "$avp(authsecret)", "0", "1"); fails wirh result -5 as there is no authsecret for realm "192.168.7.7" So an unnecessarey challenge is issued: SIP/2.0 407 Proxy Authentication Required To: <sip:1234@example.com> From: <sip:9876@example.com> CSeq: 3 BYE Proxy-Authenticate: Digest realm="192.168.7.7" To which the client replies with the changed realm: Proxy-Authorization: Digest username="****",realm="157.161.7.7",[...] and succeeds authentication. Is there a way to accept 'any' realm? Or to avoid this unnecessary change of realm just because the remote site submitted a domain realm in the contact header? 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 2

SIP routing per MSISDN
by Anthony Blandin 30 Oct '22

30 Oct '22

Hello, I need to route SIP INVITE towards a specific node based on the MSISDN of the Request URI. I saw that the dispatcher module should be able to make this with the function ds_select_dst and the algorithm "hash over request-URI user" but I don't understand how the routing is done if we can't associate the request-URI user with the destination address in the dispatcher DB. Maybe my understanding of this module is wrong. Could you help me to achieve this? Thanks Anthony

3 2

Kamailio sending response to source IP and port from Via ?
by Chaigneau, Nicolas 27 Oct '22

27 Oct '22

Hello, I'm using Kamailio in stateless mode to send redirect responses. I've noticed that the responses are sent to the packet source IP address, and to the port found in the Via header. I'm a bit confused. I was expecting the response to be sent to the address and port found in the Via header. Is it the expected behaviour ? I'm using Kamailio 5.5.2. Thanks for your help ! Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

2 4

Issue with debug 3 after upgrade to kamailio 5.6.2+
by Julia Bo 27 Oct '22

27 Oct '22

Hello, After upgrading kamailio 5.6.1 to 5.6.2 (from source) debug 3 doesn't print messages related to calls to the log file. I only see OPTIONS transactions in debug. Does anyone have the same problem? Best regards, Julia.

2 3

About the WITH_VOICEMAIL Subscriber message 407 issue
by SparkleZou 26 Oct '22

26 Oct '22

Hi Sir/Madam, I'm trying to set a Fresswitch as the Voicemail server. I set the #!define WITH_VOICEMAIL in the kamailio.cfg file to enable the default VoiceMail configuration. Set the voicemail server address as following : voicemail.srv_ip = "10.120.100.179" desc "VoiceMail IP Address" voicemail.srv_port = "5060" desc "VoiceMail Port" And the kamailio server address is 10.120.100.180. Here face the issue, the Subscribe message could NOT be authorized. The SUBSCRIBER message with token could NOT be forworded to Freeswitch. The log is also attached. It's resllay strange. Please help check. Thanks! BR, Sparkle Zou

3 4

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