After more investigation, it seems my issue is not just with the accounting module. Instead of proxying the 487 back to the original UAC, Kamailio passes a 302. To simplify, I've removed the leg outbound from Kamailio to the carrier: 0.000000 caller -> Kamailio SIP/SDP Request: INVITE sip:15202362038@Kamailio, with session description 0.002294 Kamailio -> caller SIP Status: 100 trying -- your call is important to us 0.002579 Kamailio -> LCR SIP/SDP Request: INVITE sip:15202362038@Kamailio, with session description 0.038023 LCR -> Kamailio SIP Status: 100 Trying 0.046877 LCR -> Kamailio SIP Status: 302 Redirect Request 0.047807 Kamailio -> LCR SIP Request: ACK sip:15202362038@Kamailio ... 2.262195 Kamailio -> caller SIP/SDP Status: 183 Session Progress, with session description 9.422170 caller -> Kamailio SIP Request: CANCEL sip:15202362038@Kamailio 9.424296 Kamailio -> caller SIP Status: 200 canceling ... 9.423958 Kamailio -> outbound_proxy SIP Request: CANCEL sip:15202362038@upstream_carrier 9.487730 outbound_proxy -> Kamailio SIP Status: 200 canceling 9.576758 outbound_proxy -> Kamailio SIP Status: 487 Request Terminated ... *9.579157 Kamailio -> caller SIP Status: 302 Redirect Request* 9.626503 caller -> Kamailio SIP Request: ACK sip:15202362038@Kamailio This worked flawlessly in OpenSIPS so I'm sure it has something to do with a difference since the 2 split. Any advice would be much appreciated. Thanks, Ryan On Mon, Jan 24, 2011 at 9:00 PM, thrillerbee &lt;thrillerbee(a)gmail.com <mailto:thrillerbee@gmail.com>> wrote: I'm converting my OpenSIPS routers to Kamailio & have run into a small complication. The proxy pushes all INVITEs to a least-cost router. This LCR responds with a list of routes as contact instances in a 302 Redirect. Calls are routing a serially forking normally. Connected & failed calls account normally. However, if the caller cancels the call, the acc module includes the 302 in the transaction record as the final response as opposed to the actual final response - the 487 Request Canceled. Is there something I could be missing that would cause this?

Alex, Are you referring to the modparam that would include accounting CANCELs? If so, no - I'm not doing that because I don't want to account the CANCEL transaction. I only wish to account the INVITE transaction & final response (487). I have found that I can force a 487 response back to the original UAC by using t_reply("487","...") if t_is_canceled(), but then the acc module accounts 2 transactions - one with a 302 response code & another with the 487 response code. Thanks, Ryan On Tue, Jan 25, 2011 at 5:28 AM, Alex Balashov &lt;abalashov(a)evaristesys.com&gt;wrote;wrote: