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

From: "Slutsman, Lev A, ALSVC" <[email-masked]>
Date: Tue, 31 Aug 1999 15:11:40 -0400

Scott,
In my opinion it does make sense. Now thinking about multi-leg calls, like
conferences for PINT-2, the SDP in the SUB body may provide the complete
CallLEg info, to allow monitor a leg of choice.
Regards,
Lev.

-----Original Message-----
From: Scott Petrack [mailto:[email-masked]]
Sent: Tuesday, August 31, 1999 2:51 PM
To: [email-masked]
Cc: Lawrence Conroy; Buller, Jim; Jonathan Rosenberg
Subject: Eureka! SUBSCRIBE/NOTIFY -- suggestion for compromise

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

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

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

---

From: Scott Petrack <[email-masked]>
Date: Tue, 31 Aug 1999 17:05:32 -0400 (EDT)

I can't help but make a plea. I know that it's bad form to retract an
offer, but do consider:

Here are two reasons I really like the possibility to leave the SDP out 
to mean "the entire session."

1) Maybe the requestor just doesn't know anything about the pstn legs in
the call, or has got confused about the call state. As a concrete example,
suppose that the requestor wants to know what's going on in conference
call sip: [email-masked]. Wouldn't it make sense to allow
a request like:

SUBSCRIBE ....
To: sip:[email-masked]
From: [email-masked]
Call-ID: [email-masked]

This is rather like a registration with no Contact: header. It would mean
"please send me everything you know about the destination" (which in this
case would be a conference call). 

I know that this is not quite the same as the case we were talking about
before. In that case, you might argue that once the INVITE is sent, both
sides must retain at least the PSTN session id, so that it can always be
included. 

2) if the session has a lot of pstn call legs in it (like say 10 or 20),
it's such a pain for the receiver to parse each one. Since I think that
the usual case will be that the requestor wants to know "everything", it
just seemed nice to allow this optimization. If the sender wants to
SUBSCRIBE to some subset, it need merely indicate some SDP.

How about this as a slight modification to my proposed signaling:

If a SUBSCRIBE is sent without an SDP body, and the receiver can
unambiguously determine which PSTN session is being referred to
(e.g. via some combination of SIP header fields), it should
respond with the entire state of the session. Otherwise, it returns
485 Ambiguous, and the sender must re-issue a new SUBSCRIBE (not a 
retransmission) including the SDP indicating the PSTN call legs about
which NOTIFY-cation is requested.

This rule should not bother Lawrence, who will always return 485 Ambiguous
to SUBSCRIBEs without a body. And the requestor will know what to do.

Scott

PS:

If you like, you can put the following Warning: text into the 
"485 Ambiguous" response:

Warning: 399 foo.bar.org  I need to see the body please....

---------