from:"Nuno Ferreira"

[SR-Users] siptrace: methods blacklist modparam

2020-06-25 Thread Nuno Ferreira

Hello,

We are a heavy Homer/Hepic (tks QXIP team) users and on our setup, there
are some SIP methods we don’t want to get into the database or send to the
capture server because there’s no value-added for call troubleshooting
purposes (OPTIONS, KDMQ, HTTP (from JSONRPC)…)

Typically we achieve the message filtering using siptrace in “manual” mode
and control what to send from the script. This works fine for some
situations, but there are a few we need to have the automatic mode on:

   -

   topos enabled: using manual mode we don’t get the “wire” version of the
   signaling
   -

   TCP connections: there are a few situations where the destination port
   is traced with 0 - I believe this is due to the fact the TCP socket not
   established when the message is collected


There are other technics to filter like using a HEP relay proxy dropping
unwanted traffic, but having a native kamailio functionality would make
things much easier. With that in mind, I’ve created a PR (#2374
) that allows to blacklist
methods we don’t want to send to the capture server when using automatic
trace mode. I believe this is a very helpful change for the community as
well.

To block SIP OPTIONS and KDMQ we just need to declare a new modparam:

modparam("siptrace", "trace_on", 1)

modparam("siptrace", "methods_blacklist_auto", 16896)

Let me know what you think about it.

Nuno

-- 
*Confidentiality Notice: The information contained in this e-mail and any

attachments may be confidential. If you are not an intended recipient, you

are hereby notified that any dissemination, distribution or copying of this

e-mail is strictly prohibited. If you have received this e-mail in error,

please notify the sender and permanently delete the e-mail and any

attachments immediately. You should not retain, copy or use this e-mail or

any attachment for any purpose, nor disclose all or any part of the

contents to any other person. Thank you.*
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Parallel forking - first responder wins

2020-04-21 Thread Nuno Ferreira

Hi Alex,

Isn't the option of generating multiple call legs with a B2BUA more subject
to dead air/ghost calls than letting kamailio handle parallel forking?

Nuno

On Tue, Apr 21, 2020 at 12:06 AM Alex Balashov 
wrote:

> It should be noted at a rather general level that parallel forking is
> replete with race conditions, and is a nasty and unwieldy aspect of SIP.
>
> The pain of using parallel forking to implement something like "ring
> groups", for example, is often not worth the savings in architectural
> complexity.
>
> If you have some other means of accomplishing what you want to
> accomplish, e.g. using a B2BUA to generate multiple independent call
> legs simultaneously ringing multiple destinations, I strongly advise you
> to go with that instead.
>
> -- 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/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>

-- 
*Confidentiality Notice: The information contained in this e-mail and any

attachments may be confidential. If you are not an intended recipient, you

are hereby notified that any dissemination, distribution or copying of this

e-mail is strictly prohibited. If you have received this e-mail in error,

please notify the sender and permanently delete the e-mail and any

attachments immediately. You should not retain, copy or use this e-mail or

any attachment for any purpose, nor disclose all or any part of the

contents to any other person. Thank you.*
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [ot] lightweight sip app for auto-answering with play file and echo mode

2020-03-26 Thread Nuno Ferreira

baresip is also something to consider
https://github.com/alfredh/baresip

Regards,

Nuno

On Thu, Mar 26, 2020 at 8:56 AM Daniel-Constantin Mierla 
wrote:

> I looked a bit at the pjsua recently (and used it along the time), but I
> couldn't find an option to do echo mode. Are you aware if it can be done?
>
> Cheers,
> Daniel
>
> On 26.03.20 09:08, Alexey Vasilyev wrote:
> > I’m using pjsua in test suite. It is lightweight, it can be controlled
> by telnet.
> > It is easily can be built for Alpine and run in the docker. Docker image
> size is 19 MB.
> > It can play file when calling, it can answer and play file, it can
> record call.
> > And fully supports IPv4, IPv6, TLS/TCP/UDP, SRTP so we can simulate a
> lot of cases.
> >
> > -
> > Alexey Vasilyev
> > alexei.vasil...@gmail.com
> >
> >
> >
> >> 26 Mar 2020, в 08:43, Daniel-Constantin Mierla 
> написал(а):
> >>
> >> Hello,
> >>
> >> wondering if anyone here is aware of a lightweight sip app that can
> >> answer a call, play some file and/or do echo mode, mainly targeted at
> >> using it for basic sip routing and call testing. Of course I know that
> >> Asterisk and FreeSwitch (or even SEMS) can do that, but they have many
> >> dependencies, requiring quite some resources to run them, so I thought
> >> maybe someone here figured out different solutions, eventually cli based
> >> apps like pjsua or baresip. GUI apps for Linux are also fine if they can
> >> be configured for such behaviour.
> >>
> >> Cheers,
> >> Daniel
> >>
> >> --
> >> Daniel-Constantin Mierla -- www.asipto.com
> >> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> >>
> >>
> >> ___
> >> 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
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>

-- 
*Confidentiality Notice: The information contained in this e-mail and any

attachments may be confidential. If you are not an intended recipient, you

are hereby notified that any dissemination, distribution or copying of this

e-mail is strictly prohibited. If you have received this e-mail in error,

please notify the sender and permanently delete the e-mail and any

