Hi David,
No, actually i removed my own domain details from the logs, sorry about not
mentioning that ;-)
On Mon, Mar 30, 2020 at 10:09 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:
> Are there really 2 dots in .com?
>
> 'wss://kamailio..com:7443/' failed:
>
> On Mon, 30 Mar 2020
Hello,
Quoting from the bug report, where Daniel already replied:
"It looks like you are using topoh module, which has the purpose of changing
the headers that contain ip addresses. Remove it from your config."
Have you tried already to deactivate this module in your cfg?
Cheers,
so I changed it to
t_uac_send("NOTIFY", "$(ct{s.substr,1,0}{s.striptail,1})", "$su",
"udp:192.168.1.156:5060","Call-ID: $hdr(Call-ID)\r\nSubscription-State:
terminated;reason=timeout\r\nEvent: $hdr(Event)\r\nContent-Type:
application/url\r\nFrom: $fU\r\nTo: $hdr(From)",
Hi,
I am facing the below error in my P-CSCF module as i am running P-CSCF, I-CSCF,
S-CSCF, HSS in separate VMs.
0(3512) INFO: [core/udp_server.c:206]: probe_max_receive_buffer():
SO_RCVBUF is finally 425984
0(3512) ERROR:
Are there really 2 dots in .com?
'wss://kamailio..com:7443/' failed:
On Mon, 30 Mar 2020 at 17:57, Bilal Abbasi wrote:
> I am using lets encrypt for my certs and i validated them as right via
> https://www.sslshopper.com/ssl-checker.html
>
> Regards
> Abbasi
>
> On Mon, Mar 30, 2020 at 5:34 PM
Hello,
On 30.03.20 18:41, Jan-Hendrik Dörner wrote:
> Hello Daniel,
>
> thank you for your reply.
>
> I changed the line mentioned to
> t_uac_send("NOTIFY", "$(ct{s.substr,1,0}{s.striptail,1})", "$su",
> "192.168.1.156","Call-ID: $hdr(Call-ID)\r\nSubscription-State:
>
I am using lets encrypt for my certs and i validated them as right via
https://www.sslshopper.com/ssl-checker.html
Regards
Abbasi
On Mon, Mar 30, 2020 at 5:34 PM Mack Hendricks wrote:
> Are you using a self-signed cert? If so, make sure your browser excepts
> the cert by going to
Hello Daniel,
thank you for your reply.
I changed the line mentioned to
t_uac_send("NOTIFY", "$(ct{s.substr,1,0}{s.striptail,1})", "$su",
"192.168.1.156","Call-ID: $hdr(Call-ID)\r\nSubscription-State:
terminated;reason=timeout\r\nEvent: $hdr(Event)\r\nContent-Type:
application/url\r\nFrom:
Hello,
On 30.03.20 12:07, Jan-Hendrik Dörner wrote:
> Hallo,
>
> several telephones send a SIP-multicast SUBSCRIBE message to address
> 224.0.1.75 if they have no settings-URL configured and receive none over DHCP.
>
> So I configure my kamailio server, to respond to that multicast-request.
>
Are you using a self-signed cert? If so, make sure your browser excepts the
cert by going to http://yourserver:7443 and then login using tryjssip.net
-Mack
> On Mar 30, 2020, at 8:21 AM, Bilal Abbasi wrote:
>
> Hi Users,
> I am new to kamailio, and trying to implement webrtc on kamailio, i
Hi Users,
I am new to kamailio, and trying to implement webrtc on kamailio, i am
getting following error when i try to login from tryjssip page.
Mar 29 21:11:15 kamailio kamailio[20570]: ERROR:
[core/tcp_read.c:1535]: tcp_read_req(): bad request, state=7, error=4
buf:#012GET /
Daniel-Constantin Mierla writes:
> These commits were pushed to branch 5.3 already.
Yes, I noticed, thanks, Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On 30.03.20 12:24, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> I pushed two commits on master and branch 5.3 to skip reusing tcp
>> connection id. See if it solves your case.
> I tried with master and now setting of $du in branch route worked OK.
OK, thanks for testing and the
On 30.03.20 12:16, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>>> Mar 29 10:19:28 char /usr/bin/sip-proxy[26162]: INFO: * du =
>>> sip:127.0.0.1:5090;transport=tcp
>> Does this happen after a usrloc location lookup? Trying to figure out
>> what destination-related
Daniel-Constantin Mierla writes:
> I pushed two commits on master and branch 5.3 to skip reusing tcp
> connection id. See if it solves your case.
I tried with master and now setting of $du in branch route worked OK.
-- Juha
___
Kamailio (SER) - Users
Daniel-Constantin Mierla writes:
> > Mar 29 10:19:28 char /usr/bin/sip-proxy[26162]: INFO: * du =
> > sip:127.0.0.1:5090;transport=tcp
>
> Does this happen after a usrloc location lookup? Trying to figure out
> what destination-related processing is done before to see what fields
> were
Hallo,
several telephones send a SIP-multicast SUBSCRIBE message to address 224.0.1.75
if they have no settings-URL configured and receive none over DHCP.
So I configure my kamailio server, to respond to that multicast-request.
But: Although mine is working, I do feel it could be improved,
On 30.03.20 09:24, Daniel-Constantin Mierla wrote:
> On 30.03.20 07:09, Juha Heinanen wrote:
>> Daniel-Constantin Mierla writes:
>>
>>> Have you tested with tcp/tls or with udp? There was a group of commits
>>> trying to propagate the tcp connection id as much as possible to speed
>>> up
Description
I'm running Kamailio 5.2.0, whenever I relay an invite via Kamailio, my
original contact header is changed from the original:
sip:+xx...@yyy.yyy.yyy.:5060;transport=udp;gw=netvision
To
Hi Daniel,
The above solution you suggested works for me.
However, I am observing a behavior after we have started fetching the
Session-Expires Header Value from the initial INVITE.
1. If the 200 OK(to the initial INVITE) from the UAS contains a lesser
value of Session-Expires, than the one
Description
I'm running Kamailio 5.2.0, whenever I relay an invite via Kamailio, my
original contact header is changed from the original:
sip:+xx...@yyy.yyy.yyy.:5060;transport=udp;gw=netvision
To
On 30.03.20 07:09, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> Have you tested with tcp/tls or with udp? There was a group of commits
>> trying to propagate the tcp connection id as much as possible to speed
>> up connection search, maybe that needs to be reset -- I can look into
22 matches
Mail list logo
