Re: [Yxa-devel] OPTIONS-pinging
Krister Jarl wrote: ... > Can you please clarify for me why this is incorrect DNS configuration? I > had the following setup in mind when writing the question. > > _sip._udp.sip.example.com. 41520 IN SRV 1 1 5060 > server1.example.com. > _sip._udp.sip.example.com. 41520 IN SRV 2 1 5060 > server2.example.com. > > What this essentially means is that server1.example.com should be used > as long as it's responding. But this doesn't happen since it falls out > of the blacklist. Sure, server1 should be used whenever it is available and YXA should try to fall back to server2 when server1 is _not_ available. If server1 is permanently unavailable, it is a misconfiguration of DNS to list it as the best candidate for example.com. This is how I understood the scenario that you wanted to "solve" with a longer blacklisting period or otherwise... SIP, as specified in RFC3261 does have a problem where it will always fail (timeout) the first non-INVITE sent to example.com when server1 becomes unavailable (if the first request sent to example.com after that is a non-INVITE). The reason for this is basically that the transaction layer will not ask the transport layer to try server2 before the transport layer has reported the timeout of server1, and when it does - well then it's too late because the (non-INVITE) transaction has timed out. /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] OPTIONS-pinging
Thanks for your reply! >Krister Jarl wrote: >> Hi! >> >> >> >> I've noticed that Yxa (pstnproxy) doesn't seem to start options-pinging >> blacklisted destination unless there are outgoing requests to be sent to >> that destination. > >Right. > >> What happens is that if we have a very low rate of outgoing calls to a >> destination, no options-pinging is started (although indicated by the >> probe_t in blacklist_entry) and the blacklist entry expires. > >Right. You have to draw the line somewhere; all SIP servers can't keep >track of availability of all other SIP servers on the internet, so I've >drawn the default line in YXA such as that you only keep track of peers >you've tried to speak to recently. > Ok. >> If our >> DNS-records indicate that this destination is the preferred one we will >> have a situation where every call is failed (leading to a new a >> blacklist, that then expires and so on). One could adjust the >> sipsocket_blacklist_duration time upwards but this will just by you some >> time, it doesn't really solve the problem. > >YXA can never solve this problem since the problem is incorrect DNS >configuration of the domain you are sending occasional requests to. > Can you please clarify for me why this is incorrect DNS configuration? I had the following setup in mind when writing the question. _sip._udp.sip.example.com. 41520 IN SRV 1 1 5060 server1.example.com. _sip._udp.sip.example.com. 41520 IN SRV 2 1 5060 server2.example.com. What this essentially means is that server1.example.com should be used as long as it's responding. But this doesn't happen since it falls out of the blacklist. >> Is this behaviour intentional or is this a bug? > >Intentional. You are most welcome to argue for a change of the logic >though if you'd like. I reserve the right to retort =). > >/Fredrik :-) /Krister ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] OPTIONS-pinging
Krister Jarl wrote: > Hi! > > > > I've noticed that Yxa (pstnproxy) doesn't seem to start options-pinging > blacklisted destination unless there are outgoing requests to be sent to > that destination. Right. > What happens is that if we have a very low rate of outgoing calls to a > destination, no options-pinging is started (although indicated by the > probe_t in blacklist_entry) and the blacklist entry expires. Right. You have to draw the line somewhere; all SIP servers can't keep track of availability of all other SIP servers on the internet, so I've drawn the default line in YXA such as that you only keep track of peers you've tried to speak to recently. > If our > DNS-records indicate that this destination is the preferred one we will > have a situation where every call is failed (leading to a new a > blacklist, that then expires and so on). One could adjust the > sipsocket_blacklist_duration time upwards but this will just by you some > time, it doesn't really solve the problem. YXA can never solve this problem since the problem is incorrect DNS configuration of the domain you are sending occasional requests to. > Is this behaviour intentional or is this a bug? Intentional. You are most welcome to argue for a change of the logic though if you'd like. I reserve the right to retort =). /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
