[Serusers] 487 hop to hop????

[Jiri Kuthan]

At 04:58 PM 8/25/2005, Greg Fausak wrote:

>On Aug 25, 2005, at 9:30 AM, Klaus Darilion wrote:
>
>>Hi Greg!
>>
>>Greg Fausak wrote:
>>
>>>Howdy,
>>>I've been scouring the RFCs looking for this verbiage.
>>>One of our developers here is telling me that is a mistake, that the
>>>487 needs to come from the far end.  Do you know where I might
>>>find more information about this topic?
>>
>>Imagine a forked call. If the call in canceled, ser has to wait for  
>>the 487 messages from all branches. Only after it received the 487  
>>from all branches, it will send a 487 to the caller.
>
>Using this logic ser has to wait for the 487 before it sends it to the
>caller.  What I'm seeing is the 487 is sent straight away, right  
>after the
>200.  Is this because the call is not forked?  If it was forked I'd  
>see the 487s
>come back to the ser proxy before the ser proxy sends it to the caller?

It does not care if the request is forked or not, it just sends the
487 straight. Which makes upstream  clients better happy if one or
more downstream servers don't respond to the CANCEL request.

One may argue whether this optimization is worth it or not,
but in absence of counter-arguments I am not sure we should
change it.

-Jiri