Subject: SUBs after BYEs

From: Scott Petrack <[email-masked]>
Date: Wed, 15 Sep 1999 19:49:10 -0400 (EDT)

The current text says that a client SHOULD not send a SUB after a BYE. It
does not say that a client MUST not send a SUB after a BYE. It seems to me
that this is correct. Especially now that we have totally separated the 
INVITE/BYE signalling from the SXXSCRIBE/UNSXXSCRIBE signalling, I agree
with your colleagues -- there may be unusual situaions where someone
succefully sxxscribes to a pstn phone call after it has already been wiped
out with a bye. But these are highly unusual situations. In fact, the
example you give isn't one of them, I believe:

After the BYE has been sent to clear out the state about the request in
the PINT gateway, if the request is cleared out properly there normaly 
will be no more knowledge of the request in the server. So a subsequent
SUB about the session should get back a "481 Transaction does not exist".
This is a pretty good indication that there is no such request lying
around. You are correct, however, it is entirely possible that if the 
PINT gateway wants to keep the state around for longer, it can return
a successful response to the SXXSCRIBE, giving the fact that the session
never started.

Normally, however,  the successful response to the BYE means that PINT
session is erased from the memory. (OF course, it might be stored in a
call log somewhere, or a "PDR" (pint detail record ;-) might be sent, but
this is outside of the PINT system. So the OK reponse itself is the
assurance that the session is no longer. 

We make the point in several places that you shouldn't send a BYE unless
you want the INVITE that it refers to to be wiped out. So I'd like to
leave the SHOULD there. 

Look at the paragraph beginning "In principle, a user might
send a SXXSCRIBE request after the telephone network service has
completed." We say that a PINT gateway can put an Expires header into the
response of an INVITE or SXXSCRIBE to say for how long it will keep state
around, and that it will also put an Expires: into a BYE for the same
purpose. So we leave the door open for a situation where the above SHOULD
might be violated.

BTW, as a nit I just noticed in the above paragraph, I have no trouble
adding that the gateway might also put an
Expires: header into the response to a BYE, in order to signal the same
thing -- for how long it will keep state around. This can be accomplished
by adding a short phrase to the end of this paragraph as follows:

" within the response to the
original INVITE message that triggered the service session, within the
response to the SUBSCRIBE message, or within its BYE message (but see
section 3.5.8, point 3)."
 
becomes:

" within the response to the
original INVITE message that triggered the service session, within the
response to the SUBSCRIBE message, within the response to the BYE
message, or within its own BYE message (but see
section 3.5.8, point 3)."

Scott

On Wed, 15 Sep 1999, Lawrence Conroy wrote:

> Hi all,
> (i) CLOSE/UNSUB/EXPIRE. I'm happy with UNSUB as it is easy to see that it
> closes a particular kind of session.
> On reflection, CLOSE is too generic. I feel that EXPIRE is not too good,
> for the same reason - what EXPIREs?
> (ii) Scott's idea on UNREG is interesting. I can see when this could be
> useful (and would, perhaps, mean that REG gets slightly less overloaded
> that it is at present). However, as Scott rightly says, this is one for
> confctl.
> 
> (iii) One other point/plea:
> Point 1 at the end of 3.5.8 (the bit that says that, if a Client has sent a
> BYE, it can't subsequently send a SUB). Some people in house have asked me
> "why do this"? It's a good question.
> 
> Their argument goes:
> *  A Client makes a PINT service request to be carried out at 7 AM the next
> morning.
> *  They then realise that this is a BAD idea (maybe at 3 in the morning on
> the way back from a Club) and send a BYE message to cancel the request.
> *  They will want to confirm that the request really has been cancelled;
> the obvious way of doing this is to send a SUB (with Expires set to 0) to
> check that the status is "cancelled".
> -  However, in the draft as is, this can't be done as, having sent the BYE
> to their earlier INVITE, they can't send a subsequent SUB.
> 
> This seems like a GOOD argument to me, so I'd like to remove this point
> from the draft.
> 
> Is this OK with everyone?
> 
> ----
> It seems to me that this (and changing the current BYE in setion 3.5.3.x
> and point 3 of section 3.5.8 into an UNSUB) is pretty much all that's
> needed (along with the bug fixes that others have raised). Let's do it!
> 
> 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.