Reading again I think you may be right :) . If so I will do the changes.
Klaus Darilion wrote:
I read the RFC different:
...The ESC MUST generate a new entity-tag for each successful
publication, replacing any previous entity-tag associated with
that event state.
IMO this means:
1.
PUBLISH
......
200 OK
SIP-ETag: abc
2. publish from same client
PUBLISH
SIP-If-Match: abc
200 OK
SIP-ETag: def
3.
PUBLISH
SIP-If-Match: def
200 OK
SIP-ETag: ghi
and so on ...
regards
klaus
Anca-Maria Vamanu wrote:
Hello,
RFC3903 :
8.3. Server Usage
Entity-tags are generated and maintained by the ESC. They are part
of the state maintained by the ESC that also includes the actual
event state and its remaining expiration interval. An entity-tag is
generated and stored for each successful event state publication, and
returned to the EPA in a 200 (OK) response. Each event state
publication from the EPA that updates a previous publication will
include an entity-tag that the ESC can use as a search key in the set
of active publications.
This is exacly what presence module does. When a new Publish is
received, it generates a Etag and includes in the 200ok reply. If a
publish with a SIP-If-Match header is received, that is an updating
Publish, it searches if
it has a matching etag stored in database.
It does not reuse it for other publications and it respects the
unicity propriety described in:
6. The ESC returns a 200 (OK) response. The response MUST contain an
Expires header field indicating the expiration interval chosen by
the ESC. The response MUST also contain a SIP-ETag header field
that contains a single entity-tag identifying the publication.
The ESC MUST generate a new entity-tag for each successful
publication, replacing any previous entity-tag associated with
that event state. The generated entity-tag MUST be unique from any
other entity-tags currently assigned to event state associated
with that Request-URI, and MUST be different from any entity-tag
assigned previously to event state for that Request-URI. See
Section 8.3 for more information on the ESC handling of entity-
tags.
Klaus Darilion wrote:
Hi!
Is the ETag constant for a certain client "session"?
RFC3903 mandates that the Etag should be changed with every PUBLISH:
6.6: ...The ESC MUST generate a new entity-tag for each successful
publication, replacing any previous entity-tag associated with
that event state.
I think currently openser reuses the Etag from the received PUBLISH
in the 200 Ok. Nevertheless, if "changing" Etag will be introduced
IMO a constant Etag should be chooseable with module parameters.
regards
klaus
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
