25 Aug
2005
25 Aug
'05
11:40 p.m.
On 8/25/05, Jiri Kuthan <jiri(a)iptel.org> wrote:
At 04:58 PM 8/25/2005, Greg Fausak wrote:
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(a)thursday.com
On Aug 25, 2005, at 9:30 AM, Klaus Darilion
wrote:
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 Greg!
Greg Fausak wrote:
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? 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.