Re: [SR-Users] Doing a quick test with http_async_client module from master branch

[Federico Cabiddu]

Hi Daniel,
I tested the latest master branch with different scenarios: successful
replies with/without suspending the transaction, error cases (connection
refused) and timeouts.
Look fine for now, I will try to setup some longer tests to check on the
long run.
Thank you :)

Cheers,

Federico

On Wed, Dec 6, 2017 at 2:18 PM, Daniel-Constantin Mierla 
wrote:

> Thanks Federico!
>
> Daniel
>
> On 06.12.17 12:58, Federico Cabiddu wrote:
>
> I'll do some test tonight and report.
>
> Cheers,
>
> Federico
>
> On 6 Dec 2017 10:25 am, "Daniel-Constantin Mierla" 
> wrote:
>
>> Hello,
>>
>> anyone around here that can do a quick test with http_async_module? I
>> don't have a testbed for it right now and I would spend the time on
>> other resources if someone here can run some tests with
>> http_async_client module from master branch. I did a bit of internal
>> refactoring in order to be able to export the function to kemi interface
>> -- nothing radical, but it would be good to know it didn't break anything.
>>
>> Cheers,
>> Daniel
>>
>> --
>> Daniel-Constantin Mierla
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Kamailio Advanced Training - www.asipto.com
>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - 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] Forwarding Registration to Asterisk

[Fred Posner]

On 12/6/17 6:48 PM, Wilkins, Steve wrote:

Hello Matt,

I have attempted an outbound_proxy, but when I do this I get the following 
response from Asterisk -

[Dec  6 23:42:51] VERBOSE[14500][C-0001] pbx.c: Executing [20001@from-internal:5] 
Dial("PJSIP/kamailio-", "PJSIP/20001,30,t") in new stack
[Dec  6 23:42:51] VERBOSE[14500][C-0001] app_dial.c: Called PJSIP/20001
[Dec  6 23:42:51] VERBOSE[14363] res_rtp_asterisk.c: DTLS ECDH initialized 
(automatic), faster PFS enabled
[Dec  6 23:42:51] VERBOSE[14363] res_rtp_asterisk.c: DTLS ECDH initialized 
(automatic), faster PFS enabled
[Dec  6 23:42:51] VERBOSE[14500][C-0001] app_dial.c: Everyone is 
busy/congested at this time (1:0/0/1)
[Dec  6 23:42:51] VERBOSE[14500][C-0001] pbx.c: Executing [20001@from-internal:6] 
Hangup("PJSIP/kamailio-", "") in new stack

I did verify that 20001 is registered and that I have the correct Kamailio 
Server IP in my outbound_proxy.

Thank you,
-Steve



With this list, probably best to through a SIP capture from the Asterisk 
and from the Kamailio to see where 4xx is coming from.


--fred

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

Re: [SR-Users] Forwarding Registration to Asterisk

[Wilkins, Steve]

Hello Matt,

I have attempted an outbound_proxy, but when I do this I get the following 
response from Asterisk -

[Dec  6 23:42:51] VERBOSE[14500][C-0001] pbx.c: Executing 
[20001@from-internal:5] Dial("PJSIP/kamailio-", "PJSIP/20001,30,t") in 
new stack
[Dec  6 23:42:51] VERBOSE[14500][C-0001] app_dial.c: Called PJSIP/20001
[Dec  6 23:42:51] VERBOSE[14363] res_rtp_asterisk.c: DTLS ECDH initialized 
(automatic), faster PFS enabled
[Dec  6 23:42:51] VERBOSE[14363] res_rtp_asterisk.c: DTLS ECDH initialized 
(automatic), faster PFS enabled
[Dec  6 23:42:51] VERBOSE[14500][C-0001] app_dial.c: Everyone is 
busy/congested at this time (1:0/0/1)
[Dec  6 23:42:51] VERBOSE[14500][C-0001] pbx.c: Executing 
[20001@from-internal:6] Hangup("PJSIP/kamailio-", "") in new stack

I did verify that 20001 is registered and that I have the correct Kamailio 
Server IP in my outbound_proxy.

Thank you,
-Steve



-Original Message-
From: sr-users [mailto:sr-users-boun...@lists.kamailio.org] On Behalf Of Alex 
Balashov
Sent: Wednesday, December 6, 2017 6:33 PM
To: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Forwarding Registration to Asterisk

Matt,

On Wed, Dec 06, 2017 at 04:10:21PM -0600, Matthew Jordan wrote:

> 1. Proxy REGISTER requests through to Asterisk, allowing Asterisk to
> (believe) it is the Registrar
> 
> In this particular case, you'll need a PJSIP endpoint for each SIP 
> endpoint that is registering. Identification will need to be done 
> based either on the From user or by a custom header that Kamailio can 
> add and pass off to Asterisk. You will need to use the outbound_proxy 
> options so that outbound requests go through Kamailio as opposed to 
> directly to the registered endpoints. The benefit of this is that it 
> gives Asterisk all of the information it needs, all of the time. The 
> downside is that you now have potentially many services acting as a 
> Registrar, and you have a lot of traffic flying around that you don't need or 
> want.

Can't a lot of the complications here be obviated through Path?

--
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] Forwarding Registration to Asterisk

[Alex Balashov]

Matt,

On Wed, Dec 06, 2017 at 04:10:21PM -0600, Matthew Jordan wrote:

> 1. Proxy REGISTER requests through to Asterisk, allowing Asterisk to
> (believe) it is the Registrar
> 
> In this particular case, you'll need a PJSIP endpoint for each SIP endpoint
> that is registering. Identification will need to be done based either on
> the From user or by a custom header that Kamailio can add and pass off to
> Asterisk. You will need to use the outbound_proxy options so that outbound
> requests go through Kamailio as opposed to directly to the registered
> endpoints. The benefit of this is that it gives Asterisk all of the
> information it needs, all of the time. The downside is that you now have
> potentially many services acting as a Registrar, and you have a lot of
> traffic flying around that you don't need or want.

Can't a lot of the complications here be obviated through Path?

-- 
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] Forwarding Registration to Asterisk

[Ivailo Dobrev]

Hello, I saw next emails but prefer answer directly here. Comments inline.

Regards,

Ivo

On 12/06/2017 08:33 PM, Wilkins, Steve wrote:


Hello All,

*Problem*: My main issue is that when I “REGISTER” a client via 
Kamailio, and I attempt to “Dial” a different endpoint within an 
Asterisk Dial Plan, Asterisk throws an error stating that the endpoint 
(the number I am dialing via “Dial”) is not registered or reachable. 
However, commands like “Playback” do work correctly for the client I 
“REGISTERED” via Kamailio.


   E.g. I register client 10001 in Kamailio, I then register another 
client 10002 in Kamalio; both 10001 and 10002 can exercise an Asterisk 
Dial Plan which will play videos/audio (No Problem).  But, now I want 
10001 to Call (Dial) 10002; it is at this point that Asterisk throws 
the error “10002 is not registered or reachable”.


I have tried many of the suggestion on many different help boards 
(several times) but I am still unable to forward a registration from 
Kamailio to Asterisk.



So if your statement below is true your problems are replies not request ?


With my current Kamailio configuration (I do use dispatching), I see , 
via tcpdump, Asterisk receiving a “REGISTER” request, and Asterisk 
sends back the “unauthorized” as expected, however, Kamailio does not 
re-send the “REGISTER” as is customary.  I am not sure of the next 
step to take, but I feel I have a couple of options.


At this point you can treat REGISTER as any other request in term of 
Kamailio configuration. So you dispatch it, request leaves Kamailio but 
reply is not forwarded to the endpoint. Most probably you do not have 
on_reply route handling register replies from Asterisk. On 200 OK you 
can save() location before forwarding register reply to SIP endpoint.
    - Note 1. Requested architecture/feature is targeted more to SBC 
but not to a SIP proxy. At that point Kamailio is upstream registrar and 
Asterisk is registrar and subscriber DB.
    - Note 2. This can be made w/ Kamailio but more than just 
forwarding requests need to be made. There are other cases (transport, 
nat, conatct ...) that need to be addressed.


I think it is well described here : 
http://www.frafos.com/uploa/html/29__Registration_Caching_and_Handling.html?highlight=register


  * I can continue to try and figure out why Kamailio is not sending
