Hi Tavis,
this is similar with an idea suggested by Juha some days ago. Just to improve the CANCEL processing, right after "
log(1, "Route{0}: There was a CANCEL that matched a transaction..");
just to: t_relay(); exit;
regards, bogdan
Tavis P wrote:
Just wanted to post an update on this issue, someone posted a link to a "t_check_trans()" function (its in the openser cookbook) that could be used to determine if the CANCEL had a corresponding transaction.
If the transaction was not found it could be ignored by OpenSER leading the UAC to resend the CANCEL.
After a few seconds OpenSER finishes processing the INVITE, creates a transaction and that matches one of the retransmitted CANCEL messages and the call is torn down properly
This has resolved the issue I came across, just in case anyone was curious
eg.
if ( is_method("CANCEL") ) { # If the transaction this message belongs to isn't knownabout by # the proxy, then silently discard it if ( !t_check_trans() ) { log(1, "Route{0}: There was a CANCEL that DIDN't match a transaction.."); exit; } log(1, "Route{0}: There was a CANCEL that matched a transaction.."); }
Klaus Darilion wrote:
Tavis P wrote:
With the latest CVS build of OSER, when an INVITE is sent followed by a CANCEL, before OSER has finished processing the initial INVITE, the outbound call is not torn down, and SER routes the CANCEL message to
AFAIK this may happen with all versions of ser/openser.
btw: Your SIPURA is broken:
- It sends a CANCEL although it has not received a response yet.
According tot the standard the UAC must withheld the CANCEL until a provisional response is received.
- It sends an INVITE right after the CANCEL. Weird.
regards klaus