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.
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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.
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.
El Fri, 17 Apr 2015 09:41:55 +0100 Cezary Siwek cezary.siwek@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
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.
On 17/04/15 11:25, Daniel Tryba wrote:
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
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
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.
-
Cezary Siwek -
Daniel Tryba -
Daniel-Constantin Mierla -
Jon Bonilla (Manwe)