[reSIProcate] internally generated 408/503

[Byron Campen]

	Blacklisting on a 408 from the wire is incorrect. Doing so will  
break basically any deployment that uses more than one hop. For  
example, UA1 -> P1  -> nowhere (UDP) will cause UA1 to blacklist P1  
when P1 times out and sends back a 408. If UA1 decides to send  
another request, it will fail regardless of its eventual target (this  
includes stuff like REGISTER requests). It is acceptable for P1 to  
blacklist the tuple it tried to send to, but that is only because  
that tuple sent no response at all.

Best regards,
Byron Campen

> 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
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061030/77c023c9/attachment.bin>