Will this kind of application require the multi_leg_info modparam for the acc module? I didn't have to use it with OpenSIPS, but I'm running out of ideas with Kamailio.
Thanks, Ryan On Tue, Jan 25, 2011 at 2:29 PM, thrillerbee <thriller...@gmail.com> wrote: > 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 > <abalas...@evaristesys.com>wrote: > >> 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@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 <thriller...@gmail.com >>> <mailto:thriller...@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/ >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users@lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> > >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users