the second “REGISTER” (*I have not yet been able to figure this
out*).
  * Tell Asterisk to not require authentication.  (*I am using pjsip
and do not know how to not require authentication in Asterisk when
the request is from Kamailio*).

This is more common approach, Integrate Kamailio and Asterisk via DB and 
use Kamailio as registrar.


I have put a lot of time into this one, and I am at a sticking point. 
 Any help or suggestions would be very much appreciated.


Thank you,



___
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] Forwarding Registration to Asterisk

[Matthew Jordan]

On Wed, Dec 6, 2017 at 2:16 PM, Wilkins, Steve  wrote:

> Hello and thank you for the reply.
>
> I did try something like this before with no luck => Dial(PJSIP/
> 20001@129.4.1.32) where 129.4.1.32 is the IP Address of Kamailio.
> When I attempt this, I get the error => Endpoint '20001': Could not create
> dialog to invalid URI '20001'.  Is endpoint registered and reachable?
> And 20001 is registered in 129.4.1.32.
>
> Thank you,
>
> -Original Message-
> From: sr-users [mailto:sr-users-boun...@lists.kamailio.org] On Behalf Of
> Fred Posner
> Sent: Wednesday, December 6, 2017 2:09 PM
> To: sr-users@lists.kamailio.org
> Subject: Re: [SR-Users] Forwarding Registration to Asterisk
>
> You could also just use the Kamailio address in your Dial command...
>
> Dial(SIP/user@kamailio)
>
> This will be beneficial if you will be running multiple asterisk servers
> using a base registered on Kamailio.
>
> Of course, there's many ways to go about this...
>
>
As Fred said, there's a lot of ways you can approach this, all of which
have trade-offs. You can go pretty deep in depth with any one of these
approaches, so I'll just allude to some of your options.

It's good to keep in mind that there are three ways you can map an inbound
request to an endpoint:

1) By From username. This matches to an AoR, which is associated to an
endpoint
2) By IP address/DNS hostname, using an identify section associated to an
endpoint
3) By header, which also uses an identify section

When using registration, this will create a Contact that is associated to
an AoR. That AoR can be associated to an Endpoint. When dialing, Asterisk
will look up the Contacts on the AoR that is associated to an Endpoint and
send INVITE requests to all of those Contacts.

You can, of course, simply set up a static Contact for your Kamailio proxy
(represented with an Endpoint/AoR0 and let it handle all of the subsequent
routing decisions. But that gets into some various options you have.

Thus, some options:

1. Proxy REGISTER requests through to Asterisk, allowing Asterisk to
(believe) it is the Registrar

In this particular case, you'll need a PJSIP endpoint for each SIP endpoint
that is registering. Identification will need to be done based either on
the From user or by a custom header that Kamailio can add and pass off to
Asterisk. You will need to use the outbound_proxy options so that outbound
requests go through Kamailio as opposed to directly to the registered
endpoints. The benefit of this is that it gives Asterisk all of the
information it needs, all of the time. The downside is that you now have
potentially many services acting as a Registrar, and you have a lot of
traffic flying around that you don't need or want.

2. Create an endpoint in Asterisk that represents your pool of Proxies

In this case, you would have Kamailio act as the Registrar. If it
determines that it needs Asterisk, it would route the INVITE request down
to Asterisk. Asterisk would match based on IP address or Header, and would
have a single endpoint representing inbound requests from the pool of
proxies. You could re-use this same endpoint for outbound requests, or have
several different outbound endpoints with different codec capabilities (if
needed), typically matching different phone profiles. You would most likely
want a static contact set to the DNS name of your proxies, and Dial using
SIP URI over that endpoint. The upside of this is that it keeps Asterisk
simple and ignorant of all of the phones/registrations; the downside is
that BLF handling and call state becomes problematic (as you don't have
endpoints to match them to any longer!)

3. Create endpoints for all of the phones, but have them all have a Contact
that is Kamailio

This combines both #1 and #2, giving you the best (and maybe the worst) of
both worlds. You will need an AoR with a static contact that maps to the
Kamailio proxies, so that all outbound requests flow through them. Inbound
requests can be matched either by From user or by a custom Header,
depending on how much flexibility you need. Because you have endpoints for
all your phones still, your extension state/device state handling will work
better. Handling subscriptions can be done either at Kamailio or at
Asterisk, so long as Asterisk is configured to PUBLISH state information to
the Kamailio proxies.


Note that there are many more options. PJSIP in Asterisk is a toolkit, and
there isn't a right way to do this - merely ways that balance different
system needs. For what it's worth, depending on the inbound traffic, I've
used both #2 and #3. I tend to shy away from #1, as I like to keep each
service having a specific purpose, and Kamailio acts as a good registrar in
a larger system.

Matt

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
___
Kamailio (SER) - Users Mailing List

Re: [SR-Users] IMS with online Charging system

[Ivailo Dobrev]

I am pretty sure that CGRates team was made some development related to 
diameter charging interface.


On 12/06/2017 07:37 PM, Amar Tinawi wrote:

Hello all
Is there any open souce ocs can be integrated with kamailio IMS ?

Is it possible to integrate with CGrates ?


___
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] Forwarding Registration to Asterisk

