[SR-Users] accounting serial forked transactions with 302 from LCR

[Alex Balashov]

On 01/24/2011 05:53 PM, thrillerbee wrote:
> 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 at 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 at 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 at Kamailio
> ...
> 2.262195 Kamailio -> caller SIP/SDP Status: 183 Session Progress, with
> session description
> 9.422170 caller -> Kamailio SIP Request: CANCEL sip:15202362038 at Kamailio
> 9.424296 Kamailio -> caller SIP Status: 200 canceling
> ...
> 9.423958 Kamailio -> outbound_proxy SIP Request: CANCEL
> sip:15202362038 at 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 at 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 <thrillerbee at gmail.com
> <mailto:thrillerbee at 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?

Are you sure you're setting the accounting logging flag when 
processing CANCELs?

-- 
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/