Subject: SUB/NOT - NOT with Exp:0

From: [email-masked] (Lawrence Conroy)
Date: Sat, 4 Sep 1999 12:28:26 +0100

Hi all,
A quick comment on overloading NOT.

I can see only one situation where sending BYE is any kind of a problem for
SUB/NOT - if the "old" INVITE Call Leg has been used in a SUB.

I don't see how it is ever a problem for the Gwy to return a BYE to a SUBber.
Why is this a question? I've been brushed by a bus again.

It seems to me that sending a SUB with Expires:0 to close a monitoring
session is intended to be semantically equivalent to sending a BYE (as it
is described in the PINT draft). It's needed only if one re-uses an
existing (Call-ID, From, To) tuple when opening a monitoring session.

It also seems that a Gwy sending a NOT with Expires:0 is intended to be
semantically equivalent to a Gwy sending a BYE (as described in the Draft).

****
I AM very uncomfortable with using Expires:0 in a NOT for a Gwy to close a
monitoring session. We may wish to keep this for the future, to use where
the contained status information is merely a snapshot (or more generally to
use Expires for status of limited or transient validity).

----------------

Of course, Scott is correct - the Gwy need not send back ANY message,
merely abstaining from sending any more NOTs. Thus sending back a BYE (or
the semantically equivalent NOT with Expires:0) is a MAY, not a MUST.

It IS polite, though, IMHO, particularly if the SUBber is maintaining a lot
of SUBs (as could well be the case for a back-end to a Web Server).

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: Tue, 7 Sep 1999 11:50:07 -0400 (EDT)

[Igor, I am sorry, I somehow missed or forgot your earlier posting about
the S-word. I won't use it again]

Bernie, the proposal you made is essentially what I thought was in the
draft. The problem is that this seems to bother Jonathan for two reasons:

	a) he doesn't like the "special simplification" when call-ids are
		the same; he would like the call-id to be totally
		irrelevant to determine what you sxxscribe to.

	b) he thinks the BYE is always paired with INVITE. It makes no
		sense to him to have BYE paired with SXXSCRIBE. 

[Jonathan, am I right to think that for you, call-id is totally irrelevant
to correlating SXXSCRIBE with INVITE? If a client sends along the same
call-leg: INVITE, then SXXSCRIBE, then BYE, would you consider the 
SXXSCRIBE still to be operational?, or does BYE tear it down like it tears
down the media session?]

About a), I don't care that much at all, it was meant to be a
trivial simplification, and I am happy to drop it from the draft -- if we
all start to use it we can put back in later. 

So I think that the following three rules are ones we can all agree to:

1. It is REQUIRED that the SDP appear in the SXXSCRIBE requests. Call-IDs
are not relevant to determining what is being subscribed to. (basically, I
give in).

2. An Expires:0 header in the SXXSCRIBE request means that the sxxscribe
is to be terminated. An OK response will contain in its body the current
session state, and thereafter no more notifies are to be sent. (I think
everyone agrees that this makes sense).

3. A BYE message tears down all SIP call state which was established with
a previous INVITE along the same call-leg.

The only open contentious question is how the gateway will signal that it
is not going to send any more NOTIFYs:

a) Jonathan wants to keep INVITE/BYE pairs *totally* separate from any
SXXSCRIBE request. So he can't use BYE for this purpose. He suggests using
an Expires:0. Lawrence doesn't like this, because Expires: normally would
express the duration of validity of that particular NOTIFY. If anything,
an Expires:0 header might express some important fleeting call state that
will immediately be replaced by a new NOTIFY.

b) Lawrence wants the gateway to send a BYE, which Jonathan doesn't like,
because the BYE refers to a previous INVITE, which didn't exist here.

I agree with Lawrence, but isn't all he needs to be happy is something
like a new header "Final:true" in the NOTIFY to signal that this is the
'final' NOTIFY? Maybe even
"Expires: infinite" or "Expires: never" or even just 
"Expires: 23 Jan 23123". All of these are meant to express the next time
that the client can reasonably expect to see a next NOTIFY.

Bye the way ;-), I don't think that anyone objects to sending a BYE
from the gateway back to the 3rd party to
mean "there is no longer any SIP call state associated to that session."
This would be ok, because such a BYE would refer to a session previously
established with an INVITE. The 3rd party recipient of the BYE would
understand it, because it could use the SDP to know which pstn call is
being cleared. So if such a BYE
were sent from the gateway to something which SXXSCRIBEd to a
pstn call session, it certainly would mean "there will be no further
notifies and don't bother ever SXXSCRIBing, because there is no more
record of that session." But this is more drastic that just signalling
"that was the last notify I'm going to send you." 

It may be enough to get PINT closed and out the door to agree that we will
use BYE in this way to end a monitoring session, in a way which signals
explicitly "all further requests about this session are going to get a 
"400 Bad Request" along with Warning: that the PSTN call session id does
not exist."

Can people agree that it is all right for the gateway to send a BYE back
to the SXXSCRIBEr to mean "all call state about that call is being cleared
out"? Do we need a way for the gateway to signal only "I am not going to
send any more NOTITYs"....If we do, I fear that we need some new header
for the NOTIFY to say that it is "final."

I hope that at least all the issue are out on the table, so that we can
quickly come to some rough consensus.

-------------------------------------------------------------

Postscript

This discussion pointed out to me a little thing that was not so
precisely clear to me before. Just in case I've got it wrong, let me see
if others agree:

It is very possible for a client to cause the pstn phone call to end
without sending a BYE, and it is possible for the gateway to NOTIFY a
client that a pstn phone call has ended without sending a BYE. This is
done just by indicating the correct stop time in the sdp for the phone
call. In fact, this is the only way to indicate the end of the call
without ending the PINT session. I'm not sure that anyone would do this
(maybe it would be a PINT version of the long # service. But the protocol
certainly allows one to start and stop lots and lots of pstn phone calls
over a single PINT session, just by re-issuing INVITEs lots and lots of
times.

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Sep 1999 10:46:07 -0400

> SXXSCRIBE still to be operational?, or does BYE tear it down like it tears

My aim is only to try to make sure that pint stays in line with the SIP
model as much as possible. SUBSCRIBE will have lots of future uses well
outside of pint, such subscriptions being totally independent from any
call. In this case, the Call-ID will have nothing to do with what is
being subscribed to. This is why I don't like usage of Call-ID for
indicating that a specific call is being subscribed to.

> a previous INVITE along the same call-leg.

These are all fine with me.

> because the BYE refers to a previous INVITE, which didn't exist here.

Again, it comes back to generality. The purpose of BYE is not to end
anything else except a SIP session initiated with an INVITE.
Registrations are not terminated with BYE's, since they are not uniquely
identified by the Call-ID. registrations are identified by the URI of
the individual being registered. This allows registrations to be
modified/added-to across different terminals, as the Call-ID is known
only locally at each machine. Same argument holds for a subxscriptions
in general, so I'd like to follow the same model.

That said, the rule in IETF is rough consensus. If I am the only one
that feels this way, the issue is settled....

> that the client can reasonably expect to see a next NOTIFY.

I need to think some more about whether this is best done with an
Expires header or something else (like Final or something), but I don't
object to the general idea.

> being cleared. So if such a BYE

I disagree with this last sentence. BYE's are matched to INVITE's based
on To, From, and Call-ID, not on session content. In this case, a third
party would not know what the BYE is for, and would reject it (this is
standard SIP behavior, at least).

> "400 Bad Request" along with Warning: that the PSTN call session id does

As I have explained, I don't like this. But, I do not want to hold up
the spec. If rough consensus is to do it, then so be it.

-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: Henning Schulzrinne <[email-masked]>
Date: Thu, 09 Sep 1999 11:12:08 -0400

> indicating that a specific call is being subscribed to.

I agree that the Call-ID (the name is somewhat unfortunate as it lacks
generality, but calling it session id would've added only to the number
of things called session...) should not depend on an INVITE-BYE call. To
give just one example: TIA will probably suggest the use of SUB/NOT for
"message waiting".

> that feels this way, the issue is settled....

In principle, there's nothing that would prevent setting up another kind
of "call-like object", namely one consisting of the operations SXX/NOT
and BYE (and possibly OPTIONS). If we think of the call-id as an object
id, we are just defining the behavior of BYE on that particular object.
The behavior of BYE on an INVITE-created call object is clearly
different. A REGISTER-created object only has one method.

Thus, to me there are two possible reasons not to use BYE:

- It's confusing to the human observer, since you'd have to look at the
object behind the call-id to find out what's going on.

- There is another equivalent way to achieve the "no more NOTIFYs"
indication. I tend to agree that Expire doesn't quite fit the bill here.

Thus, there are, IMO, three solutions:

- Use an explicit flag in the last NOTIFY saying "I'm the last one". We
could draft "Retry-After: 0" as a request-header, but this just
overloads another parameter.

- Use BYE, in the object-oriented spirit above.

- Create another method. Being explicit about what you are doing argues
for this. Besides minor spec-bloat, I see no penalty to adding methods
for new and distinct operations - it's not like we are running out of
letter combinations here. It also tends to make the code cleaner, since
you don't have this multiple layering of

if (method = A) {
  if (the third comma is missing) {
    do this
  }
  if (the parameter has polka dots) {
    do that
  }
  if (both are true) {
    blow a fuse
  }
}

Having a separate method makes it possible for a server to separate
notification from termination. After all, a server may just want to walk
away, but no event is occuring at that time. Sending a NOTIFY with
Expires: 0 or some other header and no body seems kind of indirect here.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---------

---

From: Scott Petrack <[email-masked]>
Date: Fri, 10 Sep 1999 15:00:57 -0400 (EDT)

I think it's *definitely* worth the extra few weeks to get this all
correct. Especially as we're so close.

> indicating that a specific call is being subscribed to.

I completely agree with Jonathan that there will be lots of situations
where SXXSCRIBE will be used totally outside the context of any previous
request, and so by force the Call-ID will be completely new.

But I do believe that there will be lots of situations where the SXXSCRIBE
*will* in fact refer to a previously established session. Some SIP methods
refer to previous SIP requests (INVITE, CANCEL, BYE) and some do not
(OPTIONS). I don't think that it breaks anything, and the meaning seems
clear enough to me, if I allow a simple form where the SXXSCRIBE
re-uses a call leg, it doesn't seem to interfere with the generic meaning
in any way. 

But since this seems to bother other people too, I have ceded on this one. 
I am happy to go with the rough consensus here. 

I will perhaps later ask for a related simplification -- in the PINT
services I have in mind, a client definitely wants to SXXSCRIBE to every
phone call from the beginning. I wish that I didn't have to send two
messages when I always know that I'm going to send an INVITE and then
SXXSCRIBE with identical SDP. I wish that I could put something into the 
INVITE to express "INVITE+SXXSCRIBE". Sort of as if I put an Also: header
with a URL which expressed a request identical to the INVITE, except for
the method. As if I had sent "Also: SXXBSCRIBE". But this is not for v1 of
PINT, I realize.
 
> The purpose of BYE is not to end

This is not quite entirely true, is it? I mean, a BYE also indicates that
the sender of the BYE is no longer involved in the media session, correct?

> object to the general idea.

OK, we seem to be down to either:

a) using "Expires:never"
b) using a new header "Final:true"
c) allowing a BYE to refer to a SXXSCRIBE.
	Note that this doesn't really break anything. A BYE definitely has
	to match with a previous call-leg, but that's possible with a
	SXXSCRIBE. The BYE would indicate that the sender has cleared out
	all SIP session state associated to that Call-leg. Note that the
	matching is a bit subtle, because the To: and From: fields may be
	reversed from the original INVITE, but we have to deal with that
	already in the classic BYE.
