16 Apr
2015
16 Apr
'15
11:42 a.m.
The idea is to use SRV records instead of a dispatcher by setting $rd to a DNS
SRV enabled host (with all hosts having the same prio and weight).
Problem is that when authentication is required the flow is as follows (with 2
hosts):
1:
UAC INVITE/REGISTER -> LB -> SIP0
SIP0 401 with nonce1 challenge -> LB -> UAC
UAC ACK -> LB -> SIP0
2:
UAC INVITE/REGISTER with nonce1 response -> LB -> SIP1
SIP1 401 with nonce2 challenge -> LB -> UAC
UACK ACK -> LB -> SIP1
3:
UAC INVITE/REGISTER with nonce2 response -> LB -> SIP0
SIP0 401 with nonce1 challenge -> LB -> UAC
UACK ACK -> LB -> SIP0
4: UAC either gives up or goes to 2
Using the dispatcher module this can be solved by using a hash over either
from/to/request URI. I can't find any hints for forcing the dialog to 1
backend.
BTW the idea is to keep the loadbalancing proxy as simple/stupid as possible
(no db), the backends have a shared db.
16 Apr
16 Apr
12:15 p.m.
New subject: Loadbalancing proxy using DNS SRV instead of dispatcher
Hey,
Try setting weight of all your SRV records to 0.
Regards,
Cezary
On 16/04/2015 16:42, Daniel Tryba wrote:
The idea is to use SRV records instead of a dispatcher
by setting $rd to a DNS
SRV enabled host (with all hosts having the same prio and weight).
Problem is that when authentication is required the flow is as follows (with 2
hosts):
1:
UAC INVITE/REGISTER -> LB -> SIP0
SIP0 401 with nonce1 challenge -> LB -> UAC
UAC ACK -> LB -> SIP0
2:
UAC INVITE/REGISTER with nonce1 response -> LB -> SIP1
SIP1 401 with nonce2 challenge -> LB -> UAC
UACK ACK -> LB -> SIP1
3:
UAC INVITE/REGISTER with nonce2 response -> LB -> SIP0
SIP0 401 with nonce1 challenge -> LB -> UAC
UACK ACK -> LB -> SIP0
4: UAC either gives up or goes to 2
Using the dispatcher module this can be solved by using a hash over either
from/to/request URI. I can't find any hints for forcing the dialog to 1
backend.
BTW the idea is to keep the loadbalancing proxy as simple/stupid as possible
(no db), the backends have a shared db.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:57 p.m.
New subject: Loadbalancing proxy using DNS SRV instead of dispatcher
On Thursday 16 April 2015 17:15:16 Cezary Siwek wrote:
Try setting weight of all your SRV records to 0.
Was 1, setting to 0 appears circumvent the problem but also impacts load
balancing itself: no loadbalancing is being done. The 1 target to be used
appears to be generated from the SRV list when refreshing the SRV record from
dns.
--
Telefoon: 088 0100 700
Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl
http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel
17097024
17 Apr
17 Apr
4:41 a.m.
New subject: Loadbalancing proxy using DNS SRV instead of dispatcher
Hi,
I haven't tried it mysefl (will probably do it in a near future) but
there is core configuration parameter to be enabled.
http://www.kamailio.org/wiki/cookbooks/4.2.x/core#dns_srv_lb
As we speak, some of our clients reported similar issue when connection
to us using FreeSWITCH and setting weight to 0 seem to resovle the issue
(it was prosposed solution on freeswitch mailing list)
We internally don't do SRV LB in outbound direction but probably will so
please come back with your results.
Cezary
On 16/04/2015 17:57, Daniel Tryba wrote:
On Thursday 16 April 2015 17:15:16 Cezary Siwek
wrote:
Try setting weight of all your SRV records to 0.
Was 1, setting to 0 appears circumvent the problem but also impacts load
balancing itself: no loadbalancing is being done. The 1 target to be used
appears to be generated from the SRV list when refreshing the SRV record from
dns.
5:09 a.m.
El Fri, 17 Apr 2015 09:41:55 +0100
Cezary Siwek <cezary.siwek(a)nexmo.com> escribió:
Hi,
I haven't tried it mysefl (will probably do it in a near future) but
there is core configuration parameter to be enabled.
http://www.kamailio.org/wiki/cookbooks/4.2.x/core#dns_srv_lb
As we speak, some of our clients reported similar issue when connection
to us using FreeSWITCH and setting weight to 0 seem to resovle the issue
(it was prosposed solution on freeswitch mailing list)
We internally don't do SRV LB in outbound direction but probably will so
please come back with your results.
I had the issue in the past and here's how it was solved:
- When sending your "first" request to the server resolving it by DNS, you can
store the destination IP in a hash table (callid--> IP) using onsend_route
The kamailio script should check something like this:
1: Initial request. Is the callid in hash table?
Yes --> Don't resolve DNS and send it to the stored IP
NO --> Use DNS to send it and store the IP using onsend_route
If you set the autoexpire of keys to 3-4 secs it will work well.
cheers,
Jon
5:25 a.m.
New subject: Loadbalancing proxy using DNS SRV instead of dispatcher
On Friday 17 April 2015 11:09:23 Jon Bonilla wrote:
I had the issue in the past and here's how it was
solved:
- When sending your "first" request to the server resolving it by DNS, you
can store the destination IP in a hash table (callid--> IP) using
onsend_route
The kamailio script should check something like this:
1: Initial request. Is the callid in hash table?
Yes --> Don't resolve DNS and send it to the stored IP
NO --> Use DNS to send it and store the IP using onsend_route
If you set the autoexpire of keys to 3-4 secs it will work well.
Sounds like a very useful solution. May need some extra mangling for failover
situations
Thank you for sharing.
--
Telefoon: 088 0100 700
Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl
http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel
17097024
9:06 a.m.
New subject: Loadbalancing proxy using DNS SRV instead of dispatcher
On 17/04/15 11:25, Daniel Tryba wrote:
On Friday 17 April 2015 11:09:23 Jon Bonilla wrote:
Another possibility is to configure the servers to accept the nonce
generated by the other server. This is possible by setting the same
secret for auth module:
- http://kamailio.org/docs/modules/stable/modules/auth.html#auth.p.secret
The the time on the servers must be sync'ed.
I expect is not going to work with one time nonce.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
I had the issue in the past and here's how it
was solved:
- When sending your "first" request to the server resolving it by DNS, you
can store the destination IP in a hash table (callid--> IP) using
onsend_route
The kamailio script should check something like this:
1: Initial request. Is the callid in hash table?
Yes --> Don't resolve DNS and send it to the stored IP
NO --> Use DNS to send it and store the IP using onsend_route
If you set the autoexpire of keys to 3-4 secs it will work well.
Sounds like a
very useful solution. May need some extra mangling for failover
situations
5:14 a.m.
New subject: Loadbalancing proxy using DNS SRV instead of dispatcher
On Friday 17 April 2015 09:41:55 Cezary Siwek wrote:
http://www.kamailio.org/wiki/cookbooks/4.2.x/core#dns_srv_lb
As we speak, some of our clients reported similar issue when connection
to us using FreeSWITCH and setting weight to 0 seem to resovle the issue
(it was prosposed solution on freeswitch mailing list)
We internally don't do SRV LB in outbound direction but probably will so
please come back with your results.
dns_srv_lb is set to yes.
The solution of setting weight to 0 works because it disables loadbalancing.
It appears that whenever the SRV records are queried by kamailio, at that
point in time the a random result record is taken as destination for all
request to that domain (didn't test any failover scenario) till next cache
refresh. This idea is supported by disabling dns caching in kamailio, then the
destination for requests is randomized and the same problem appears when
setting weight to not 0.
--
Telefoon: 088 0100 700
Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl
http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel
17097024
3363
days inactive
3364
days old
7 comments
4 participants
participants (4)
-
Cezary Siwek -
Daniel Tryba -
Daniel-Constantin Mierla -
Jon Bonilla (Manwe)