On Wed, 2008-09-24 at 11:55 -0400, keccles wrote: > > 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?
I think we're in agreement here. > Is the proxy supposed to ACK > and BYE a 2xx response for a call which the calling party has > subsequently cancelled? No, 2xx always goes upstream. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
