Re: [reSIProcate] RRVIP and white list
"The
first one that works will be the one that is used from then on,
regardless of how many DNS results are returned for that same
hostname in the future. (it will also ignore changes in the
prioritization built into DNS) "
This is caused by
// !bwc! Debatable.
DnsResult->whitelistLast(), right?
Suggest to add #ifdefined (USE_DNS_VIP) to above.
Thanks Byron, very good explanation.
kaiduan
----- Original Message ----
From: Byron Campen <bcampen@xxxxxxxxxxxx>
To: kaiduan xie <kaiduanx@xxxxxxxx>
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Sent: Friday, May 11, 2007 11:40:09 AM
Subject: Re: [reSIProcate] RRVIP and white list
Whitelisting is an optional behavior that will cause the stack to
indefinitely re-use a DNS result that has proven fruitful. So, the
stack tries to send a message, and gets multiple DNS results. The
first one that works will be the one that is used from then on,
regardless of how many DNS results are returned for that same
hostname in the future. (it will also ignore changes in the
prioritization built into DNS) This is non-standard behavior, and
will cause DNS-based load-balancing to not work properly. However,
there are use-cases for this, which is why it is there.
Best regards,
Byron Campen
> Some quesitons,
>
> 1) Can anyone explain the rationale behind RRVIP and whitelist?
>
> 2) In DnsInterface, it seems that if we do not define USE_DNS_VIP,
> then RRVIP and whitelist will not come into play. Then the question
> comes, why not define USE_DNS_VIP?
>
> 3) What is the reason for the following action?
>
> TransactionState::sendToTU()
> {
> ....
> // !bwc! Debatable.
> DnsResult->whitelistLast()
> }
>
> 4) In TransactionState::sendToTU()
> case 408:
> if(sipMsg->getReceivedTransport() == 0 && mState ==
> Trying) // only blacklist if internally generated and we haven't
> received any responses yet
> {
> // blacklist last target.
> // ?bwc? How long do we blacklist this for? Probably
> should make
> // this configurable. TODO
> mDnsResult->blacklistLast(resip::Timer::getTimeMs()
> + 32000);
> }
>
> break;
>
> We miss the case where the INVITE client transaction is in Calling
> state.
>
> BTW, I am referring to 1.1 version.
>
> Thanks,
>
> kaiduan
>
>
> Ask a question on any topic and get answers from real people.
> Go to Yahoo! Answers and share what you know at http://
> ca.answers.yahoo.com
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
Get news delivered with the All new Yahoo! Mail. Enjoy RSS feeds right
on your Mail page. Start today at http://mrd.mail.yahoo.com/try_beta?.intl=ca