[OpenSER-Devel] [ openser-Bugs-1814350 ] transaction not released after handle_subscribe()

[SourceForge.net]

Bugs item #1814350, was opened at 2007-10-16 08:04
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1814350&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: Fixed
Priority: 3
Private: No
Submitted By: Juha Heinanen (juhe)
>Assigned to: anca (anca_vamanu)
Summary: transaction not released after handle_subscribe()

Initial Comment:
i add this old thing to the tracker, because it would be nice to get it fixed before 1.3 is released.

when sip ua sends an in-dialog subscribe to a non-existing subscription, i get the following to syslog:

Aug 31 08:58:26 tutpro /usr/sbin/openser[13320]: Handling in-dialog SUBSCRIBE to <sip:192.98.101.10:5090>
Aug 31 08:58:26 tutpro /usr/sbin/openser[13320]: PRESENCE:get_database_info:ERROR No matching subscription dialog found in database
Aug 31 08:58:26 tutpro /usr/sbin/openser[13320]: PRESENCE:handle_subscribe:ERROR getting stored info
Aug 31 08:58:26 tutpro /usr/sbin/openser[13320]: WARNING: script writer didn't release transaction

perhaps an ALERT would be better description of this situation than ERROR.  

my main point, however, is the warning about not releasing transaction, which should not be issued, because my script DOES release the transaction:

        if (method == "SUBSCRIBE") {
            if (! t_newtran()) {
                xlog("L_ERR", "Could not create new transaction for <$rm> to <$ru>\n");
                sl_send_reply("500","Could not create new transaction");
                exit;
            };
     xlog("L_INFO", "Handling in-dialog SUBSCRIBE to <$ru>\n");
                if (!handle_subscribe()) {
                    xlog("L_ERR", "SUBSCRIBE to <$ru> failed\n");
                    t_reply("500", "SUBSCRIBE failed");
                };
                t_release();
                exit;
        } ...

also, since handle_subscribe() fails, why is the corresponding xlog not executed?

-- juha

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

>Comment By: anca (anca_vamanu)
Date: 2007-10-23 14:38

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

Hello Juha,

The solution you proposed, and at which we already thought of, can not be
implemented in presence module. The reason is that it is compulsory to send
Notify messages immediately after Publish/Subscribe messages are received
and also, the 2xx reply for the latter must be sent before the Notify
message. 
Therefore, we decided to send a stateless error reply in all cases and
return -1, for the transaction, if created, to be released from the
script.
Thanks for the report.

regards, 
Anca  

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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-23 11:18

Message:
Logged In: NO 

bogdan,

yes, wireshark shows that presence module returns "481 subscription does
not exist" response.  if presence module then exists the script, it
explains why the xlog statement is not executed nor is the transaction
released.

now the question is, how to properly handle this?  perhaps presence module
could in case of an error return -1 instead of 0 and put the error code and
error message in two avps which the script writer could then use in
t_reply?

-- juha


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

Comment By: Bogdan (bogdan_iancu)
Date: 2007-10-23 07:22

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

Hi Juha,

can you see the a stateless reply generated by the presence module in this
case of error? - having a quite look at the handle_subscribe() function, I
see that in case of error, it internally generates a stateless error reply
and then returns 0 to exit the script (that's why you do not see the
xlog).

>From logical point of view, there is a bit of mess about using TM support
here - the module sends stateless replies, but you create a
tranasction....I will have to talk with Anca about this.

regards,
bogdan

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

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