[Fred Posner]

You could also just use the Kamailio address in your Dial command...

Dial(SIP/user@kamailio)

This will be beneficial if you will be running multiple asterisk servers 
using a base registered on Kamailio.


Of course, there's many ways to go about this...

--fred

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

[SR-Users] Forwarding Registration to Asterisk

[Wilkins, Steve]

Hello All,

Problem: My main issue is that when I "REGISTER" a client via Kamailio, and I 
attempt to "Dial" a different endpoint within an Asterisk Dial Plan, Asterisk 
throws an error stating that the endpoint (the number I am dialing via "Dial") 
is not registered or reachable. However, commands like "Playback" do work 
correctly for the client I "REGISTERED" via Kamailio.
   E.g. I register client 10001 in Kamailio, I then register another client 
10002 in Kamalio; both 10001 and 10002 can exercise an Asterisk Dial Plan which 
will play videos/audio (No Problem).  But, now I want 10001 to Call (Dial) 
10002; it is at this point that Asterisk throws the error "10002 is not 
registered or reachable".

I have tried many of the suggestion on many different help boards (several 
times) but I am still unable to forward a registration from Kamailio to 
Asterisk.

With my current Kamailio configuration (I do use dispatching), I see , via 
tcpdump, Asterisk receiving a "REGISTER" request, and Asterisk sends back the 
"unauthorized" as expected, however, Kamailio does not re-send the "REGISTER" 
as is customary.  I am not sure of the next step to take, but I feel I have a 
couple of options.

  *   I can continue to try and figure out why Kamailio is not sending the 
second "REGISTER" (I have not yet been able to figure this out).
  *   Tell Asterisk to not require authentication.  (I am using pjsip and do 
not know how to not require authentication in Asterisk when the request is from 
Kamailio).

I have put a lot of time into this one, and I am at a sticking point.  Any help 
or suggestions would be very much appreciated.

Thank you,


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

[SR-Users] IMS with online Charging system

[Amar Tinawi]

Hello all
Is there any open souce ocs can be integrated with kamailio IMS ?

Is it possible to integrate with CGrates ?
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Need useful graphics ideas

[Karsten Horsmann]

Hi Joel,
Hi List,

Thanks for the nice ideas.

We already use go-lang telegraf for collecting data.

I saw an push to influx version of this "another sipserver" config. But if
there is no influx the start of the server breaks.

The pull or statsd method are both nice.

I use webrtc on my frontend Kamailios, hopefully I can sort this out to
make both available (websocket and json stats for telegraf).

Thank you Joel for the nice hint. I will try this.

Kind regards
Karsten Horsmann

Am 06.12.2017 6:11 nachm. schrieb "Joel Serrano" :

