[OpenSER-Devel] [ openser-Bugs-1844798 ] Transaction matching causes CANCEL to fail

[SourceForge.net]

Bugs item #1844798, was opened at 2007-12-05 14:55
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1844798&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: modules
Group: ver devel
>Status: Closed
>Resolution: Invalid
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Transaction matching causes CANCEL to fail

Initial Comment:
The new transaction matching code in 1.3 for CANCEL does find a match as shown below, however the CANCEL is not relayed to the device that is to receive the CANCEL.

DBG:tm:t_newtran: T on entrance=0xffffffff
DBG:core:parse_headers: flags=ffffffffffffffff
DBG:core:parse_headers: flags=78
DBG:tm:t_lookup_request: start searching: hash=14478, isACK=0
DBG:tm:matching_3261: RFC3261 transaction matched, tid=7b84a7f5EE519894
DBG:tm:t_lookup_request: REF_UNSAFE: after is 2
DBG:tm:t_lookup_request: transaction found (T=0xa7bd2074)
DBG:tm:t_retransmit_reply: buf=0xb7b71c40: SIP/2.0 2..., shmem=0xa7bd3c0c: SIP/2.0 2
DBG:tm:t_unref_cell: UNREF_UNSAFE: after is 1
DBG:tm:t_unref: UNREF_UNSAFE: after is 1
DBG:core:destroy_avp_list: destroying list 0xa7bd4148
DBG:core:qm_free: params(0xa79a8000, 0xa7bd4148), called from usr_avp.c: destroy_avp_list(390)

The same processing on a 1.2 system produced the following.  It clearly shows the "end-to-end" cancel proceeding. The device at 192.168.1.99 is the correct recipient of the CANCEL.

DEBUG: t_newtran:  T on entrance=0xffffffff
core:parse_headers: flags=ffffffffffffffff
core:parse_headers: flags=78
t_lookup_request: start searching: hash=46314, isACK=0
DEBUG: RFC3261 transaction matching failed
DEBUG: t_lookup_request: no transaction found
DBG: trans=0xa7b21fc8, callback type 1, id 2 entered
trace_onreq_in: trace off...
DBG: trans=0xa7b21fc8, callback type 1, id 1 entered
DBG: trans=0xa7b21fc8, callback type 1, id 0 entered
core:parse_headers: flags=78
DEBUG:rr:is_direction: param ftag not found
core:check_via_address: params x.x.x.x, 192.168.1.99, 0
DEBUG:tm:set_timer: relative timeout is 500000
DEBUG: add_to_tail_of_timer[4]: 0xa7b22114 (25700000)
DEBUG:tm:set_timer: relative timeout is 30
DEBUG: add_to_tail_of_timer[0]: 0xa7b22130 (55)
DEBUG: e2e_cancel: e2e cancel proceeding

Detailed sip traces and logs have been provided "offline" because of their private nature.

Regards,
Norm

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2007-12-06 23:07

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Actually what was happening was that the CANCEL processing was delayed
(due an unresponsive acc Radius server) enough to allow the 200 OK for
INVITE the pass through - of course, when finally openser was trying to
send out the CANCEL, nothing was left to CANCEL, so no forward was done
(just reply).

Bogdan 

----------------------------------------------------------------------

Comment By: Norm Brandinger (norm_brandinger)
Date: 2007-12-05 15:06

Message:
Logged In: YES 
user_id=1786021
Originator: NO

Minor correction: 192.168.1.99 is the device initiating the CANCEL.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1844798&group_id=139143