Re: [SR-Users] Encode host ip in Contact header for semi-stateless setup

[César Pinto]

Just a tip for old times.
I had problems with a broken provider and I had to put this snipt of code in my 
script:

xlog ("$shv(log_debug)"," [$ci] Fixing Contact header to 
.\n");
remove_hf("Contact");
append_hf("Contact: \r\n");

It worked very well for me. The only problem is that you should forge all the 
Contact from zero.

I hope this can help you.

César Pinto
Voice Service Administrator
t: +34 91 787 23 00
alhambra-eidos.com


-Mensaje original-
De: sr-users [mailto:sr-users-boun...@lists.kamailio.org] En nombre de Daniel 
Tryba
Enviado el: martes, 26 de noviembre de 2019 17:40
Para: Kamailio (SER) - Users Mailing List 
Asunto: Re: [SR-Users] Encode host ip in Contact header for semi-stateless setup

On Tue, Nov 26, 2019 at 10:57:57AM -0500, Daniel Greenwald wrote:
> Yes I've played with topoh but I need more than hiding, I need to 
> store data (freeswitch's ip) in the contact header.

That can be done with set_contact_alias / handle_ruri_alias from the nathelper 
module. But I guess you are aware of those, so maybe I just don't understand 
what you are trying to accomplish and what parts you have control over.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] No Audio using RTP Proxy

[Sujit Roy]

Hello

I am facing a problem as below. Please suggest for the work around.

My call flow is like this.

SIP Gateway-1 (IP x.179) -> SIP Gateway-2 ( IP x.177) -> Kamalio+RTPProxy

So when the call arrives at Kamalio+RTPProxy, i m getting below in log.

Nov 26 23:25:31 rtpproxy[18508]: INFO:GLOBAL:rtpp_command_ul_handle: new
IPv4/IPv4 session 1b7c870763616c6c15fff410@ 192.168.100.177, tag
1aa18fc201a68168;1 requested, type strong
Nov 26 23:25:31 rtpproxy[18508]: INFO:1b7c870763616c6c15fff410@
192.168.100.177:rtpp_command_ul_handle: new session on IPv4 port 15920
created, tag 1aa18fc201a68168;1
Nov 26 23:25:31 rtpproxy[18508]:
INFO:1b7c870763616c6c15fff410@192.168.100.177:rtpp_stream_prefill_addr:
pre-filling caller's RTP address with 192.168.100.177:27360
Nov 26 23:25:31 rtpproxy[18508]: INFO:1b7c870763616c6c15fff410@
192.168.100.177:rtpp_stream_prefill_addr: pre-filling caller's RTCP address
with 192.168.100.177:27361

But x.177 is working on signalling mode only ( Not routing Media ) . As a
result, i m not getting any voice from IP x.179

What can be done to change the caller's RTP address to x.179 in RTPProxy ?

Thanks

-- 
Regards
===
Sujit Roy
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Possible conflict between t_newtran and setflag for ACC

[Patrick Wakano]

Hello list,
Hope you all doing well!

I am using the ACC module and using the setflag() function as done in
several examples. It works fine. However, I've added the t_newtran()
function almost in the begging of the INVITE handler to help the
retransmission detection and after that I noticed the ACC was not saving
anything in DB.
So after debugging I discovered that if I call the t_newtran() before
setting the ACC flags, the module will not save the calls in DB, but if I
call it after setting the ACC flags, it works
So my question is, is this a bug or it is a expected side effect so when
one is using t_newtran you must be careful and set all your transaction
flags before? (ACC are the only transaction flags I am using so can't tell
if other modules have the same problem)
This is happening in Kamailio 5.2.2.

Thank you!
Kind regards,
Patrick Wakano
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

[Sergiu Pojoga]

Daniel's recommendation must have raised quite a few eyebrows.
I'd also like to know more about the logic behind this. It's not what the
'book' says.

Thanks,

On Tue, Nov 26, 2019, 7:04 PM Alex Balashov, 
wrote:

> Is the idea behind doing this to provide extra safety in case the TM
> callbacks that feed into dialog life-cycle tracking do not work? Are
> there remaining known cases of this, given how long the dialog module
> has been around?
>
> On Tue, Nov 26, 2019 at 03:33:19PM +0100, Daniel-Constantin Mierla wrote:
>
> > Hello,
> >
> > the recommended way is to call dlg_manage() for all requests belonging
> > to the dialog. There can be a record-routing callback executed for
> > requests within dialog for the same purpise, but it has some constraints
> > related to the presence of an unaltered parameter, as well as it was
> > designed with the use of setting a flag for tracking the dialogs. Even
> > the r-r callback is executed, doing the dlg_manage() for all requests is
> > still safe.
> >
> > Cheers,
> > Daniel
> >
> > On 26.11.19 15:25, George Diamantopoulos wrote:
> > > Thank you both for your input. I guess I'll continue calling
> > > dlg_manage() for in-dialog requests for now until I gather more
> > > feedback, since we do cater for a large set of endpoints and several
> > > have at times exhibited various offending behaviours.
> > >
> > > ___
> > > Kamailio (SER) - Users Mailing List
> > > sr-users@lists.kamailio.org
> > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> > --
> > Daniel-Constantin Mierla -- www.asipto.com
> > www.twitter.com/miconda -- www.linkedin.com/in/miconda
> > Kamailio World Conference - April 27-29, 2020, in Berlin --
> www.kamailioworld.com
> >
>
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

[Alex Balashov]

Is the idea behind doing this to provide extra safety in case the TM
callbacks that feed into dialog life-cycle tracking do not work? Are
there remaining known cases of this, given how long the dialog module
has been around?

On Tue, Nov 26, 2019 at 03:33:19PM +0100, Daniel-Constantin Mierla wrote:

> Hello,
> 
> the recommended way is to call dlg_manage() for all requests belonging
> to the dialog. There can be a record-routing callback executed for
> requests within dialog for the same purpise, but it has some constraints
> related to the presence of an unaltered parameter, as well as it was
> designed with the use of setting a flag for tracking the dialogs. Even
> the r-r callback is executed, doing the dlg_manage() for all requests is
> still safe.
> 
> Cheers,
> Daniel
> 
> On 26.11.19 15:25, George Diamantopoulos wrote:
> > Thank you both for your input. I guess I'll continue calling
> > dlg_manage() for in-dialog requests for now until I gather more
> > feedback, since we do cater for a large set of endpoints and several
> > have at times exhibited various offending behaviours.
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - April 27-29, 2020, in Berlin -- 
> www.kamailioworld.com
> 

> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Encode host ip in Contact header for semi-stateless setup

[Daniel Tryba]

On Tue, Nov 26, 2019 at 10:57:57AM -0500, Daniel Greenwald wrote:
> Yes I've played with topoh but I need more than hiding, I need to store
> data (freeswitch's ip) in the contact header.

That can be done with set_contact_alias / handle_ruri_alias from the
nathelper module. But I guess you are aware of those, so maybe I just
don't understand what you are trying to accomplish and what parts you
have control over.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Modify SIP Message Header and Message Body parameter

[Sergiu Pojoga]

1. UA
- https://www.kamailio.org/wiki/cookbooks/5.3.x/core#server_header
- https://www.kamailio.org/wiki/cookbooks/5.3.x/core#user_agent_header

2. Topo hiding and others
https://kamailio.org/docs/modules/5.3.x/modules/topoh.html
https://kamailio.org/docs/modules/5.3.x/modules/topos.html
https://kamailio.org/docs/modules/5.3.x/modules/nathelper.html#nathelper.p.nortpproxy_str

On Tue, Nov 26, 2019 at 10:41 AM Sujit Roy  wrote:

> Hello
>
> Please see below SIP Message
>
> SIP/2.0 100 trying -- your call is important to us
> Via: SIP/2.0/UDP
> 192.1681.101:5060;branch=z9hG4bK5a61798d7c850d39;rport=5060
> From: ;tag=51a0dc1e620de16d
> To: 
> Call-ID: 6fd9b9d563616c6c15f2d7fa@ 192.1681.101
> CSeq: 21701 INVITE
> *Server: kamailio (5.1.9 (x86_64/linux))*
> Content-Length: 0
>
> *1.  I want to Change the Server Parameter . How to do it ? *
>
>
> SIP/2.0 183 Session Progress
> Via: SIP/2.0/UDP
> 192.1681.101:5060;rport=5060;branch=z9hG4bK5a61798d7c850d39
> Record-Route: 
> From: ;tag=51a0dc1e620de16d
> To: ;tag=as728725b3
> Call-ID: 6fd9b9d563616c6c15f2d7fa@ 192.1681.101
> CSeq: 21701 INVITE
> Server: VOS3000 V2.1.4.0
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 600;refresher=uas
> *Contact:  >*
> Content-Type: application/sdp
> Require: timer
> Content-Length: 289
> v=0
> o=root 912643161 912643161 IN IP4 192.1681.104
> s=VOS3000 V2.1.4.0
> c=IN IP4 192.1681.104
> t=0 0
> m=audio 10784 RTP/AVP 18 101
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:230
> a=sendrecv
> *a=nortpproxy:yes*
>
> 2. I Want to hide the Contact Parameter and a= nortpproxy:yes ==> How to
> do it as well ?
>
> Thanks in advance.
>
> --
> Regards
> ===
> Sujit Roy
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Encode host ip in Contact header for semi-stateless setup

[Daniel Greenwald]

Yes I've played with topoh but I need more than hiding, I need to store
data (freeswitch's ip) in the contact header.

On Tue, Nov 26, 2019 at 5:01 AM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> I do not remember exactly what was that presentation about, but maybe
> topoh module is something that can help you if you need the contact to be
> hidden.
>
> Cheers,
> Daniel
> On 26.11.19 05:42, Daniel Greenwald wrote:
>
> At kamailio world 2017, Jan Lorenz of Pascom explained how they use
> kamailio in a semi-stateless manner and encode the asterisk's IP into the
> contact header on the way out so that it can be decoded and used to route
> properly on the way back without Record-Routing. I would like to create
> such a setup.
>
> I'm looking for pointers if there is a particular module/method that would
> be ideal to to use for this. Any other gotcha's to consider in such a
> setup. My plan is to keep the transaction on the same kamailio by not
> altering the VIA but allow the subsequent in-dialog transactions to
> potentially hit another kamailio by changing the contact to a shared SRV
> record (and encoding the freeswitch box's IP into it for later retrieval.)
>
> Thanks in advance.
>
> Daniel Greenwald
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Kamailio World Conference - April 27-29, 2020, in Berlin -- 
> www.kamailioworld.com
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Modify SIP Message Header and Message Body parameter

[Sujit Roy]

Hello

Please see below SIP Message

SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 192.1681.101:5060;branch=z9hG4bK5a61798d7c850d39;rport=5060
From: ;tag=51a0dc1e620de16d
To: 
Call-ID: 6fd9b9d563616c6c15f2d7fa@ 192.1681.101
CSeq: 21701 INVITE
*Server: kamailio (5.1.9 (x86_64/linux))*
Content-Length: 0

*1.  I want to Change the Server Parameter . How to do it ? *


SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.1681.101:5060;rport=5060;branch=z9hG4bK5a61798d7c850d39
Record-Route: 
From: ;tag=51a0dc1e620de16d
To: ;tag=as728725b3
Call-ID: 6fd9b9d563616c6c15f2d7fa@ 192.1681.101
CSeq: 21701 INVITE
Server: VOS3000 V2.1.4.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 600;refresher=uas
*Contact: http://sip:1018801751481417@104.216.39.66:5060>>*
Content-Type: application/sdp
Require: timer
Content-Length: 289
v=0
o=root 912643161 912643161 IN IP4 192.1681.104
s=VOS3000 V2.1.4.0
c=IN IP4 192.1681.104
t=0 0
m=audio 10784 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:230
a=sendrecv
*a=nortpproxy:yes*

2. I Want to hide the Contact Parameter and a= nortpproxy:yes ==> How to do
it as well ?

Thanks in advance.

-- 
Regards
===
Sujit Roy
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Problem with max tcp connections

[Jose Fco . Irles Durá]

I will try to upgrade to the latest version and re test.

Best regards

El mar., 26 nov. 2019 a las 13:15, David Villasmil
() escribió:
>
> That’s strange, I have 5000+ tcp connections and I can’t remember I did 
> anything special at the os level. I’m using 5.2 now, but it was the same with 
> 5.1
>

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

[Daniel-Constantin Mierla]

Hello,

the recommended way is to call dlg_manage() for all requests belonging
to the dialog. There can be a record-routing callback executed for
requests within dialog for the same purpise, but it has some constraints
related to the presence of an unaltered parameter, as well as it was
designed with the use of setting a flag for tracking the dialogs. Even
the r-r callback is executed, doing the dlg_manage() for all requests is
still safe.

Cheers,
Daniel

On 26.11.19 15:25, George Diamantopoulos wrote:
> Thank you both for your input. I guess I'll continue calling
> dlg_manage() for in-dialog requests for now until I gather more
> feedback, since we do cater for a large set of endpoints and several
> have at times exhibited various offending behaviours.
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - April 27-29, 2020, in Berlin -- 
www.kamailioworld.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

[George Diamantopoulos]

Thank you both for your input. I guess I'll continue calling dlg_manage()
for in-dialog requests for now until I gather more feedback, since we do
cater for a large set of endpoints and several have at times exhibited
various offending behaviours.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Beginner Help: Relay vs Forward

[Michael Iedema]

Thank you to everyone who has chimed in on this thread. I’m learning a lot! I 
now have some successful flows and have resolved the bind issue by setting a 
specific bind interface.


The reason for such specialized endpoints (one for REGISTER, one for INVITE, 
etc) is that they already exist. My intention is to place Kamailio in front of 
them to eventually accomplish the following soft migration:

 1) initially just forward traffic transparently from the originator to allow 
the legacy endpoints to continue to serve
 2) new SIP accounts will be added which are not present in the legacy 
endpoints’ databases
 3) when Kamailio sees a 404 when passing through the traffic, it will then 
handle the traffic itself
 4) eventually all accounts will be transitioned to use the new Kamailio-only 