attachments immediately. You should not retain, copy or use this e-mail or

any attachment for any purpose, nor disclose all or any part of the

contents to any other person. Thank you.*
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] pipelimit: inexistent pipe error logs

2020-02-10 Thread Nuno Ferreira

Hi Daniel,

I noticed that you already moved the ERR log to DBG in the pipe limit
module. Did you have the opportunity to look at the other 2 errors?
Glad if I can help, but I will need some directions especially about
the place where the "[466B blob data]" is getting printed.

Thanks,
Nuno

On Wed, Jan 22, 2020 at 3:03 PM Nuno Ferreira  wrote:

> Hi,
>
> http_reply_parse is not present in the configs. I've explicitly set it as
> "no" and the result is the same. If I set it as "yes", topos complains like
> this:
>
> Jan 22 15:00:10 proxy1 kamailio[29316]: ERROR: topos [topos_mod.c:282]:
> tps_prepare_msg(): cannot parse cseq header
>
> Thank you,
>
> Nuno
>
> On Wed, Jan 22, 2020 at 2:45 PM Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> do you have http_reply_parse=yes ?
>>
>> The error is from topos catching the http reply being sent out and trying
>> to handle it.
>>
>> Cheers,
>> Daniel
>> On 22.01.20 12:34, Nuno Ferreira wrote:
>>
>> Hi,
>>
>> I'm using kamailio 5.2.4 (topos enabled) and HTTP 1.1
>> Here's ngrep output:
>> 
>> T 127.0.0.1:32322 -> 127.0.0.1:8000 [AP]
>> POST /RPC HTTP/1.1.
>> User-Agent: curl/7.29.0.
>> Host: 127.0.0.1:8000.
>> Accept: */*.
>> Content-Type: application/json.
>> Content-Length: 75.
>> .
>> {"id": 1, "jsonrpc": "2.0", "method": "pl.list", "params":
>> ["pipe_INVITE"]}
>> ##
>> T 127.0.0.1:8000 -> 127.0.0.1:32322 [AP]
>> HTTP/1.1 400 Unknown pipe id pipe_INVITE.
>> Sia: SIP/2.0/TCP 127.0.0.1:32322.
>> Content-Type: application/json.
>> Server: SIP Proxy (v1.1.0-360).
>> Content-Length: 105.
>> .
>> {
>> ."jsonrpc":."2.0",
>> ."error":.{
>> .."code":.400,
>> .."message":."Unknown pipe id pipe_INVITE"
>> .},
>> ."id":.1
>> }
>> 
>>
>> Debug logs from kamailio:
>> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
>> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 127.0.0.1
>> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
>> [core/tcp_main.c:999]: tcpconn_new(): on port 32304, type 2
>> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
>> [core/tcp_main.c:1309]: tcpconn_add(): hashes: 3634:3788:434, 41
>> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
>> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa85ba0, 39, 2,
>> 0x7f87c726b9e0), fd_no=29
>> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
>> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa85ba0, 39, -1,
>> 0x0) fd_no=30 called
>> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
>> [core/tcp_main.c:4196]: handle_tcpconn_ev(): sending to child, events 1
>> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
>> [core/tcp_main.c:3878]: send2child(): selected tcp worker idx:0 proc:19
>> pid:18996 for activity on [tcp:127.0.0.1:8000], 0x7f87c726b9e0
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/tcp_read.c:1759]: handle_io(): received n=8 con=0x7f87c726b9e0, fd=11
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/tcp_read.c:1560]: tcp_read_req(): content-length=75
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:610]: parse_msg(): SIP Request:
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:612]: parse_msg():  method:  
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:614]: parse_msg():  uri: 
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:616]: parse_msg():  version: 
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:185]: get_hdr_field(): content_length=75
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: topos [topos_mod.c:269]:
>> tps_prepare_msg(): non sip request message
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:610]: parse_msg(): SIP Request:
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:612]: parse_msg():  method:  
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:614]: parse_msg():  uri: 
>> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
>> [core/parser/msg_parser.c:616]: parse_msg

Re: [SR-Users] pipelimit: inexistent pipe error logs

2020-01-22 Thread Nuno Ferreira

Hi,

http_reply_parse is not present in the configs. I've explicitly set it as
"no" and the result is the same. If I set it as "yes", topos complains like
this:

Jan 22 15:00:10 proxy1 kamailio[29316]: ERROR: topos [topos_mod.c:282]:
tps_prepare_msg(): cannot parse cseq header

Thank you,

Nuno

On Wed, Jan 22, 2020 at 2:45 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> do you have http_reply_parse=yes ?
>
> The error is from topos catching the http reply being sent out and trying
> to handle it.
>
> Cheers,
> Daniel
> On 22.01.20 12:34, Nuno Ferreira wrote:
>
> Hi,
>
> I'm using kamailio 5.2.4 (topos enabled) and HTTP 1.1
> Here's ngrep output:
> 
> T 127.0.0.1:32322 -> 127.0.0.1:8000 [AP]
> POST /RPC HTTP/1.1.
> User-Agent: curl/7.29.0.
> Host: 127.0.0.1:8000.
> Accept: */*.
> Content-Type: application/json.
> Content-Length: 75.
> .
> {"id": 1, "jsonrpc": "2.0", "method": "pl.list", "params": ["pipe_INVITE"]}
> ##
> T 127.0.0.1:8000 -> 127.0.0.1:32322 [AP]
> HTTP/1.1 400 Unknown pipe id pipe_INVITE.
> Sia: SIP/2.0/TCP 127.0.0.1:32322.
> Content-Type: application/json.
> Server: SIP Proxy (v1.1.0-360).
> Content-Length: 105.
> .
> {
> ."jsonrpc":."2.0",
> ."error":.{
> .."code":.400,
> .."message":."Unknown pipe id pipe_INVITE"
> .},
> ."id":.1
> }
> 
>
> Debug logs from kamailio:
> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 127.0.0.1
> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
> [core/tcp_main.c:999]: tcpconn_new(): on port 32304, type 2
> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
> [core/tcp_main.c:1309]: tcpconn_add(): hashes: 3634:3788:434, 41
> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa85ba0, 39, 2,
> 0x7f87c726b9e0), fd_no=29
> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa85ba0, 39, -1,
> 0x0) fd_no=30 called
> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
> [core/tcp_main.c:4196]: handle_tcpconn_ev(): sending to child, events 1
> Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
> [core/tcp_main.c:3878]: send2child(): selected tcp worker idx:0 proc:19
> pid:18996 for activity on [tcp:127.0.0.1:8000], 0x7f87c726b9e0
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/tcp_read.c:1759]: handle_io(): received n=8 con=0x7f87c726b9e0, fd=11
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/tcp_read.c:1560]: tcp_read_req(): content-length=75
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:610]: parse_msg(): SIP Request:
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:612]: parse_msg():  method:  
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:614]: parse_msg():  uri: 
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:616]: parse_msg():  version: 
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:185]: get_hdr_field(): content_length=75
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: topos [topos_mod.c:269]:
> tps_prepare_msg(): non sip request message
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:610]: parse_msg(): SIP Request:
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:612]: parse_msg():  method:  
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:614]: parse_msg():  uri: 
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:616]: parse_msg():  version: 
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:185]: get_hdr_field(): content_length=75
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/receive.c:246]: receive_msg(): --- received sip message - request -
> call-id: [] - cseq: []
> Jan 22 11:20:50 proxy1 kamailio[18996]: [328B blob data]
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:610]: parse_msg(): SIP Request:
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:612]: parse_msg():  method:  
> Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
> [core/parser/msg_parser.c:614]: parse_ms

Re: [SR-Users] pipelimit: inexistent pipe error logs

2020-01-22 Thread Nuno Ferreira

ly(): response with content-type: application/json
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: xhttp [xhttp_mod.c:439]:
xhttp_send_reply(): response with body: {
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: xhttp [xhttp_mod.c:441]:
xhttp_send_reply(): sending out response: 400 Unknown pipe id pipe_INVITE
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/msg_translator.c:162]: check_via_address(): (127.0.0.1, 127.0.0.1, 0)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: sl [sl_funcs.c:500]:
sl_run_callbacks(): execute callback for event type 1
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: siptrace [siptrace.c:1369]:
trace_sl_onreply_out(): trace off...
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/parser/parse_fline.c:249]: parse_first_line(): parse_first_line: bad
request first line
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/parser/parse_fline.c:251]: parse_first_line(): at line 0 char 20:
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/parser/parse_fline.c:257]: parse_first_line(): parsed so far:
HTTP/1.1 400 Unknown
Jan 22 11:20:50 proxy1 kamailio[18996]: ERROR: 
[core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad
message (offset: 20)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/parser/msg_parser.c:606]: parse_msg(): invalid message
Jan 22 11:20:50 proxy1 kamailio[18996]: [456B blob data]
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: topos [topos_mod.c:263]:
tps_prepare_msg(): outbuf buffer parsing failed!
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_main.c:2226]: tcpconn_send_put(): send from reader (18996 (19)),
reusing fd
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_main.c:2460]: tcpconn_do_send(): sending...
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_main.c:2494]: tcpconn_do_send(): after real write: c=
0x7f87c726b9e0 n=278 fd=11
Jan 22 11:20:50 proxy1 kamailio[18996]: [431B blob data]
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/xavp.c:495]:
xavp_destroy_list(): destroying xavp list (nil)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/receive.c:458]:
receive_msg(): cleaning up
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/io_wait.h:380]:
io_watch_add(): DBG: io_watch_add(0xaf1560, 11, 2, 0x7f87c726b9e0), fd_no=1
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_read.c:198]: tcp_emit_closed_event(): TCP closed event creation
triggered (reason: 0)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_read.c:206]: tcp_emit_closed_event(): no callback registering for
handling TCP closed event
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_read.c:318]: tcp_read_data(): EOF on 0x7f87c726b9e0, FD 11
([127.0.0.1]:32304 ->
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_read.c:319]: tcp_read_data(): -> [127.0.0.1]:8000)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_read.c:1527]: tcp_read_req(): EOF
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG:  [core/io_wait.h:602]:
io_watch_del(): DBG: io_watch_del (0xaf1560, 11, -1, 0x10) fd_no=2 called
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_read.c:1683]: release_tcpconn(): releasing con 0x7f87c726b9e0,
state -1, fd=11, id=4137 ([127.0.0.1]:32304 -> [127.0.0.1]:8000)
Jan 22 11:20:50 proxy1 kamailio[18996]: DEBUG: 
[core/tcp_read.c:1684]: release_tcpconn(): extra_data (nil)
Jan 22 11:20:50 proxy1 kamailio[19000]: DEBUG: 
[core/tcp_main.c:3308]: handle_tcp_child(): reader response= 7f87c726b9e0,
-1 from 0

