osip-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [osip-dev] RFC 3263 - SRV Priority


From: Aymeric Moizard
Subject: Re: [osip-dev] RFC 3263 - SRV Priority
Date: Sat, 28 Mar 2015 11:48:46 +0100


2015-03-27 21:55 GMT+01:00 Rudolf Svanda <address@hidden>:

Hi Aymeric,

Hi Rudolf,

 
I have a small problem with DNS handling in libeXosip. I have 2 account
and DNS server answers with 2 SRV records:
_sip._udp.example.com,sip1.example.com,5061,1
_sip._udp.example.com,sip2.example.com,5062,2

eXosip tries to contact sip1.example.com first and sends REGISTER. There
is no answer, so eXosip changes to sip2.example.com.
Than eXosip starts registering second account and sends REGISTER to
sip2.example.com too.

As I understand RFC, REGISTER of second account should be send to
sip1.example.com first and after no answer is received, it should be
changed to second server.

Well, the rfc is about standard, but implementation will try to do optimal
stuff: if we know a server is failiing, then, it's quicker to use the working
server?
 
Additionally, is it possible manually to roll to next SRV answer?

No. The logic for NAPTR/SRV is internal and there is no application
configuration.
 
Our customer implements load balancing with 500 or 503 answers, so I would
like to switch to next SRV server after receiving those responses.
 
This requires internal change.
Note that as a 500 may comes for another reason, it may sometimes introduce
a loop because all servers may returns the same 500...

But i think with the current implementation of DNS cache it would affect
future transactions too.

The easier change can be to remove the DNS/NAPTR/SRV "cache": this
may be enough to avoid dependancy between transactions.

It may also means the INVITE may use a different proxy than REGISTER: 
which is usually not what you want... That's a reason for using cache in
exosip.

There is no doubt that an API to give the application layer more decision
about loadbalancing and failover would be interesting.

Also, the current way is not the best: most failover code is not very readable...


Regards
Aymeric
 
Thanks for answer.

BR
   Rudi





_______________________________________________
osip-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/osip-dev



--

reply via email to

[Prev in Thread] Current Thread [Next in Thread]