The suggestion/option seems to be useful/logical for that scenario you
mentioned.
As per RFC 3903,
The presence of a body and the SIP-If-Match header field
determine the specific operation that the request is performing,
as described in Table 1.
+-----------+-------+---------------+---------------+
| Operation | Body? | SIP-If-Match? | Expires Value |
+-----------+-------+---------------+---------------+
| Initial | yes | no | > 0 |
| Refresh | no | yes | > 0 |
| Modify | yes | yes | > 0 |
| Remove | no | yes | 0 |
+-----------+-------+---------------+---------------+
Table 1: Publication Operations
So the PUBLISH you suggested would be *Initial-Publication*. Then the RFC
continues in the ESC publish-request processing as follows,
4. The ESC processes the Expires header field value from the PUBLISH
request.
* If the request has an Expires header field, that value MUST be
taken as the requested expiration.
So far it looks like perfect for our scenario...
* The ESC MAY choose an expiration less than the requested
expiration interval. Only if the requested expiration interval
is greater than zero and less than a locally-configured
minimum, the ESC MAY reject the publication with a response of
423 (Interval Too Brief), and skip the remaining steps. This
response MUST contain a Min-Expires header field that states
the minimum expiration interval the ESC is willing to honor.
Your request cannot be rejected with Interval-Too-Brief (423) response. So
the solution you have should work for the scenario mentioned.
--
Thanks & Regards,
Noble Antony Thattil.
On Tue, Mar 2, 2010 at 4:59 PM, Iñaki Baz Castillo <[email protected]> wrote:
> Hi, I'm thinking about a custom usage of PUBLISH method. The idea is to
> send a
> PUBLISH with body and "Expires: 0" but no "SIP-If-Match" header, so it
> would
> generate a NOTIFY for current subscribers, but since "Expires" is 0 future
> subscriptions would not receive such notification (this is what I want to
> achieve).
>
> Is it a legal usage of PUBLISH method? In RFC 3903 I read that "Expires: 0"
> is
> used, in conjunction with "SIP-If-Match" header, to terminate an existing
> publication:
>
> -----------------------------------------------
> To request the immediate removal of event state, an EPA MUST create a
> PUBLISH request with an Expires value of "0", and set the SIP-If-
> Match header field to contain the entity-tag of the event state
> publication to be removed.
>
> Note that removing event state is effectively a publication
> refresh suggesting an infinitesimal expiration interval.
> Consequently, the refreshed event state expires immediately after
> being refreshed.
>
> Similar to an event state refresh, the removal of event state only
> affects the expiry of the event state. Therefore, a PUBLISH request
> that removes event state MUST NOT contain a body.
> -----------------------------------------------
>
>
> In my case the PUBLISH has body and "Expires: 0" but no "SIP-If-Match" so I
> expect is a legal usage. Opinions? Thanks.
>
>
> --
> Iñaki Baz Castillo <[email protected]>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
