Subject: Re: Eureka! SUBSCRIBE/NOTIFY -- suggestion for compromise

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 3 Sep 1999 00:41:29 +0300 (EET DST)

On Tue, 31 Aug 1999, Scott Petrack wrote:

> 3. A SUB SCRIBE is ended by sending a new SUB SCRIBE with Expires:0
> 
> 	A BYE is not used to end a monitoring session.

A question to your proposual: What has the server/gateway to send,
if it wants to terminate the monitoring session?

Also SUB SCRIBE with Expires:0? (Although this would be possible, it
sounds somehow unlogical to me.)
And another problem is, that it would no longer be possible to indicate
in the Expires header, for how long a new SUB SCRIBE for the same call
sessen can be sent (following section 3..5.3.3). Or am I wrong?

t. Bernie

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

---

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

> if it wants to terminate the monitoring session?

Maybe I need to clarify what I meant:

If the PSTN *call* is over, then it is entirely reasonable for the server
to send a BYE to the original monitoring client. This signals something
very important -- that the call is over and the state is never going to
change. 

But if the call is not over, and the server merely wishes to indicate that
it will no longer send any NOTIFYs to the monitoring client,
I would suggest that the server send nothing at all. 

In fact, I will turn the question to you -- how would a server send
signaling to a monitoring client to distinguish between the two cases:

	a) the call is over, and the state is final. 
	b) I'm not going to tell you about any futher changes in call
state.

Sending a BYE to a monitoring client signals a). The most scaleable and
secure way to do b) is just not to send any more NOTIFYs. 

In fact, if I were a client and received such a signal (i.e. a "BYE"
corresponding to a previous NOTIFY), I would just send an immediate
SUBSCRIBE once again. This would have the opposite effect of what the
server wants, as well as increasing network traffic. 

If you don't want your client to know about the changes in a session,
don't tell it about the changes. Or do you really feel you want to express
the notion that "I'm not going to tell you anything more, and I want to
tell you that I'm not going to tell you anything more."

So my proposal should be clarified to say instead:

	"A BYE is sent to a monitoring client only when the PSTN call is
	ended. This BYE contains the final state of the PSTN call, and
	after it is sent, no further NOTIFY messages are sent. So a BYE
	ends a monitoring session if and only if also indicates the end of
	the phone call."

> sounds somehow unlogical to me.)

No, I was not suggesting this.

> sessen can be sent (following section 3..5.3.3). Or am I wrong?
A new SUBSCRIBE for the same call can be sent at an time, with an Expires
field of any length. I could send a SUBSCRIBE with no Expires: field
(indicating that I don't want the subscribe to timeout), then 20 minutes
later send one with Expires=0, and then later send a new one with
Expires=123876. As long as the session id is valid, the server can
certainly act on the request. 

Scott

---------

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Fri, 03 Sep 1999 12:26:27 -0400

I have to agree with Jonathan.  It seems more consistant for the gateway to
tell the SUB SCRIBED client of changes in the SUB SCRIPTION via the NOTIFY
method.  I seems out of place to use BYE  just for this case.  The client is
expecting NOTIFY messages from the gateway anyway, this is just a more
specialized version which says:
- I am unable to send more notifications
or
- I am unwilling to send more notifications
or
- There are no more possible changes to be notified of
so don't bother re-SUB SCRIBING.

Dan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Sep 1999 16:13:06 -0400

> so don't bother re-SUB SCRIBING.

Actually, Scott (I think it was Scott), said something interesting.
There is a difference between "your subscription has expired, you can
subscribe again if you want" and "your subscription has been forcefully
expired, and attempts to resubscribe will fail". Which one is meant by
NOTIFY with expires:0 is not clear. Perhaps it doesn't matter; it has
been argued that the gateway will just stop sending notifications and
doesn't need to tell the client. Or, if the gateway does  mean "your
subscription has been forcefully expired", but the client thinks it
means "your subscription has expired, subscribe again", the
re-subscription can be rejected with a 6xx anyway. So, I'm not sure this
is a particularly troubling issue.

-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: Fri, 03 Sep 1999 16:20:15 -0400

> is a particularly troubling issue.

Plus, it may be hard to distinguish between shades of "don't try again"

- until you've paid your bill

- until this server is less busy

- after we get the server fixed

- never (because we are Iridium and just went bankrupt)

unless you do this at subscription time

---------