date:20170307

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

2017-03-07 Thread Daniel-Constantin Mierla

On 08/03/2017 08:01, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>>> So, for example, if k2 is a presence server and k1 is forwarding
>>> subscribes/publish requests to it, only one process at k2 would be
>>> processing them since the tcp connection between k1 and k2 is reused?
>>>
>> Those were the observations described by the one opening this thread and
>> then I responded with why I think it happens so, but as I wrote, I
>> haven't really checked the source code yet.
> If that is true, then K tcp implementation is really broken.  Why can't
> tcp manager distribute the requests that come over a shared single
> connection to the workers?
Well, if you think this (my assumption) is broken, then your approach is
also broken, because then you have one single sip tcp reader (the tcp
manager), so you just shift the problem to another place.

Tcp manager process is just dealing with tcp connections only, not doing
any sip stuff.

This situation is exposed only when having a trunk between two servers,
otherwise when phones connect via tcp/tls, there is a connection for
each. I already exposed my assumption of keeping the connection, as the
sip tcp worker sends back some reply in most of the cases (auth
challenge, trying...).

So, I wouldn't call the current implementation like broken at all, I
know deployments with many hundred thousands of active tcp/tls
connections, working for many years without issues. This is just someone
reported a case that is not handled as one expects.

Besides writing some code to do an enhancement for this trunking case,
another solution that came in my mind using current version is to
leverage the async layer via the config file: if the request is sent
from the other server, then suspend the transaction and resume it in an
another processes (rtimer or maybe async workers). I already exposed two
other solutions with using different ports or closing connections after
sending out.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - 
www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

2017-03-07 Thread Juha Heinanen

Daniel-Constantin Mierla writes:

> > So, for example, if k2 is a presence server and k1 is forwarding
> > subscribes/publish requests to it, only one process at k2 would be
> > processing them since the tcp connection between k1 and k2 is reused?
> >
> Those were the observations described by the one opening this thread and
> then I responded with why I think it happens so, but as I wrote, I
> haven't really checked the source code yet.

If that is true, then K tcp implementation is really broken.  Why can't
tcp manager distribute the requests that come over a shared single
connection to the workers?

-- Juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

2017-03-07 Thread Daniel-Constantin Mierla



On 08/03/2017 01:36, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> So, I expect kamailio wil reuse the connection between kamailio1 and
>> kamailio2. The tcp manager process selects the least loaded tcp worker
>> when a new connection is accepted, and the worker start consuming the
>> packets on it until there is nothing to be read on it. The reason behind
>> this approach is that a proxy is typically sending back a 100 trying or
>> some other provisional response while handling the request. If the
>> connection is very busy, so there are always packets to read, then
>> practically the selected tcp workers keeps processing the traffic and
>> never release the tcp connection back to the tcp manager.
> So, for example, if k2 is a presence server and k1 is forwarding
> subscribes/publish requests to it, only one process at k2 would be
> processing them since the tcp connection between k1 and k2 is reused?
>
Those were the observations described by the one opening this thread and
then I responded with why I think it happens so, but as I wrote, I
haven't really checked the source code yet.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - 
www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

2017-03-07 Thread Juha Heinanen

Daniel-Constantin Mierla writes:

> So, I expect kamailio wil reuse the connection between kamailio1 and
> kamailio2. The tcp manager process selects the least loaded tcp worker
> when a new connection is accepted, and the worker start consuming the
> packets on it until there is nothing to be read on it. The reason behind
> this approach is that a proxy is typically sending back a 100 trying or
> some other provisional response while handling the request. If the
> connection is very busy, so there are always packets to read, then
> practically the selected tcp workers keeps processing the traffic and
> never release the tcp connection back to the tcp manager.

So, for example, if k2 is a presence server and k1 is forwarding
subscribes/publish requests to it, only one process at k2 would be
processing them since the tcp connection between k1 and k2 is reused?

-- Juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] new keepalive module ?

2017-03-07 Thread Daniel-Constantin Mierla

Hello,

On 07/03/2017 21:22, Guillaume Bour wrote:
> Hi all,
>
> I would like to implement destinations keepalive in drouting module (as it is 
> done in dispatcher).
> But instead of duplicating what's implemented in dispatcher, I think it would 
> be more clever to create a new module
> dedicated to pinging destinations, and to plug drouting, dispatcher and other 
> modules to this new one
>
> What's you opinion about that ?
>
could be an interesting module, not able to say at this moment if I
would plug it into dispatcher, as I cannot assert the impact, but at
least for adding to drouting or other modules which don't have this
feature, should worth the try.

How do you plan to have the relation between the modules? Each of them
will have a copy of the addresses, or the addresses of the destinations
will be in. a single module, and the other will refer to them via some
unique id? Will drouting just build the list of destination based on
priority, then check with the new module to see which are active and
remove the inactive ones?

Again, when I would see some sort of prototype/initial version, probably
I can comment more. The questions above just pop up in my mind, but
probably you can just go ahead to write some code as you consider, then
we can start a discussion from there and see what can be improved/better
integrated with existing modules.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - 
www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] problem with avpops and mongodb modules

2017-03-07 Thread Daniel-Constantin Mierla

Hello,

