This interface represents the Event SIP header, as defined by
RFC3265, this header is
not part of RFC3261.

For the purposes of matching responses and NOTIFY messages with SUBSCRIBE
messages, the event-type portion of the "Event" header is compared
byte-by-byte, and the "id" parameter token (if present) is compared
byte-by-byte. An "Event" header containing an "id" parameter never matches
an "Event" header without an "id" parameter. No other parameters are
considered when performing a comparison, i.e. "Event: foo; id=1234" would
match "Event: foo; param=abcd; id=1234", but not "Event: Foo; id=1234".

There MUST be exactly one event type listed per event header. Multiple events
per message are disallowed i.e Subscribers MUST include exactly one "Event"
header in SUBSCRIBE requests, indicating to which event or class of events
they are subscribing. The "Event" header will contain a token which indicates
the type of state for which a subscription is being requested. This token
will correspond to an event package which further describes the semantics of
the event or event class. The "Event" header MAY also contain an "id" parameter.
When a subscription is created in
the notifier, it stores the event package name and the "Event" header "id"
parameter (if present) as part of the subscription information.

This "id" parameter, if present:

contains an opaque token which identifies the specific subscription
within a dialog.

is only valid within the scope of a single dialog.

if contained in the initial SUBSCRIBE message on the "Event" header, then
refreshes of the subscription must also contain an identical "id" parameter,
they will otherwise be considered new subscriptions in an existing dialog.

if present in the SUBSCRIBE message, that "id" parameter MUST also be
present in the corresponding NOTIFY messages.

If the event package to which the event token corresponds defines behavior
associated with the body of its SUBSCRIBE requests or parameters for the
Event header, those semantics apply.