> I use a mix of the above...
>
> With kamailio I export that stats I want via http:
>
>
> event_route[xhttp:request] {
> # Verify request come from localhost
> if(src_ip!=127.0.0.1) {
> xhttp_reply("403", "Forbidden", "text/html",
> "Forbidden");
> xlog("L_WARN", "[HTTP] Unauthorized access from: $si\n");
> exit;
> }
>
> # Metrics endpoint
> if ($hu =~ "^/statistics") {
>
> ... build a $var(metrics_json) with the metrics you want, must be
> JSON format ...
>
> }
> xhttp_reply("200", "OK", "application/json", "$var(metrics_json)");
> }
> return;
> }
>
>
> Then in telegraf I use the httpjson module to gather the metrics:
>
> ...
> [[inputs.httpjson]]
>   name_override = "kamailio"
>   servers = [ "http://127.0.0.1/statistics; ]
>   method = "GET"
> ...
>
>
>
> This is an example:
>
> joel@sbc-dev:~$ curl -q http://127.0.0.1/statistics 2> /dev/null | python
> -m json.tool
> {
> "core-bad_URIs_rcvd": 0,
> "core-bad_msg_hdr": 0,
> "core-drop_replies": 0,
> "core-drop_requests": 188,
> "core-err_replies": 0,
> "core-err_requests": 0,
> "core-fwd_replies": 0,
> "core-fwd_requests": 25635,
> "core-rcv_replies": 436444,
> "core-rcv_replies_18x": 27981,
> "core-rcv_replies_1xx": 73595,
> "core-rcv_replies_2xx": 347704,
> "core-rcv_replies_3xx": 0,
> "core-rcv_replies_401": 0,
> "core-rcv_replies_404": 345,
> "core-rcv_replies_407": 79,
> "core-rcv_replies_480": 1008,
> "core-rcv_replies_486": 1678,
> "core-rcv_replies_4xx": 8791,
> "core-rcv_replies_5xx": 6077,
> "core-rcv_replies_6xx": 277,
> "core-rcv_requests": 268891,
> "core-rcv_requests_ack": 40666,
> "core-rcv_requests_bye": 25600,
> "core-rcv_requests_cancel": 5313,
> "core-rcv_requests_info": 0,
> "core-rcv_requests_invite": 40983,
> "core-rcv_requests_message": 0,
> "core-rcv_requests_notify": 0,
> "core-rcv_requests_options": 98026,
> "core-rcv_requests_prack": 0,
> "core-rcv_requests_publish": 0,
> "core-rcv_requests_refer": 0,
> "core-rcv_requests_register": 28,
> "core-rcv_requests_subscribe": 0,
> "core-rcv_requests_update": 0,
> "core-unsupported_methods": 0,
> "dialog-active_dialogs": 26,
> "dialog-early_dialogs": 2,
> "dialog-expired_dialogs": 1,
> "dialog-failed_dialogs": 15036,
> "dialog-processed_dialogs": 40577,
> "dns-failed_dns_request": 130,
> "httpclient-connections": 0,
> "httpclient-connfail": 43,
> "httpclient-connok": 18466,
> "pike-blocked_ips": 0,
> "shmem-fragments": 52,
> "shmem-free_size": 1070501576,
> "shmem-max_used_size": 3526632,
> "shmem-real_used_size": 3240248,
> "shmem-total_size": 1073741824,
> "shmem-used_size": 2941760,
> "siptrace-traced_replies": 0,
> "siptrace-traced_requests": 0,
> "sl-1xx_replies": 0,
> "sl-200_replies": 155494,
> "sl-202_replies": 0,
> "sl-2xx_replies": 0,
> "sl-300_replies": 0,
> "sl-301_replies": 0,
> "sl-302_replies": 0,
> "sl-3xx_replies": 0,
> "sl-400_replies": 0,
> "sl-401_replies": 0,
> "sl-403_replies": 0,
> "sl-404_replies": 4,
> "sl-407_replies": 0,
> "sl-408_replies": 0,
> "sl-483_replies": 0,
> "sl-4xx_replies": 1,
> "sl-500_replies": 2,
> "sl-5xx_replies": 188,
> "sl-6xx_replies": 0,
> "sl-failures": 0,
> "sl-received_ACKs": 188,
> "sl-sent_err_replies": 0,
> "sl-sent_replies": 155689,
> "sl-xxx_replies": 0,
> "tcp-con_reset": 0,
> "tcp-con_timeout": 0,
> "tcp-connect_failed": 0,
> "tcp-connect_success": 0,
> "tcp-current_opened_connections": 2,
> "tcp-current_write_queue_size": 0,
> "tcp-established": 9,
> "tcp-local_reject": 0,
> "tcp-passive_open": 9,
> "tcp-send_timeout": 0,
> "tcp-sendq_full": 0,
> "tmx-2xx_transactions": 347673,
> "tmx-3xx_transactions": 0,
> "tmx-4xx_transactions": 66902,
> "tmx-5xx_transactions": 6123,
> "tmx-6xx_transactions": 277,
> "tmx-UAC_transactions": 349602,
> "tmx-UAS_transactions": 420877,
> "tmx-active_transactions": 5,
> "tmx-inuse_transactions": 13,
> "tmx-rpl_absorbed": 57086,
> "tmx-rpl_generated": 110231,
> "tmx-rpl_received": 436444,
> "tmx-rpl_relayed": 379358,
> "tmx-rpl_sent": 489589,
> 

Re: [SR-Users] Need useful graphics ideas

[Joel Serrano]

I use a mix of the above...

With kamailio I export that stats I want via http:


event_route[xhttp:request] {
# Verify request come from localhost
if(src_ip!=127.0.0.1) {
xhttp_reply("403", "Forbidden", "text/html",
"Forbidden");
xlog("L_WARN", "[HTTP] Unauthorized access from: $si\n");
exit;
}

# Metrics endpoint
if ($hu =~ "^/statistics") {

... build a $var(metrics_json) with the metrics you want, must be
JSON format ...

}
xhttp_reply("200", "OK", "application/json", "$var(metrics_json)");
}
return;
}


Then in telegraf I use the httpjson module to gather the metrics:

...
[[inputs.httpjson]]
  name_override = "kamailio"
  servers = [ "http://127.0.0.1/statistics; ]
  method = "GET"
...



This is an example:

joel@sbc-dev:~$ curl -q http://127.0.0.1/statistics 2> /dev/null | python
-m json.tool
{
"core-bad_URIs_rcvd": 0,
"core-bad_msg_hdr": 0,
"core-drop_replies": 0,
"core-drop_requests": 188,
"core-err_replies": 0,
"core-err_requests": 0,
"core-fwd_replies": 0,
"core-fwd_requests": 25635,
"core-rcv_replies": 436444,
"core-rcv_replies_18x": 27981,
"core-rcv_replies_1xx": 73595,
"core-rcv_replies_2xx": 347704,
"core-rcv_replies_3xx": 0,
"core-rcv_replies_401": 0,
"core-rcv_replies_404": 345,
"core-rcv_replies_407": 79,
"core-rcv_replies_480": 1008,
"core-rcv_replies_486": 1678,
"core-rcv_replies_4xx": 8791,
"core-rcv_replies_5xx": 6077,
"core-rcv_replies_6xx": 277,
"core-rcv_requests": 268891,
"core-rcv_requests_ack": 40666,
"core-rcv_requests_bye": 25600,
"core-rcv_requests_cancel": 5313,
"core-rcv_requests_info": 0,
"core-rcv_requests_invite": 40983,
"core-rcv_requests_message": 0,
"core-rcv_requests_notify": 0,
"core-rcv_requests_options": 98026,
"core-rcv_requests_prack": 0,
"core-rcv_requests_publish": 0,
"core-rcv_requests_refer": 0,
"core-rcv_requests_register": 28,
"core-rcv_requests_subscribe": 0,
"core-rcv_requests_update": 0,
"core-unsupported_methods": 0,
"dialog-active_dialogs": 26,
"dialog-early_dialogs": 2,
"dialog-expired_dialogs": 1,
"dialog-failed_dialogs": 15036,
"dialog-processed_dialogs": 40577,
"dns-failed_dns_request": 130,
"httpclient-connections": 0,
"httpclient-connfail": 43,
"httpclient-connok": 18466,
"pike-blocked_ips": 0,
"shmem-fragments": 52,
"shmem-free_size": 1070501576,
"shmem-max_used_size": 3526632,
"shmem-real_used_size": 3240248,
"shmem-total_size": 1073741824,
"shmem-used_size": 2941760,
"siptrace-traced_replies": 0,
"siptrace-traced_requests": 0,
"sl-1xx_replies": 0,
"sl-200_replies": 155494,
"sl-202_replies": 0,
"sl-2xx_replies": 0,
"sl-300_replies": 0,
"sl-301_replies": 0,
"sl-302_replies": 0,
"sl-3xx_replies": 0,
"sl-400_replies": 0,
"sl-401_replies": 0,
"sl-403_replies": 0,
"sl-404_replies": 4,
"sl-407_replies": 0,
"sl-408_replies": 0,
"sl-483_replies": 0,
"sl-4xx_replies": 1,
"sl-500_replies": 2,
"sl-5xx_replies": 188,
"sl-6xx_replies": 0,
"sl-failures": 0,
"sl-received_ACKs": 188,
"sl-sent_err_replies": 0,
"sl-sent_replies": 155689,
"sl-xxx_replies": 0,
"tcp-con_reset": 0,
"tcp-con_timeout": 0,
"tcp-connect_failed": 0,
"tcp-connect_success": 0,
"tcp-current_opened_connections": 2,
"tcp-current_write_queue_size": 0,
"tcp-established": 9,
"tcp-local_reject": 0,
"tcp-passive_open": 9,
"tcp-send_timeout": 0,
"tcp-sendq_full": 0,
"tmx-2xx_transactions": 347673,
"tmx-3xx_transactions": 0,
"tmx-4xx_transactions": 66902,
"tmx-5xx_transactions": 6123,
"tmx-6xx_transactions": 277,
"tmx-UAC_transactions": 349602,
"tmx-UAS_transactions": 420877,
"tmx-active_transactions": 5,
"tmx-inuse_transactions": 13,
"tmx-rpl_absorbed": 57086,
"tmx-rpl_generated": 110231,
"tmx-rpl_received": 436444,
"tmx-rpl_relayed": 379358,
"tmx-rpl_sent": 489589,
"usrloc-registered_users": 0
}
joel@sbc-dev:~$


We have all those metrics available now in influxdb, then, as others have
stated, Grafana is your best friend to make those metrics look nice.


Hope these little snippets help you and anyone else getting started with
Kamailio metrics.


Cheers,
Joel.

On Wed, Dec 6, 2017 at 1:20 AM, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> have you seen the article posted at:
>
>   - https://www.kamailio.org/w/2015/03/kamailio-statsd-best-practices/
>
> Eloy had a blog about it linked from above page.
>
> Cheers,
> Daniel
>
> On 06.12.17 08:54, Karsten Horsmann wrote:
>
> Hello List,
>
> I thought about some kind of Kamailio stats source (like registered users,
> calls active and some other things) to collect them into influx dB and draw
> them with grafana.
>
> How do you solved that?
>
> 

Re: [SR-Users] t_set_fr behaviour

[Kelvin Chua]

thanks daniel

might be good to add to documentation


Kelvin Chua

On Mon, Nov 13, 2017 at 4:32 PM, Daniel-Constantin Mierla  wrote:

> Hello,
>
>
> On 11.11.17 07:04, Kelvin Chua wrote:
> > hi guys,
> >
> > has anyone of you tried playing around with a scenario similar to this?
> >
> > A. invite -> t_set_fr() 2 seconds  - if "100 trying" not received in 2
> > seconds, timeout. works fine.
> > B. after receiving "100 trying" received, t_set_fr() 30 seconds - if
> > 18x not received in 30 seconds, timeout. works fine
> > C. after receiving the first 180, t_set_fr() 10 seconds - if "200 ok"
> > not received in 10 seconds, it will not timeout, but instead it will
> > timeout 30 seconds after B.
> >
> > i noticed this behavior recently and noticed that when a previous
> > t_set_fr() is bigger than the new one, it will be ignored. so if i did
> > 2 -> 10 -> 30, it works (swapping timeout values of B and C)
> >
> > my question is, is this an expected behavior?
> >
> just time for a very quick look at the code and I could see that only
> values for these timers are set by t_set_fr(), the transaction callback
> is not taken out and added to the timer lists. So, given that the
> previous timeout was longer, the callback was not executed yet and the
> new value is not seen. When the value is higher, then when callback is
> executed, then the new value is seen and used.
>
> I haven't implemented this part, and again, just a very quick look at
> the code, but for now is seems to be the way it works...
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
> Kamailio World Conference - 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] load testing ims_charging

[Kelvin Chua]

i am trying to load test the ims_charging module and notice some issues

whenever i send test calls one by one, it's perfect. but when i use sipp
and generate a bunch of calls, i would get this intermittently

CRITICAL: ims_charging [ro_timer.c:122]: insert_ro_timer(): Trying to
insert a bogus ro tl=0x7f207e91c2d0 tl->next=0x7f207e8b57b8
tl->prev=0x7f207e97c398

if i continue to hammer the server, it would end up failing all calls. When
this issue happens, Ro_CCR will not return any value and will also not
trigger the async route, looks like it just sits there frozen. during this
time, sip client will receive a 408.

also notice cdp complaining of latency usually around 1 second, using
packet capture i am sure diameter server is responding properly. i think
there is a choke point somewhere. i tried playing around with
async_workers, no improvement.

any pointers?


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

Re: [SR-Users] Doing a quick test with http_async_client module from master branch

[Federico Cabiddu]

I'll do some test tonight and report.

Cheers,

Federico

On 6 Dec 2017 10:25 am, "Daniel-Constantin Mierla" 
wrote:

> Hello,
>
> anyone around here that can do a quick test with http_async_module? I
> don't have a testbed for it right now and I would spend the time on
> other resources if someone here can run some tests with
> http_async_client module from master branch. I did a bit of internal
> refactoring in order to be able to export the function to kemi interface
> -- nothing radical, but it would be good to know it didn't break anything.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.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] Need useful graphics ideas

[Jurijs Ivolga]

Hi,

You can trigger kamctl and collect necessary data and then push this data
to grafana.

Check this script which collects data for zabbix, but logic should be same:

https://gist.github.com/crashdump/7751564

With kind regards,

Jurijs

On Wed, Dec 6, 2017 at 10:29 AM, Loic Chabert 
wrote:

> Hi,
>
> If you are aware about golang, you should probably wrote a telegraf input
> plugin for kamailio.
>
> Installed on kamalio's Host, telegraf will export metric to influxdb. Then
> you can graph it with grafana :)
>
> Regards.
>
> Le 6 déc. 2017 08:54, "Karsten Horsmann"  a écrit :
>
>> Hello List,
>>
>> I thought about some kind of Kamailio stats source (like registered
>> users, calls active and some other things) to collect them into influx dB
>> and draw them with grafana.
>>
>> How do you solved that?
>>
>> Timer based routes or statsd or whatever?
>>
>> Kind regards
>> Karsten Horsmann
>>
>> ___
>> 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
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Need useful graphics ideas