I pushed another patch to fix a similar case in a different function.
Can you try with it (6bd32088de1d7ae816643aea4a60c70911e46b5e)?

Cheers,
Daniel


On 07/03/2017 14:50, hdssdsdsdsfsdf hdssdsdsdsfsdf wrote:
> Hi, thanks, we have a similar error further on after succesfully applying 
> your patch on 4.4.4. The setup is the same as it was before, and the result 
> this time is:
>
> Mar  7 14:45:32 slb04 /usr/local/sbin/kamailio[28073]: ERROR:

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

2017-03-07 Thread Daniel-Constantin Mierla

Hello,

On 07/03/2017 08:50, Surendra Pullaiah wrote:
> Dear Daniel,
>
>
>   A small concern in kamailio, existing TCP stack is not doing load 
> distribution among children for SIP messages. For example UE-->kamailio1 (TCP 
> listen (4 children)) ->kamailio2 (TCP Listen 4 children)
>
>   As per stack if UE opens a connection with kamailio1 based on free 
> children it is sharing the FD, so no problem towards from UE to kamailio1, 
> then need requirement to forward same sip message to kamailio2, here 
> kamailio1 is opening connection with kamailio2 and then forwarding. Suppose 
> if we forward two requests to kamailio2, only one children is getting used 
> among four. With this design suppose if we want to run our kamailio as two 
> sip servers we may not achieve good results when performance matters.
>
>
>   Please suggest something on this to move further. 
>
as I haven't implemented myself the tcp client/server in kamailio, it
may require source code checking to safety prove my next statements ...

So, I expect kamailio wil reuse the connection between kamailio1 and
kamailio2. The tcp manager process selects the least loaded tcp worker
when a new connection is accepted, and the worker start consuming the
packets on it until there is nothing to be read on it. The reason behind
this approach is that a proxy is typically sending back a 100 trying or
some other provisional response while handling the request. If the
connection is very busy, so there are always packets to read, then
practically the selected tcp workers keeps processing the traffic and
never release the tcp connection back to the tcp manager.

If kamailio1 and kamailio2 are very close to each other, so tcp connect
is very fast, you can try setting the option to close the connection as
soon as the request is forwarded, via set_forward_close(), then each
request will be on a different connection.

An alternative would be to listen on 4 ports in kamailio2 and do round
robin forwarding to each of these ports.

Of course, it is open source, there is the option of patching the c code
add an option to release back the tcp connection to the tcp manager as
soon as reading the sip request.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - 
www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] new keepalive module ?

2017-03-07 Thread Guillaume Bour

Hi all,

I would like to implement destinations keepalive in drouting module (as it is 
done in dispatcher).
But instead of duplicating what's implemented in dispatcher, I think it would 
be more clever to create a new module
dedicated to pinging destinations, and to plug drouting, dispatcher and other 
modules to this new one

What's you opinion about that ?

Cheers,
Guillaume

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtpengine sending rtp to wrong endpoint after reinvite

2017-03-07 Thread Daniel-Constantin Mierla

Hello,


On 07/03/2017 13:10, Grant Bagdasarian wrote:
>
> Hi,
>
>  
>
> One of our customers is using a SEMS box to place two outbound calls
> using our sip trunk.
>
> Once the first call is connected a second call is placed and when the
> second call answers their server sends a re-invite to switch audio
> ports so the rtp traffic doesn’t flow through their server anymore but
> is routed inside our platform.
>
> Basically, they just switch SDP’s of both calls.
>
> It seems like a random issue, and is not really reproducible, except
> for placing multiple calls and sometimes both parties can hear each
> other, other times they can’t, because rtpengine fails (I think) to
> update the endpoint and keeps sending rtp back to their server for one
> of the call legs.
>
>  
>
> We tried to reproduce the case using a freeswitch box and it worked
> every time. After the reinvite, the rtp remained within our platform.
>
> The signaling in both cases still goes through the freeswitch or sems
> for call control.
>
>  
>
> Does anyone have experience with this case? Or seen the issue before
> where rtpengine keeps sending rtp to the original endpoint?
>

Have your checked to see if the sip messages are received/processed in
the expected order?

In some very rare situations, it happened that the re-invite was sent
very fast by callee after just sending the 200ok, so that the re-invite
arrived to the proxy/rtprelay before the 200ok, so at the end the sdp
from 200ok was taken as the last relevant one for the peer. I put there
rtprelay, because I faced this issue where I had rtpproxy, but maybe the
issue is exposed by the rtpengine as well.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - 
www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SIP contact header question

2017-03-07 Thread Alex Balashov

On Tue, Mar 07, 2017 at 03:44:31PM -0600, Jack Davis wrote:

> What kind of problems can arise from inserting said header?

Theoretically, none. It should be ignored, as per the RFC. Moreover, the
RFC doesn't _prohibit_ such a header in an in-dialog request, so you are
probably clear to add it. Fundamentally, § 12.2 says:

   Requests within a dialog MAY contain Record-Route and Contact header
   fields. However, these requests do not cause the dialog's route set
   to be modified...

I have certainly seen instances in the field where RRs in in-dialog
requests are not ignored, however. That's on the endpoints, of course,
but it can make things worse.

> I'm trying to find a way to get a pesky setup to start behaving, of course,
> without requiring them to make any changes.