route so the legacy endpoints can be deprecated

With all of that in mind, t_relay() doesn’t look like it’s going to get me 
there. I want Kamailio to be able to see everything going on between the 
origination and legacy endpoints but right now they respond to the originator 
directly without passing back through Kamailio on the return.

Apologies again for the possible rephrasing of the same technical question. I 
probably should have explained my design’s purpose in the beginning to clarify 
why I cannot let the Kamailio instance be optimized out of the path.

Thanks as always for your time,
-Michael



> On Nov 20, 2019, at 16:08, Alex Balashov  wrote:
> 
> Hi Michael,
> 
> First, the "no corresponding socket" issue is the result of a
> determination by Kamailio that it has no outgoing listener (the
> combination of transport protocol, IP address and port) interface that
> can reach the destination network of the next hop.
> 
> The way that Kamailio makes this determination is influenced by this
> setting -- not sure if you have it on.
> 
>   https://www.kamailio.org/wiki/cookbooks/5.3.x/core#mhomed
> 
> Keep in mind that the entire triplet - (transport, address, port) -
> matters.
> 
> Second, I noticed your comment 
> 
>   # ORIGINATOR sent us something
> 
> and considered this condition:
> 
>   if ( $(ct{nameaddr.uri}{uri.port}) == PORT_ORIGINATOR )
> 
> it's probably worth keeping in mind that Contact is a fairly cosmetic
> value and can be set to just about anything, and most importantly, can
> be spoofed. So, if you are using this to determine whether a given
> component of your infrastructure sent you something, you might want to
> operate on the real source address and port of the SIP message instead:
> 
>   
> https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#si_-_source_ip_address
> 
>   
> https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#sp_-_source_port
> 
> Third: this is by way of philosophical commentary only, and under the
> aegis of "helping newbies" :-) -- others may disagree, and are free to
> do so.
> 
> Early on in my experience with Kamailio (then OpenSER), I was
> responsible for some rather unfortunately baroque platform architecture
> designs involving many specialised Kamailio proxies performing esoteric
> functions. This was based on a consistent tendency to underestimate how
> much traffic Kamailio can actually handle and how much work it can do.
> I've designed platforms with a dedicated registrar, dedicated business
> logic / call processing logic, and a carrier-facing element, separated
> into multiple instances, all deployed with redundant mates, etc. 
> 
> Some of them I still have to support, and they're a nightmare, and most
> importantly of all, from a technical point of view they're completely
> unnecessary. In hindsight, it was all a mistake, and can easily be done
> with a single Kamailio element 99% of the time (as long as the config is
> manageable in its organisation), and I regret it all deeply. Cloud
> orchestration / deployment tooling that did not exist in those days
> might have made it a little easier, but also in many respects more
> complicated due to all the service discovery required.
> 
> I was thinking about this in the context of:
> 
>> Originator:
>> - reachable on port 5060
>> - originates all traffic to the services
>> 
>> Service A:
>> - reachable on port 5061
>> - handles REGISTER
>> 
>> Service B:
>> - reachable on port 5062
>> - handles INVITE
>> 
>> Service C:
>> - reachable on port 5063
>> - handles MESSAGE
> 
> I could be wrong, and you might have very credible reasons for such a
> design, but at first glance it reminds me of some massively
> overcomplicated things I built when I first got started with Kamailio.
> :-) As I said, they were all based on a perception that this or that
> element can only handle so much, but it turns out one element can handle
> it all - and 20x more.
> 
> -- Alex
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> ___
> Kamaili

Re: [SR-Users] Problem with max tcp connections

[David Villasmil]

That’s strange, I have 5000+ tcp connections and I can’t remember I did
anything special at the os level. I’m using 5.2 now, but it was the same
with 5.1

On Tue, 26 Nov 2019 at 11:37, Jose Fco. Irles Durá  wrote:

> In my case, from the upgrade I haven't issues (Kamailio has ~2700 tcp
> connections)
>
> But when I restarted the service (for the upgrade), tcp connections
> grow until ~2850 and in that moment I can't create new connections.
>
> I will continue investigating
>
>
> El mar., 26 nov. 2019 a las 10:48, Daniel Tryba ()
> escribió:
> >
> > On Tue, Nov 26, 2019 at 10:32:59AM +0100, Daniel Tryba wrote:
> > > Well, the problem happened to me on 2 different loadbalancers (withing
> > > 24 hours where the loadbalancers had a near identical uptime) For about
> > > 35m no new connections can be established. Already established
> > > connections work fine. I'm not seeing any queueing in to OS
> (netstat/ss)
> > > After some time all works well again without doing anything to the
> machine/kamailio.
> > >
> > > I could try to make a core dump if this happens again and the timing
> is more
> > > appropriate for that.
> >
> > And then it happened again. Coredumps weren't reacted sadly enough. But
> > after restarting I still couldn't reconnect. I'm starting to think this
> > is an OS issue.
> >
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> --
> Jose Fco. Irles Durá
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Problem with max tcp connections

[Jose Fco . Irles Durá]

In my case, from the upgrade I haven't issues (Kamailio has ~2700 tcp
connections)

But when I restarted the service (for the upgrade), tcp connections
grow until ~2850 and in that moment I can't create new connections.

I will continue investigating


El mar., 26 nov. 2019 a las 10:48, Daniel Tryba () escribió:
>
> On Tue, Nov 26, 2019 at 10:32:59AM +0100, Daniel Tryba wrote:
> > Well, the problem happened to me on 2 different loadbalancers (withing
> > 24 hours where the loadbalancers had a near identical uptime) For about
> > 35m no new connections can be established. Already established
> > connections work fine. I'm not seeing any queueing in to OS (netstat/ss)
> > After some time all works well again without doing anything to the 
> > machine/kamailio.
> >
> > I could try to make a core dump if this happens again and the timing is more
> > appropriate for that.
>
> And then it happened again. Coredumps weren't reacted sadly enough. But
> after restarting I still couldn't reconnect. I'm starting to think this
> is an OS issue.
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
Jose Fco. Irles Durá

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Encode host ip in Contact header for semi-stateless setup

[Daniel-Constantin Mierla]

Hello,

I do not remember exactly what was that presentation about, but maybe
topoh module is something that can help you if you need the contact to
be hidden.

Cheers,
Daniel

On 26.11.19 05:42, Daniel Greenwald wrote:
> At kamailio world 2017, Jan Lorenz of Pascom explained how they use
> kamailio in a semi-stateless manner and encode the asterisk's IP into
> the contact header on the way out so that it can be decoded and used
> to route properly on the way back without Record-Routing. I would like
> to create such a setup. 
>
> I'm looking for pointers if there is a particular module/method that
> would be ideal to to use for this. Any other gotcha's to consider in
> such a setup. My plan is to keep the transaction on the same kamailio
> by not altering the VIA but allow the subsequent in-dialog
> transactions to potentially hit another kamailio by changing the
> contact to a shared SRV record (and encoding the freeswitch box's IP
> into it for later retrieval.) 
>
> Thanks in advance.
>
> Daniel Greenwald
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - April 27-29, 2020, in Berlin -- 
www.kamailioworld.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Problem with max tcp connections

[Daniel Tryba]

On Tue, Nov 26, 2019 at 10:32:59AM +0100, Daniel Tryba wrote:
> Well, the problem happened to me on 2 different loadbalancers (withing
> 24 hours where the loadbalancers had a near identical uptime) For about
> 35m no new connections can be established. Already established
> connections work fine. I'm not seeing any queueing in to OS (netstat/ss)
> After some time all works well again without doing anything to the 
> machine/kamailio.
> 
> I could try to make a core dump if this happens again and the timing is more 
> appropriate for that.

