Subject: Sorry, I missed something

From: Scott Petrack <[email-masked]>
Date: Mon, 30 Aug 1999 08:34:01 -0400 (EDT)

My stupidity -- I was trying to go fast, and I made things slower.

What I meant to say was:

As far as I can tell, there are two small clarifications needed to the
draft:

1. A note that a SUBSCRIBE "session" can be modified by re-issuing the
subscribe with new parameters. We might as well make it clear that
changing the parameter to "Expires: 0" causes the session to effectively
end (assuming a sucessful response to the new SUBSCRIBE).

2. If a SUBSCRIBE was sent along a SIP call-leg already used to signal a
PSTN call, then of course a BYE sent along that leg will cause the entire
session to end -- pstn call and subscribe.

Do we need to add a clarification saying that a BYE sent along an "old"
SIP call-leg doesn't need to include the SDP, since the call-leg refers to
an already set up PSTN call.

Scott

On Sun, 29 Aug 1999, Scott Petrack wrote:

> 
> Some very short bullets about the subscribe/notify business. 
> 
> 1. As far as I can tell, only a very small claficiations need to be
> added to the draft:
> 
> 	if the SUBSCRIBE contained only the call-id (referring to some
> 	previously started session, and not the original session description)
> 	then of course the subsequent BYE terminates both the PSTN
> 	call and the "monitoring session". 
> 
> 
> 2. here is a new worm from the same can. I am curious to hear reactions:
> 
> Suppose a third-party subscribe is made, with a new Call-ID in the SIP
> call-id header, using the SDP description of th e PSTN call to 
> say which PSTN call is being subscribed to. Now suppose that later, 
> that third-party wants to send a BYE to terminate the call. It is entirely
> reasonable for the BYE to have *no* SDP, right? I mean, it went through
> all the trouble of inventing a new Call-ID to make a new transaction and
> everything, so why do we need to send the SDP and make the server parse it
> all over again? 
> 
> 	The basic point is that when a BYE is sent, it is almost always 
> 	clear to the receiver which session is being talked about, because
> 	that session was opened by a previous request. The only exception
> 	is true third-party BYEs, where the BYE request uses a totally
> 	new call-id, never before seen in human history. In this case,
> 	the SDP is required to tell which PSTN session is being
> 	terminated. (I myself shudder at the security implications of such
> 	a message, and don't plan to implement it for some time, let me
> 	assure you). 
> 
> Scott
> 
> 

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

---

From: Scott Petrack <[email-masked]>
Date: Sun, 29 Aug 1999 09:08:41 -0400 (EDT)

Scott

---------