That's always a tough gig.

-- 
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/

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SIP contact header question

2017-03-07 Thread Jack Davis

What kind of problems can arise from inserting said header?

I'm trying to find a way to get a pesky setup to start behaving, of course,
without requiring them to make any changes.

Thank you,
Jack Davis


On Fri, Mar 3, 2017 at 2:39 PM, Alex Balashov 
wrote:

> On Fri, Mar 03, 2017 at 02:35:10PM -0600, Jack Davis wrote:
>
> > Is the preferred method to also include a record-route header in the 200
> OK
> > that is given in response to the re-invite?
>
> No. Only initial INVITEs and their replies should have a Record-Route
> header. In-dialog requests and their replies contain Route headers that
> are constructed from that Record-Route set.
>
> --
> 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/
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] new keepalive module ?

2017-03-07 Thread Guillaume Bour

Hi all,

I would like to implement destinations keepalive in drouting module (as it is 
done in dispatcher).
But instead of duplicating what's implemented in dispatcher, I think it would 
be more clever to create a new module
dedicated to pinging destinations, and to plug drouting, dispatcher and other 
modules to this new one

What's you opinion about that ?

Cheers,
Guillaume

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio Presence help required.

2017-03-07 Thread Phil Lavin

Looks fairly sane. Try setting “pua” db_mode to 0. db_mode 2 takes a very 
different path through the code of the pua module and we have found it to be 
somewhat broken beyond repair. Our config is as follows. You may not have some 
of the stuff highlighted in yellow as I recently added those features to 
Kamailio. Depends which version you’re running. They’re not necessary for 
normal operation, however.

modparam("presence", "db_url", DBURL)
modparam("presence", "db_update_period", 20)
modparam("presence", "clean_period", 60)
modparam("presence", "local_log_facility", "LOG_LOCAL3")
modparam("presence", "max_expires", 14430)

modparam("presence_xml", "db_url", DBURL)
modparam("presence_xml", "force_active", 1)

modparam("pua", "db_url", DBURL)
modparam("pua", "db_mode", 0) # Memory only. Required due to the "multiple 
states for a single dialog" bug
modparam("pua", "update_period", 20)
modparam("pua", "outbound_proxy", MY_SIP_URL)

modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO)
modparam("pua_dialoginfo", "override_lifetime", 14420)
modparam("pua_dialoginfo", "callee_trying", 1)
modparam("pua_dialoginfo", "disable_caller_publish_flag", 
FLT_DISABLE_CALLER_PUBLISH)
modparam("pua_dialoginfo", "disable_callee_publish_flag", 
FLT_DISABLE_CALLEE_PUBLISH)

From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of 
SamyGo
Sent: 06 March 2017 22:51
To: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Kamailio Presence help required.

Phil, here are all the Presence related modules and their params.

Igor, I go clearly understand that difference and I accept it. However, Im 
finding it difficult to digest that FreeSWITCH sends back initial NOTIFY and 
phone light works while Kamailio is unable to do the same.

#!ifdef WITH_PRESENCE
loadmodule "presence.so"
loadmodule "presence_xml.so"
loadmodule "presence_dialoginfo.so"
loadmodule "presence_reginfo.so"
loadmodule "pua.so"
loadmodule "pua_dialoginfo.so"
loadmodule "pua_reginfo.so"
loadmodule "pua_usrloc.so"
#!endif

#!ifdef WITH_PRESENCE
# - presence params -
modparam("presence", "db_url", DBURL)
modparam("presence", "server_address", "sip:ServerIP:5060" )
modparam("presence", "send_fast_notify", 0)
modparam("presence", "db_update_period", 20)
modparam("presence", "clean_period", 40)
modparam("presence", "subs_db_mode", 2)
modparam("presence", "fetch_rows", 1000)

# - presence_xml params -
modparam("presence_xml", "db_url", DBURL)
modparam("presence_xml", "force_active", 1)
modparam("presence_xml", "force_dummy_presence", 1)

# - presence_dialoginfo params -
modparam("presence_dialoginfo", "force_single_dialog", 1)
modparam("presence_dialoginfo", "force_dummy_dialog", 0)

# - pua params -
modparam("pua", "db_url", DBURL)
modparam("pua", "db_mode", 2)
modparam("pua", "update_period", 60)
modparam("pua", "dlginfo_increase_version", 0)
modparam("pua", "reginfo_increase_version", 0)
modparam("pua", "check_remote_contact", 1)
modparam("pua", "fetch_rows", 1000)

# - pua_dialoginfo params -
modparam("pua_dialoginfo", "include_callid", 1)
modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO)
modparam("pua_dialoginfo", "caller_confirmed", 0)
modparam("pua_dialoginfo", "include_tags", 1)
modparam("pua_dialoginfo", "override_lifetime", 124)

modparam("pua_reginfo|pua_usrloc", "default_domain", 
"voipguy.ca")
modparam("pua_reginfo", "server_address", "sip:REGINFO@ServerIP")
modparam("pua_usrloc", "branch_flag", FLT_DLGINFO)

#!endif

Thanks for helping me out on this.

Regards,
Sammy

On Mon, Mar 6, 2017 at 4:31 PM, Igor Olhovskiy 
> wrote:
Hi, Samy.

