Re: [reSIProcate] internally generated 408/503
I can't think of any case where you would blacklist from a 408 that
came from the wire.
(I'm stating that more softly than I want to because I'm tired).
Most of the time, if somethings there enough to send you a 408, you
definitely still want
to talk to it. You really _don't_ want to blacklist some proxy that
sent you a 408 because
its timer C went off and it canceled all the downstream legs for
instance.
What case are you thinking of Jason?
On Oct 30, 2006, at 4:58 PM, Jason Fischl wrote:
I didn't think it should blacklist the SRV record - but certainly the
particular tuple that sent the 408.
Jason
On 10/30/06, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
I'm not sure this was a valid change. network generated 408 should
still black list.
I don't think so - I discussed this with RjS in some detail. I was
seeing blacklisting of an entire proxy (SRV record) - when one of the
registered endpoints disappeared.
Consider the following:
1. Endpoint A registers with a proxy.
2. Endpoint A is disconnected from the network.
3. Endpoint B (using resip) places a call to endpoint A, through the
proxy.
4. The proxy returns a 408 after 32s, since endpoint A is not
reachable, but the registration is still valid.
5. Endpoint B (Resip) - blacklists the proxy SRV record.
In this case - the proxy (ie. first hop) - is alive and well (as
indicated by the 408 response that is sent) - so it should not be
blacklisted.
On the other hand - if the stack generated the 408 and we have not
seen
any other responses from the wire - then the first hop is not
available
and the record should be blacklisted.
Scott
-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On
Behalf
Of Jason Fischl
Sent: Monday, October 30, 2006 5:36 PM
To: Scott Godin
Cc: Byron Campen; resiprocate
Subject: Re: [reSIProcate] internally generated 408/503
On 10/30/06, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
isExternal doesn't work. Apparently we are making internally
generated
408's appear as external so that the transaction state handles them
in
the same manner as external messages. The SipMessage method
getReceivedTransport() works - just look for a return of 0.
I kind of thought that might be the case.
BTW: I committed a fix to resip so that we will not blacklist if a
408
response is from the wire.
I'm not sure this was a valid change. network generated 408 should
still black list.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel