Alright, I finally found the proper RFC, http://www.rfc-editor.org/rfc/rfc4235.txt
Section 4.1 :
"version: This attribute allows the recipient of dialog information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a subscription. Versions MUST be representable using a non-negative 32 bit integer."
Versions are scoped within a subscription, so when a new subscription is started, ( after the 1 hour expiry ), the version should be reset as it is a new subscription and therefore a new scope ?
When the subscription expires, is it renewed or is a new subscription created? Is the scope separate, or is it the same subscription updated?
Thanks,
David
kamailio.org@spam.lublink.net wrote:
Hey,
I had a look at rfc3265, 4.3.2. I find the language is ambigious :
" it ignores the NOTIFY message containing the state delta (except
for the version number, which it retains to detect message loss),"
Why would it retain the version number if the versions will be reset
after it resends a SUBSCRIPTION ?
"Any event package that supports delta changes to states MUST include
a version number that increases by exactly one for each NOTIFY transaction in a subscription."
It speaks of incrementing, but it says nothing of resetting on a
renewal of ths subscription...
kamailio.org@spam.lublink.net wrote:
Hey,
I have noticed that the XML body of the dialog messages contains a
version attribute. The server is counting the versions using the latest subscription as a reference point, and the phone is counting the versions from the first subscription ( at reboot ).
Which is the correct way to count these versions?
Consider :
10:00 Subscription 10:05 Notification version 1 10:35 Notification version 2 11:01 Subscription 11:05 Notification version X
Is X = 3 because it is the third notification or 1 because it is the
first after the last subscription? If it's version 1, it could confuse the phone cause a notification that is sent at the same time as the notification would have a confusing version.
On the other hand, each subscription, has it's own versioning, so
would it not logically follow that the different subscriptions for the same device have seperate versioning?
From my phone : BLF Notify received for line: 3 has older version: 3
last version:135
To confirm my theory, I redialed the number 133 times, and once the
version number had run up to 136, the lights started flashing again.
Is this a bug in Grandstream, Kamailio, or perhaps an RFC which was
unclear?
Thanks,
David
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users