[asterisk-bugs] [JIRA] (ASTERISK-18140) Expires handling in SUBSCRIBE confuses the absence of the Expires header field with an unsubscribe action.

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-18140:
-------------------------------------

    Target Release Version/s: 15.2.0

> Expires handling in SUBSCRIBE confuses the absence of the Expires header field with an unsubscribe action.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-18140
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-18140
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>            Reporter: Jonathan Cloots
>            Severity: Minor
>      Target Release: 13.19.0, 15.2.0
>
>
> RFC3265:
>    SUBSCRIBE requests SHOULD (NOT MUST) contain an "Expires" header (defined in SIP
>    [1]).  This expires value indicates the duration of the subscription.
>    In order to keep subscriptions effective beyond the duration
>    communicated in the "Expires" header, subscribers need to refresh
>    subscriptions on a periodic basis using a new SUBSCRIBE message on
>    the same dialog as defined in SIP [1].
>    >>If no "Expires" header is present in a SUBSCRIBE request, the implied
>    default is defined by the event package being used.<<
>    200-class responses to SUBSCRIBE requests also MUST contain an
>    "Expires" header.  The period of time in the response MAY be shorter
>    but MUST NOT be longer than specified in the request.  The period of
>    time in the response is the one which defines the duration of the
>    subscription.
>    An "expires" parameter on the "Contact" header has no semantics for
>    SUBSCRIBE and is explicitly not equivalent to an "Expires" header in
>    a SUBSCRIBE request or response.
>    *A natural consequence of this scheme is that a SUBSCRIBE with an
>    "Expires" of 0 constitutes a request to unsubscribe from an event.
>       In addition to being a request to unsubscribe, a SUBSCRIBE message
>       with "Expires" of 0 also causes a fetch of state; see section
>       3.3.6.
>    Notifiers may also wish to cancel subscriptions to events; this is
>    useful, for example, when the resource to which a subscription refers
>    is no longer available.  Further details on this mechanism are
>    discussed in section 3.2.2.
> I guess the gist of it is, that asterisk should be able to provide a subscription /subscriber/ with a reasonable expirey, based on it's own internal configuration.



--
This message was sent by Atlassian JIRA
(v6.2#6252)