Yes, there is. You're best off building an rtimer+mqueue pipeline (or
streamlined 'async' equivalent) and running your exec() calls in the
asynchronous route. You can then t_continue() the transaction inside there.
> On Jun 18, 2024, at 1:16 PM, Jon Bonilla (Manwe) via sr-users
> wrote:
>
>
RTPEngine will time out a call if it ceases to receive RTP from both endpoints.
You can lower this timeout to something much more stringent, and that will help
shorten the life cycle of ports.
> On May 31, 2024, at 9:49 AM, Ghulam Mustafa via sr-users
> wrote:
>
> I'm wondering how to handle
> On May 31, 2024, at 8:39 AM, Ghulam Mustafa via sr-users
> wrote:
>
> SIP/2.0 607.
Well, that seems clear enough. ;-)
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
__
> On May 31, 2024, at 8:09 AM, Benoît Panizzon via sr-users
> wrote:
>
> This would also solve another problem. We have some CPE with limited
> memory which struggle with a long record-route list.
Indeed, and this is why I recommended it. It would solve a larger class of
problems, above and
Fred,
This is beautiful:
I was not aware it was that simple. Thank you for the education!
-- Alex
> On May 30, 2024, at 6:24 PM, Fred Posner via sr-users
> wrote:
>
>
>> On May 30, 2024, at 5:49 PM, Alex Balashov via sr-users
>> wrote:
>
Benoit,
> On May 30, 2024, at 4:05 PM, Benoît Panizzon wrote:
>
> *sigh* yes I guess you may ask. Somehow I think we do 'normal' VSP
> business, but it looks like we seem to have a complicated set-up.
I think the first part of that sentence, about normal VSP business, is a
powerful intuition,
> On May 30, 2024, at 4:24 PM, tfayomi--- via sr-users
> wrote:
>
> Yes, I have done an sngrep and the Identity header isn't shown at all on any
> incoming requests.
Well, you've answered your own question, as far as the technical side of it
goes.
On the business/policy side: carriers are
> On May 30, 2024, at 3:23 PM, Benoît Panizzon wrote:
>
>
> Unfortunately, life sometimes is not that simple, like when you have to
> find a way to process spiralling calls with rtpengine.
Curious: why is this necessary? Is there a possibility there is an unnecessary
complicating assumption
Have you done a packet capture to try to ascertain whether the Identity header
is objectively present in incoming requests, on the wire?
> On May 30, 2024, at 2:48 PM, tfayomi--- via sr-users
> wrote:
>
> Hi All,
>
> I have a quick question regarding verification on incoming calls regarding
Hello Benoit,
You can use $T_inv(...) to access attributes of the original INVITE
transaction, to which the CANCEL pertains:
https://www.kamailio.org/wikidocs/cookbooks/5.8.x/pseudovariables/#t_invpv
However, you may instead consider the attractive simplicity of just calling
Wow. This is an incredibly bad guide, at least in terms of the Kamailio config it prescribes. Terrible security, no validation, no error handling to speak of...—Sent from mobile, apologies for brevity and errors.On May 29, 2024, at 4:14 PM, Blake Ivey via sr-users wrote:Not sure if something
Indeed, there are quite a few modules that perform this type of dynamic routing
function.
`drouting` is good, but may be overkill. If the destinations being compared are
all fully-qualified phone numbers and not prefixes, `alias_db` may be simplest.
-- Alex
> On May 21, 2024, at 7:22 AM, Ihor
Hi,This and related PVs may assist you in your quest:Pseudo-Variables - Kamailio Wiki Documentationkamailio.org-- Alex—Sent from mobile, apologies for brevity and errors.On May 13, 2024, at 7:42 PM, tfayomi--- via sr-users wrote:Hi All,I'm having trouble understanding/finding resources on how to
I had no idea the Chinese syndicated my article:
https://www.cnblogs.com/shunzh/p/14360712.html
Ah well.
Yeah, just use set_contact_alias() / handle_ruri_alias(). These flags are
unnecessary and a source of much confusion.
> On Apr 29, 2024, at 9:17 AM, Benoit Panizzon wrote:
>
> Hi Alex
>
I wouldn't worry too much about these. They're kind of an anachronism.
> On Apr 29, 2024, at 6:13 AM, Benoit Panizzon via sr-users
> wrote:
>
> Hi Gang
>
> Somehow I don't get my head around NAT Flags and the nathelper module
>
You're going to have to figure out some way to tell Kamailio where the parked
call is, or keep the parked calls on one Asterisk server specially for that
purpose.
> On Apr 25, 2024, at 4:17 PM, Social Boh via sr-users
> wrote:
>
> Hello list,
>
> I'm using Kamailio to balance SIP request
I think Fred's answer is correct, complete and I have no amendments to offer.
:-)
-- Alex
> On Apr 19, 2024, at 8:34 AM, Fred Posner via sr-users
> wrote:
>
>
>> On Apr 19, 2024, at 1:02 PM, Ghulam Mustafa via sr-users
>> wrote:
>>
>>
>> Hello,
>> I'm new to Kamailio and considering its
On Apr 14, 2024, at 12:25 PM, Alex Balashov wrote:
> Medium to large organisations, in particular, tend to extract labour from
> consistent (if unextraordinary) output of everyday do-gooders, and not the
> more stochastic and volatile heroics of open-source superstars.
Sorry, I meant to say
> On Apr 14, 2024, at 12:26 PM, Mahmood Alkhalil
> wrote:
>
> You are right Alex, it is all on premise!
>
> We were offered to move it to cloud, and yes they asked for a lot…
The economics of public cloud providers depend on oversubscribing physical
hardware with lots of small, and mostly
> On Apr 14, 2024, at 12:19 PM, Mahmood Alkhalil
> wrote:
>
> Thank you for the insights Alex!
>
> Now that I give it more attention, the need for employees with the required
> skillset would be challenging to find. And wouldn't like the company to
> suffer incase skilled personals leave.
Excellent analysis, Jawaid.
I would add only that, in my opinion, a lot of the argument for open-source
related to control over one's destiny lies in APIs, connectors and integration
paths.
There are some value-added telephony services which rely heavily on these, so
there is a lot of
> On Apr 14, 2024, at 11:40 AM, Jawaid Bazyar via sr-users
> wrote:
>
> Mahmood, are you paying for that resource in something like AWS? That would
> be big $$$!
Given that he said:
"... DSP devices for PRI lines and media resources for phones which is using
almost an entire rack"
I doubt
Hello,
> On Apr 14, 2024, at 11:09 AM, Mahmood Alkhalil via sr-users
> wrote:
>
> The cost saving that will be the main reason before licenses is the amount of
> hardware resources currently used, the system we are using in total is using
> around 128 GB of RAM, 64 cores of CPU, and total of
Mahmood,
Alas, the business case for open-source telephony solutions is not
self-evident.
Of course, being invested in open-source, we'd all like to think so. But this
is a reflection of our own competencies.
I have seen open-source telephony succeed massively, and deliver improved
> On Apr 9, 2024, at 7:25 PM, David Cunningham via sr-users
> wrote:
>
> Thank you very much for the information. In our Kamailio configuration the
> rtpengine_manage() lines have "SDES-off", so presumably then we are using
> DTLS?
Exactly so. My response was more presumptuous than
Hello,
The encryption mechanism is called DTLS-SRTP, and you might think of it best as
just TLS over UDP. The certificate is dynamically generated by RTPEngine. It is
somewhat simpler than what you might think of as full-blown TLS. The APIs used
for this are indeed OpenSSL.
—
Sent from
for as STIR/SHAKEN with a REST API...)-Will have a try with EVAPI.Sérgio CharruaOn Mon, Apr 8, 2024 at 6:14 PM Alex Balashov via sr-users <sr-users@lists.kamailio.org> wrote:
> On Apr 8, 2024, at 11:12 AM, Sergio Charrua via sr-users <sr-users@lists.kamailio.org> w
> On Apr 8, 2024, at 11:12 AM, Sergio Charrua via sr-users
> wrote:
>
> Also, as this is a stateless script, is there another way of using async http
> or making http requests to a REST API without having to use TM Module?
You can always use an outside service, which communicates with
For immediate release:
HAZARD, Kentucky (1 April 2024)--Evariste Systems LLC, Georgia-based veteran
brokers of international charity partnerships, are pleased to announce the
conclusion of lengthy trilateral negotiations among Taylor Swift, the Public
Investment Fund (the sovereign wealth fund of
gt; On Sat, Mar 23, 2024 at 22:11 Alex Balashov via sr-users
> wrote:
>
> > On Mar 23, 2024, at 9:30 PM, Ovidiu Sas wrote:
> >
> > In the end, we agree with each other and my feeling is that we are
> > repeating the same concept.
>
> Yeah, I think that's
> On Mar 23, 2024, at 9:30 PM, Ovidiu Sas wrote:
>
> In the end, we agree with each other and my feeling is that we are repeating
> the same concept.
Yeah, I think that's mostly right.
> In most of my deployments I don’t need to mess with the udp queue size.
> For high cps traffic, from my
> On Mar 23, 2024, at 7:29 PM, Ovidiu Sas via sr-users
> wrote:
>
> Because you have dropped packets.
> The queue it’s empty most of the time and if is full for a few milliseconds
> and that’s the moment when you experience dropped packets.
Totally fair. Just wondering if that's what we're
> On Mar 23, 2024, at 7:19 PM, Ovidiu Sas wrote:
>
> Things could cascade due to retransmission.
> It all depends on how much the system is loaded and the type of the traffic
> and message handling in kamailio.
> Sometimes the system recovers and works ok for a while until the next burst.
> On Mar 23, 2024, at 6:05 PM, Ovidiu Sas wrote:
>
> if most of the time the udp queue is empty and dropped packets are observed,
> then the size of the udp queue is too small.
But would that happen with a sipp load test, once the threshold of dropped
requests is observed?
--
Alex Balashov
> On Mar 23, 2024, at 5:19 PM, Ovidiu Sas wrote:
>
> But the CPU is not the limiting factor.
We can agree on that, at least. :-)
> Back to the funnel analogy: you have a big bottle and you are using a small
> funnel. That will not work well. If you use a bigger funnel with the same
>
> On Mar 23, 2024, at 5:14 PM, Ovidiu Sas wrote:
>
> But if you are dealing with network jitter and several clients pumping
> traffic at different rates, for a short period of time all the workers will
> be busy while new SIP messages will pile up and the default queue will not be
> able to
funnel. At some point, when you’re pouring a lot of
> liquid, you need to use a wider funnel. Ain’t nothing you do after the funnel
> will matter. The funnel is the problem.
>
> -- Fred Posner
> Sent from mobile
> Phone: +1 (352) 664-3733
> qxork.com
>
>
>
&
ner wrote:
>
> The default queue I believe is about 2MB. Not very hard to exceed that queue
> while still having a good amount of CPU/processor available.
>
> -- Fred Posner
> Sent from mobile
> Phone: +1 (352) 664-3733
> qxork.com
>
>
>
>> On Mar 23, 202
> On Mar 22, 2024, at 10:21 PM, Ovidiu Sas wrote:
>
> The default udp queue length is not enough for high cps.
That's interesting. I'm not necessarily saying you're wrong, but I'd be curious
to know more about what informs this theory.
--
Alex Balashov
Principal Consultant
Evariste Systems
into a fundamental throughput limit of your
environment, and if you have, I would not take the advice to increase receive
queue depth.
-- Alex
> On Mar 22, 2024, at 4:03 PM, Ilie Soltanici wrote:
>
> Totally agree with Alex here.
>
> On Fri 22 Mar 2024, 19:24 Alex Balash
I don't know that I would do that. If your server isn't coping with the load,
making the kernel receive queue deeper doesn't increase throughput, it just
relocates the queueing -- or rather, adds another layer of queueing.
Squeeze the balloon in one place, it inflates in another.
-- Alex
>
I'm really not sure what to tell you, Vishal. The documentation isn't entirely
clear for all use-cases, but it literally lays out exactly how to do this. You
just have to read it.
https://kamailio.org/docs/modules/5.8.x/modules/rtpengine.html
> On Mar 22, 2024, at 2:16 PM, Vishal Pai via
You can obtain the destination set IP from $dd, or $(du{uri.host}). However,
you can't just modify the To URI like that.
You will need to do it in a way that doesn't break standards-based
proscriptions about what a proxy can do, otherwise endpoint A can look at the
modified header received in
Indeed, it has become a bit of a cliché that msg_apply_changes() should be
called after append_hf(), uac_replace_from(), etc.
This should be dispelled. In the vast majority of use-cases, it is not only
unnecessary, but highly undesirable.
-- Alex
> On 11 Mar 2024, at 06:45, Henning Westerholt
if(proto == TCP)
$ru = $(ru{s.replace,transport=TCP,}{s.replace,transport=tcp,});
...
t_relay();
-- Alex
> On 7 Mar 2024, at 10:46, Alberto Diez via sr-users
> wrote:
>
> Hi kamailio community,
>
> I have an issue with a Kamailio 5.7. It's listening both in TCP and UDP. In
> my
If you just strip the incoming ;transport=tcp attribute, I think all should be
well when t_relay() consumes the modified RURI.
> On 7 Mar 2024, at 12:48, Alberto Diez via sr-users
> wrote:
>
> Hi Sergiu,
> yes I am pretty sure something is going wrong.
> I do have kamailio listening udp
> On 7 Mar 2024, at 06:25, Marrold via sr-users
> wrote:
>
> After digging through old mailing posts I've been able to resolve this by
> applying the changes in the BRANCH route. This fixes the corruption, although
> the logs still show a warning for applying it twice.
This is the way. :-)
The RFCs are correct; strictly speaking, a proxy should not alter the
encapsulated message body, or most other SIP message attributes.
Kamailio is a huge toolbox with many capabilities, not unlike a programming
language. It gives one the power to do a great many things.
Some of these things
No, that's pretty much how it's done.
> On 4 Mar 2024, at 08:24, Valentin Christoph via sr-users
> wrote:
>
> Dear all,
>
> Is there any other possibility to (automatically) check the
> plausibility/syntax of an existing kamailio.cfg, besides
>
> kamailio -c -f kamailio.cfg
>
> ?
>
>
> On 27 Feb 2024, at 18:34, Ovidiu Sas wrote:
>
> That’s a huge marginal gain!
> Most of the time is 0.01% or less. :-)
>
> High availability is for hardware failures, not for software failures. If
> there’s an issue in one node in the cluster and that node goes down, the next
> node in the
> On 27 Feb 2024, at 18:50, Richard Edmands wrote:
>
> Then to find out in those 0.1% that Corosync replicates the issue to the node
> it replaces in 60% of the cases where you would have utilised it.
And the other 40% are outages caused by some bug or malfunction in the fancy HA
gewgaws --
Maybe. It's another one of those things where you might spend 99% of your
effort for that 0.1% marginal gain...
> On 27 Feb 2024, at 14:58, Social Boh via sr-users
> wrote:
>
> Better use corosync and pacemaker to keeep call audio flow during moving
> virtual IP using master-slave redis
>
That would require transaction replication, which Kamailio doesn't have.
Most messages can be processed statelessly, so this isn't a huge obstacle.
However, CANCELs won't work.
> On 27 Feb 2024, at 06:49, Sergio Charrua via sr-users
> wrote:
>
> Hi all!
>
> I am having some
Sadly, there is no way to make Kamailio inject compact headers. That's up to
the UAs.
Well, if your hands really are that tied, then maybe topos is worth exploring
after all. However, I would carefully weigh the complexity and failure modes
and overall supportability issues against short-term
There are lots of strategies for reducing message size, although the
RFC-recommended (better said, mandated :-) approach is just to switch to TCP
whenever your message sizes come within 200 bytes of the MTU, if I'm not
mistaken.
Otherwise:
1) Turn on compact (abbreviated) SIP headers;
2)
Not really a great answer for you, but I think you should reconsider using
`topos` to reduce SIP message size.
`topos` is complex and I'm not sure the added complexity pays off in this case,
from a purely thermodynamic point of view.
> On 26 Feb 2024, at 06:11, Benoit Panizzon via sr-users
>
Hi Jayapal,
"Integration" is a vague concept. It's important to have some understanding of
where Kamailio fits in in relation to FreeSWITCH, and what sort of
functionality is provided by each.
Broadly speaking, absent any other clarity, FreeSWITCH is a PBX and voice
application server, while
Hi Benoit,
> On 30 Jan 2024, at 08:28, Benoit Panizzon wrote:
>
> Hi Alex
>
>> As is often the case, there is a useful opportunity here to step back,
>> switch to decaf, and ask why you want to call 'exit' from a branch_route in
>> the first place.
>
> :-)
>
> Actually I intended to call
As is often the case, there is a useful opportunity here to step back, switch
to decaf, and ask why you want to call 'exit' from a branch_route in the first
place.
> On 30 Jan 2024, at 06:49, Benoit Panizzon via sr-users
> wrote:
>
> Hi
>
> I was wondering what exactly happens with
Hi,
I don't think what you are wanting to do here is possible with a SIP proxy. :-)
—
Sent from mobile, apologies for brevity and errors.
> On Jan 29, 2024, at 1:08 AM, mm e via sr-users
> wrote:
>
> When receiving to-tag and returning 180 ring without SDP body, how can it be
> converted
OK (and state 5 for BYE) if same kamailio that received the INVITE, also
> receives 200 OK (and BYE).
>
> ---
> Stefan
> From: Alex Balashov via sr-users
> Sent: Friday, January 26, 2024 2:11:29 PM
> To: Kamailio (SER) - Users Mailing List
> Cc: Alex Balashov
> Subj
I'm not sure of the internals, and am just speculating here, but I suspect that
dialog replication through DMQ is about synchronising profile membership/counts
only, and will not deliver the entire dialog state machine life cycle to all
cluster members.
To fully deserialise the dialog state
> On 25 Jan 2024, at 06:34, Benoit Panizzon via sr-users
> wrote:
>
> Hi List
>
> Via sql_xquery I get a stacked xavp aka array.
>
> I would like to store that stacked xavp into a hash table for later usage in
> other transactions. Is this
> possible?
You can always iterate through the
> On 25 Jan 2024, at 03:35, Unai Rodriguez via sr-users
> wrote:
>
> I tried this (and some variations) to no avail:
>
> request_route {
> insert_hf("Contact: $fu\r\n");
> ...
> ...
>
> I see the Contact header inserted but after receiving the first SIP INVITE
> (ie too late). Is
Hi,
A complication of your request is that SDP can contain an arbitrary number of
media sections for different streams. That's not needless pedantry, but rather
to say that this makes it hard to create a straightforward, scalar
pseudovariable around a concept like "the media IP". Besides that,
Hi,
Contact is mandatory in INVITEs. Per RFC 3261 § 8.1.1.8 ("Contact"):
The Contact header field MUST be present and contain exactly one SIP
or SIPS URI in any request that can result in the establishment of a
dialog. For the methods defined in this specification, that includes
These are all valid approaches, depending on preference. Catching 302s and
extracting exactly the desired info might be easier with Kamailio, so I
suppose, ceteris paribus, I'd recommend the first one.
Dispatcher is a great approach!
> On 23 Jan 2024, at 00:01, Anthony Wittig via sr-users
>
;, "Calling sl_send_reply then exit\n");
>sl_send_reply("302", "Moved Temporarily");
> exit;
> }
> }
>
>
> But I still have this WARNING message logged by Kamailio when handling a SIP
> INVITE:
>
>
sl_send_reply("302", "Moved Temporarily");
>exit;
>}
> }
>
>
> But I still have this WARNING message logged by Kamailio when handling a SIP
> INVITE:
>
>WARNING: [core/dset.c:690]: print_dset(): no r-uri or branches
>
>
ot;);
>
> This works, but then I get WARNING messages in the logs:
> WARNING: [core/dset.c:690]: print_dset(): no r-uri or branches
>
> Which is also why I was confused...
> You're telling me I should not create branches... but if I don't, I get these
> messages.
>
I used base64 encoding transformations to deal with these kinds of problems.
—
Sent from mobile, apologies for brevity and errors.
> On Jan 12, 2024, at 6:11 AM, Benoît Panizzon via sr-users
> wrote:
>
> Hi Daniel
>
>> comma is not allowed in an unquoted value for SIP parameters because
>>
Hi James,
This all happens on the tick of the 'timer_interval'.
As the point of the timer interval is to batch these sync/expiration
operations, it would defeat the aims of the concept if contacts' expiration
were continuously polled for in real time by other means.
-- Alex
> On 11 Jan
Hi,
First off, a bit confused as to why you are appending a branch and then sending
a final reply? Adding a branch only makes sense if you plan to fork the request
to an additional destination, instead of responding to the sender with a final
dispositive (>= 3xx) reply.
-- Alex
> On 11 Jan
Hi Gavin,
This error is generated internally when trying to relay the message. A useful
troubleshooting step would be to add a line that prints the Request URI to
console before this happens, but subsequent to the registration lookup (if
you're using a registrar, and I presume you are):
:-) Why not just have frequent re-registration intervals?
> On 11 Dec 2023, at 13:33, Benoit Panizzon wrote:
>
> Hi Alex
>
>> Perhaps it is helpful to ask a more basic question: why are you using
>> server-side keepalives?
>
> Because of a *stupid* cloud hosted PBX vendor solution.
>
> That
Perhaps it is helpful to ask a more basic question: why are you using
server-side keepalives?
> On 11 Dec 2023, at 12:56, Benoit Panizzon via sr-users
> wrote:
>
> Hi
>
> We have reached 2 registered CPE and start facing issues.
>
> Am I observing correctly that when ka_mode 4 is
Hello,
Ports are allocated dynamically. Even ports are for RTP, odd ports are for
RTCP. There is no standard that I am aware of, but common practice is for the
lower bound to be UDP 8000. The upper bound varies, but can be as high as the
logical maximum of 65535.
-- Alex
> On 8 Dec 2023, at
t]): add to the transaction
> specified by tindex and tlabel a new branch for
> Maybe names are a bit long but is to give the idea.
> Do you think that a solution like this would cover your (and others')
> scenarios?
> I can try to find the time to work on it :)
>
> Che
Hi,
It is important to know that the scope of $var(...) is per-process[1], and
timer functions run in a different process.
When REFRESH_CALLSTATE_TIMER runs, it is not in response to any particular SIP
message or call, and it does not know the context of any particular SIP message
or call.
Hi Ilie,
Glad it worked out for you, and thank you for forcing me to take a second look
at the mechanics of this for myself. You could say we both learned something.
:-) Likewise thank you to Daniel for the clarity.
-- Alex
> On 29 Nov 2023, at 11:08, Ilie Soltanici wrote:
>
> Hi Alex,
>
>
Hi Ilie,
I think the confusion is about behaviour rather than transaction reality. A
transaction suspended by evapi_async_relay() does not generate any productive
replies back to the UAC, it's true.
But it does go away, as Daniel says. Setting an example `fr_timer` value of 4
sec:
Hi,
I use evapi_async_relay() very extensively, and can say that the transaction
does time out if it goes unreplied, and relatively quickly. I haven't checked
exactly which timer guides this, but it doesn't remain suspended indefinitely.
I don't think that's a concern.
-- Alex
> On 29 Nov
PS. It seems to me there are some kludgy options to work around this
limitation, i.e. to basically reinvent tsilo.
They all boil down to suspending the transaction and using some sort of IPC
mechanism to queue new branch destinations, then, after some defined interval,
using some dequeueing
Hi,
I wanted to revisit the topic of tsilo dependence on the location service. All
three ts_append*() functions have the following quality:
- ts_append(): "performing a contact lookup on the table specified by the
domain parameter."
- ts_append_by_contact(): "the contact lookup is performed"
-
If you're having to think about how to do things that break basic SIP
semantics, it may be time to rethink your design.
More particularly, passing requests from A to B back to A, when A and B are
both proxies, is problematic. It will lead to potential call loops if the
request should find
Hi,You may wish to explore this function, and its RPC correlate:dialog Modulekamailio.org-- Alex—Sent from mobile, apologies for brevity and errors.On Nov 22, 2023, at 7:17 PM, Social Boh via sr-users wrote:Hello,I'd like to know if there is a way, from Kamailio side, take the refer-to header
our Kamailio configuration uses rtpengine_manage(), which
>> > according to the documentation is not compatible with set_rtpengine_set().
>> > I'll try it without the 11.x server and the large weights, and see if the
>> > calls are evenly distributed between the 22.x and 3
with set_rtpengine_set(). I'll try it
> without the 11.x server and the large weights, and see if the calls are
> evenly distributed between the 22.x and 33.x servers then.
>
> Thanks again.
>
>
> On Thu, 9 Nov 2023 at 10:25, Alex Balashov via sr-users
> wrote:
> Hi,
Hi,
>From the docs:
"The balancing inside a set is done automatically by the module based on the
weight of each RTPEngine from the set. The default weight is 1, if another
RTPEngine should be used twice as often as the first one, one would specify the
weight 2 for this server, for example."
e_path 1 and path_mode 1.
>
> Path mode 2 does not seem appropriate.
>
> What other path related parameters did you have in mind?
>
>
>
>
> On 10/27/23, 11:37 AM, "Alex Balashov via sr-users"
> mailto:sr-users@lists.kamailio.org>> wrote:
>
>
In thinking through it a bit more, I think I understand better now. You want to
interrogate -- that is, to query -- the location service via redirect rather
than by sending a request directly to it, and you want the returned coordinates
for the AOR being interrogated to incorporate the path hop
Yes, the remove_hf() et al. functions are designed to operate on requests. Only
a small subset of textops-family manipulation functions operate on replies, and
they should be explicitly labelled or named in a way that reflects that.
I can't say I understand the scenario you've outlined, either,
PS. Kamailio gives you lots of low-level building blocks that can be used to
stitch together a custom location service, if you want to rewrite
usrloc/registrar. There are quite a few ways to replicate data out of Kamailio
at little to no cost to an external consumer.
But if you want to use the
> On 20 Oct 2023, at 11:34, Jawaid Bazyar wrote:
>
> Would a DMQ cluster with RAM-based store and a relatively small number of
> nodes (say, 5 for example) be able to handle a location table measured in the
> scale of 1 million nodes?
A million rows isn't really that much in contemporary
> On 20 Oct 2023, at 09:17, Jawaid Bazyar wrote:
>
> Hi Alex,
>
> Well I guess the other effects if any are unclear.
>
> As to what I want..
>
> The goal is to ensure that all the nodes in a large-scale
> geographically-distributed system have routing information to locate the
> dynamic
If what you want is what you really want, db_mode 3 is the only way to achieve
it. What other effects of mode 3 are you concerned about?
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
Would join Kaufman here to say that free-range STIR/SHAKEN implementations in
the US are limited by the small number of certified authentication providers,
but presumably the EU version will to some extent avoid US-style Guilded Age
corporate welfare...
-- Alex
> On 19 Oct 2023, at 09:33, Ben
Hi Ali,
> On 14 Oct 2023, at 10:11, Ali Taher wrote:
>
> That means that kamailio should forward the 183 session progress received
> from UAS as it to the UAC, which in their turn must send PRACK and kamailio
> forwards it back to UAS?
Yes, that's right.
-- Alex
--
Alex Balashov
Principal
PRACKs are up to the UAs to send.
> On 13 Oct 2023, at 08:30, Ali Taher via sr-users
> wrote:
>
> Hello,
> Is there a way to send PRACK as reply to a 183 Session Progress (with
> Require: 100rel) sent to Kamailio sip proxy?
> Regards,
>
he example puts me on the right track. It tells me that what
> I need to do is bounce the reply off to the other nodes(s) if TM doesn't
> recognize it. Having a DMQ option for the TM module would be great though.
>
> Cheers,
>
> Michel Pelletier
>
>
> On Tue, Oct 10, 2023 at
1 - 100 of 115 matches
Mail list logo
