Subject: ISUP tunneling

From: Sanchez Jorge <[email-masked]>
Date: Fri, 06 Aug 1999 09:45:32 +0200

Hi Adam,

I have a question regarding draft "ISUP parameters expected in SIP
messages"
<draft-roach-sip-isup-parameters-00.txt>. You describe that ISUP
messages
can be expected in a CANCEL or BYE request. I suppose that all messages
tunneled
onto SIP are carried in Content-Encoding header field, and this header
is defined in
SIP as being not applicable for CANCEL and BYE methods. What am I
missing here?

Regards,
    Jorge

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 10 Aug 1999 14:35:10 -0500 (CDT)

>SIP as being not applicable for CANCEL and BYE methods. What am I

Nothing; I overlooked this fact when I put the draft together.
Thanks for pointing this out. I will mention, in future versions
of the draft, that the use of ISUP tunneling for this application
adds the possibility of having Content-Encoding headers on
BYE and CANCEL messages.

Henning, Jonathan, et al: is there a reason the Content-Encoding
was marked as N/A on BYE and CANCEL? Could this be added to 2543
when all the other bugfixes are put in?

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Aug 1999 22:55:59 -0400

> when all the other bugfixes are put in?

The reason was that BYE was not supposed to carry any body.
Content-Length and
Content-Type are similarly not allowed. Clearly, if ISUP tunnelling is
done,
there is a need. I can see there might be other applications. Its easy
enough
to fix.

CANCEL is a different story. Its not end to end; its regenerated at each
proxy.
This means it cannot be protected by end to end authentication or
encryption. 
It can also be originated by proxies, unlike BYE, which cannot. I would
argue
that there never should be a body in a CANCEL. It should not be used to
convey
call information beyond "cancel the search".

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Aug 1999 03:36:01 -0400

> when all the other bugfixes are put in?

Yes, that's one of the bug fixes to be included. I hope to have the
first post-2543 draft ready in a few weeks.

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 11 Aug 1999 10:26:01 -0500 (CDT)

>call information beyond "cancel the search".

We had a conversation last week about CANCEL and BYE that really 
cleared some things up for me; however, it's not information that 
I've seen written down anywhere. It may be useful to document 
somewhere that, for example, when a UAC wishes to terminate a session, 
he typically sends a BYE instead of a CANCEL to do so, even if no 
INVITE response has been received yet. (As an aside: doesn't this 
mean you have two pending transactions at the same time? Is that okay?)

More to the point, it seems that the only nodes that would ever have 
an interest in generating a CANCEL is forking proxies.

Section 4.2.5 of RFC2543 implies that there is some utility in the UAC 
generating a CANCEL; perhaps this was part of the original design. 
At any rate, this no longer seems to be the case, so I'd propose 
that 4.2.5 be reworded to reflect current conventional wisdom.

I'll make a note to clean this up in the next draft of "ISUP parameters
expected in SIP messages," unless someone has a counter-argument.
Specifically, I'll remove mention of CANCEL from sections 2.6 and
2.7, and add CANCEL to the list of messages which should not carry
ISUP payloads in section 2.9.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Aug 1999 03:36:01 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Aug 1999 03:36:01 -0400

> when all the other bugfixes are put in?

X-Mozilla-Status: 0009e bug fixes to be included. I hope to have the
first post-2543 draft ready in a few weeks.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Aug 1999 13:05:32 -0400

"Adam B. Roach" wrote:

> mean you have two pending transactions at the same time? Is that okay?)

See Section 4.2.4 in the preliminary revised version of the SIP spec
posted on the SIP web page (ttp://www.cs.columbia.edu/sip/drafts.html).
(Note that this version does not yet incorporate all proposed changes
and corrections noted in the "Changes" section.)

> that 4.2.5 be reworded to reflect current conventional wisdom.

Not quite. If I've connected to a callee and would like to make the
probability of another 200 very small, CANCEL is the right approach. BYE
won't do it in that case, as it would terminate the call.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Aug 1999 17:51:49 -0400

> and corrections noted in the "Changes" section.)

The issue, as I recall, was to how the BYE is used. There are two
possibilities:

1. After the INVITE is sent, the UAC decides it wants to hang up. So, it
sends a CANCEL. Under normal circumstances, this will arrive before any
UAS has answered. The UAC receives a 200 OK to the CANCEL immediately
(since its locally generated by the first proxy), and then a 487 Request
Cancelled response later on, after its been passed back from the UAS's,
through the proxies, and back to the UAC. Problem is, a 200 OK and a
CANCEL may "pass on the wire". In this case, the UAC still gets a 200 OK
to the request. So, it sends an ACK (?), and then hangs up with a BYE.
Note that the ACK and BYE both have tags, as they are directed at a
specific user. In really oddball cases, there may be multiple 200 OK's,
and the UAC must send an ACK (?) and then a BYE for each (always with
tags matching the tag in the 200 OK).