Point, there is 2 modes of presence. Based on 'presence' and 'dialog'. Only 
'presence' indicates states like online/offline, 'dialog' indicates only 
different call states, but also hold more info about a call. In 'dialog' case 
XML does not even has an option to indicate, that phone is online or offline.

Refer to https://tools.ietf.org/html/rfc3856 and 
https://tools.ietf.org/html/rfc4235
So, when phone subscribes to 'dialog', according to rfc, they just want to know 
active states and not care about online/offline.

Regards, Igor

6 марта 2017 г., 18:00 +0200, Phil Lavin 
>, писал:

You should get an initial NOTIFY when you subscribe. Can you share the parts of 
your config that are relevant to presence/pua/etc.?

From: sr-users 
[mailto:sr-users-boun...@lists.sip-router.org]
 On Behalf Of SamyGo
Sent: 06 March 2017 15:50
To: Daniel-Constantin Mierla >; 
Kamailio (SER) - Users Mailing List 
>
Subject: Re: [SR-Users] Kamailio Presence help required.

Thanks Daniel for replying,
Yes the BLF/Callstates are working

Re: [SR-Users] Cdr on shutdown

2017-03-07 Thread Diego Nadares

Hi Daniel! Thanks for your answer.

Sorry, i didn't provide enough data for what I need. I'm using kamailio as
a statefull proxy and  I all ready have dialog module working too but with
no database.

Today I started testing dialog with db_mode = 3 (shutdown). The thing is
that when I kill kamailio from terminal, the dialog module does not save
any data. It only works when I execute kamctl stop.


Cheers,

Diego.



2017-03-07 10:49 GMT-03:00 Daniel Tryba :

> On Tue, Mar 07, 2017 at 10:34:05AM -0300, Diego Nadares wrote:
> > Is it possible to generate cdrs or to save dialogs to db when kamailio
> > receives a kill signal from terminal?
>
> Killing kamailio doesn't end running calls. So if you restart kamailio
> before a BYE, accounting will be correct on teardown of the calls.
>
> The dialog module can store state in a database, but if your are
> specifically looking for something that only happens when kamailio is
> killed without a database backend, you'd have to do some dumping of
> state before the kill is processed and I don't know if that is possible.
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] problem with avpops and mongodb modules

2017-03-07 Thread hdssdsdsdsfsdf hdssdsdsdsfsdf

Hi, thanks, we have a similar error further on after succesfully applying your 
patch on 4.4.4. The setup is the same as it was before, and the result this 
time is:

Mar  7 14:45:32 slb04 /usr/local/sbin/kamailio[28073]: ERROR:

Re: [SR-Users] Cdr on shutdown

2017-03-07 Thread Daniel Tryba

On Tue, Mar 07, 2017 at 10:34:05AM -0300, Diego Nadares wrote:
> Is it possible to generate cdrs or to save dialogs to db when kamailio
> receives a kill signal from terminal?

Killing kamailio doesn't end running calls. So if you restart kamailio
before a BYE, accounting will be correct on teardown of the calls.

The dialog module can store state in a database, but if your are
specifically looking for something that only happens when kamailio is
killed without a database backend, you'd have to do some dumping of
state before the kill is processed and I don't know if that is possible.

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Cdr on shutdown

2017-03-07 Thread Diego Nadares

Hi Guys,


Is it possible to generate cdrs or to save dialogs to db when kamailio
receives a kill signal from terminal?

Thanks in advance.

Diego
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] rtpengine sending rtp to wrong endpoint after reinvite

2017-03-07 Thread Grant Bagdasarian

Hi,

One of our customers is using a SEMS box to place two outbound calls using our 
sip trunk.
Once the first call is connected a second call is placed and when the second 
call answers their server sends a re-invite to switch audio ports so the rtp 
traffic doesn't flow through their server anymore but is routed inside our 
platform.
Basically, they just switch SDP's of both calls.
It seems like a random issue, and is not really reproducible, except for 
placing multiple calls and sometimes both parties can hear each other, other 
times they can't, because rtpengine fails (I think) to update the endpoint and 
keeps sending rtp back to their server for one of the call legs.

We tried to reproduce the case using a freeswitch box and it worked every time. 
After the reinvite, the rtp remained within our platform.
The signaling in both cases still goes through the freeswitch or sems for call 
control.

Does anyone have experience with this case? Or seen the issue before where 
rtpengine keeps sending rtp to the original endpoint?

Regards,

Grant Bagdasarian
CM
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio core dumped

2017-03-07 Thread Alexey V. Panfilov

Hello, Daniel!

Sure, issue is here - https://github.com/kamailio/kamailio/issues/1021

Thanks!


