Subject: RE: PINT: Question to SUBSCRIBE/BYE -- I disagree

From: "Buller, Jim" <[email-masked]>
Date: Fri, 27 Aug 1999 12:29:32 +0100

Hello Scott, everyone,

> Sorry, Lawrence, I disagree. I would like to ask the list for 
> comments. 
> I ask you not to send out a new draft quite yet. I believe the
> correct result is quite simple, and should not cause too much stress.
> But it is important to get this right, so I have a much 
> simpler solution,
> which I think will give everyone what they want. 
> 
For want of trying to add a little clarity (or succinctness) 
to this 'disagreement', I'm guessing that what is being asked 
is :

 "Can the SUBS/NOT relationship to be proposed, potentially be
  terminated in different ways dependent on whether the 
  terminating entity issued the original INVITE?"

Is it better that there is one implementation for SUBS/NOT or 
several? 

Personally I always thought the monitoring relationship, 
which the SUBS/NOT mechanism was to provide, was considered 
and intended to be a separate session. Therefore the issuance
of a SUB-SCRIBE with a different callID is OK, and in fact, 
the norm. 

To me this is not a religious issue or point or principle,
yet. 

All I would ask is that looking to the future when 'perhaps' 
several details of a finer granularity may be required by 
the sub-scriber at once e.g "I want to SUB-SCRIBE to these 
items of info. related to this INVITE", how would Scott's 
proposal fair? To terminate these sessions, would it be 
more intuitive (or indeed possible) to issue several SUBS 
messages with the original callID and Expires: set to 0 or 
a series of BYE's on the individual monitoring sessions 
themselves?

Also, please note that this issue, or one very similar, will 
arise in what could be considered to be the asymmetric work 
which will be undertaken in the PIN (or as it will be known 
the SPIRITS) working group. 

> I welcome any comments, including of course from my esteemed fellow
> editor, on the subject. My feeling is that both camps should 
> be perfectly
> happy. It is entirely possible to use a new call-id, and 
> indeed there are
> cases where this will happen quite naturally. But if you are 
> in the simple
> ordinary case where the same client first sends and INVITE and then a
> SUB-SCRIBE to the same call, the simpler syntax of just using the same
> Call-ID can be used. 

Sorry, I'm not too sure it is as easy as this Scott. What 
'I think' you are proposing, as a "simple ordinary case" 
could, be considered to be 'somewhat' more confusing, namely: 

'Everyone CAN use BYE to terminate a SUBS/NOT monitoring session, 
UNLESS they issued the original INVITE, in which case they MAY 
ALTERNATIVELY use the same callID in the SUB-SCRIBE message as 
was used in that originally INVITE message. Such SUBS/NOT 
monitoring sessions MUST then be terminated using a re SUB-
SCRIBE with the Expires header set to 0 (and the same callID).
This is because any use of BYE with these attributes, in these 
cases, would terminate the INVITE.'

As I previously stated I am not intending to get all religious 
about this, I just hope we get something that apart from 'just'
working, also makes sense (now and in the future) and is clearly 
understandable in all (forseeable) cases.

Kind regards,

Jim Buller

Roke Manor Research Ltd.
+44 1794 833697

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

---

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

1. However you slice and dice it, now or in the future, if an INVITE is
received, and then later a BYE, with identical (to, from, call-id), the
call is over, ended, kaput, erased. This includes any monitoring, changes,
INFOs, OPTIONs, whatever. The call is over. This is the simple, basic,
straightfoward, one-party, case. It is absolutely true that you can't get
fancy dancy granularity or third-party or lots of other services. 

Let us not argue whether this simple case is the "norm" or not. I happen
to believe that it will be the norm, and you happen to believe that it
won't be. That's fine. On the other hand, it's not a matter of belief that
signaling this case by three messages (INVITE, SUBSCRIBE, BYE) with a
single call-id requires a less memory and processing than signaling
this case by four messages (INVITE, SUBSCRIBE, BYE, BYE) and two call-ids.
This means three-quarter the messages on the wire and half the SIP
call-legs in memory. When call volumes get very very large, it seems a
pretty big win to me.

But I completely agree that there are services such as third-party
monitoring (and others) where there will be multiple SIP call legs
referring to a single PSTN call.

As far as the argument about "why have two ways to do things when one will
suffice" -- this is a very good question, and I agree that it requires a
solid answer. The reasons in this case are:

	a. in the case of basic first-party call control, the "same
call-id" method reduces processing and memory in the end systems, and also
the network traffic (i.e. number of messages) required.
	b. both methods must be supported anyway: In SIP, you may
issue new requests with an old call-id, and we have a requirement to
enable third-party monitoring, which implies a requirement to have new SIP
call-legs to refer to an ongoing PSTN call. 

I admit that in my mind, I am happiest thinking that the "ordinary" case
is when a single SIP call-leg
refers to a single PSTN call. For all sorts of wierdo reasons, this isn't
quite true all the time, in SIP or in PINT. But I still think that it's
worthwhile to allow the simple signalling whenever possible. 

Scott

---------

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 30 Aug 1999 15:40:05 -0400

Pardon my ignorance as I have not kept up todate with PINT, but it seems to me

that the problem is not with the callId being overloaded.  It seems quite
logical to correlate the monitoring of a call session by using the same callId

in a SUB-SCRIBE. I see the problem being that BYE is being overloaded.   In
the core SIP BYE ends a call session.  Now with the PINT extension BYE can
mean end the call session or end the SUB-SCRIPTION or both.  I see the BYE
method used with SUB-SCRIBE for two reasons:
  1) To end a subscription without the final notify infomation.
  2) To reduce the number of messages (i.e. instead of 2 instead of 1 in
Scotts example to end the call session and UNSUB-SCRIBE in a single message).

A quick (i.e. not well thought out) suggestion as to how to provide these two
(I am assuming) requirements follows:
1) SUB-SCRIBE with Expires equal zero makes clearly ends a SUB-SCRIPTION. If
you would like to end a SUB-SCRIPTION without the final notification why not
add some sort of modifier (i.e. an additional field or Expires: equals -1).
2) If you want the BYE to also end the SUB-SCRIPTION (it should ALWAYS mean
end the call session, IMHO) add a modifer to the BYE to clearly indicate this
( i.e. an additional field EndSubscriptions: callIds).

I appologize if this has already been discussed.
Dan