sr-users March 2021

sr-users@lists.kamailio.org

61 participants
67 discussions

Kamailio how to make UAC challenge on Dispatcher failure route
by Antonio Couto 17 Mar '21

17 Mar '21

I have one Kamailio that makes an outbound register on two Asterisk. I have a dispatcher with that same two Asterisk destinations, on INVITE message I call replace_from("", ) in order to call a internal extension and on failure route I receive 401 and call the process of authorization is OK. The problem is that if the first Asterisk fail and I get 500 on failure route I can not call replace_from() because is not valid on the block. Is there any way to make this type of authorization process after receiving a 500 on failure route of dispatcher ? Below my cfg file. Thanks in advance. Antonio Couto #!KAMAILIO#!ifdef WITH_DEBUG#!define DBGLEVEL 3#!else#!define DBGLEVEL 2#!endif # - flags# FLT_ - per transaction (message) flags# FLB_ - per branch flags#!define FLT_ACC 1#!define FLT_ACCMISSED 2#!define FLT_ACCFAILED 3#!define FLT_NATS 5 #!define FLB_NATB 6#!define FLB_NATSIPPING 7 ####### Global Parameters ######### /* LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR, ... */ debug=DBGLEVEL /* set to 'yes' to print log messages to terminal or use '-E' cli option */log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0log_prefix="{$mt $hdr(CSeq) $ci} " children=8 auto_aliases=noenable_tls=noenable_sctp=no tcp_accept_no_cl=yes # SIP port listen=udp:192.168.0.201:5060# xhttp port listen=tcp:127.0.0.1:8181 loadmodule "xhttp.so" loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "acc.so" loadmodule "dispatcher.so" loadmodule "htable.so" loadmodule "db_text.so" loadmodule "dialog.so" loadmodule "uac.so" # ----------------- setting module-specific parameters --------------- # ----- jsonrpcs params ----- modparam("jsonrpcs", "pretty_format", 1) modparam("jsonrpcs", "transport", 1) # ----- sanity params ----- modparam("sanity", "autodrop", 0) # ----- tm params -----# default retransmission timeout: 2sec modparam("tm", "fr_timer", 1500)# default invite retransmission timeout after 1xx: 40sec modparam("tm", "fr_inv_timer", 40000) # ----- rr params -----# set next param to 1 to add value to ;lr param (helps with some UAs) modparam("rr", "enable_full_lr", 0) modparam("rr", "append_fromtag", 1) # account triggers (flags) modparam("acc", "log_flag", FLT_ACC) modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") # ----- dispatcher params ----- modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "flags", 2) modparam("dispatcher", "xavp_dst", "_dsdst_") modparam("dispatcher", "xavp_ctx", "_dsctx_") modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_from", "sip:proxy@kamailio.org") modparam("dispatcher", "ds_ping_interval", 1) modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_probing_threshold", 1) modparam("dispatcher", "ds_inactive_threshold", 1) modparam("dispatcher", "ds_timer_mode", 1) modparam("db_text", "db_mode", 1) modparam("db_text", "emptystring", 1) modparam("dialog", "dlg_flag", 4) modparam("dialog", "track_cseq_updates", 1) modparam("uac", "restore_dlg", 1) modparam("uac", "reg_db_url", "text:///etc/kamailio/dbtext") modparam("uac", "reg_db_table", "uacreg") modparam("uac", "reg_timer_interval", 60) modparam("uac", "reg_retry_interval", 60) modparam("uac", "reg_contact_addr", "192.168.0.201:5060") modparam("uac","auth_username_avp","$avp(auser)") modparam("uac","auth_password_avp","$avp(apass)") modparam("uac","auth_realm_avp","$avp(arealm)") ####### Routing Logic ######## # main request routing logic request_route { # per request initial checks route(REQINIT); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle retransmissions if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } # handle requests within SIP dialogs route(WITHINDLG); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { record_route(); } # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations if (is_method("INVITE")) { route(DISPATCH); } else { sl_send_reply("501","Not Implemented"); exit; } } # Dispatch requests route[DISPATCH] { if ($si == "192.168.0.44" and $sp == 5060) { xlog("L_ALERT","from switch $si:$sp)\n"); $var(groupid) = "2"; } else{ xlog("L_ALERT","from others $si:$sp)\n"); $var(groupid) = "1"; } if(!ds_select_dst($var(groupid), "11")) { send_reply("503", "Service Unavailable"); exit; } if ($du =~ "192.168.0.210") { xlog("L_ALERT", "SCRIPT: uac_replace_from\n"); uac_replace_from("", "sip:4000@192.168.0.201:5060"); } xlog("L_ALERT", "SCRIPT: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } failure_route[RTF_DISPATCH] { $var(ts) = t_get_status_code(); xlog("L_ALERT","ALERT: failure_route[RTF_DISPATCH]] from $si:$rp status:$var(ts)\n"); if (t_is_canceled()) { exit; } if(t_check_status("401|407")) { $avp(auser) = "4000"; $avp(apass) = "1234"; $avp(arealm) = "asterisk"; if (uac_auth()) { route(RELAY); } exit; } if (t_check_status("500") or (t_branch_timeout() and !t_branch_replied())) { if (ds_next_dst()) { xlog("L_ALERT", "retrying to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } } } # Per SIP request initial checks route[REQINIT] { if($ua =~ "friendly|scanner|sipcli|sipvicious|VaxSIPUserAgent") { # silent drop for scanners - uncomment next line if want to reply # sl_send_reply("200", "OK"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS") && uri==myself && $rU==$null) { sl_send_reply("200","Keepalive"); exit; } if(!sanity_check("17895", "7")) { xlog("Malformed SIP request from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (!has_totag()) { return; } # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } route(RELAY); exit; } if (is_method("ACK")) { if (t_check_trans()) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server route(RELAY); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("500","Server Internal Error"); exit; } # Wrapper for relaying requests route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } # jsonrpc dispatch event_route[xhttp:request] { if ($hu =~ "^/RPC") { jsonrpc_dispatch(); } else { xhttp_reply("200", "OK", "text/html", "<html><body>Wrong URL $hu</body></html>"); } }

