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.*
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.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
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
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…
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
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
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
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
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.