1 Nov
2005
1 Nov
'05
4:39 a.m.
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 known
about 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:
>1. 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.
>
>2. It sends an INVITE right after the CANCEL. Weird.
>
>regards
>klaus
>
>
>