Am 09.01.20 um 09:52 schrieb Daniel-Constantin Mierla:
> > Hello,
> >
> > Fosdem 2020 is approaching, there will be a talk from Henning about
> > Kamailio, many other friends and related projects are presenting in the
> > RTC Devroom (Giacomo Vacca and Federico Ca
Hi Sergiu, Henning,
I'm seeing the same reported, in both debian 5.2.4 (stock package) and
5.3.2 built from git on ubuntu.
Maybe I'm doing something wrong too, but with 5.3.2 if I reload I see the
expected values in the logs:
*22(21385) INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing():
TLSs:
Hi Ahmed,
there is a lot of material related to integrating Kamailio and Asterisk.
You will get useful help here by describing in detail what you want to
achieve, what constraints you have, and what you have tried already.
Cheers,
Giacomo
On Mon, 20 Apr 2020 at 01:43, ahmed moghazy
wrote:
> Exc
Hi all,
I was looking for a solution to set a dedicated From URI in OPTIONS
requests to a specific dispatcher target.
ds_ping_from (
https://www.kamailio.org/docs/modules/devel/modules/dispatcher.html#dispatcher.p.ds_ping_from)
applies globally, why I needed the granularity of a single target.
Wi
Hi Andrew,
is there a \r\n at the end of the CSeq header?
You may also want to add 'Content-Length: 0'.
Alternatively sipsak is a tool often used for such keepalive requests.
Best regards,
Giacomo
On Fri, 13 Sep 2019 at 08:15, Andrew White wrote:
> Hi all,
>
> As part of a custom monitoring sol
Hi Shahid,
> This system also listens on port 8080 which is meant for websocket
communication [...]
> [...] but Kamailio considering the response is on websocket port 8080
,$Rp value is 8080
Do you see the same behaviour if you set the listen directive for SIP
before the one for WS, in kamailio.c
ould still be curious to know what was the root cause, how the
> previous combination was taking us into strange issues where Kamailio was
> assuming 8080 as Received port. Is it not based on where the OPTION
> response arrived ?
>
> Thanks & Regards,
> Shahid
>
> On T
Hi,
reusing the same connection to the same url is delegated to liburl, so you
can have that when using http_async_client.
More workers will increase the capacity at the price of resources (shared
memory).
I wrote a wrap up about building the request payload here:
https://lists.kamailio.org/piperma
I have updated the http_async_client documentation for master and 5.0.
Please note that in respect to 4.4 http_async_query() now only takes 2
parameters: the payload is passed with $http_req(body).
Giacomo
On 25 April 2017 at 22:09, Giacomo Vacca wrote:
> Hi,
> reusing the same connect
Hi Agalya,
I'm not sure I understand this part: "In the mock server if I send the
response with a delay of 1 sec then, TCP port are opened and closed for
every HTTP transfer.".
Are there other requests while the current connection is waiting for a
response?
Perhaps the best way is to provide a san
Hi Giovanni,
what's the related OS and libcurl versions please?
Regards,
Giacomo
On 2 November 2017 at 09:54, gmele wrote:
> Hello,
>
> I'm having strange behavior with the http_async_client module and https
> connections. Our kamailio config use REST interfaces to send push to mobile
> apps wh
Thanks Giovanni,
the good news is that I'm able to reproduce the issue (same CentOS and
libcurl version, but kamailio 5.1.0-pre0).
I still don't understand the root cause though.
In my case under some light load in about 1 case every 20 I see something
like this logged (debug level 3):
Nov 2 23
OK Giovanni,
this is likely to be an issue with the way CURLOPT_CAPATH is set. I'll
submit a fix as soon as possible.
Giacomo
On 3 November 2017 at 09:49, gmele wrote:
> Hello Giacomo,
>
> currently, I don't see these CURL warnings. Here are the logs I get using
> the verbose mode of Curl.
>
>
Hi Giovanni,
This commit attempts to fix the issue:
https://github.com/kamailio/kamailio/commit/574a11d8c0c20d3d0c058726609df8ed4e5b68dc
Would it be possible to try that branch or patch the module accordingly?
I've tested it on CentOS 7.4.1708 with libcurl 7.56.1-1.0.cf.rhel7 (but I
don't think th
OK Giovanni,
then I'd need some more information to try and get to the root cause, like:
- 5.0.2 git hash you've applied the patch on.
- Rate of requests that seem to trigger this behaviour.
- A sample .cfg file I can use to simulate your scenario (you posted one at
the beginning but please see if
Hi Giovanni,
This is what I've done, on the same CentOS 7.4.1708 (and libcurl
7.56.1-1.0.cf.rhel7) machine referred to in this thread.
- Checked out 071b85f66cabaa3a705a014b26b7c1eb31029b26 from branch 5.0
(which is the last one before Aug 18th).
- Used the latest http_async_client module
- make
Hi Giovanni,
I'm glad it's fixed. The patch was pushed in 5.0 branch after the latest
release (5.0.4, Oct 25th 2017), so it should be available as soon as 5.0.5
will be released (I think soon).
Best Regards,
Giacomo
On 20 November 2017 at 15:12, gmele wrote:
> Hi,
>
> I recompiled the http_asyn
Hi,
I'd like to join you too.
Best Regards,
Giacomo
On 19 January 2018 at 13:15, George Diamantopoulos
wrote:
> Hello,
>
> i would be interested in attending too.
>
> BR,
> George
>
> On 15 January 2018 at 10:28, Daniel-Constantin Mierla
> wrote:
>
>> Hello,
>>
>> in the past 10 years or so, m
18 matches
Mail list logo
