18 Dec
2017
18 Dec
'17
3:33 p.m.
Hello all,
I use the dispatcher module extensively for load balancing and fail-over.
My kamailio instance is multihomed, and I use the "socket" attribute to
determine which socket SIP messages should use for each dispatcher
destination, as such:
+----+-------+-------------------------+-------+----------+-----------------------------+
| id | setid | destination | flags | priority |
attrs |
+----+-------+-------------------------+-------+----------+-----------------------------+
| 1 | 0 | sip:192.168.0.1:5060 | 8 | 0 | socket=udp:
10.10.10.1:5060 |
| 2 | 1 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp:
44.44.44.1:5060 |
| 3 | 1 | sip:222.222.22.2:5060 | 8 | 0 | socket=udp:
55.55.55.1:5060 |
+----+-------+-------------------------+-------+----------+-----------------------------+
The dispatcher module uses OPTIONS to probe each destination for
availability. When a destination goes down or up, the respective
event-route is executed.
What I need to do is to be able to "capture" the sending socket used for
this probing when a destination becomes unavailable or available in the
event-routes. The $fs variable is set, but unfortunately its value does not
make sense. Here's an example route and the results that are printed:
event_route[dispatcher:dst-down] {
xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs)
$T_req($Ru)\n");
}
Now say destination with id = '2' goes down. This is what I get in the logs
for the event_route above:
ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060 (sip:
192.168.0.1:5060) Contact: <sip:111.111.11.1:5060> udp:10.10.10.1:5060
<null> <null> <null>
The xlog PV/log mapping for the above line is the following:
$rm: OPTIONS
$ru: sip:111.111.11.1:5060
$du: sip:192.168.0.1:5060
$ds: Contact: <sip:111.111.11.1:5060>
$Ru: udp:10.10.10.1:5060
The rest are $null. $ru and $ds are consistent with the actual destination
being probed, $du and $fs are not (the are set to values corresponding to
id = '1', for some reason).
This log line is, of course, inaccurate. Not only does it not make sense,
but also this is not consistent with messages captured on network
interfaces using sngrep: Kamailio does indeed behave as it should, the
OPTIONS is sent out to 111.111.11.1 from socket
udp:44.44.44.1:5060. But this is not reflected in the log entry above when
the event_route is executed.
Now the weird part is that this OPTIONS "transaction" (which is locally
generated by kamailio) has the $du PV set to the value of another
destination (namely the that of id = '1'). As a result, the $fs PV is
consistent with that choice for $du. I can verify with sngrep that this is
not the case in reality, as the request was sent to destination id = '2'
from the correct socket as indicated above.
What I would like to ask is whether these "OPTIONS" used by dispatcher for
probing go through the request_route processing at some point. This is the
only way that would explain the $du PV being set to a false value. If yes,
is there any way to prevent this from happening? I need to be able to
access the $fs PV when a destination goes up or down, and I can't have any
other configuration file routes interfering with that. Thanks!
Best regards,
George
20 Dec
20 Dec
11:57 a.m.
New subject: Dispatcher module OPTIONS and event routes: how are they handled by core?
Hello,
those event routes are executed with a so called faked request (a
request generated internally, unrelated to the OPTIONS request sent to
the wire), apart of request uri, the rest of values are not related to
the dispatcher records.
To get access to other attributes of dispatcher records in a straight
way in the config, it would require C coding, Anyhow, even now using
scripting, you can try with sql queries to database or rpc commands
execution via jsonrpcs module and then parse the result using jansson
module.
Cheers,
Daniel
On 18.12.17 13:33, George Diamantopoulos wrote:
Hello all,
I use the dispatcher module extensively for load balancing and
fail-over. My kamailio instance is multihomed, and I use the "socket"
attribute to determine which socket SIP messages should use for each
dispatcher destination, as such:
+----+-------+-------------------------+-------+----------+-----------------------------+
| id | setid | destination | flags | priority |
attrs |
+----+-------+-------------------------+-------+----------+-----------------------------+
| 1 | 0 | sip:192.168.0.1:5060 <http://192.168.0.1:5060> |
8 | 0 | socket=udp:10.10.10.1:5060 <http://10.10.10.1:5060> |
| 2 | 1 | sip:111.111.11.1:5060 <http://111.111.11.1:5060>
| 8 | 0 | socket=udp:44.44.44.1:5060
<http://44.44.44.1:5060> |
| 3 | 1 | sip:222.222.22.2:5060 <http://222.222.22.2:5060>
| 8 | 0 | socket=udp:55.55.55.1:5060
<http://55.55.55.1:5060> |
+----+-------+-------------------------+-------+----------+-----------------------------+
The dispatcher module uses OPTIONS to probe each destination for
availability. When a destination goes down or up, the respective
event-route is executed.
What I need to do is to be able to "capture" the sending socket used
for this probing when a destination becomes unavailable or available
in the event-routes. The $fs variable is set, but unfortunately its
value does not make sense. Here's an example route and the results
that are printed:
event_route[dispatcher:dst-down] {
xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru
$T_req($fs) $T_req($Ru)\n");
}
Now say destination with id = '2' goes down. This is what I get in the
logs for the event_route above:
ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060
(sip:192.168.0.1:5060 <http://192.168.0.1:5060>) Contact:
<sip:111.111.11.1:5060> udp:10.10.10.1:5060 <http://10.10.10.1:5060>
<null> <null> <null>
The xlog PV/log mapping for the above line is the following:
$rm: OPTIONS
$ru: sip:111.111.11.1:5060
$du: sip:192.168.0.1:5060 <http://192.168.0.1:5060>
$ds: Contact: <sip:111.111.11.1:5060>
$Ru: udp:10.10.10.1:5060 <http://10.10.10.1:5060>
The rest are $null. $ru and $ds are consistent with the actual
destination being probed, $du and $fs are not (the are set to values
corresponding to id = '1', for some reason).
This log line is, of course, inaccurate. Not only does it not make
sense, but also this is not consistent with messages captured on
network interfaces using sngrep: Kamailio does indeed behave as it
should, the OPTIONS is sent out to 111.111.11.1 from socket
udp:44.44.44.1:5060 <http://44.44.44.1:5060>. But this is not
reflected in the log entry above when the event_route is executed.
Now the weird part is that this OPTIONS "transaction" (which is
locally generated by kamailio) has the $du PV set to the value of
another destination (namely the that of id = '1'). As a result, the
$fs PV is consistent with that choice for $du. I can verify with
sngrep that this is not the case in reality, as the request was sent
to destination id = '2' from the correct socket as indicated above.
What I would like to ask is whether these "OPTIONS" used by dispatcher
for probing go through the request_route processing at some point.
This is the only way that would explain the $du PV being set to a
false value. If yes, is there any way to prevent this from happening?
I need to be able to access the $fs PV when a destination goes up or
down, and I can't have any other configuration file routes interfering
with that. Thanks!
Best regards,
George
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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
5:32 p.m.
New subject: Dispatcher module OPTIONS and event routes: how are they handled by core?
Hello Daniel,
Thanks for the reply. Unfortunately I can't really use the database records
to achieve what I want. The example in my previous message didn't show
this, but I would like to be able to differentiate between the following:
+----+-------+-------------------------+-------+----------+-
----------------------------+
| id | setid | destination | flags | priority |
attrs |
+----+-------+-------------------------+-------+----------+-
----------------------------+
| 1 | 1 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp:
44.44.44.1:5060 |
| 2 | 10 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp:
55.55.55.1:5060 |
+----+-------+-------------------------+-------+----------+-
----------------------------+
In this case, how can I tell which destination went down? The URI is the
same, but the sockets differ for each id.
If only $ru is available in these event routes, I can't query the database
because $ru matches both records. If I can't access the socket used with a
PV, is there any way to have access to *either* the id *or* the setid for
the destination for which the event was generated?
Thanks!
BR,
George
On 20 December 2017 at 10:57, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
those event routes are executed with a so called faked request (a request
generated internally, unrelated to the OPTIONS request sent to the wire),
apart of request uri, the rest of values are not related to the dispatcher
records.
To get access to other attributes of dispatcher records in a straight way
in the config, it would require C coding, Anyhow, even now using scripting,
you can try with sql queries to database or rpc commands execution via
jsonrpcs module and then parse the result using jansson module.
Cheers,
Daniel
On 18.12.17 13:33, George Diamantopoulos wrote:
Hello all,
I use the dispatcher module extensively for load balancing and fail-over.
My kamailio instance is multihomed, and I use the "socket" attribute to
determine which socket SIP messages should use for each dispatcher
destination, as such:
+----+-------+-------------------------+-------+----------+-
----------------------------+
| id | setid | destination | flags | priority |
attrs |
+----+-------+-------------------------+-------+----------+-
----------------------------+
| 1 | 0 | sip:192.168.0.1:5060 | 8 | 0 | socket=udp:
10.10.10.1:5060 |
| 2 | 1 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp:
44.44.44.1:5060 |
| 3 | 1 | sip:222.222.22.2:5060 | 8 | 0 | socket=udp:
55.55.55.1:5060 |
+----+-------+-------------------------+-------+----------+-
----------------------------+
The dispatcher module uses OPTIONS to probe each destination for
availability. When a destination goes down or up, the respective
event-route is executed.
What I need to do is to be able to "capture" the sending socket used for
this probing when a destination becomes unavailable or available in the
event-routes. The $fs variable is set, but unfortunately its value does not
make sense. Here's an example route and the results that are printed:
event_route[dispatcher:dst-down] {
xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru
$T_req($fs)
$T_req($Ru)\n");
}
Now say destination with id = '2' goes down. This is what I get in the
logs for the event_route above:
ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060 (sip:
192.168.0.1:5060) Contact: <sip:111.111.11.1:5060> udp:10.10.10.1:5060
<null> <null> <null>
The xlog PV/log mapping for the above line is the following:
$rm: OPTIONS
$ru: sip:111.111.11.1:5060
$du: sip:192.168.0.1:5060
$ds: Contact: <sip:111.111.11.1:5060>
$Ru: udp:10.10.10.1:5060
The rest are $null. $ru and $ds are consistent with the actual destination
being probed, $du and $fs are not (the are set to values corresponding to
id = '1', for some reason).
This log line is, of course, inaccurate. Not only does it not make sense,
but also this is not consistent with messages captured on network
interfaces using sngrep: Kamailio does indeed behave as it should, the
OPTIONS is sent out to 111.111.11.1 from socket
udp:44.44.44.1:5060. But this is not reflected in the log entry above
when the event_route is executed.
Now the weird part is that this OPTIONS "transaction" (which is locally
generated by kamailio) has the $du PV set to the value of another
destination (namely the that of id = '1'). As a result, the $fs PV is
consistent with that choice for $du. I can verify with sngrep that this is
not the case in reality, as the request was sent to destination id = '2'
from the correct socket as indicated above.
What I would like to ask is whether these "OPTIONS" used by dispatcher for
probing go through the request_route processing at some point. This is the
only way that would explain the $du PV being set to a false value. If yes,
is there any way to prevent this from happening? I need to be able to
access the $fs PV when a destination goes up or down, and I can't have any
other configuration file routes interfering with that. Thanks!
Best regards,
George
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://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
6:26 p.m.
New subject: Dispatcher module OPTIONS and event routes: how are they handled by core?
Hello,
an workaround would be to add a custom parameter to the destination
value, like sip:1.2.3.4:5060;sid=1. Unknown parameters should be ignored
by the receiving party. Or if you have only two records with same
address, add to one ";transport=udp".
Of course, coding in C to make it easier in config would be the elegant
solution.
Cheers,
Daniel
On 20.12.17 15:32, George Diamantopoulos wrote:
Hello Daniel,
Thanks for the reply. Unfortunately I can't really use the database
records to achieve what I want. The example in my previous message
didn't show this, but I would like to be able to differentiate between
the following:
+----+-------+-------------------------+-------+----------+-----------------------------+
| id | setid | destination | flags | priority |
attrs |
+----+-------+-------------------------+-------+----------+-----------------------------+
| 1 | 1 | sip:111.111.11.1:5060 <http://111.111.11.1:5060>
| 8 | 0 | socket=udp:44.44.44.1:5060
<http://44.44.44.1:5060> |
| 2 | 10 | sip:111.111.11.1:5060 <http://111.111.11.1:5060>
| 8 | 0 | socket=udp:55.55.55.1:5060
<http://55.55.55.1:5060> |
+----+-------+-------------------------+-------+----------+-----------------------------+
In this case, how can I tell which destination went down? The URI is
the same, but the sockets differ for each id.
If only $ru is available in these event routes, I can't query the
database because $ru matches both records. If I can't access the
socket used with a PV, is there any way to have access to *either* the
id *or* the setid for the destination for which the event was generated?
Thanks!
BR,
George
On 20 December 2017 at 10:57, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
those event routes are executed with a so called faked request (a
request generated internally, unrelated to the OPTIONS request
sent to the wire), apart of request uri, the rest of values are
not related to the dispatcher records.
To get access to other attributes of dispatcher records in a
straight way in the config, it would require C coding, Anyhow,
even now using scripting, you can try with sql queries to database
or rpc commands execution via jsonrpcs module and then parse the
result using jansson module.
Cheers,
Daniel
On 18.12.17 13:33, George Diamantopoulos wrote:
--
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
Hello all,
I use the dispatcher module extensively for load balancing and
fail-over. My kamailio instance is multihomed, and I use the
"socket" attribute to determine which socket SIP messages should
use for each dispatcher destination, as such:
+----+-------+-------------------------+-------+----------+-----------------------------+
| id | setid | destination | flags | priority |
attrs |
+----+-------+-------------------------+-------+----------+-----------------------------+
| 1 | 0 | sip:192.168.0.1:5060 <http://192.168.0.1:5060>
| 8 | 0 | socket=udp:10.10.10.1:5060
<http://10.10.10.1:5060> |
| 2 | 1 | sip:111.111.11.1:5060 <http://111.111.11.1:5060>
| 8 | 0 | socket=udp:44.44.44.1:5060
<http://44.44.44.1:5060> |
| 3 | 1 | sip:222.222.22.2:5060 <http://222.222.22.2:5060>
| 8 | 0 | socket=udp:55.55.55.1:5060
<http://55.55.55.1:5060> |
+----+-------+-------------------------+-------+----------+-----------------------------+
The dispatcher module uses OPTIONS to probe each destination for
availability. When a destination goes down or up, the respective
event-route is executed.
What I need to do is to be able to "capture" the sending socket
used for this probing when a destination becomes unavailable or
available in the event-routes. The $fs variable is set, but
unfortunately its value does not make sense. Here's an example
route and the results that are printed:
event_route[dispatcher:dst-down] {
xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru
$T_req($fs) $T_req($Ru)\n");
}
Now say destination with id = '2' goes down. This is what I get
in the logs for the event_route above:
ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060
(sip:192.168.0.1:5060 <http://192.168.0.1:5060>) Contact:
<sip:111.111.11.1:5060> udp:10.10.10.1:5060
<http://10.10.10.1:5060> <null> <null> <null>
The xlog PV/log mapping for the above line is the following:
$rm: OPTIONS
$ru: sip:111.111.11.1:5060
$du: sip:192.168.0.1:5060 <http://192.168.0.1:5060>
$ds: Contact: <sip:111.111.11.1:5060>
$Ru: udp:10.10.10.1:5060 <http://10.10.10.1:5060>
The rest are $null. $ru and $ds are consistent with the actual
destination being probed, $du and $fs are not (the are set to
values corresponding to id = '1', for some reason).
This log line is, of course, inaccurate. Not only does it not
make sense, but also this is not consistent with messages
captured on network interfaces using sngrep: Kamailio does indeed
behave as it should, the OPTIONS is sent out to 111.111.11.1 from
socket
udp:44.44.44.1:5060 <http://44.44.44.1:5060>. But this is not
reflected in the log entry above when the event_route is executed.
Now the weird part is that this OPTIONS "transaction" (which is
locally generated by kamailio) has the $du PV set to the value of
another destination (namely the that of id = '1'). As a result,
the $fs PV is consistent with that choice for $du. I can verify
with sngrep that this is not the case in reality, as the request
was sent to destination id = '2' from the correct socket as
indicated above.
What I would like to ask is whether these "OPTIONS" used by
dispatcher for probing go through the request_route processing at
some point. This is the only way that would explain the $du PV
being set to a false value. If yes, is there any way to prevent
this from happening? I need to be able to access the $fs PV when
a destination goes up or down, and I can't have any other
configuration file routes interfering with that. Thanks!
Best regards,
George
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
<http://www.kamailioworld.com>
21 Dec
21 Dec
8:15 p.m.
New subject: Dispatcher module OPTIONS and event routes: how are they handled by core?
Hello Daniel,
A URI param doesn't sound bad at all for this purpose, and works like a
charm! I believe the parameter never makes it to the receiving end when
using regular dispatcher functionality, as the R-URI is not rewritten and
only the $du variable is set with this URI, which never appears in the SIP
message anywhere, right? So there's some degree of elegance here as well
:-D.
Thanks again for the workaround, I've been working on this for a while...
Best regards,
George
On 20 December 2017 at 17:26, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
an workaround would be to add a custom parameter to the destination value,
like sip:1.2.3.4:5060;sid=1. Unknown parameters should be ignored by the
receiving party. Or if you have only two records with same address, add to
one ";transport=udp".
Of course, coding in C to make it easier in config would be the elegant
solution.
Cheers,
Daniel
On 20.12.17 15:32, George Diamantopoulos wrote:
Hello Daniel,
Thanks for the reply. Unfortunately I can't really use the database
records to achieve what I want. The example in my previous message didn't
show this, but I would like to be able to differentiate between the
following:
+----+-------+-------------------------+-------+----------+-
----------------------------+
| id | setid | destination | flags | priority |
attrs |
+----+-------+-------------------------+-------+----------+-
----------------------------+
| 1 | 1 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp:
44.44.44.1:5060 |
| 2 | 10 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp:
55.55.55.1:5060 |
+----+-------+-------------------------+-------+----------+-
----------------------------+
In this case, how can I tell which destination went down? The URI is the
same, but the sockets differ for each id.
If only $ru is available in these event routes, I can't query the database
because $ru matches both records. If I can't access the socket used with a
PV, is there any way to have access to *either* the id *or* the setid for
the destination for which the event was generated?
Thanks!
BR,
George
On 20 December 2017 at 10:57, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
those event routes are executed with a so called faked request (a request
generated internally, unrelated to the OPTIONS request sent to the wire),
apart of request uri, the rest of values are not related to the dispatcher
records.
To get access to other attributes of dispatcher records in a straight way
in the config, it would require C coding, Anyhow, even now using scripting,
you can try with sql queries to database or rpc commands execution via
jsonrpcs module and then parse the result using jansson module.
Cheers,
Daniel
On 18.12.17 13:33, George Diamantopoulos wrote:
Hello all,
I use the dispatcher module extensively for load balancing and fail-over.
My kamailio instance is multihomed, and I use the "socket" attribute to
determine which socket SIP messages should use for each dispatcher
destination, as such:
+----+-------+-------------------------+-------+----------+-
----------------------------+
| id | setid | destination | flags | priority |
attrs |
+----+-------+-------------------------+-------+----------+-
----------------------------+
| 1 | 0 | sip:192.168.0.1:5060 | 8 | 0 | socket=udp:
10.10.10.1:5060 |
| 2 | 1 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp:
44.44.44.1:5060 |
| 3 | 1 | sip:222.222.22.2:5060 | 8 | 0 | socket=udp:
55.55.55.1:5060 |
+----+-------+-------------------------+-------+----------+-
----------------------------+
The dispatcher module uses OPTIONS to probe each destination for
availability. When a destination goes down or up, the respective
event-route is executed.
What I need to do is to be able to "capture" the sending socket used for
this probing when a destination becomes unavailable or available in the
event-routes. The $fs variable is set, but unfortunately its value does not
make sense. Here's an example route and the results that are printed:
event_route[dispatcher:dst-down] {
xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru
$T_req($fs) $T_req($Ru)\n");
}
Now say destination with id = '2' goes down. This is what I get in the
logs for the event_route above:
ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060 (sip:
192.168.0.1:5060) Contact: <sip:111.111.11.1:5060> udp:10.10.10.1:5060
<null> <null> <null>
The xlog PV/log mapping for the above line is the following:
$rm: OPTIONS
$ru: sip:111.111.11.1:5060
$du: sip:192.168.0.1:5060
$ds: Contact: <sip:111.111.11.1:5060>
$Ru: udp:10.10.10.1:5060
The rest are $null. $ru and $ds are consistent with the actual
destination being probed, $du and $fs are not (the are set to values
corresponding to id = '1', for some reason).
This log line is, of course, inaccurate. Not only does it not make sense,
but also this is not consistent with messages captured on network
interfaces using sngrep: Kamailio does indeed behave as it should, the
OPTIONS is sent out to 111.111.11.1 from socket
udp:44.44.44.1:5060. But this is not reflected in the log entry above
when the event_route is executed.
Now the weird part is that this OPTIONS "transaction" (which is locally
generated by kamailio) has the $du PV set to the value of another
destination (namely the that of id = '1'). As a result, the $fs PV is
consistent with that choice for $du. I can verify with sngrep that this is
not the case in reality, as the request was sent to destination id = '2'
from the correct socket as indicated above.
What I would like to ask is whether these "OPTIONS" used by dispatcher
for probing go through the request_route processing at some point. This is
the only way that would explain the $du PV being set to a false value. If
yes, is there any way to prevent this from happening? I need to be able to
access the $fs PV when a destination goes up or down, and I can't have any
other configuration file routes interfering with that. Thanks!
Best regards,
George
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://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
--
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
2528
days inactive
2531
days old
4 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
George Diamantopoulos