[reSIProcate] internally generated 408/503

[Robert Sparks]

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 at icescape.com> 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 at gmail.com [mailto:jason.fischl at gmail.com] 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 at icescape.com> 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 at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel