On 8/25/05, Juha Heinanen <jh(a)tutpro.com> wrote:
Greg Fausak writes:
It seems to me that the ser proxy is responding
to the cancel with
a 487. If I had to make it come from the far end can that be
accomplished with ser?
ser is not responding to cancel with 487. response to cancel is 200
canceling. 487 is sent by uas when it receives a cancel to an invite to
which it has not yet sent a final response.
That's what I would think should happen.
The 487 would come all the way from the UAS to the UAC. However,
what I'm seeing is SER is responding with a 487 at each hop.
I am running t_relay between each hop, so, that's stateful.
I've attached an .rtf file of the trace overview, it shows the 183s
coming end to end, from the uas to the uac, but the 487s are being
generated by the ser proxies hop to hop.
I can eliminate that behaviour if I use 'forward' between proxies instead
of t_relay. Maybe I just don't understand the implication of these
ser commands.
t_relay is a transaction/stateful, forward is not.
---greg
now the question is what is the proper thing for statefull ser to do,
when uac cancels an invite which is forked by ser to multiple
destinations and some of the branches have already responded with final
non 2xx reply.
currently in failure route ser.cfg sees the lowest numbered reply
whereas ser itself responds to uac with 200 canceling and then with 487.
in my opinion this makes no sense, because it makes failure route think
that a uas was, for example, busy and acts accordingly. a better
behavior would be if also failure route would see 487 as the final
reply.
i'm currently experimenting with the following change to t_reply.c
t_pick_branch to solve this problem:
for ( b=t->first_branch; b<t->nr_of_outgoings ; b++ ) {
/* "fake" for the currently processed branch */
if (b==inc_branch) {
if (inc_code == 487) {
lowest_b=b;
lowest_s=inc_code;
break;
}
if (inc_code<lowest_s) {
lowest_b=b;
lowest_s=inc_code;
}
continue;
}
...
-- juha
--
Greg Fausak
greg(a)thursday.com