Subject: Re: SUB/NOT proposal

From: [email-masked] (Lawrence Conroy)
Date: Fri, 27 Aug 1999 01:29:45 +0100

Hi folks,
In response to the question raised by Scott...

What we have in the draft already works (but needs a text clarification).

Scott's suggestion (sometimes using SDP, sometimes not, sometimes using
BYE, sometimes not) is a different design.

The underlying assumptions seem to be that a Monitoring session is a new
session (in the Draft) or another aspect of the same session (in the new
proposal). In the draft it should (but doesn't quite :) say that a new
Call-ID is used for the Subscription in all cases.

This has the advantage that the same technique (and code :) is used in any
case. (and it's a couple of lines of text to clarify the situation).

Scott's proposal allows the client who originated the Invitation to use the
same Call-ID, but then they must use SUB with Expires:0 to close the
session; they can't use BYE as that would be ambiguous.

It has the advantage that there is no apparent need to send an SDP body
part with the Invited global-session-id when the original Client makes the
SUB, but this is not possible if another entity makes the Sub scription.
Thus we have two different "opening" methods.

Note that the Sub with Expires:0 will always work - any node can use this
closing technique. The only real difference is that the Inviting client
can't use BYE, whilst everyone else can, IF it uses the same Call-ID.

PINT Gateway code has to support sending SDP and using that to correlate
the two sessions when the SUB is received from a third party. That's
required as the third party can't use the same (Call-ID, From, and To)
tuplle as the original Invite.

If we accept the other approach, then the Gateway will have to see whether
or not the "SIP-part" of the SUB (Call-ID, From, To) matches an earlier
Invite, and then to process that. If, however, it's from another node (and
so has a different Call-ID, From, To) tuple the Gateway will reject it if
it doesn't contain an SDP body with a global-session-id that correlates
with an earlier request. I think that my Gateway code just got a whole lot
more complex.

BTW, I have a feeling that this situation is more complex when one is
dealing with Subscriptions that involve hand-off, or Subscriptions that are
made by a third party but thet hand-off to a fourth. The "draft" scheme
works (I've drawn enough diagrams to check), but I'm not sure what the
impact of the new proposal is in these cases.

Is saving an SDP body in the case where an Inviting client makes a SUB
worth the extra complexity (and the necessary re-design/re-write in Last
Call)? Opinions requested.

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.

---

From: Scott Petrack <[email-masked]>
Date: Fri, 27 Aug 1999 17:19:51 -0400 (EDT)

The possibility to use the Call-ID of the session has been in the draft
from the very beginning. It is stated explicitly in simple English (well,
in English, at any rate ;-)) at the start of paragraph 3.5.3.1.
I am happy to be able to assert that poor Lawrence's code will be
exactly as complex or simple as it is now.

Further, what I am suggesting is a part of simple vanilla SIP. It is
a standard part of the way requests and "re-issues" of requests work. 
It is a simple optimization of the most common case as well. Please bear
with the following comments:

> Call-ID is used for the Subscription in all cases.

In SIP, after
an INVITE, you can always issue other requests concerning the same Call.
We do this in several places in PINT. We say
explicitly that if you send an additional request concerning Call-ID YYY,
you don't have to send the SDP if you know that it is known to both sides.
This is a normal feature of SIP. For example, you don't have to re-send
SDP in a BYE -- the Call-ID is enough to know what session you are
referring to (because you sent it in a previous INVITE and so it is shared
state among the participants).

> case. (and it's a couple of lines of text to clarify the situation).

The same technique and code is used in every case. When you get a new 
request concerning an known (To, from, Call-ID) triple, it refers to
a known SIP call leg. The SIP call leg may well have session information
associated with it. No need to resend it.

> session; they can't use BYE as that would be ambiguous.
No, they can use BYE as well, and it is not ambiguous:

	SUB with Expires:0 means -- end the subscription (what Lawrence
calls a "monitoring session")
	BYE means -- tear down the entire call PLUS monitoring session.

The client may send a SUB or a BYE, depending on what it wants.

Please remember that there is no protocol police on the Internet. It is
certainly possible to send these messages. Their meaning is unambiguous.
So you had best be able to respond to them. I suppose that a server
*could* reject a SUBSCRIBE with the same Call-ID with a "400 Bad Request".
But this would be a very impolite server, IMHO. It would also contradict
the beginning of 3.5.3.1.

> Thus we have two different "opening" methods.
This is no different than in every other aspect of SIP. If I send an
INVITE, and then change the parameters of the INVITE, I can use the
same Call-ID. If a third-party issues a new INVITE, then the session id
must be used. The idea is that in the most common case (that of first 
party monitoring or control), the signalling can be very simple. 
And when one wants a more complex service (like the ability to end the
Call without ending the monitoring), the signaling gets more complex. 

> can't use BYE, whilst everyone else can, IF it uses the same Call-ID.

No, the inviting client can also use BYE, but it will end the call. 

I am just interested in making simple signalling for the common case with
no third parties. I send the SDP exactly once, to request the call. After
that,
if all I want to do is monitor the phone call that I requested, the
Call-id is enough. Who would send SDP if s/he could avoid it ;-)

> tuplle as the original Invite.
Unless of course the Gateway does not support third-party
monitoring. In that case (which sounds very plausible to me). Once again,
the simple common case (no third party SUBSCRIBEs) can be implemented
simply.

I don't mean to sound fanatical. It's just that a SIP call leg is a 
resource like any other. If you believe (as I do), that for the vast 
majority of calls, there will be a SUBCSRIBE, but not a third party
subscribe, then it is nice to have the entire whole experience map to a
single SIP call leg. Not a big big deal, I admit, but simpler, it seems to
me, not more complex.

> with an earlier request. I think that my Gateway code just got a whole lot

Well, if it did, then you have missed some cases in your gateway. I am
sorry to say that you will have to check if the (Call-ID, From, To)
matches an known call leg in any case. Are you suggesting that you ONLY
look at the global-session-id, but not at the (Call-ID, to, from) triple?
Hmm, if you do, then you are not complying with the explicit allowance:

"The SUBSCRIBE request indicates that the a user wishes to receive
information about the status of a session. The request identifies the
session of interest by including the original session description along
with the request, or the Call-ID may be used if it is know to the receiver
to refer to a previously established session."

This is in the draft to cover exactly the case at hand. 

> impact of the new proposal is in these cases.

Unfortunately, the "new" proposal is in the draft too. I can save you 
the graphite, though -- the "new" proposal is equivalent to the other,
except that termiating the call terminates the monitoring....

> Call)? Opinions requested.

There is no re-design involved. The fact that you can use Call-ID has been
in the draft forever. In fact, at first, I only used Call-ID, but then we
realized that we need third party subscriptions as well.

Well, obviously, a clarification is needed in the draft. Probably in a few
places. 

My own feeling is that this is not a huge deal. But perhaps I am missing
something. I would like to keep the case of no third parties simple if at
all possible, however.

---------