[reSIProcate] DNS graylist issue with non-INVITE transaction failures
Aron Rosenberg
arosenberg at logitech.com
Mon Oct 3 12:45:04 CDT 2011
I have the following topology setup.
Focus A <--> Proxy A <--> Proxy B <--> User B
User B does a SUBSCRIBE and INVITE to Focus A
At some point, User B loses connectivity due to a WiFi dropout or other such
network interface change that is transient.
If Focus A sends a NOTIFY to User B, the NOTIFY to User B will fail with a *
locally* generated 408 before Proxy B sends back a 503 or 504 message. Also
because this is a non-INVITE transaction, no 100 Trying is sent by Proxy A
or Proxy B.
Now because this was a locally generated 408 error a DNS graylist entry is
added for the IP Address of Proxy A since it was an in-dialog message that
was sent based on a numerical IP Route header.
This then causes all of Focus A's other traffic which is Routed through
Proxy A to temporarily fail including new transactions.
Another interesting side effect is that even though the original Route
header did not include a transport= value (Route: x.x.x.x:port), resip will
try to contact that IP:Port with TCP even though TCP was never part of the
original DNS lookup (not in the SRV records).
I can see a few possible ways to fix this issue:
- Change Proxy A to send 100 Trying for non-INVITE transactions. This will
change the TransactionState from "Trying" to "Connecting" which then won't
trigger a graylist (requires Proxy changes)
- Change TransactionState class to only graylist entries for INVITE
transactions based on "mMachine==ClientInvite" since those are the only ones
which seem to send 100 Trying messages.
- Allow Application writer control over black/gray list.
- If we don't want to break source compatibility, we could modify the
MarkListener class to add a new virtual function "before" insertion which
could return true/false or allow modifying the Mark or Expirery.
- If we wanted to break source compatibility, we could modify the current
onMark callback to have a new signature and be called before insertion
allowing changing of the values.
If anybody is interested, I have a full resip debug log showing this issue
from Focus A's perspective.
Aron Rosenberg
Sr. Director, Engineering,
LifeSize, a division of Logitech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20111003/3957976f/attachment.htm>
More information about the resiprocate-devel
mailing list