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?
I think this is another questionable thing about SIP. IMO, it is same
subscription if the dialog attributes do not change (call-id, from tag
and to tag). But others can argue is it a new subscription. Anyone else
on this one?
Cheers,
Daniel
Thanks,
David
kamailio.org(a)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(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
_______________________________________________
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
_______________________________________________
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