[Loic Chabert]

Hi,

If you are aware about golang, you should probably wrote a telegraf input
plugin for kamailio.

Installed on kamalio's Host, telegraf will export metric to influxdb. Then
you can graph it with grafana :)

Regards.

Le 6 déc. 2017 08:54, "Karsten Horsmann"  a écrit :

> Hello List,
>
> I thought about some kind of Kamailio stats source (like registered users,
> calls active and some other things) to collect them into influx dB and draw
> them with grafana.
>
> How do you solved that?
>
> Timer based routes or statsd or whatever?
>
> Kind regards
> Karsten Horsmann
>
> ___
> 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] redis via haproxy

[Aidar Kamalov]

There is no problems without haproxy. And haproxy no problems without
kamailio :)

I used tcpdump (can't attach here) to dump port 6380, so kamailio should
connect to haproxy, because it send ping and receive pong.

2017-12-06 11:06 GMT+03:00 Юрий Горличенко :

> Hi try first to use single redis for make sure that it is not a ha proxy
> trouble.
>
> If error still exists - try to collect debug information.
>
> Среда, 6 декабря 2017, 10:53 +03:00 от Aidar Kamalov <
> aidar.kama...@gmail.com>:
>
> Hello,
>
> Kamailio after restart(or start) sometimes can't connect to redis (via
> haproxy) with logs:
>
> Dec  6 07:29:30 siptest /usr/sbin/kamailio[47291]: NOTICE: 

Re: [SR-Users] redis via haproxy

[Юрий Горличенко]

Hi try first to use single redis for make sure that it is not a ha proxy 
trouble.

If error still exists - try to collect debug information. 
>Среда,  6 декабря 2017, 10:53 +03:00 от Aidar Kamalov 
>:
>
>Hello,
>
>Kamailio after restart(or start) sometimes can't connect to redis (via 
>haproxy) with logs:
>
>Dec  6 07:29:30 siptest /usr/sbin/kamailio[47291]: NOTICE: