You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I feel like we have removed Base Notification eventing from the specification a while ago because it has always been optional on clients to support it and only in Profile S. Since then, the default has always been PullPoint.
We've recently hit an issue with a device where the Subscription termination time is not updated by the PullMessages request and the answer we received was that we had to call the Renew command on the subscription. Looking at the WSDL, the Renew command is not listed and in the Core Spec, section 9.1, there's some mention of Renew for Base Notification, and also one mention in section 9.1, 3rd step saying Additionally it provides the Renew and Unsubscribe operations of the Base Subscription Manager Interface.
But then the Diagram does not show the Renew operation in the lifecycle of the subscription.
9.1.1 says: By default the pull point keep alive is controlled via the PullMessages operation. In this case, after a PullMessages response is returned, the subscription should be active for at least the timeout specified in the PullMessages request.
So if I understand this right, if I create a Subscription with an initial termination time of 2 minutes, then the moment I start calling PullMessages, the TerminationTime of the subscription becomes TimeOfLastPullMessagesResponse+PullMessageTimeoutValue OR TimeOfLastPullMessages+2*PullMessageTimeoutValue. The moment a new PullMessages request comes in, this subscription termination time is automatically updated.
Do I follow the spec properly or am I missing something?
The text was updated successfully, but these errors were encountered:
There is an existing DTT test "5.3.2 REALTIME PULLPOINT SUBSCRIPTION - RENEW" that is sending Renew command and expecting Renew response for a pull point subscription, If PullMessages is the ONLY mechanism to be used to renew the subscription and not via the Renew command this test needs to be removed, need to clone a ticket into DTT accordingly to do tool update and validate no regression in the existing profile tests.
Hi everyone,
I feel like we have removed Base Notification eventing from the specification a while ago because it has always been optional on clients to support it and only in Profile S. Since then, the default has always been PullPoint.
We've recently hit an issue with a device where the Subscription termination time is not updated by the PullMessages request and the answer we received was that we had to call the Renew command on the subscription. Looking at the WSDL, the Renew command is not listed and in the Core Spec, section 9.1, there's some mention of Renew for Base Notification, and also one mention in section 9.1, 3rd step saying
Additionally it provides the Renew and Unsubscribe operations of the Base Subscription Manager Interface.
But then the Diagram does not show the Renew operation in the lifecycle of the subscription.
9.1.1 says:
By default the pull point keep alive is controlled via the PullMessages operation. In this case, after a PullMessages response is returned, the subscription should be active for at least the timeout specified in the PullMessages request.
So if I understand this right, if I create a Subscription with an initial termination time of 2 minutes, then the moment I start calling PullMessages, the TerminationTime of the subscription becomes TimeOfLastPullMessagesResponse+PullMessageTimeoutValue OR TimeOfLastPullMessages+2*PullMessageTimeoutValue. The moment a new PullMessages request comes in, this subscription termination time is automatically updated.
Do I follow the spec properly or am I missing something?
The text was updated successfully, but these errors were encountered: