31 Oct
2014
31 Oct
'14
12:37 p.m.
Hi all,
after fighting in the last days with dispatcher and the socket used to send
pings and dispatch requests, I'm thinking in adding to the module the
support for configuring the sending socket. Specifically what I'm thinking
is:
1) add the sending socket as a gateways' parameter
2) add an avp to store the gateways' send socket, to be used for load
balancing failover
3) add a module parameter "ds_send_socket" to define a global socket
The logic to select the sending socket would be:
1) if the gateway has send socket configured, use it
2) else, if configured, use the socket specified in ds_send_socket
3 else use the socket corresponding to the first listen directive (current
behaviour)
What do you think about? Do you find that this would be generally useful?
About adding the send socket per gateway: how do you think it should be
configured? In a dedicated column (db or file) or in the attrs parameter
(just adding another attributes)?
Looking forward to your feedback.
Cheers,
Federico
31 Oct
31 Oct
2 p.m.
Hello,
in the first phase add the socket as an attribute for each gateway.
At some point we should look at making some of the attributes as
dedicated fields (columns), but I would prefer to make it at once for
all attributes that should be split out.
Cheers,
Daniel
On 31/10/14 11:37, Federico Cabiddu wrote:
Hi all,
after fighting in the last days with dispatcher and the socket used to
send pings and dispatch requests, I'm thinking in adding to the module
the support for configuring the sending socket. Specifically what I'm
thinking is:
1) add the sending socket as a gateways' parameter
2) add an avp to store the gateways' send socket, to be used for load
balancing failover
3) add a module parameter "ds_send_socket" to define a global socket
The logic to select the sending socket would be:
1) if the gateway has send socket configured, use it
2) else, if configured, use the socket specified in ds_send_socket
3 else use the socket corresponding to the first listen directive
(current behaviour)
What do you think about? Do you find that this would be generally useful?
About adding the send socket per gateway: how do you think it should
be configured? In a dedicated column (db or file) or in the attrs
parameter (just adding another attributes)?
Looking forward to your feedback.
Cheers,
Federico
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
2 Nov
2 Nov
10:25 a.m.
Hi,
according to Daniel's suggestion here are my proposed changes to implement
per gateway and default sending socket in the dispatcher module.
Some notes about them:
- per gateway socket configuration is done using the "socket" attribute
- module default sending socket is configured via the "ds_default_socket"
parameter
- sock_avp AVP is used to hold the sockets list for the selected gateways.
It actually holds a pointer to the socket_info struct for the gateway
sending socket (I borrowed the idea from another project). I'm currently
wondering if it makes sense having its name configurable and empty by
default (I followed the same logic as for the already existing AVPs) or if,
due to its mainly internal usage, it wouldn't be better to give it a name
by default and hide it to the module's user.
Looking forward to hearing your feedback.
Regards,
Federico
On Fri, Oct 31, 2014 at 1:00 PM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
Hello,
in the first phase add the socket as an attribute for each gateway.
At some point we should look at making some of the attributes as dedicated
fields (columns), but I would prefer to make it at once for all attributes
that should be split out.
Cheers,
Daniel
On 31/10/14 11:37, Federico Cabiddu wrote:
Hi all,
after fighting in the last days with dispatcher and the socket used to
send pings and dispatch requests, I'm thinking in adding to the module the
support for configuring the sending socket. Specifically what I'm thinking
is:
1) add the sending socket as a gateways' parameter
2) add an avp to store the gateways' send socket, to be used for load
balancing failover
3) add a module parameter "ds_send_socket" to define a global socket
The logic to select the sending socket would be:
1) if the gateway has send socket configured, use it
2) else, if configured, use the socket specified in ds_send_socket
3 else use the socket corresponding to the first listen directive (current
behaviour)
What do you think about? Do you find that this would be generally useful?
About adding the send socket per gateway: how do you think it should be
configured? In a dedicated column (db or file) or in the attrs parameter
(just adding another attributes)?
Looking forward to your feedback.
Cheers,
Federico
_______________________________________________
sr-dev mailing
listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4 Nov
4 Nov
12:28 a.m.
Hello,
On 02/11/14 09:25, Federico Cabiddu wrote:
Hi,
according to Daniel's suggestion here are my proposed changes to
implement per gateway and default sending socket in the dispatcher module.
Some notes about them:
- per gateway socket configuration is done using the "socket" attribute
- module default sending socket is configured via the
"ds_default_socket" parameter
- sock_avp AVP is used to hold the sockets list for the selected
gateways. It actually holds a pointer to the socket_info struct for
the gateway sending socket (I borrowed the idea from another project).
I'm currently wondering if it makes sense having its name configurable
and empty by default (I followed the same logic as for the already
existing AVPs) or if, due to its mainly internal usage, it wouldn't be
better to give it a name by default and hide it to the module's user.
the name has to be empty, forcing the admin to set it to be explicitly
aware of its value. Long time ago (iirc, it was even SER or beginning of
openser years), there were some default values in the code. Surprising,
from time to time various people used same name for avp in config for
different purpose, messing up the things.
As a related remark, for xavps that use two layers (e.g., $xavp(x=>y) ),
only the first name (x) needs to be forced to the admin selection, as
the second (x) is inside the first xavp, there is no real exposure to a
conflict. In other words, the admin is made aware that $xavp(x=>...) is
used for a particular module and must not mess it.
Thanks for the patch, I will look over it in the very near future.
Cheers,
Daniel
Looking forward to hearing your feedback.
Regards,
Federico
On Fri, Oct 31, 2014 at 1:00 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
in the first phase add the socket as an attribute for each gateway.
At some point we should look at making some of the attributes as
dedicated fields (columns), but I would prefer to make it at once
for all attributes that should be split out.
Cheers,
Daniel
On 31/10/14 11:37, Federico Cabiddu wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com
Hi all,
after fighting in the last days with dispatcher and the socket
used to send pings and dispatch requests, I'm thinking in adding
to the module the support for configuring the sending socket.
Specifically what I'm thinking is:
1) add the sending socket as a gateways' parameter
2) add an avp to store the gateways' send socket, to be used for
load balancing failover
3) add a module parameter "ds_send_socket" to define a global socket
The logic to select the sending socket would be:
1) if the gateway has send socket configured, use it
2) else, if configured, use the socket specified in ds_send_socket
3 else use the socket corresponding to the first listen directive
(current behaviour)
What do you think about? Do you find that this would be generally
useful?
About adding the send socket per gateway: how do you think it
should be configured? In a dedicated column (db or file) or in
the attrs parameter (just adding another attributes)?
Looking forward to your feedback.
Cheers,
Federico
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12 Nov
12 Nov
12:55 p.m.
Hello,
overall, the patch can be committed.
As a remark, printing the socket pointer to a string in an avp and
getting it back is the ideal, still can be a bit faster than storing the
socket string.
For the near future, I think that the dispatcher needs a bit of a review
and move those avps in xavp, where a pointer can be stored directly,
along with other simplifications/optimizations -- but this when the time
comes for it.
Cheers,
Daniel
On 02/11/14 09:25, Federico Cabiddu wrote:
Hi,
according to Daniel's suggestion here are my proposed changes to
implement per gateway and default sending socket in the dispatcher module.
Some notes about them:
- per gateway socket configuration is done using the "socket" attribute
- module default sending socket is configured via the
"ds_default_socket" parameter
- sock_avp AVP is used to hold the sockets list for the selected
gateways. It actually holds a pointer to the socket_info struct for
the gateway sending socket (I borrowed the idea from another project).
I'm currently wondering if it makes sense having its name configurable
and empty by default (I followed the same logic as for the already
existing AVPs) or if, due to its mainly internal usage, it wouldn't be
better to give it a name by default and hide it to the module's user.
Looking forward to hearing your feedback.
Regards,
Federico
On Fri, Oct 31, 2014 at 1:00 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
in the first phase add the socket as an attribute for each gateway.
At some point we should look at making some of the attributes as
dedicated fields (columns), but I would prefer to make it at once
for all attributes that should be split out.
Cheers,
Daniel
On 31/10/14 11:37, Federico Cabiddu wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com
Hi all,
after fighting in the last days with dispatcher and the socket
used to send pings and dispatch requests, I'm thinking in adding
to the module the support for configuring the sending socket.
Specifically what I'm thinking is:
1) add the sending socket as a gateways' parameter
2) add an avp to store the gateways' send socket, to be used for
load balancing failover
3) add a module parameter "ds_send_socket" to define a global socket
The logic to select the sending socket would be:
1) if the gateway has send socket configured, use it
2) else, if configured, use the socket specified in ds_send_socket
3 else use the socket corresponding to the first listen directive
(current behaviour)
What do you think about? Do you find that this would be generally
useful?
About adding the send socket per gateway: how do you think it
should be configured? In a dedicated column (db or file) or in
the attrs parameter (just adding another attributes)?
Looking forward to your feedback.
Cheers,
Federico
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3663
days inactive
3675
days old
4 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Federico Cabiddu