[SR-Users] Multiple SIP-servers with SRV-records and authentication secrets

2016-04-03 Thread Alfred E. Heggestad
Dear SIP-experts and DNS-SRV gurus; I have some questions to the deployers of SER/Kamailio and best current practice for multiple SIP-servers with SRV-records and authentication. This is not a question about Kamailio itself but rather experience with deployment of it in the field. The current

Re: [SR-Users] Multiple SIP-servers with SRV-records and authentication secrets

2016-04-03 Thread James Cloos
> "AH" == Alfred E Heggestad writes: AH> 1. Multiple SIP-servers are deployed for the same domain AH> 2. The DNS is configured with SRV-records for load balancing, AH>example: (lets call the domain "example.com") AH> 3. when a SIP client registers, it resolves the domain using RFC3263 [

Re: [SR-Users] Multiple SIP-servers with SRV-records and authentication secrets

2016-04-03 Thread Daniel-Constantin Mierla
Hello, are you using also a different realm per server? Because, iirc, the username/password must be the same for a realm. On the other hand, for many kamailio in a farm should not matter much, because the relevant attribute in the 401 is the nonce. If you set the secret for generating the nonce

Re: [SR-Users] Multiple SIP-servers with SRV-records and authentication secrets

2016-04-04 Thread Olle E. Johansson
> On 03 Apr 2016, at 18:09, Alfred E. Heggestad wrote: > > Dear SIP-experts and DNS-SRV gurus; > > > I have some questions to the deployers of SER/Kamailio and > best current practice for multiple SIP-servers with SRV-records > and authentication. This is not a question about Kamailio itself >

Re: [SR-Users] Multiple SIP-servers with SRV-records and authentication secrets

2016-04-09 Thread Alfred E. Heggestad
On 04/04/16 10:27, Olle E. Johansson wrote: On 03 Apr 2016, at 18:09, Alfred E. Heggestad wrote: Dear SIP-experts and DNS-SRV gurus; I have some questions to the deployers of SER/Kamailio and best current practice for multiple SIP-servers with SRV-records and authentication. This is not a