2 1

kamcmd dlg.end_dlg not working in shell script
by Andrew Chen 16 Mar '21

16 Mar '21

Hi all, I have a script that cleans up hanging dialog and for some reason, executing 'kamcmd dlg.end_dlg' does not seem to work. Below I log events of stuck calls and as you can see it just keeps logging the same call until I manually run the kamcmd either in bash shell prompt or in kamcmd cli: 2021-03-08T19:00:04.347807+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:00:04 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:01:02.531822+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:01:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:02:02.689823+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:02:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:03:02.044960+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:03:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:04:02.436588+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:04:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:05:02.685572+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:05:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:06:02.775561+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:06:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:07:01.867021+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:07:01 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:08:01.888512+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:08:01 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:09:02.146887+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:09:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:10:02.649627+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:10:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:11:01.904948+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:11:01 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:12:01.932267+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:12:01 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:13:02.428128+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:13:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:14:02.617683+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:14:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:15:01.863099+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:15:01 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:16:01.650299+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:16:01 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:17:02.338576+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:17:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:18:01.743163+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:18:01 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:19:02.257369+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:19:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:20:01.624170+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:20:01 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul 2021-03-08T19:21:02.287343+00:00 sjointgkama51 /scripts/get-call-from-hepic.sh - get-call-from-hepic: Mon Mar 8 19:21:02 UTC 2021 Found active dialog on completed call. Delete call using h_entry: 1333 *h_id*: 11225 on SIP Call-ID 7j5r1msitcvg9siohoul Thoughts? Thanks! -- Andy Chen Sr. Telephony Lead Engineer achen@ <achen(a)thinkingphones.com>fuze.com -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

5 15

dmq support for all transports - udp, tcp, tls, sctp
by Daniel-Constantin Mierla 16 Mar '21

16 Mar '21

Hello, (cross-posting - notification for developers, but also looking for testing support in the users community). So far dmq had support only for UDP, suitable to use for replication over trusted networks (local private network, or vpn). There were couple of discussions in the past about supporting other transport like tcp or tls. Earlier today I pushed several commits to dmq module trying to remove the limitation on UDP, and support the rest of the base protocols available in Kamailio (TCP, TLS and SCTP). Internally, a significant behaviour change is that the first (startup) peer notification is now done in the SIP worker one process, instead of the main process, in order to have all transports initialized. I could not spot any relevant side effect that can happen based on quick analysis, because the code with UDP only support was sending out the KDMQ requests, the corresponding replies could come back later. Anyhow, if any other dmq developer thinks of something not being quite right, reply to the sr-dev mailing list to discuss further. For users community: it would be appreciated if people using dmq can test with other transports (TLS, TCP, ...) and report any problems on sr-users mailing list or open an issue on bug tracker. Interesting test scenarios would be with replication of large amount of data or high rate of replicated requests per second. My testing got to the level of connecting to peers via TLS, trying to ensure the code is no longer limiting to UDP. I will do more, but I thought of giving a notification in early phase and get some feedback in order to avoid advancing too much in a wrong direction. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla

1 0

Dialog using Recod Route, with an asterisk
by Nicki Otte 15 Mar '21

15 Mar '21

Hi everyone I have a question regarding the dialog module. It uses the RecordRoute header, which seems all fine. The situation: I have a setup, where the Kamailio proxy, which is running with the dialog module, is talking to an Asterisk. Now the logic in the Asterisk, is to place a new call, and return in to the Kamailio proxy, which sends it to the PSTN. By the logic of the asterisk, it doesn’t persist with the RecordRoute headers. It starts from scratch with a new callId. Here lies the problem. Because the RecordRoute header isn’t given, then a new “dialog” is made, instead of using the one that is established. Here comes my question. Is it against the standards to make the Asterisk persist with these headers, or am I looking at the wrong solution? If not, I do see the power of the dialog module, when a call bounces between UAS’, but not when an asterisk is in the setup. Another solution could be to use a custom x- header for the dialog id, but it doesn’t look like that is a possibility. Have any of you run into this situation, and might have a solution? Thanks in advance // Nicki Bo Otte

2 2

Re: [SR-Users] Trouble with Kamailio/RTPEngine and NAT/Firewall
by PJ Slauta 15 Mar '21

15 Mar '21

Hi Jeremy, We are currently using that configuration. -----Original Message----- From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of sr-users-request(a)lists.kamailio.org Sent: Sunday, March 14, 2021 7:00 AM To: sr-users(a)lists.kamailio.org Subject: sr-users Digest, Vol 190, Issue 13 Send sr-users mailing list submissions to sr-users(a)lists.kamailio.org To subscribe or unsubscribe via the World Wide Web, visit https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kama… 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. Re: iOS CallKit and tsilo (Jeremy McNamara) 2. Re: Trouble with Kamailio/RTPEngine and NAT/Firewall (Jeremy McNamara) ---------------------------------------------------------------------- Message: 1 Date: Sat, 13 Mar 2021 12:43:55 -0500 From: Jeremy McNamara <mcnamara.jeremy(a)gmail.com> To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Subject: Re: [SR-Users] iOS CallKit and tsilo Message-ID: <CAO0X5JSeyYHB8MhWrxd9khdQNbSigfGVOVZBw43=z0rVwhi-GA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Igor - Are you following the example from Frederico? We have implemented his idea for our iOS and Android apps... Make sure to send over the SIP CallID in the push notification. That way if a CANCEL does get sent (on JOIN/RESUME) the app can react to it correctly. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamail…

1 0

iOS CallKit and tsilo
by Igor Olhovskiy 14 Mar '21

14 Mar '21

Hello! Is there any way to "store" already finished transactions in tsilo? Idea is to deliver, for example, canceled calls to the phone, when call already was answered on other device, but push notification arrive later? Major problem here, that there how it's working on iOS. On iOS phone first show you calling screen, than - app is waking and after app will register and receive invite with tsilo, it updates calling screen with CallerID and other info. But if call was canceled before, calling screen is shown, but app not receiving INVITE, so, call screen is just there for some timeout (for Linphone, for ex, it's 20 sec). Right now I've manage to do it via external SIPP call, that emulates "fake missed call", but maybe there is other way to "store" already dead transactions for some time? PS: Unfortunately, can't solve this on mobile app level. -- Regards, Igor

4 10

Trouble with Kamailio/RTPEngine and NAT/Firewall
by PJ Slauta 13 Mar '21

13 Mar '21

Hi, I have a Kamailio/RTPEngine setup with Asterisk on a couple of EC2 instances. There is a public IP and it's setup to accept any ports from our IP addresses. If I DMZ my machine behind my router, I get audio, otherwise I don't get any audio, but the SIP portion of the call connects properly. It isn't specific to my network either, it's the same for my partner on his network. I'm assuming that NAT is getting in the way, although I'm not 100% if it's that or if it's a problem opening ports. I have tried with SIP/RTP Passthrough enabled without success. Can anyone provide some guidance here? Thanks, PJ Slauta

2 1

Open separate TCP streams to the same destination
by Sebastian Damm 12 Mar '21

12 Mar '21

Hi, I have a peer that requests separate TCP connections for each registration to their server. Those registrations run through the same Kamailio instance on my side. Now what I tried is to use tcpops and the tcp_set_otcpid function, supplying a previously nonexistant TCP connection ID before relaying the register request. The command itself returns true, however, it does not do anything. The content of $conid of the reply is something totally different. So I guess, this function only works for already existing connections. Is there another way to explicitly tell Kamailio to open up another connection to a peer even though a connection to that peer is already open? Thanks in advance. Regards, Sebastian

3 3

Comparing if header has 0 value in body
by Jurijs Ivolga 11 Mar '21

11 Mar '21

Hi, I'm running Kamailio 5.3.5 I have following header "X-myheader: 0" Nevertheless it seems this is not working for me: if ($hdr(X-myheader)==0) { ..... }; What I'm doing wrong? Jurijs

3 4

Best way to ignore HTTP requests
by Ben Kaufman 11 Mar '21

11 Mar '21

I've set up a server listening on TCP recently, and notice that I'm receiving intermittent, random HTTP requests from the internet. While it would probably be a good idea to enforce a firewall rule to only allow known hosts to communicate, what would be the best way within Kamailio to ignore http requests? Would just checking $rP work? Regards, Ben Kaufman ben.kaufman(a)altigen.com<mailto:ben.kaufman@altigen.com> Director of Cloud Operations AltiGen Communications, Inc.

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 March 2021