Subject: RE: PINT: Question to SUBSCRIBE/BYE -- I disagree

From: [email-masked] (Lawrence Conroy)
Date: Mon, 30 Aug 1999 13:25:15 +0100

At 8:28 am 29/8/99, Scott Petrack wrote:
>1. However you slice and dice it, now or in the future, if an INVITE is
>received, and then later a BYE, with identical (to, from, call-id), the
>call is over, ended, kaput, erased. This includes any monitoring, changes,
>INFOs, OPTIONs, whatever. The call is over. This is the simple, basic,
>straightfoward, one-party, case. It is absolutely true that you can't get
>fancy dancy granularity or third-party or lots of other services.
>
Um... really?
That means that, if I have a third party that is in a monitoring session
over a request I have made, then if I send a BYE to my earlier INVITE, the
third party monitoring session is kaput?

- but wait, what is this I see yonder...

>...snip...
>
>But I completely agree that there are services such as third-party
>monitoring (and others) where there will be multiple SIP call legs
>referring to a single PSTN call.
>
Um... is this a different case - i.e. do my third party monitoring sessions
get erased when I BYE an earlier INVITE of mine, even if they have
different (CallID, From, To) tuples, or only if they use the same (CallID,
From,To) tuple?

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---------
This message came from the IETF PINT Working Group Mailing List.

---

From: Scott Petrack <[email-masked]>
Date: Mon, 30 Aug 1999 12:43:38 -0400 (EDT)

I apologize, Lawrence. I am trying hard to be hard and clear, but I can
see that I am making things less clear for you;

What I meant was that a BYE which is addressed to some call-leg (to, from,
call-id) triple tears down any state which was set up using that Call leg.

You are quite correct (as I tried to explain below) that *other* call-legs
are not torn down. Thus, in the sequence:

INVITE (to: A, from: B, Call-ID: 234, containing some SDP)
SUBSCRIBE (to: A, from: B, Call-ID: 234, containing NO SDP)
SUBSCRIBE (to: A, from: C, Call-ID: 34598, containing SDP)
BYE (to: A, from:B, Call-ID: 234, no SDP)

the PSTN call is ended, and B no longer monitors the call.

Of course C knows nothing of the signaling from B to A, so it is still
monitoring the call. Since the PSTN call is no over and gone, there 
usually won't be a whole lot of changes to it in the future. Personally,
I would expect that the next thing to happen would be that A would send a
BYE to C, using call-id 34598, giving the final state of the call. This
also informs C that it isn't going to get any more NOTIFIYs.

Was this clearer? When I said before that the BYE tears down any
monitoring, changes, INFOs, OPTIONs, whatever, of course I meant this
about shared state between the two sides of the call leg. In addition, the
actual PSTN call is ended. In PINT 1.0, we don't really allow any third
party call control, so only the original setter-up of the PSTN call can
kill it. (Although I have mentioned how that might be accomplished in the
future).

Scott

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Aug 1999 13:46:09 -0400

Some comments on this stuff:

SUBSCRIBE/NOTIFY is not in baseline SIP, so nothing about it is
"standard SIP" in any way.

I'm not convinced that BYE should be used to end a subscription. The
model for subscriptions is registrations; to remove a registration, you
send an updated one with Expires: 0. There is no need for a BYE, since a
REGISTER with Expires:0 has exactly the same effect. Yes, you also get
back the current registration in the response, but if you don't want it,
just ignore it. Same argument for subscriptions. BYE is used only to end
sessions started with INVITE. Whats the difference? Registrations (and
subscriptions) always have some kind of expiration, and do not require
both sides to be actively aware of the state established by the REGISTER
to work. In other words, I can have my UA register, crash, and reboot,
and if it forgot about the registration, thats fine. This is not the
case for a call established with INVITE. 

I don't have a strong opinion about whether a BYE for the INVITE also
ends subscriptions generated by that user. 

So, how does one correlate the SUBSCRIPTION with the session being
subscribed to? In fact, this is a really broad question when one
considers the range of things which might, in the future, be subscribed
to. This includes pint sessions, as is done here, but could include SIP
call states (am I busy or not, useful for camp-on), registration states
(to know when someone has come online), and who knows what else. I'd
therefore rather have one way to indicate the correlations, and have it
be fairly general. In this case, the Call-ID is irrelevant. It can be
the same as the original Call-ID in the INVITE, but could be different
also. I kind of like the idea of the body of the SUBSCRIBE request
indicating what is being subscribed to. In this case, the body contains
SDP, and the most important part is the SDP identifier, naming the
session being subscribed to. To subscribe to a registration, one might
include a list of URI's in the body, listing those users being
subscribed to. I'm not adverse to using headers for this instead, but it
seems somewhat more general and cleaner to use a body.

There might be a need for headers to indicate the type of information
being subscribed to, since this might affect call routing. For example,
subscribing to a registration can be handled by either a registrar or
the UA, but subscribing to call state can probably only be handled by
the UA.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 30 Aug 1999 16:44:55 -0400

Jonathan: I agree with your suggestions on generalizing the SUB/NOT mechanizm.
We have discussed the use of this mechanizm for providing a number of SIP phone
features in business phone systems.

Jonathan Rosenberg wrote:

> be fairly general.

This is a good point.  To stretch the application of SUB-SCRIBE a bit (perhaps
beyond the scope of PINT, but relevant to some of the SIP IP phone requirements
identified by the TIA work group TR41.3.4) one might want to SUB-SCRIBE to get
information about all call sessions at a particular end point (user agent)
regardless of call-id.

> In this case, the Call-ID is irrelevant. It can be

---------

---

From: Scott Petrack <[email-masked]>
Date: Tue, 31 Aug 1999 14:50:35 -0400 (EDT)

I would like to propose a compromise which I think will give
each person the essential thing they want/need. Please note that it
requires a *real* change in the spec (for me as well as for Lawrence ;-)).
I am not thrilled about changing things, but I'd rather get agreement and
close this. I believe that the new rules will satisfy Lawrence. I'd like
to hear if others are happy or not.

We have the following (new) rules:

1. The SDP body out MUST be included within the SUBSCRIBE request.

	If the SDP is left out of the SUBSCRIBE request, a 
	"485 Ambiguous" response is returned (which means "just
	what is it you are subscribing to?"). 

2. An old call-leg can be re-used when sending a SUBSCRIBE.

	But the SUBSCRIBE *MUST* also contain the SDP 
	which describes the PSTN session being subscribed to, as 
	stated in 1.

3. A SUBSCRIBE is ended by sending a new SUBSCRIBE with Expires:0

	A BYE is not used to end a monitoring session.

For clarification, this means that if a call-leg is used to send an
INVITE, and then a SUBSCRIBE, and then a BYE, the monitoring is still
up. The monitoring will only be ended when a SUBSCRIBE is sent with
Expires:0 is sent.

I certainly feel that this is a compromise I can live with. It requires
changes to all of our implementations, but not large ones, and I believe
it gives everyone the essential features they seem to require. 

Can we all live with this?

Scott

---------