Subject: Re: PINT: Question to SUBSCRIBE/BYE

From: [email-masked] (Lawrence Conroy)
Date: Thu, 26 Aug 1999 01:33:02 +0100

Bernie asks the question on how the INVITE and SUB sessions can be
differentiated when sending a BYE.

Hmm.. I think that a lot of the original ideas on SUB/NOT surfaced around
the L.A. meeting (both in the meeting itself and around the tables
afterwards). As I have the memory of a Goldfish, please forgive me if I
have mis-remembered.

An initial caveat: the rest of this posting does NOT cover the privacy
aspects of SUB/NOT - see the draft for comments on this.

As I recall...
One requirement for SUB/NOT was that it should be possible for another
entity other than the inviting PINT client to SUB to find out about the
invited service invocation. Thus, we need some way for that other entity to
make the request. This request should indicate in which service invocation
it was interested.

Another requirement was for it to be possible to have a sequence of
registrations of interest in the same service invocation; this would allow
a user to check, for example, that the requested service had started, to
end that SUB session, and then to check, the next morning, that the service
had completed successfully, in a new SUB session.

In addition, the idea was that either the PINT Gateway that was reporting
status OR the entity that was receiving the notifications could terminate
this monitoring relationship.

----------------
To fit these requirements, we needed some way to indicate in the
SUBscription the service invitation in question without relying on this
montioring request coming from the same entity that made the original
invitation.

I honestly can't remember who came up with the idea, but it was pointed out
that the SUBscription could include an SDP session description with the
same unique-session-id field. In this way it could come from any node but
would stil have the information needed to identify the service invitation
(uniquely :).

This avoided having to make the SUBscription message include the original
"SIP-style" tuple of (Call-ID, Cseq, and source). It's not easy to see how
these could be fitted in, other than adding yet more headers to SIP and
(probably) breaking existing parsers.

The choice on whether or not to use a new Call-ID was influenced both by
the requirement to allow another entity to start the monitoring session,
and also by the requirement that "either party" could terminate the
SUBscription.

Our choice was to allow either to send a BYE to the other indicating that
it was no longer ready to maintain this relationship (at this time). If the
PINT request was for a defered or delayed service, then sending a BYE
indicating that a monitoring session was no longer required (at that time)
should NOT be taken as indicating that the whole service request was a
horrible mistake and could the gateway please forget about the whole thing.

We needed to allow the "standard" BYE message to do what it normally does
(i.e. request that a session be terminated). The session in question is
indicated by the (Call-ID, Cseq, source) tuple, so, if we needed to
terminate the monitoring session without terminating the originally
requested service invitation, we needed two different tuples.

If the entity requesting the monitoring relationship were to be different
from that making the originaal invitation, then in theory a similar Call-ID
and CSeq could be used (I think) as the tuple would differ in the source,
but in practice it will be a different Call-ID "as it constitutes a new
call".

In the case where the SUBscription came from the same entity, then a new
Call-ID would need to be used, or at least a new CSeq; otherwise sending a
subsequent BYE would cause confusion as to its intent (forget the
INVITATION, or the SUBscription?). This would indeed cause the problem that
was raised on the list.

I HAD thought that it was apparent from this section that a new Call-ID
would be used, but sure enough, it says "Where the subscription is being
made by the user who initiated the original service request, the Call-ID
may be used as it will be known to the receiver to refer to a previously
established session". That was in the para talking about the reasoning
behind using the global-session-id; the next sentence shows why we can't
use this.

I can see how this could be misunderstood; I think another para is needed
to point out that a different tuple is needed to differentiate between
service invitation and monitoring sessions, and to spell out that a BYE to
a SUBscription is indicated by it's different Call-ID, CSeq, source) tuple.
I'll work on this and post later today.

-----------------
BTW, the text of section 3.5.8 (points 1 & 2) is actually referring to a
Client sending a BYE to an INVITE that it has previously sent (i.e. it
isn't talking about the BYE that ends a SUB/NOT session).

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: Thu, 26 Aug 1999 19:33:25 -0400 (EDT)

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. 

1. Of course it is allowed to send out a SUBSCRIBE with a new Call-ID.
Ordinary SIP allows this, and so do we. When a new Call-ID is used, this
is of course a new SIP call leg. Thus, this SIP call leg can be terminated
with a BYE, like every other SIP call leg. This is all very standard.

2. As the draft says, and as I for one certainly intended and do indeed
implement, for the simple case when you are SUBSCRIBE-ing to a call that
you are a party to, you can use the *same* Call-ID. In this case, there is
no need to send the SDP. The Call-ID is enough to say "I want to subsribe
to the call". This is very simple, and in many cases is enough.

3. Any SIP request can be re-issued with a higher CSeq later, in order to
update some parameters. This is used in vanilla SIP when an INVITE is
re-issued with a change in session parameters, and it is used in PINT
when a NOTIFY is re-issued with a change in the session parameters. In
exactly the same way, it is entirely possible to re-issue a SUBSCRIBE with
a change in parameters. In all these cases, the Cseq is increased in order
to show that it is not a retransmission, but a new request. In particular,
it is entirely allowed to re-issue a new SUBSCRIBE with a new Expires:
header. One example might be if an initial SUBCRIBE was for 1 week, and
then later is revised to SUBSCRIBE for only 6 hours. In fact, there is no
other way to change the subscribe time. In particular, it is perfectly
allowable to re-issue a subscribe with an Expires: header of 0. In this
case, the response will contain one last session description, and then
there will be no more NOTIFY messages sent. Simple, no? 

4. If you start a call with some Call-ID, and later SUBSCRIBE to the call
by using the same Call-ID, and then later send a BYE, you have terminated
the call (including any subscription). If you want to terminate the 
subscription only, you can re-issue a SUBSCRIBE with Expires:0.

Just to make certain that we are all on the same page, there is a small
and rather silly difference between what happens when terminate a
subscription via a BYE and when you terminate it via a SUBSCRIBE with
Expires:0 header. The difference is that if you use the Expires:0 header,
you will get one last look at the status in the response, whereas if you
terminate with a BYE, the response will just be 200 OK and will not
contain the "final" session description. (This is in the case when the BYE
contains the Call-ID of the previous SUBSCRIBE only -- of course if the
BYE had the Call-ID of the INVITE, the difference is rather more
significant: it terminates the call).

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
SUBSCRIBE to the same call, the simpler syntax of just using the same
Call-ID can be used. 

Can we agree on the list that this satisfies everyone? If so, then
Lawrence and I will agree on text to clarify the situation. 

Scott

---------