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(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users