Re: [reSIProcate] internally generated 408/503
> 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.
>