On Wed, 2008-09-24 at 11:33 -0400, Dale Worley wrote: > On Wed, 2008-09-24 at 11:16 -0400, keccles wrote: > > > It seems to me that 487 Canceled would be preferable, although I don't > > > know if we can cause that to happen. But I see 487 as indicating "ring > > > no answer" as well as "caller canceled call". > > Ring no answer currently causes 408. Do we want to substitue 487 in > > this case? > > That's an interesting question. It's clear that when they wrote 3261 > that 408 is intended to be generated by the phone for RNA. But as far > as I know, PBXs all do the RNA time-out in the proxy, not the phone, so > the response generated to the INVITE is 487. So I think that people > expect 487 to mean RNA and 408 to mean "network failure". > > But I'm wondering if the current stack logic is doing something > incorrect here -- when a CANCEL comes downstream, (in a proxy) it causes > the transaction to stop generating forks, but it does not cause the > transaction to end and send a response upstream -- that happens only > when the downstream UAs sent final responses, or when the transaction > times out. So the response sent upstream for a canceled transaction is > mostly determined by the responses received from downstream. > Currently, when the calling party sends a Cancel to the proxy, the proxy sends a cancel on all forks. The Cancel causes some kind of response for each fork, either a far-end response or a timeout.
Are you saying that this behavior is not correct? Doesn't the proxy need to wait in the case where the Cancel overlaps a final response, especially a 2xx response? Is the proxy supposed to ACK and BYE a 2xx response for a call which the calling party has subsequently cancelled? The proxy also _initiates_ cancels on its forks. This can happen when the call is simply not answered and the proxy times out. This is the case you suggest we return 487 for RNA. -Kathy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
