[Serusers] 487 hop to hop????

[Greg Fausak]

On 8/25/05, Jiri Kuthan <jiri at iptel.org> wrote:
> 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
> 
> 

Hi Jiri,

Hope all is well!

The main argument I'm getting is that the totag is different when the
SER proxy responds to the CANCEL with a 200 and then a 487.
The 487 totag does not match the original 183's totag.  The Via/branch
matches OK, but the developers here are relying on the totag to
match the 487 to the INVITE/183 transaction, not the CANCEL 'transaction'.

Do you know what I'm talking about?  What is your opinion?
I can forward a call trace (ngrep) or ethereal if you want to see it.

Are you heading out to VON?

---greg




-- 
Greg Fausak
greg at thursday.com