On 8/25/05, Jiri Kuthan jiri@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