I think I had the same issue with 3xx retransmissions and ACK as you are
having....
Not sure it this is the correct way, but I solved this by:
- setting TM parameters :
modparam("tm", "failure_reply_mode", 3)
modparam("tm", "fr_timer", 500)
and adding in the main route:
if (is_method("ACK") ) {
xlog("L_INFO","New SIP message $rm with call-ID $ci \n");
exit;
}
(I don't care about ACK at this point.... once I get an ACK from SBC, the
process should be released)
And I am using http_async_client in stateful transactions. I am now trying
to set a failover to a second URL if the 1st request fails...
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
On Mon, Dec 23, 2024 at 7:02 PM Alexis Fidalgo via sr-users <
[email protected]> wrote:
> For sure ill consider this in the future scenarios (i need to see how it
> deals with the load balancing part that for example K8 offers for having n
> replicas of the evapi server side), but in my case im stuck with http on
> this scenario (cannot change that), now is stateless (blocking) and i would
> like to move it to http_async, i did it, but i get the 3xx retransmission
> and found now way yet on how to absorb the ACK (matching it with the
> transaction to end it)
>
> im on the way, not there yet
>
>
> On 23 Dec 2024, at 2:17 PM, Alex Balashov via sr-users <
> [email protected]> wrote:
>
> The http_async_client event loop is a better performer, for sure. But the
> original controversy was about whether it's better to let slow HTTP
> requests block things or stack up in an async context, and the contention
> was that it doesn't much matter either way and that the difference won't be
> too big. You just can't have a slow HTTP API.
>
> The beauty of EVAPI is that there's no query, no new connection, and no
> event loop beyond normal TCP socket multiplexing.
>
> —
> Sent from mobile, apologies for brevity and errors.
>
> On Dec 23, 2024, at 12:10 PM, Ben Kaufman <[email protected]> wrote:
>
>
> We're agreed on creating a dedicated redirect server for this process, I'm
> not sure I agree on the need to ramp up processes on this, when the
> tradeoff of holding the transaction in shared memory while waiting for an
> http response exists. To be sure, you're trading increased shared memory
> vs increased package memory, but there's frequently other considerations as
> well. In situations like this, I find that I'm doing a database dip, etc.
> in addition to the http request . Adding more workers adds more DB
> connections, unnecessarily increasing memory consumption.
>
> I'd go so far as to say that the older http_client generally shouldn't be
> used. If you have very infrequent http requests to execute and want to use
> it because it's syntactically easier then it might make sense, but beyond
> that it only offers lesser performance.
>
> Honestly, this thread has mostly devolved to two points:
>
>
> 1. Should HTTP requests ever be used: I think we're all agreed that
> they're not ideal. **HOW** not ideal they are and how much we can force
> other things to use an alternate process remain.
> 2. When making http requests, which module should be used. Without
> hesitation I would say to use http_async_query for the performance gain.
>
>
>
> *Kaufman*
>
> *Senior Voice Engineer *
>
>
> E: [email protected]
>
>
>
>
>
> SIP.US Client Support: 800.566.9810 *|* SIPTRUNK Client Support:
> 800.250.6510 *|* Flowroute Client Support: 855.356.9768
> [image: img] <https://www.sip.us/>
> [image: img] <https://www.siptrunk.com/>
> *[image: img] <https://www.flowroute.com/>*
>
>
> ------------------------------
> *From:* Alex Balashov via sr-users <[email protected]>
> *Sent:* Monday, December 23, 2024 10:51 AM
> *To:* Kamailio (SER) - Users Mailing List <[email protected]>
> *Cc:* Alex Balashov <[email protected]>
> *Subject:* [SR-Users] Re: Kamailio not receiving packets on high CPS
>
> CAUTION: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> One additional thought -- sorry for the numerous messages:
>
> This discussion has got a little too academic. When talking about
> concurrency, it's important to ask what the workload actually is and how
> parallelisable it is.
>
> 1) All these async tricks are most useful when you have a busy Kamailio
> server that does lots of different kinds of things. Freeing up worker
> processes becomes an important objective, because not blocking them with
> these requests allows them to handle those requests and those other replies.
>
> 2) The other important consideration is locking: how much are
> shared-memory structures (transaction state, dialog state, htables, etc)
> being accessed by multiple worker processes?
>
> These issues are typical of Kamailio-based multiservice SIP gateways that
> perform functions like call routing, registration, presence, etc. all in
> one system.
>
> Purpose-built redirect servers that query an HTTP API have a trivial and
> one-track workload. They receive an INVITE, it's allocated to a worker, the
> worker goes and bangs on an HTTP server, gets a response, and sends it back
> to the callee. There are no other requests to juggle, save for the
> incidental OPTIONS ping maybe, there are no SIP replies to process and
> relay, and nothing else to do except to absorb ACKs (if the redirects are
> sent statefully). Along the way, vanishingly little is being accessed apart
> from transaction memory (if stateful), and concurrent accesses to that are
> fast because the locks are pretty granular.
>
> Thus, this type of workload doesn't benefit from general-purpose
> throughput optimisations much. The proper approach, using whichever HTTP
> client module, is to spin up as many child processes as can be spun up
> without diminishing returns, and just dedicating them to that singular
> function while studiously avoiding lockable shared data (e.g. htable). This
> keeps all the cars mostly in their own lanes, and the success or failure of
> that per se will dictate throughput.
>
> -- Alex
>
> > On Dec 23, 2024, at 11:25 am, Alex Balashov <[email protected]>
> wrote:
> >
> > PS. A key selling point of this is that if the TCP client crashes or
> becomes unavailable, the transaction just times out after a while, instead
> of any Kamailio worker processes shitting themselves or blocking because
> they're unable to connect to something. There's nothing to connect to.
> >
> > This alone sold me. Once you go EVAPI, you can't go back.
> >
> > -- Alex
> >
> >> On Dec 23, 2024, at 11:23 am, Alex Balashov <[email protected]>
> wrote:
> >>
> >>
> >>> On Dec 23, 2024, at 10:56 am, Ben Kaufman via sr-users <
> [email protected]> wrote:
> >>>
> >>> This came off a bit more harsh than I intended. I think I understand
> the advantage of EVAPI in that it can initiate a command to Kamailio (thus
> Kamailio doesn't need to hold the thread, possibly it doesn't need to store
> the message even), but it would still be nice to have a higher level
> overview of how this would be achieved. Not even example code, but more a
> base architecture explanation / diagram of the flow.
> >>
> >> It's probably not complicated enough to warrant a diagram.
> >>
> >> 1) EVAPI server is initialised:
> >>
> >> loadmodule "evapi"
> >> modparam("evapi", "workers", 3)
> >> modparam("evapi", "bind_addr", "xxx:10399")
> >>
> >> 2) TCP client connects to this socket when it becomes available;
> >>
> >> 2) Kamailio receives request and serialises it (e.g. JSON), embedding
> the transaction ID and label in whatever serialisation structure is used,
> then emits it on the EVAPI bus, e.g.
> >>
> >>
> evapi_async_relay("invite_request:$T(id_index):$T(id_label):$(var(data){s.encode.base64})");
> >>
> >> 3) TCP client reads this package off the wire; the built-in netstring
> support is ideal. It then processes it, generates a response, serialises
> it, and puts it back on the wire. Vitally, the $T(id_index) and
> $T(id_label) are embedded in the response, allowing Kamailio to resume the
> transaction:
> >>
> >> 4) Kamailio receives this message in $evapi(msg), in this event_route,
> and resumes the transaction into route[RESUME]:
> >>
> >> event_route[evapi:message-received] {
> >> ...
> >> jansson_get("tm_trans.tm_index", "$evapi(msg)", "$var(t_index)");
> >> jansson_get("tm_trans.tm_label", "$evapi(msg)", "$var(t_label)");
> >>
> >> t_continue("$var(t_index)", "$var(t_label)", "RESUME");
> >>
> >> ...
> >> }
> >>
> >> 5) In route[RESUME], INVITE processing continues as normal, enlightened
> by anything else that was deserialised out of $evapi(msg).
> >>
> >> EVAPI is my favourite Kamailio module, and the only way I interface
> with outside services, when it's up to me.
> >>
> >> -- Alex
> >>
> >> --
> >> Alex Balashov
> >> Principal Consultant
> >> Evariste Systems LLC
> >> Web:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7C36599b935f8749f6887008dd2372e98b%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638705698656233126%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2yJfCA8sIC37%2FrMQebYxYUK2YftzJ1ZBWkWA%2FSCt1ck%3D&reserved=0
> <https://evaristesys.com/>
> >> Tel: +1-706-510-6800
> >>
> >
> > --
> > Alex Balashov
> > Principal Consultant
> > Evariste Systems LLC
> > Web:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7C36599b935f8749f6887008dd2372e98b%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638705698656254563%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=F39ZiuWvpbPrqWpniUhQmPKFbhLEFFtgQuXHOaHEdl4%3D&reserved=0
> <https://evaristesys.com/>
> > Tel: +1-706-510-6800
> >
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7C36599b935f8749f6887008dd2372e98b%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638705698656272188%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=enmSM1XRjVMIk9j2TT5Gw5Co9Iq63ZN9GLpWHOAsC8g%3D&reserved=0
> <https://evaristesys.com/>
> Tel: +1-706-510-6800
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
[email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
