Subject: [Sipping] Implicit subscriptions

From: [email-masked]
Date: Tue, 23 Jul 2002 11:41:01 +0300

Packages like Registration Info and Dialog all require explicit subscriptions to get any notification of the state of an earlier request being sent (REGISTER and INVITE). So, I was thinking why don't we have implicit subscriptions for these things.

Subscription for reginfo almost always follows a REGISTER request. Subscription for dialog almost always follows an INVITE request. So, why not include an implicit subscription when sending the request? (This is when the subscribe and the earlier request are sent from the same UAC. This does not apply if the subscriber is a 3rd party).

This type of thing was first introduced in REFER using the supported and require headers and I thought this can be generalised for all packages that use earlier sent requests as their source of notification information.

E.g. 1: If I send an INVITE and then want to trace the state of that dialog, I need to send an INVITE followed by a SUBSCRIBE. This idea eliminates the need to send the SUBSCRIBE.
E.g. 2: If I send a REGISTER and then want to trace the state of my registration, I need to send a REGISTER followed by a SUBSCRIBE. This idea eliminates the need to send the SUBSCRIBE.

Other examples include MESSAGE and REFER.

I also suggest creating a new header for that (instead of using supported and require): "subscribe-event" in the request. The response can simply contain the "event" header.  

If the UAS does not return the event header in the response, it means that it did not understand the implicit subscription and an explicit one needs to be sent (a SUBSCRIBE).

This could also be added as an extension to the event-notification RFC3265. New packages are required to add a section describing implicit subscriptions, if applicable (not applicable for packages like presence). Or even SIP extension for new methods can describe which packages implicit subscriptions are possible with it.

If this idea is acceptable, I can write a short I-D describing it.

Comments?

Regards,
Hisham

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Robert Sparks <[email-masked]>
Date: 23 Jul 2002 13:52:25 -0500

One of the biggest lessons I've taken away from the
experience of designing REFER is that implicit subscriptions
are _not_ a good thing.

Generally, doing two things with one request is a bad design
choice - it forces a combinatorial explosion of failure cases.

We're also going to discover that sharing dialog identifiers
( which is what happens when you issue a REFER or a SUBSCRIBE
inside an INVITE dialog ) will cause significant implementation
pain and possibly undesirable protocol artifacts. (Ask yourself,
when is "the dialog" over when you have overlapping subscribes
using the same dialog ID).

So, please don't take this path. Instead, work for lightweight
ways to explicitly subscribe to the desired event package.

RjS

btw - Note that the supported/require mechanism in refer-3265disc has
been abandoned in favor of always instantiating a subscription
for REFER. We may come back and define an extension (Requires)
that allows a REFER without an implicit subscription.