d) invent a new method "EXPIRED". In principle, this could be used by a 
	server to indicate that it has changed its mind about a previous
	response to a previous request and has shortened the Expires: 
	time. I guess it could even be used by the server to indicate that
	a client has now been unREGISTERed, or unSXXSCRIBEd. EXPIRED 
	requests, would use the same rules as BYE to be matched to 
	previous requests (REGISTER or SXXSCRIBE).

> > I don't think that anyone objects to sending a BYE

Ah well, if this is the case, then there is no problem to use BYE to mean 
"the sxxscription is now over." I realize that you [Jonathan] don't like,
but at least it has perfectly celar semantics. A BYE sent on a call-leg
which was set up via a  SXXSCRIBE  request means "end the sxxscribe", and
a BYE sent on a call-leg which was set up via INVITE request means "end
the INVITE".

Except there is a small robustness issue:

Suppose a client sends an INVITE, and then later sends a SXXSCRIBE with 
the same call-id. (I'm assuming that it includes the correct SDP).
Perhaps it shouldn't do this, but suppose it does.
Should the SXXSCRIBE be rejected just because it used an old call-id? I
find this distateful -- I can't imagine returning a bad request error just
because the Call-ID is old, when the meaning is crystal clear. But then
later a BYE is sent. Is this a BYE to the INVITE, or to the SXXSCRIBE? 

I am not happy with the pedantic solution that says "you must use a
separate call id, and if you don't the SXXSCRIBE will be rejected.". The
fact is that a SIP session takes state in the server, and I would like to
build large SIP servers, and I think that it's just plain silly to require
two Call-IDs and two separate BYEs, when almost all the time one Call-ID
and one BYE is enough. I'd much rather say that if you may use the same 
call-id, but if you do, then the single BYE will tear down state
associated to both the INVITE and the SXXSCRIBE. This does not preculde
the more generic usages which everyone agrees will happen with SXXSCRIBE
and NOTIFY.

The least change to the
current PINT spec is to allow BYE to end a SXXSCRIBE session, and to say
that if you re-use a call-leg for multiple INVITE and SXXSCRIBE requests,
then a BYE with that Call-ID terminates both all INVITES and SXXSCRIBEs
that were sent along that call-leg.

But I'd like to hear other opinions please. 

Scott

On a personal note, SIP has come a very long way in the last year, and
promises even more interesting things for the coming one.  Wishing you all
the very best in the coming year....

---------