Regards,

Nuno

On Wed, Jan 22, 2020 at 7:19 AM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> what version of kamailio are you using and what http version is curl
> using? Can you paste here the http request taken with ngrep from the
> network?
>
> Cheers,
> Daniel
> On 21.01.20 19:00, Nuno Ferreira wrote:
>
> Hi Daniel,
>
> There's no other traffic than the HTTP requests.
> This comment in src/core/parser/parse_fline.c 99 - 113, caugh my attention:
>
>  } else if (http_reply_parse != 0 &&
> (*tmp=='H' || *tmp=='h') &&
> /* 'HTTP/1.' */
> strncasecmp( tmp+1, HTTP_VERSION+1, HTTP_VERSION_LEN-1)==0 &&
> /* [0|1] */
> ((*(tmp+HTTP_VERSION_LEN)=='0') || (*(tmp+HTTP_VERSION_LEN)=='1&

Re: [SR-Users] pipelimit: inexistent pipe error logs

2020-01-21 Thread Nuno Ferreira

Hi Daniel,

There's no other traffic than the HTTP requests.
This comment in src/core/parser/parse_fline.c 99 - 113, caugh my attention:

 } else if (http_reply_parse != 0 &&
(*tmp=='H' || *tmp=='h') &&
/* 'HTTP/1.' */
strncasecmp( tmp+1, HTTP_VERSION+1, HTTP_VERSION_LEN-1)==0 &&
/* [0|1] */
((*(tmp+HTTP_VERSION_LEN)=='0') || (*(tmp+HTTP_VERSION_LEN)=='1')) &&
(*(tmp+HTTP_VERSION_LEN+1)==' ')  ){


* /* ugly hack to be able to route http replies * Note: - the http reply
must have a via *   - the message is marked as SIP_REPLY (ugly)*
*/
fl->type=SIP_REPLY;
fl->flags|=FLINE_FLAG_PROTO_HTTP;
fl->u.reply.version.len=HTTP_VERSION_LEN+1 /*include last digit*/;
tmp=buffer+HTTP_VERSION_LEN+1 /* last digit */;

and later in error1:
error1:
fl->type=SIP_INVALID;
LOG((core, core_cfg, corelog), "parse_first_line: bad message (offset:
%d)\n", offset);
/* skip  line */
nl=eat_line(buffer,len);
return nl;

So that log line can be conditional if FLINE_FLAG_PROTO_HTTP is not part
of fl->flags.
I just don't know where the "[466B blob data]" is getting printed

On Tue, Jan 21, 2020 at 4:30 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> as I said, watch the traffic on port 8000 with ngrep or some other network
> sniffer to see what data comes there. You can also start kamailio with
> debug=3 in config, more debug logs should be printed to syslog to get the
> context of what is processed at that time.
>
> Cheers,
> Daniel
> On 21.01.20 16:31, Nuno Ferreira wrote:
>
> Hi Daniel,
>
> Thanks for your feedback.
> I have a dedicated listen directive for JSONRPC
> listen = 127.0.0.1:8000
>
> and then an event_route for it:
> event_route[xhttp:request] {
> if ($Rp != 8000) {
> xhttp_reply("403", "Forbidden", "text/html",
> "Forbidden");
> exit;
> }
> if ($hu =~ "^/RPC") {
> jsonrpc_dispatch();
> } else {
> xhttp_reply("200", "OK", "text/html", "Wrong URL
> $hu");
> }
> return;
> }
>
> So, I'm already doing HTTP traffic only in port 8000.
> The interesting part is that if I use kamcmd pl.list pipe_INVITE, only the
> first log line is printed. Using curl, I see the other 2 logs all the time.
>
> Thank you
>
> On Tue, Jan 21, 2020 at 2:45 PM Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> can you want the traffic on port 8000 and see if there is no "unexpected"
>> traffic there? There should be no error message for parsing the first line
>> of an HTTP request.
>>
>> The error message related the missing pipe can be made debug.
>>
>> Cheers,
>> Daniel
>> On 21.01.20 15:34, Nuno Ferreira wrote:
>>
>> Hi all,
>>
>> I'm using pipelimit with the "clean_unused" option to get rid of pipes
>> that are not used for quite some time. At the same time we are monitoring
>> pipelimit with a jsonrpc call similar to:
>>
>> # curl --header 'Content-Type: application/json' --data-binary '{"id": 1,
>> "jsonrpc": "2.0", "method": "pl.list", "params": ["pipe_INVITE"]'
>> http://127.0.0.1:8000/RPC
>>
>> Reply:
>> {
>>"jsonrpc": "2.0",
>>"error": {
>>   "code": 400,
>>   "message": "Unknown pipe id pipe_INVITE"
>>},
>>"id": 1
>> }
>>
>> The above reply is valid because the pipe_INVITE was not loaded yet, but
>> the request makes kamailio to log the following log messages:
>>
>> Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: pipelimit [pl_ht.c:519]:
>> rpc_pl_list(): no pipe: pipe_INVITE
>> Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: 
>> [core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad
>> message (offset: 20)
>> Jan 20 11:21:48 proxy1 kamailio[24474]: [466B blob data]
>>
>> Since the monitoring system does periodic requests, those log lines get a
>> bit annoying and fill the log with ERROR messages that aren't really errors.
>>
>> IMHO the first log line should be converted to DEBUG instead of ERROR,
>> but I have some doubts about the one
>> from parse_fline.c:262. parse_first_line() is used to process both SIP and
>> HTTP. It makes sense to log ERROR if SIP but not in the case of HTTP...
>> Regarding the "[466B blob data]" I really don't know from where it

Re: [SR-Users] pipelimit: inexistent pipe error logs

2020-01-21 Thread Nuno Ferreira

Hi Daniel,

Thanks for your feedback.
I have a dedicated listen directive for JSONRPC
listen = 127.0.0.1:8000

and then an event_route for it:
event_route[xhttp:request] {
if ($Rp != 8000) {
xhttp_reply("403", "Forbidden", "text/html",
"Forbidden");
exit;
}
if ($hu =~ "^/RPC") {
jsonrpc_dispatch();
} else {
xhttp_reply("200", "OK", "text/html", "Wrong URL
$hu");
}
return;
}

So, I'm already doing HTTP traffic only in port 8000.
The interesting part is that if I use kamcmd pl.list pipe_INVITE, only the
first log line is printed. Using curl, I see the other 2 logs all the time.

Thank you

On Tue, Jan 21, 2020 at 2:45 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> can you want the traffic on port 8000 and see if there is no "unexpected"
> traffic there? There should be no error message for parsing the first line
> of an HTTP request.
>
> The error message related the missing pipe can be made debug.
>
> Cheers,
> Daniel
> On 21.01.20 15:34, Nuno Ferreira wrote:
>
> Hi all,
>
> I'm using pipelimit with the "clean_unused" option to get rid of pipes
> that are not used for quite some time. At the same time we are monitoring
> pipelimit with a jsonrpc call similar to:
>
> # curl --header 'Content-Type: application/json' --data-binary '{"id": 1,
> "jsonrpc": "2.0", "method": "pl.list", "params": ["pipe_INVITE"]'
> http://127.0.0.1:8000/RPC
>
> Reply:
> {
>"jsonrpc": "2.0",
>"error": {
>   "code": 400,
>   "message": "Unknown pipe id pipe_INVITE"
>},
>"id": 1
> }
>
> The above reply is valid because the pipe_INVITE was not loaded yet, but
> the request makes kamailio to log the following log messages:
>
> Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: pipelimit [pl_ht.c:519]:
> rpc_pl_list(): no pipe: pipe_INVITE
> Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: 
> [core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad
> message (offset: 20)
> Jan 20 11:21:48 proxy1 kamailio[24474]: [466B blob data]
>
> Since the monitoring system does periodic requests, those log lines get a
> bit annoying and fill the log with ERROR messages that aren't really errors.
>
> IMHO the first log line should be converted to DEBUG instead of ERROR, but
> I have some doubts about the one from parse_fline.c:262. parse_first_line()
> is used to process both SIP and HTTP. It makes sense to log ERROR if SIP
> but not in the case of HTTP...
> Regarding the "[466B blob data]" I really don't know from where it's
> coming from.
> I can submit a PR, but I would like to have first some feedback from you.
>
> Thank you,
>
> Nuno
>
>
> *Confidentiality Notice: The information contained in this e-mail and any
> attachments may be confidential. If you are not an intended recipient, you
> are hereby notified that any dissemination, distribution or copying of this
> e-mail is strictly prohibited. If you have received this e-mail in error,
> please notify the sender and permanently delete the e-mail and any
> attachments immediately. You should not retain, copy or use this e-mail or
> any attachment for any purpose, nor disclose all or any part of the
> contents to any other person. Thank you.*
>
> ___
> 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 Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
> Kamailio World Conference - April 27-29, 2020, in Berlin -- 
> www.kamailioworld.com
>
>

-- 
*Confidentiality Notice: The information contained in this e-mail and any

attachments may be confidential. If you are not an intended recipient, you

are hereby notified that any dissemination, distribution or copying of this

e-mail is strictly prohibited. If you have received this e-mail in error,

please notify the sender and permanently delete the e-mail and any

attachments immediately. You should not retain, copy or use this e-mail or

any attachment for any purpose, nor disclose all or any part of the

contents to any other person. Thank you.*
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] pipelimit: inexistent pipe error logs

2020-01-21 Thread Nuno Ferreira

Hi all,

I'm using pipelimit with the "clean_unused" option to get rid of pipes that
are not used for quite some time. At the same time we are monitoring
pipelimit with a jsonrpc call similar to:

# curl --header 'Content-Type: application/json' --data-binary '{"id": 1,
"jsonrpc": "2.0", "method": "pl.list", "params": ["pipe_INVITE"]'
http://127.0.0.1:8000/RPC

Reply:
{
   "jsonrpc": "2.0",
   "error": {
  "code": 400,
  "message": "Unknown pipe id pipe_INVITE"
   },
   "id": 1
}

The above reply is valid because the pipe_INVITE was not loaded yet, but
the request makes kamailio to log the following log messages:

Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: pipelimit [pl_ht.c:519]:
rpc_pl_list(): no pipe: pipe_INVITE
Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: 
[core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad
message (offset: 20)
Jan 20 11:21:48 proxy1 kamailio[24474]: [466B blob data]

Since the monitoring system does periodic requests, those log lines get a
bit annoying and fill the log with ERROR messages that aren't really errors.

IMHO the first log line should be converted to DEBUG instead of ERROR, but
I have some doubts about the one from parse_fline.c:262. parse_first_line()
is used to process both SIP and HTTP. It makes sense to log ERROR if SIP
but not in the case of HTTP...
Regarding the "[466B blob data]" I really don't know from where it's coming
from.
I can submit a PR, but I would like to have first some feedback from you.

Thank you,

Nuno

-- 
*Confidentiality Notice: The information contained in this e-mail and any

attachments may be confidential. If you are not an intended recipient, you

are hereby notified that any dissemination, distribution or copying of this

e-mail is strictly prohibited. If you have received this e-mail in error,

please notify the sender and permanently delete the e-mail and any

attachments immediately. You should not retain, copy or use this e-mail or

any attachment for any purpose, nor disclose all or any part of the

contents to any other person. Thank you.*
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio-5.2.1 - Issues in NDB_MONGODB module initialisation

2019-04-22 Thread Nuno Ferreira

Hello,

I've submitted https://github.com/kamailio/kamailio/pull/1932 to address
this problem.
I believe this is unnoticed if db_mongodb is already being used by some
module because mongoc driver would be initialized for each process.
The patch was tested in our testbed and it's working fine now.

Regards

On Thu, Apr 18, 2019 at 3:14 PM José Seabra  wrote:

> Hello there,
> I have NDB_MONGODB loaded in kamailio with following configurations:
>
>
> *loadmodule "ndb_mongodb"*
> *modparam("ndb_mongodb", "server",
> "name=mgs1;uri='mongodb://mongodbserver:27017/proxyregistrar'")*
>
>
> Kamailio breaks up on start up and prints the following messages:
>
> *Apr 18 13:16:10.464 proxy-registrar[-]: DEBUG: 
> [core/modparam.c:83]: set_mod_param_regex(): 'ndb_mongodb' matches module
> 'ndb_mongodb'*
> *Apr 18 13:16:10.464 proxy-registrar[-]: DEBUG: 
> [core/sr_module.c:711]: find_param_export(): found  in module
> ndb_mongodb [/usr/lib64/kamailio/modules/ndb_mongodb.so]*
> *Apr 18 13:16:10.464 proxy-registrar[-]: DEBUG: 
> [core/modparam.c:99]: set_mod_param_regex(): found  in module
> ndb_mongodb [/usr/lib64/kamailio/modules/ndb_mongodb.so]*
> *Apr 18 13:16:10.464 proxy-registrar[-]: DEBUG: ndb_mongodb
> [mongodb_client.c:155]: mongodbc_add_server(): added
> server[mgs1]=mongodb://10.225.121.12:27017/proxyregistrar
> *
>
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: DEBUG: 
> [core/sr_module.c:942]: init_mod_child(): idx 21 rank 8: ndb_mongodb [tcp
> receiver (generic) child=3]*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: CRITICAL: 
> [core/pass_fd.c:277]: receive_fd(): EOF on 23*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: ALERT:  [main.c:739]:
> handle_sigs(): child process 3181 exited by a signal 11*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: ALERT:  [main.c:742]:
> handle_sigs(): core was generated*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: DEBUG: 
> [core/tcp_main.c:3513]: handle_ser_child(): dead child 16, pid 3181
> (shutting down?)*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: INFO:  [main.c:764]:
> handle_sigs(): terminating due to SIGCHLD*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: DEBUG:  [core/io_wait.h:602]:
> io_watch_del(): DBG: io_watch_del (0xa6d0e0, 23, -1, 0x0) fd_no=23 called*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: DEBUG:  [main.c:766]:
> handle_sigs(): terminating due to SIGCHLD*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: INFO:  [main.c:819]:
> sig_usr(): signal 15 received*
> *123: INFO:  [main.c:819]: sig_usr(): signal 15 received*
> *123: INFO:  [main.c:819]: sig_usr(): signal 15 received*
> *123: INFO:  [main.c:819]: sig_usr(): signal 15 received*
> *123: INFO:  [main.c:819]: sig_usr(): signal 15 received*
> *1a7311e30a6793da-3165@10.225.121.93
> <1a7311e30a6793da-3165@10.225.121.93>: DEBUG: ndb_mongodb
> [ndb_mongodb_mod.c:128]: mod_destroy(): cleaning up *
>
>
> Core dump back trace output:
>
> *(gdb) bt full*
> *#0  0x7f3daa134f93 in _mongoc_client_new_from_uri () from
> /lib64/libmongoc-1.0.so.0*
> *No symbol table info available.*
> *#1  0x7f3daa156553 in mongoc_uri_get_ssl () from
> /lib64/libmongoc-1.0.so.0*
> *No symbol table info available.*
> *#2  0x7f3daa134f88 in _mongoc_client_new_from_uri () from
> /lib64/libmongoc-1.0.so.0*
> *No symbol table info available.*
> *#3  0x7f3daa135029 in mongoc_client_new () from
> /lib64/libmongoc-1.0.so.0*
> *No symbol table info available.*
> *#4  0x7f3daae6d75f in mongodbc_init () at mongodb_client.c:63*
> *rsrv = 0x7f3db0f86728*
> *__FUNCTION__ = "mongodbc_init"*
> *#5  0x7f3daae73c46 in child_init (rank=3) at ndb_mongodb_mod.c:113*
> *__FUNCTION__ = "child_init"*
> *#6  0x005470d7 in init_mod_child (m=0x7f3db0f85e88, rank=3) at
> core/sr_module.c:846*
> *__FUNCTION__ = "init_mod_child"*
> *#7  0x005474b6 in init_child (rank=3) at core/sr_module.c:874*
> *ret = 32573*
> *#8  0x004b3840 in fork_process (child_id=3, desc=0x7ffecc20c7f0
> "udp receiver child=2 sock=10.225.121.93:5060 ",
> make_sock=1) at core/pt.c:341*
> *pid = 0*
> *child_process_no = 3*
> *ret = -1*
> *new_seed1 = 1273263324*
> *new_seed2 = 1531871627*
> *sockfd = {14, 15}*
> *__FUNCTION__ = "fork_process"*
> *#9  0x00424b9b in main_loop () at main.c:1631*
> *i = 2*
> *pid = 3807*
> *si = 0x7f3db123a988*
> *si_desc = "udp receiver child=2 sock=10.225.121.93:5060
> \000\177\000\000P\310
> \314\376\177\000\000\000e|\261=\177\000\000 \313
> \314\376\177\000\000\063\225{\000\000

Re: [SR-Users] Kamailio OPTIONS Round-Trip

2019-02-04 Thread Nuno Ferreira

Hey there,

Just trying to see if there was any conclusion on this topic...

Thanks

On Wed, Jan 16, 2019 at 3:18 PM Sergiu Pojoga  wrote:

> After re-reading the original question, it appears that it isn't about
> Asterisk at all, it was a simple reference to it, the actual question being
> how to get RTT in Kamailios's usloc.
>
> Apologies for the confusion. Let's carry on with the topic, lol.
>
> Cheers,
> --Sergiu
>
> On Wed, Jan 16, 2019 at 9:55 AM Sergiu Pojoga  wrote:
>
>> Correct me if I'm wrong, but wasn't the original poster looking for
>> Asterisk (behind Kamailio) to show the round-trip of its peers based on
>> qualify OPTIONS requests that Asterisk sends out to the peer?
>>
>> If so, I'm curious what is the impediment not to accept the previously
>> suggested sip PATH approach? Aside from elegance and simplicity to
>> implement, it isn't even subject to the UDP limitation you've brought up.
>>
>> Not that the topic of usrloc qualify isn't of interest, but it just feels
>> like we are drifting into another topic, although somehow related to the
>> original one.
>>
>> Best regards,
>> --Sergiu
>>
>> On Wed, Jan 16, 2019 at 7:59 AM Nuno Ferreira  wrote:
>>
>>> Hello Daniel,
>>>
>>> I'm reading this thread with some interests. We were planning to use
>>> nat_traversal module to do keepalive, but we came across the UDP only
>>> limitation. In our use case, we wanted to offload the registrar from doing
>>> keepalive. Of course, that's an option, but it has yet another limitation
>>> when having active/active registrar servers using dmq_usrloc. If one of the
>>> registrars goes down which server will be in charge of doing keepalive for
>>> the contacts previously registered on the faulty registrar? That was one of
>>> the reasons for us to seek doing keeplive on the edge with nat_traversal,
>>> but again it's only valid for UDP.
>>> If usrloc/dmq_usrloc provides some automatic election mechanism to
>>> keepalive orphan AORs, I would prefer going with it for the task. Another
>>> benefit like I read from your words is that we would automatically have
>>> available latency/rtt attached to each contact and that is a big plus.
>>>
>>> Regards,
>>>
>>> Nuno
>>>
>>> On Wed, Jan 16, 2019 at 12:26 PM Daniel-Constantin Mierla <
>>> mico...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> maybe we can just add this feature to the usrloc module -- right now
>>>> the nat keepalive is done from nathelper module, which queries usrloc
>>>> module to retrieve the list of the contacts to send OPTIONS to. Of course,
>>>> the nathelper has the other variant witj 4-bytes pings, but I expect not
>>>> many are using it these days.
>>>>
>>>> Furthermore, because the nathelper has some options to forge the source
>>>> ip address as well as willing to be lightweight, it sends the packets
>>>> directly, no relying on tm module.
>>>>
>>>> However, it seems that it is an increase interest in having more
>>>> feedback based on these keepalives. Including the ability to do mirroring
>>>> for sipcapture (a feature request being open in the tracker). Other request
>>>> in the past was to send OPTIONS also for non-UDP contacts, nathelper does
>>>> it only for UDP.
>>>>
>>>> So we can consider adding a transaction based keepalive layer, which of
>>>> course might take a bit more resources that current nathelper
>>>> implementation, but can bring extra benefits. I think we can leave
>>>> nathelper as it is and add this feature directly in the usrloc module,
>>>> avoiding to pass data between modules, but also because we have to
>>>> set/updates some fields in the contract structure (like this round trip
>>>> time).
>>>>
>>>> There are other modules that do keepalive, some mentioned dispatcher,
>>>> there is a dedicated one named keepalive, and, afaik, also nat_traversal
>>>> can do it. I am listing them so others can assert where it would be better
>>>> to add the new feature -- as said, I would do it in usrloc, but I am open
>>>> for other suggestions as well (eventually accompanied with a pull request).
>>>>
>>>> Cheers,
>>>> Daniel
>>>> On 15.01.19 21:12, Julien Chavanton wrote:
>>>>
>>>> Depending o

Re: [SR-Users] Kamailio OPTIONS Round-Trip

2019-01-16 Thread Nuno Ferreira

Hello Daniel,

I'm reading this thread with some interests. We were planning to use
nat_traversal module to do keepalive, but we came across the UDP only
limitation. In our use case, we wanted to offload the registrar from doing
keepalive. Of course, that's an option, but it has yet another limitation
when having active/active registrar servers using dmq_usrloc. If one of the
registrars goes down which server will be in charge of doing keepalive for
the contacts previously registered on the faulty registrar? That was one of
the reasons for us to seek doing keeplive on the edge with nat_traversal,
but again it's only valid for UDP.
If usrloc/dmq_usrloc provides some automatic election mechanism to
keepalive orphan AORs, I would prefer going with it for the task. Another
benefit like I read from your words is that we would automatically have
available latency/rtt attached to each contact and that is a big plus.

Regards,

Nuno

On Wed, Jan 16, 2019 at 12:26 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> maybe we can just add this feature to the usrloc module -- right now the
> nat keepalive is done from nathelper module, which queries usrloc module to
> retrieve the list of the contacts to send OPTIONS to. Of course, the
> nathelper has the other variant witj 4-bytes pings, but I expect not many
> are using it these days.
>
> Furthermore, because the nathelper has some options to forge the source ip
> address as well as willing to be lightweight, it sends the packets
> directly, no relying on tm module.
>
> However, it seems that it is an increase interest in having more feedback
> based on these keepalives. Including the ability to do mirroring for
> sipcapture (a feature request being open in the tracker). Other request in
> the past was to send OPTIONS also for non-UDP contacts, nathelper does it
> only for UDP.
>
> So we can consider adding a transaction based keepalive layer, which of
> course might take a bit more resources that current nathelper
> implementation, but can bring extra benefits. I think we can leave
> nathelper as it is and add this feature directly in the usrloc module,
> avoiding to pass data between modules, but also because we have to
> set/updates some fields in the contract structure (like this round trip
> time).
>
> There are other modules that do keepalive, some mentioned dispatcher,
> there is a dedicated one named keepalive, and, afaik, also nat_traversal
> can do it. I am listing them so others can assert where it would be better
> to add the new feature -- as said, I would do it in usrloc, but I am open
> for other suggestions as well (eventually accompanied with a pull request).
>
> Cheers,
> Daniel
> On 15.01.19 21:12, Julien Chavanton wrote:
>
> Depending on the use case, you could use the dispatcher module latency
> stats.
>
>
> https://kamailio.org/docs/modules/devel/modules/dispatcher.html#dispatcher.p.ds_ping_latency_stats
>
> Regards
>
> On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba  wrote:
>
>> On Sun, Jan 13, 2019 at 10:08:31PM +0300, Soltanici Ilie wrote:
>> > With Asterisk, we are able to get some peer round-trip connection
>> statistic by setting qualify=yes for the specified peer.
>> > It sends periodic OPTIONS to the peer and calculates the time round
>> trip time.
>> > It's something like - "Status: OK (30 ms)".
>> > Is there any way to achieve this in Kamailio by using
>> nathelper??module, or any other?
>>
>> I think the only way to do this is to make this yourself (tm). In your
>> favorite scripting language, query the locations and fire OPTIONS and
>> measure the time for a response (if any) on basis of the "random" callid
>> you create. If you route these requests through kamailio you will
>> prevent any NAT problems or connection with TCP endpoints.
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> ___
> 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 - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
> Washington, DC, USA -- www.asipto.com
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
&

[SR-Users] siptrace: methods blacklist modparam

Re: [SR-Users] Parallel forking - first responder wins

Re: [SR-Users] [ot] lightweight sip app for auto-answering with play file and echo mode

Re: [SR-Users] pipelimit: inexistent pipe error logs

Re: [SR-Users] pipelimit: inexistent pipe error logs

Re: [SR-Users] pipelimit: inexistent pipe error logs

Re: [SR-Users] pipelimit: inexistent pipe error logs

Re: [SR-Users] pipelimit: inexistent pipe error logs

[SR-Users] pipelimit: inexistent pipe error logs

Re: [SR-Users] Kamailio-5.2.1 - Issues in NDB_MONGODB module initialisation

Re: [SR-Users] Kamailio OPTIONS Round-Trip

Re: [SR-Users] Kamailio OPTIONS Round-Trip

12 matches

Site Navigation

Mail list logo

Footer information