5 Oct
2005
5 Oct
'05
6 a.m.
Bogdan-Andrei Iancu wrote:
ugly
regards
klaus
Hi Tavis,
please see my inline comments.
regards,
bogdan
Tavis P 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. I have a
development cluster of mediaproxy servers setup and one of them
was taken offline but left in the loop which increased the time it took
for a message to be processed which is how i came across this situation
(it took some seconds before the INVITE was able to be transmitted to
the nexthop_proxy)
what you can do is to force transaction creation before any
time-consuming operations (use t_newtran to create the transaction) -
but be very, very carefully - you will have to use exclusively statefull
functions and what is more important, all later changes over the message
will not be saved into transaction.
.....and coming back to the idea: create the transaction, do all
time-consuming operations and forward. If in the mean while you get a
CANCEL, it will match the transaction, but it will not be forwarded
since there is no branch (no forward done); but once you get a reply for
the INVITE, OpenSER will remember that it was CANCEL and generate one -
this is a new feature of this release ;)