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

thrillerbee thrillerbee at gmail.com
Tue Jan 25 16:46:31 CET 2011


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 <thrillerbee at 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 <abalashov at 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 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/
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110125/2264628b/attachment.htm>


More information about the sr-users mailing list