On 8/25/05, Juha Heinanen jh@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