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

thrillerbee thrillerbee at gmail.com
Mon Jan 24 23:53:10 CET 2011


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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110124/67cec2a1/attachment.htm>


More information about the sr-users mailing list