07.03.2017 12:58, Daniel-Constantin Mierla wrote:
> Hello,
> 
> can you open an issue on bug tracker? Having it there ensure that it is
> not forgotten and properly handles -- sometimes people travel and miss
> various messages on the mailing list. As a matter of fact for this
> specific case, your messages is put in spam folder for me by the gmail
> server and only spotted now as I looked into the mailing list archive.
> 
> I will try to look at it as soon as I get a chance, right now being out
> of the office.
> 
> Cheers,
> Daniel
> 
> On 07/03/2017 09:08, Alexey V. Panfilov wrote:
>> Hello,
>>
>> 01.03.2017 13:51, Alexey V. Panfilov wrote:
>>> Hi there,
>>>
>>> I've kamailio 4.2.3 (i386/freebsd) which works perfectly with 200-300
>>> cps for years.
>>>
>>> Now I need migrate to freebsd amd64. I've installed kamailio 4.4.5
>>> (amd64/freebsd), copied kamailio.cfg, made a test call - it was all right.
>>>
>>> But when I start work load (200-300 cps), kamailio core dumped and
>>> exited. In logs (skipped

Re: [SR-Users] Kamailio core dumped

2017-03-07 Thread Daniel-Constantin Mierla

Hello,

can you open an issue on bug tracker? Having it there ensure that it is
not forgotten and properly handles -- sometimes people travel and miss
various messages on the mailing list. As a matter of fact for this
specific case, your messages is put in spam folder for me by the gmail
server and only spotted now as I looked into the mailing list archive.

I will try to look at it as soon as I get a chance, right now being out
of the office.

Cheers,
Daniel

On 07/03/2017 09:08, Alexey V. Panfilov wrote:
> Hello,
>
> 01.03.2017 13:51, Alexey V. Panfilov wrote:
>> Hi there,
>>
>> I've kamailio 4.2.3 (i386/freebsd) which works perfectly with 200-300
>> cps for years.
>>
>> Now I need migrate to freebsd amd64. I've installed kamailio 4.4.5
>> (amd64/freebsd), copied kamailio.cfg, made a test call - it was all right.
>>
>> But when I start work load (200-300 cps), kamailio core dumped and
>> exited. In logs (skipped

Re: [SR-Users] Kamailio 4.2 crashed

2017-03-07 Thread Igor Potjevlesch

Hello,



There were 3 additional crashes. The two last coredump are (for the same crash):



(gdb)   bt full

#0  0x003f5d232925 in raise () from /lib64/libc.so.6

No symbol table info available.

#1  0x003f5d234105 in abort () from /lib64/libc.so.6

No symbol table info available.

#2  0x0061a75d in qm_debug_frag (qm=0x7fa2abe2d000, f=0x7fa2bb870de8) 
at mem/q_malloc.c:151

__FUNCTION__ = "qm_debug_frag"

#3  0x0061cd90 in qm_free (qm=0x7fa2abe2d000, p=0x7fa2bb870e18, 
file=0x7fa2d2d4c36d "tm: h_table.c", func=0x7fa2d2d4c648 "free_cell", line=186) 
at mem/q_malloc.c:468

f = 0x7fa2bb870de8

size = 40

next = 0x400

prev = 0x7fffd1ab2a00

__FUNCTION__ = "qm_free"

#4  0x7fa2d2c8dc9d in free_cell (dead_cell=0x7fa2bb86b408) at h_table.c:186

b = 0x7fa2bb870e18 "INVITE sip:0123456789@fqdn SIP/2.0\r\nRecord-Route: 
\r\nDiversion: 
;privacy=off;reason=unconditional;counter=1\r\nVia:
 SIP/2.0/UDP 91.213.1"...

i = 0

rpl = 0x0

tt = 0x0

foo = 0x7fa2abe62528

cbs = 0x0

cbs_tmp = 0x7fa2bb880f10

__FUNCTION__ = "free_cell"

#5  0x7fa2d2c8f1fd in free_hash_table () at h_table.c:448

p_cell = 0x7fa2bb86b408

tmp_cell = 0x7fa2abeec9c8

i = 7898

__FUNCTION__ = "free_hash_table"

#6  0x7fa2d2cb420d in tm_shutdown () at t_funcs.c:123

__FUNCTION__ = "tm_shutdown"

#7  0x005929e6 in destroy_modules () at sr_module.c:811

t = 0x7fa2d42c53e8

foo = 0x7fa2d42c4d28

__FUNCTION__ = "destroy_modules"

#8  0x0049c917 in cleanup (show_status=1) at main.c:569

memlog = 0

__FUNCTION__ = "cleanup"

#9  0x0049dedf in shutdown_children (sig=15, show_status=1) at 
main.c:711

__FUNCTION__ = "shutdown_children"

#10 0x004a04b5 in handle_sigs () at main.c:802

chld = 0

chld_status = 139

memlog = -1410980464

__FUNCTION__ = "handle_sigs"

#11 0x004a82e6 in main_loop () at main.c:1757

i = 8

pid = 16151

si = 0x0

si_desc = "udp receiver child=7 
sock=A.B.C.60:5060\000\177\000\000\060/\253\321\377\177\000\000\023{N\000\000\000\000\000\200/\253\321\377\177\000\000\004\000\000\000\000\000\000\000`TA\000\000\000\000\000(%æ«¢\177",
 '\000' , 
"\001\000\000\000\200/\253\321\377\177\000\000\266{N\000\000\000\000"

nrprocs = 8

__FUNCTION__ = "main_loop"

#12 0x004acfa6 in main (argc=7, argv=0x7fffd1ab31f8) at main.c:2581

cfg_stream = 0x174e010

c = -1

r = 0

tmp = 0x7fffd1ab3f70 ""

tmp_len = 32767

port = -777310002

proto = 0

options = 0x703718 
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:"

ret = -1

seed = 2069815000

rfd = 4

debug_save = 0

debug_flag = 0

dont_fork_cnt = 0

n_lst = 0x40d134

p = 0xc2 

__FUNCTION__ = "main"



And the other one:

(gdb) bt full

#0  0x7fa2d2c8c9f4 in atomic_get (v=0x7fa451f0f49c) at 
../../mem/../atomic/atomic_common.h:74

No locals.

#1  0x7fa2d2c8d7c2 in lock_hash (i=221261872) at h_table.c:104

mypid = 16151

#2  0x7fa2d2cd29c3 in wait_handler (ti=2134563371, wait_tl=0x7fa2bb871420, 
data=0x7fa2bb87130a) at timer.c:671

p_cell = 0x7fa2bb87130a

ret = 1

#3  0x005fd647 in timer_list_expire (t=2134563371, h=0x7fa2abea6908, 
slow_l=0x7fa2abea8f08, slow_mark=35391) at timer.c:888

tl = 0x7fa2bb871420

ret = 2134563371

#4  0x005fda8f in timer_handler () at timer.c:953

saved_ticks = 2134563371

run_slow_timer = 0

i = 575

__FUNCTION__ = "timer_handler"

#5  0x005fdefd in timer_main () at timer.c:992

No locals.

#6  0x004a77e1 in main_loop () at main.c:1700

i = 8

pid = 0

si = 0x0

si_desc = "udp receiver child=7 
sock=A.B.C.60:5060\000\177\000\000\060/\253\321\377\177\000\000\023{N\000\000\000\000\000\200/\253\321\377\177\000\000\004\000\000\000\000\000\000\000`TA\000\000\000\000\000(%æ«¢\177",
 '\000' , 
"\001\000\000\000\200/\253\321\377\177\000\000\266{N\000\000\000\000"

nrprocs = 8

__FUNCTION__ = "main_loop"

#7  0x004acfa6 in main (argc=7, argv=0x7fffd1ab31f8) at main.c:2581

cfg_stream = 0x174e010

c = -1

r = 0

tmp = 0x7fffd1ab3f70 ""

tmp_len = 32767

port = -777310002

proto = 0

options = 0x703718 
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:"

ret = -1

seed = 2069815000

rfd = 4

debug_save = 0

debug_flag = 0

dont_fork_cnt = 0

n_lst = 0x40d134

p = 0xc2 

__FUNCTION__ = "main"



Regards,



Igor.



De : Igor

Re: [SR-Users] SCTP support for CDP

2017-03-07 Thread Jason Penton

Hi Sergey,

The peer looks correct and established/up. could you perhaps send me debug
output for CDP module when you try and route? Please also share your xml
configuration file for CDP module - there is most likely a configuration
problem in the routing section...

Cheers
Jason

On Tue, Mar 7, 2017 at 11:21 AM, Sergey Zyrianov 
wrote:

> Hi Carsten,
>
> Does this look ok on i-cscf:
>
> kamcmd cdp.list_peers
> {
> Realm: ims.mnc06.mcc240.3gppnetwork.org
> Identity: icscf.mnc06.mcc240.3gppnetwork.org
> Accept unknown peers: 1
> Connect timeout: 5
> Transaction timeout: 5
> Default auth session timeout: 3600
> Queue length: 32
> Workers: 16
> Peer count: 1
> Peers: {
> FQDN: 10.47.10.153
> Details: {
> State: I_Open
> Disabled: False
> Last used: 0
> Applications: {
> appid:vendorid: 16777216:10415
> }
> }
> }
> }
>
>
> Thanks,
> Sergey.
>
> On Mon, Mar 6, 2017 at 11:04 AM, Carsten Bock 
> wrote:
>
>> Hi Sergey,
>>
>> can you do the following:
>>
>> kamcmd cdp.list_peers
>>
>> If everything is working, you should see your peer
>>
>> Thanks,
>> Carsten
>>
>> 2017-03-03 23:08 GMT+01:00 Sergey Zyrianov :
>> > Hi Carsten,
>> >
>> > I did socat relay from TCP to SCTP and Diameter caps exchange seems to
>> > happen. But CDP module still refuses to use this connection/peer:
>> >
>> >  AAASendMessage(): AAASendMessage(): Can't find a suitable connected
>> peer in
>> > the routing table.
>> >  0(1) ERROR: cdp [routing.c:275]: get_routing_peer():
>> get_routing_peer(): No
>> > connected DefaultRoute peer found for app_id 16777216 and vendor id
>> 10415.
>> >
>> >
>> > I suspect something wrong in the xml config for CDP I got:
>> > > > 
>> > > > port="7868"/>
>> > 
>> > 
>> >
>> > And this is HSS's response:
>> >
>> >
>> > Thanks,
>> > Sergey.
>> >
>> >
>> >
>> > 2017-03-03 17:14 GMT+01:00 Carsten Bock :
>> >>
>> >> Hi,
>> >>
>> >> currently, SCTP is not implemented in the CDP module.
>> >>
>> >> Thanks,
>> >> Carsten
>> >>
>> >> 2017-03-03 10:12 GMT+01:00 Sergey Zyrianov > >:
>> >> > Hello,
>> >> >
>> >> > Can I enable use of SCTP for diameter connections by CDP module?
>> >> >
>> >> > Thanks,
>> >> > Sergey.
>> >> >
>> >> > ___
>> >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>> list
>> >> > sr-users@lists.sip-router.org
>> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Carsten Bock
>> >> CEO (Geschäftsführer)
>> >>
>> >> ng-voice GmbH
>> >> Millerntorplatz 1
>> >> 20359 Hamburg / Germany
>> >>
>> >> http://www.ng-voice.com
>> >> mailto:cars...@ng-voice.com
>> >>
>> >> Office +49 40 5247593-40
>> >> Fax +49 40 5247593-99
>> >>
>> >> Sitz der Gesellschaft: Hamburg
>> >> Registergericht: Amtsgericht Hamburg, HRB 120189
>> >> Geschäftsführer: Carsten Bock
>> >> Ust-ID: DE279344284
>> >>
>> >> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
>> >> http://www.ng-voice.com/imprint/
>> >>
>> >> ___
>> >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> >> sr-users@lists.sip-router.org
>> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >
>> >
>> > ___
>> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> > sr-users@lists.sip-router.org
>> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> >
>>
>>
>>
>> --
>> Carsten Bock
>> CEO (Geschäftsführer)
>>
>> ng-voice GmbH
>> Millerntorplatz 1
>> 20359 Hamburg / Germany
>>
>> http://www.ng-voice.com
>> mailto:cars...@ng-voice.com
>>
>> Office +49 40 5247593-40
>> Fax +49 40 5247593-99
>>
>> Sitz der Gesellschaft: Hamburg
>> Registergericht: Amtsgericht Hamburg, HRB 120189
>> Geschäftsführer: Carsten Bock
>> Ust-ID: DE279344284
>>
>> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
>> http://www.ng-voice.com/imprint/
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>


-- 

*Jason Penton*
*Senior Manager: Applications and Services*
*Smile Communications Pty (Ltd)*


*Voice:Mobile:* +234 (0) 702 000 000 7

+27 (0) 83 283 7000

Re: [SR-Users] SCTP support for CDP

2017-03-07 Thread Sergey Zyrianov

Hi Carsten,

Does this look ok on i-cscf:

kamcmd cdp.list_peers
{
Realm: ims.mnc06.mcc240.3gppnetwork.org
Identity: icscf.mnc06.mcc240.3gppnetwork.org
Accept unknown peers: 1
Connect timeout: 5
Transaction timeout: 5
Default auth session timeout: 3600
Queue length: 32
Workers: 16
Peer count: 1
Peers: {
FQDN: 10.47.10.153
Details: {
State: I_Open
Disabled: False
Last used: 0
Applications: {
appid:vendorid: 16777216:10415
}
}
}
}


Thanks,
Sergey.

On Mon, Mar 6, 2017 at 11:04 AM, Carsten Bock  wrote:

> Hi Sergey,
>
> can you do the following:
>
> kamcmd cdp.list_peers
>
> If everything is working, you should see your peer
>
> Thanks,
> Carsten
>
> 2017-03-03 23:08 GMT+01:00 Sergey Zyrianov :
> > Hi Carsten,
> >
> > I did socat relay from TCP to SCTP and Diameter caps exchange seems to
> > happen. But CDP module still refuses to use this connection/peer:
> >
> >  AAASendMessage(): AAASendMessage(): Can't find a suitable connected
> peer in
> > the routing table.
> >  0(1) ERROR: cdp [routing.c:275]: get_routing_peer():
> get_routing_peer(): No
> > connected DefaultRoute peer found for app_id 16777216 and vendor id
> 10415.
> >
> >
> > I suspect something wrong in the xml config for CDP I got:
> >  > 
> >  > port="7868"/>
> > 
> > 
> >
> > And this is HSS's response:
> >
> >
> > Thanks,
> > Sergey.
> >
> >
> >
> > 2017-03-03 17:14 GMT+01:00 Carsten Bock :
> >>
> >> Hi,
> >>
> >> currently, SCTP is not implemented in the CDP module.
> >>
> >> Thanks,
> >> Carsten
> >>
> >> 2017-03-03 10:12 GMT+01:00 Sergey Zyrianov :
> >> > Hello,
> >> >
> >> > Can I enable use of SCTP for diameter connections by CDP module?
> >> >
> >> > Thanks,
> >> > Sergey.
> >> >
> >> > ___
> >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> >> > sr-users@lists.sip-router.org
> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >> >
> >>
> >>
> >>
> >> --
> >> Carsten Bock
> >> CEO (Geschäftsführer)
> >>
> >> ng-voice GmbH
> >> Millerntorplatz 1
> >> 20359 Hamburg / Germany
> >>
> >> http://www.ng-voice.com
> >> mailto:cars...@ng-voice.com
> >>
> >> Office +49 40 5247593-40
> >> Fax +49 40 5247593-99
> >>
> >> Sitz der Gesellschaft: Hamburg
> >> Registergericht: Amtsgericht Hamburg, HRB 120189
> >> Geschäftsführer: Carsten Bock
> >> Ust-ID: DE279344284
> >>
> >> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
> >> http://www.ng-voice.com/imprint/
> >>
> >> ___
> >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >> sr-users@lists.sip-router.org
> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> >
> > ___
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> > sr-users@lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
>
>
>
> --
> Carsten Bock
> CEO (Geschäftsführer)
>
> ng-voice GmbH
> Millerntorplatz 1
> 20359 Hamburg / Germany
>
> http://www.ng-voice.com
> mailto:cars...@ng-voice.com
>
> Office +49 40 5247593-40
> Fax +49 40 5247593-99
>
> Sitz der Gesellschaft: Hamburg
> Registergericht: Amtsgericht Hamburg, HRB 120189
> Geschäftsführer: Carsten Bock
> Ust-ID: DE279344284
>
> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
> http://www.ng-voice.com/imprint/
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio core dumped

2017-03-07 Thread Alexey V. Panfilov

Hello,

01.03.2017 13:51, Alexey V. Panfilov wrote:
> Hi there,
> 
> I've kamailio 4.2.3 (i386/freebsd) which works perfectly with 200-300
> cps for years.
> 
> Now I need migrate to freebsd amd64. I've installed kamailio 4.4.5
> (amd64/freebsd), copied kamailio.cfg, made a test call - it was all right.
> 
> But when I start work load (200-300 cps), kamailio core dumped and
> exited. In logs (skipped

Re: [SR-Users] problem with avpops and mongodb modules

2017-03-07 Thread Daniel-Constantin Mierla

Hello,

can you try with current master branch or using the patch from next
commit in your version?

  -
https://github.com/kamailio/kamailio/commit/501c41dd35fb9f15fdf96f4f3778860395e37a84

I am not able to test these days, but if you report it is working fine,
then I can backport to stable branches.

Cheers,
Daniel


On 06/03/2017 09:48, hdssdsdsdsfsdf hdssdsdsdsfsdf wrote:
>> On 22/02/2017 14:35, hsdsdssdfsdf dsasd wrote:
>>> I implemented call forwarding according to
>>> https://www.kamailio.org/wiki/tutorials/mini-howto-admin/call_forwarding,
>>> which is working fine. When I replace db_mysql with db_mongodb
>>> however, I receive an error on "if (avp_db_load("$ruri/username",
>>> "$avp(s:fwd_blind)")) {":
>>>  
>>> ERROR: db_mongodb [mongodb_dbase.c:381]: db_mongodb_get_columns():
>>> field [attribute] not found in result iterator
>>> ERROR: db_mongodb [mongodb_dbase.c:739]: db_mongodb_store_result():
>>> failed to set the columns
>>> ERROR: db_mongodb [mongodb_dbase.c:918]: db_mongodb_query(): failed to
>>> store result
>>> ERROR: db_mongodb [mongodb_dbase.c:927]: db_mongodb_query(): failed to
>>> do the query
>>> ERROR: avpops [avpops_impl.c:381]: ops_dbload_avps(): db_load failed
>> can you set debug=3 in kamailio.cfg, restart kamailio and test again?
>> Then grab the log messages from syslog and send them here. It should
>> provide more debug information.
>>
>> Is there a record for this query? Or should be an empty response (no
>> record returned)?
>>
>> Cheers,
>> Daniel
>
> I used the following to store a forward:
> avp_db_store("$from/username","$avp(s:fwd_blind)");
>
> Which in this case resulted in (after replacing the true forward info):
> > db.usr_preferences.find()
> { "_id" : ObjectId("58ac40f7e498420e0703a2e1"), "uuid" : "", 
> "attribute" : "fwd_blind", "value" : "sip:0003@x.x.x;user=phone", "type" : 0, 
> "username" : "0002", "domain" : null }
>
> After setting:
> debug=3
>
> ...
> xlog("bla00");
> if (avp_db_load("$ruri/username", "$avp(s:fwd_blind)")) {
> xlog("bla01"
> ...
> }
> xlog("bla02");
> ...
>
> The syslog shows (after replacing the true username):
> Feb 24 10:42:18 slb04 /usr/local/sbin/kamailio[20311]: ERROR: 
>

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

Re: [SR-Users] new keepalive module ?

Re: [SR-Users] problem with avpops and mongodb modules

Re: [SR-Users] TCP stack is not doing load distribution among children for SIP

[SR-Users] new keepalive module ?

Re: [SR-Users] rtpengine sending rtp to wrong endpoint after reinvite

Re: [SR-Users] SIP contact header question

Re: [SR-Users] SIP contact header question

[SR-Users] new keepalive module ?

Re: [SR-Users] Kamailio Presence help required.

Re: [SR-Users] Cdr on shutdown

Re: [SR-Users] problem with avpops and mongodb modules

Re: [SR-Users] Cdr on shutdown

[SR-Users] Cdr on shutdown

[SR-Users] rtpengine sending rtp to wrong endpoint after reinvite

Re: [SR-Users] Kamailio core dumped

Re: [SR-Users] Kamailio core dumped

Re: [SR-Users] Kamailio 4.2 crashed

Re: [SR-Users] SCTP support for CDP

Re: [SR-Users] SCTP support for CDP

Re: [SR-Users] Kamailio core dumped

Re: [SR-Users] problem with avpops and mongodb modules

25 matches

Site Navigation

Mail list logo

Footer information