Re: [SR-Users] accounting serial forked transactions with 302 from LCR
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.comwrote: 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.00 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
Re: [SR-Users] accounting serial forked transactions with 302 from LCR
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.comwrote: 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.00 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
Re: [SR-Users] accounting serial forked transactions with 302 from LCR
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.00 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 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? Thanks, Ryan ___ 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