And then it happened again. Coredumps weren't reacted sadly enough. But
after restarting I still couldn't reconnect. I'm starting to think this
is an OS issue.


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Problem with max tcp connections

[Daniel Tryba]

On Thu, Nov 21, 2019 at 07:49:28PM +0100, Jose Fco. Irles Dur?? wrote:
> Thanks for the info!
> 
> Tomorrow I'll test it with the 5.1.9 version.
> 

Well, the problem happened to me on 2 different loadbalancers (withing
24 hours where the loadbalancers had a near identical uptime) For about
35m no new connections can be established. Already established
connections work fine. I'm not seeing any queueing in to OS (netstat/ss)
After some time all works well again without doing anything to the 
machine/kamailio.

I could try to make a core dump if this happens again and the timing is more 
appropriate for that.

kamcmd> core.tcp_info 
{
readers: 4
max_connections: 4096
max_tls_connections: 2048
opened_connections: 617
opened_tls_connections: 0
write_queued_bytes: 0
}

tcp options in .cg:
tcp_max_connections=4096
tcp_connection_lifetime=3605

Only funny thing I see is that there are some TCP connections with a very high 
timeout:

{
id: 15453
type: TCP
state: CONN_OK
timeout: 268435455
lifetime: 3605
ref_count: 2
src_ip: a.b.c.d
src_port: 51196
dst_ip: e.f.g.h
dst_port: 5060
}

The timeout is either [0,3605] or 268435455. The high timeout ones
dissear quickly:

while sleep 1 ; do date; kamcmd core.tcp_list | grep 268435455; done

Tue Nov 26 10:29:21 CET 2019
Tue Nov 26 10:29:22 CET 2019
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
Tue Nov 26 10:29:23 CET 2019
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
Tue Nov 26 10:29:24 CET 2019
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
Tue Nov 26 10:29:25 CET 2019
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
Tue Nov 26 10:29:26 CET 2019
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
Tue Nov 26 10:29:27 CET 2019
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
timeout: 268435455
Tue Nov 26 10:29:28 CET 2019
timeout: 268435455
timeout: 268435455
Tue Nov 26 10:29:29 CET 2019
timeout: 268435455
timeout: 268435455


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users