[Serusers] 487 hop to hop????
lgfausak at gmail.com
Thu Aug 25 22:40:01 CEST 2005
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:
> >>>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.
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 at thursday.com
More information about the sr-users