Hello, Forgive me for the following long-winded description: Here is the scenario. Sip Server (VPS) is running at 10.0.0.162. PJSIP client is at 888 at 10.0.0.163. Bria is at 401 at 10.0.0.163. 401 andd 888 are in each others contact list. Capture from VPS tracelog shows times of subscribe refreshes from clients. VPS has set expiration timer to 180 seconds. Bria resubscribes about 17 to 18 seconds before the timer expires. PJSIP resubscribes 5 seconds before the timer expires. 07-28 12:42:05 Subscribe refresh from: 401 for 888 07-28 12:42:28 Subscribe refresh from: 888 for 401 07-28 12:44:47 Subscribe refresh from: 401 for 888 07-28 12:45:23 Subscribe refresh from: 888 for 401 07-28 12:47:29 Subscribe refresh from: 401 for 888 07-28 12:48:18 Subscribe refresh from: 888 for 401 07-28 12:50:11 Subscribe refresh from: 401 for 888 07-28 12:52:12 Subscribe refresh from: 888 for 401 07-28 12:52:54 Subscribe refresh from: 401 for 888 You can see normal process for first couple of cycles. Then after PJSIP resubscribed at 12:48:18, VPS sent a Notify to him after 401 changed its status at 12:49:18. The next resubscribe should come at 12:51:13 but guess what! It comes at 12:52:13. This seems to indicate that PJSIP is resetting the timer when it gets the Notify. It is possible for me to prevent PJSIP from ever sending a resubscribe simply by changing the status at 401 every 60 seconds. This causes a NOTIFY to be sent to PJSIP client and because it restarts the clock (resets countdown to 180 seconds) Sip Server never gets a resubscribe. Then VPS removes the subscription for 401 from 888. If PJSIP was not resetting the timer when it receives a NOTIFY, the situation above would not be possible. BRIA does not exhibit this behavior. Problem: in evsub.c function: on_tsx_state_uac starting after this comment: /* Update expiration from the value of expires param in * Subscription-State header, but ONLY when subscription state * is "active" or "pending", AND the header contains expires param. */ at line 1842. The comment is correct but the implementation is not. The else branch where next_refresh is set = sub->expires->expires_param should be removed. If it isn't, and the expires param is not included in the Subscription-State header, update_expires() gets called and the expiration timer gets reset to the original value (in my case 180 seconds). The calls to update_expires and set_timer should only be made if the conditions in the if statement are met. In addition, the value in sub_state->expires_param should be checked to make sure the NOTIFY is not being used to lengthen the subscription. In section 3.2.2 of RFC 3265 it states that: "The notifier MAY use this mechanism to shorten a subscription; however, this mechanism MUST NOT be used to lengthen a subscription". Note: suggested solution has been tested and it corrects the problem. Everything is working as it should. Regards, Shawn Sincoski Voipswitch
