5 Oct
2005
5 Oct
'05
6:13 a.m.
Hi Klaus,
that was a second idea :).
actually you do not have to do anything special to keep the CANCEL in
memory - it will be kept as transaction if you forward it statefully.
what I do not like in this approach is that for each INVITE you have to
search for a potential previous CANCEL - which is quite consuming... I
would prefer an approach with minimum impact on the performance.
regards,
bogdan
Klaus Darilion wrote:
What about forwarding the CANCEL and keept in in memory. For every
incoming INVITE we will first check if there is already a CANCEL for
this.
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
itself.
this is more a logical problem and not sure how it can be fixed (if
it can be fixed). The only idea it come into my mind is to delay the
CANCEL that does not match a transaction....but is quite ugly.