2. After the INVITE is sent, the UAC decides it wants to hang up. So, it
sends a BYE. This BYE has no tag in it (as there has not been any final
responses). The BYE (hopefully) follows the same set of proxies as the
original INVITE (there is no Route header either), and reaches the same
set of UAS's as the INVITE. Each of those then sends a 200 OK to the
BYE, and some kind of error response to the INVITE. The UAC will
therefore see a 200 OK to its BYE, and an error response to its INVITE.
However, there is also a race condition here. The BYE and a 200 OK to
the INVITE may pass on the wire. Thus, the UAC may see a 200 OK to the
INVITE, and a 200 OK to the BYE. In this case, though, the UAC doesn't
need to do anything else, since the BYE will still have caused the call
to hang up. This case can yield odd results if the BYE reaches a
different set of UAS's than the INVITE. Then, the UAC may still receive
a 200 OK to the BYE (since one of the UAS's responded with a 200 OK),
but the call is still active with some other UAS which did not get the
BYE. This would be really bad, in fact. 

I used to think the right approach is (2), but after discussing it with
Igor, Adam and others, and thinking about it some more, I'm beginning to
think (1) might be better. The case of one side thinking the call is
active, and the other thinking its not, is quite bad. The only issue
here is whether to send an ACK to the INVITE in this case. I'm inclined
to say yes, so that the effect of a CANCEL is really just to speed up
completion of a transaction; otherwise, the behavior is normal. 

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Aug 1999 19:08:05 -0400

Jonathan Rosenberg wrote:

> Cancelled response later on, after its been passed back from the UAS's,

Assuming, of course, that there were no lower-numbered responses from
somewhere else in the pipe. 

> BYE. This would be really bad, in fact.

I agree that (1) is cleaner in that each transaction is either canceled
or any call state explicitly removed via BYE, but (2) may still work,
sort of.

The UAS that didn't get the BYE will send a 200 (worst-case; if it sends
something else, no harm is done). At that point, the UAC will get the
200, and will send another BYE, with tags and direct via Contact. Or, if
it is stupid and lost all memory of ever having dialed that Call-ID, it
won't send anything (no ACK) and the other side will time out after
retransmitting the 200. This is not great, as the callee presumably has
to assume that the call exists until the 200 retransmissions ceases
rather than waiting for the ACK.

> completion of a transaction; otherwise, the behavior is normal.

I think it would be best to have the transactions complete as much as
possible. 

The UAC should send an ACK to stop the retransmission of the 487 by
either the nearest stateful proxy or the UAS.

Let's see if we can formulate a set of reasonably simple rules for this:

- Once an INVITE has been sent, the UAC has to be prepared to ACK final
responses even after hanging up. (The final response contains enough
information to formulate the ACK, so the UAC wouldn't have to keep
call-state.)

- If a UAC receives a 200 response [for a call it has cancelled | call
that is not currently active], it sends a BYE to the Contact address or
>From address, if available.

One question is when a UAC that wants to hang up can stop sending
CANCELs and just send a BYE. After all, it could happen that it received
the first 200, but the proxy didn't CANCEL the other pending calls. One
simple rule is after the (first) ACK.

---

From: Scott Petrack <[email-masked]>
Date: Sun, 22 Aug 1999 22:30:45 -0400 (EDT)

We certainly prefer approach 2 -- send a BYE to terminate a call. The
rules seemed simple to us:

	a) Send a CANCEL to stop branches of a parallel search. 
	b) Send a BYE to terminate a call.

These are two separate things. A CANCEL never affects a UAS which already
sent a 200 OK. If you want to terminate a call, you can always try sending
a CANCEL in hopes that it will help, but you will have to send a BYE to
anything that responded 200 OK to the INVITE. We just send BYEs for now.

If the UAC gets a tagged response to the
INVITE, and does not get an identically tagged response to the untagged 
BYE, the UAC must retransmit the BYE with the correct tag in the To: line.
(of course, it might have to send the BYE to the address it got from the
Contact: field in the response). 

If the SIP system routes the BYEs to a different set of UAS as it routed
the INVITEs, maybe it will also route CANCEL to still a different set. 

Bottom line: send a BYE to hang up a call. You might have to send more
than one BYE (a "general" BYE and then some specific ones aimed at
particular UAS (using a tag or a Contact: address).

Scott

---

From: Igor Slepchin <[email-masked]>
Date: Tue, 24 Aug 1999 15:43:18 -0400

I would argue that sending a BYE with no tag creates a considerable
number of problems and protocol changes and gives little advantage. 

First, such a BYE is not guaranteed to reach the same set of recipients
as the original INVITE (e.g., due to some ACD logic or because of
200OK-BYE race condition) so the UAC still must be prepared to receive
200OK even after sending the BYE and will have to send tagged BYEs to
those call legs.

Second, there is no way to honor Record-Route in such a BYE, which might
leave some of the midstream proxies in inconsistent states.

Third, such a BYE would be just another exception from the rules for
forming SIP requests. Basically, it would follow almost the same rules
as CANCEL (no tag, don't honor Contact, etc.), which is quite different
from regular (tagged) BYE. This will also violate the rule that
consecutive transactions on a call leg must include the tag (which is
mentioned in several places throughout the RFC).
	
Finally, what do you gain by sending a BYE with no tag? If you are
concerned about call tear down time, you can send CANCEL and tagged BYEs
in quick succession. This will take nearly the same time and only few
extra messages since it does not seem likely that UAC would receive more
than a handful of 200OKs. Of course, this still violates the rule of
never having two active transactions for the same call leg, but I
believe this is considerably cleaner than the "no tag BYE" approach.

---
Igor Slepchin

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 24 Aug 1999 15:00:56 -0500 (CDT)

>number of problems and protocol changes and gives little advantage. 

(Summary)
1) ACD (and similar services) makes BYE routing unreliable
2) Can't honor Record-Route
3) Another exceptional behavior (BYE that acts much like CANCEL)
4) No gain in sending BYE instead of CANCEL

 From a SIP protocol point of view, I agree with what Igor is saying.
Now, to confuse the issue:

Since CANCEL is sent hop-by-hop (instead of end-to-end), it
makes it impossible to transit ISUP release messages across
the SIP network unless a call has already been established.
I know this isn't a SIP problem, but, since people are expecting
to be able to do this, it might be something we want to take
into account.