Subject: 183, BCP & forking

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 16 Nov 1999 16:51:51 +0200

Hi,

In the last SIP meeting in DC there was a discussion about forking or
not forking in the SIP-BCP-T...

I would like to write down some ideas about this, but not just related
to SIP-BCP-T...

When we have a SIP UA in our computer is not a problem to reach a user
in several places at the same time (forking the INVITE), but when we
have the "old black phone" we run into troubles. This is the case of
PSTN phones, but also if we build a SIP phone that looks like a
traditional phone, and I believe lots of people want this kind of
device.

We want to call B, and we issue an INVITE. Our INVITE hits a proxy that
forks it and sends it to several locations (parallel search) where B can
be reached. We receive one 183 reponse and we begin hearing a ringback
tone or an announce... in the meantime, we receive a 200 from another
location... what should we do??

Because it is not a good idea to CANCEL the rest of the branches when I
receive a 183...

Maybe we could specify that we do not want parallel search in our caller
preferences... in this case, as Scott suggested, the caller preferences
would have to have priority over any logic (CPL) intalled in the server.

Maybe it is worthwhile saying something about this in the 183 draft.
Maybe instead of saying "no fork" it is better to say "no parallel
search" in SIP-BCP-T...

Any ideas?

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 17 Nov 1999 10:19:19 +0200

[email-masked] wrote:
> Gonzalo Camarillo wrote:
> Why? Seems perfectly fine to me. This is a feature rather than a bug --
> you'd typically want all phones at which you're potentially reachable to
> ring. How second and subsequent 200 OK's are handled is up to the
> calling UA and/or the forking proxy.  I don't see why "old black phones"
> are any different from SIP softphones in this respect, and I think it
> would be a mistake to disallow forking whenever black phones are
> involved. Neither calling UA or proxies should need to know there's a
> PSTN (-like) phone at the other end.

The problem is not when we callee (B-party) is a "black phone". The
problem I see is when the caller (A-party) is one PSTN-like phone.

We do not have a display or something like that to trace the status of
all the locations where our INVITE arrived.

So, A is calling B, and B can be reachable at B1, B2 and B3.

B1 sends back a 183, and A hears from the speaker some kind of announce.
In the meantime, B picks up B2, and A receives a 200. Now A's speaker
suddently stops playing the message from B1, tears down the connection
with B1 and connects to B2... then we will CANCEL the other branches, so
as soon as we receive the first 200 there is no problen with receiving
subsequent 200 responses.

I believe this is not acceptable.

What do you suggest if we receive two 183 responses from different
locations? Which one shall the caller hear?

Maybe one is an announce and the other is a ringback tone... maybe both
are ring back tones...maybe both are announces...

Gonzalo

> That assumes the caller knows he's calling a black phone, right?
> Otherwise he'd have to always specify no-forking in the caller prefs.
> 
> >
> Anders Kristensen <[email-masked]>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Nov 1999 08:47:41 -0500

> location... what should we do??

Two choices:

1. If your aim is for the phone to speak with the first person that is
reached,
accept the 200 OK with an ACK, and stop playing out any ringback
received as a result
of the 183. As a 200 OK has been received, a CANCEL would have been
generated by the
proxies that will effectively stop the announcement on the remote side.

2. Send a BYE to the 200 OK (automatically, without user intervention),
and hope that the party that sent the 183 will answer the phone.

> would have to have priority over any logic (CPL) intalled in the server.

Doing this is probably the best bet.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 16 Nov 1999 19:21:32 +0000

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 18 Nov 1999 11:33:30 +0000

> problem I see is when the caller (A-party) is one PSTN-like phone.

Ah, I see.  I'd say the calling UA probably should send caller prefs
saying parallel search is undesirable, but other than that it is a local
matter for it to figure out how best to deal with multiple responses,
early media etc.  Yes, there may be odd cases, but they're likely to be
uncommon and probably unavoidable (in principle at least).

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 18 Nov 1999 18:17:07 -0600 (CST)

>Because it is not a good idea to CANCEL the rest of the branches when I

For starters, there is a major flaw, in my opinion, in using 183 and
then sending a *ringtone*, as you suggest. That would be a *180*
followed by a ringtone, or a 183 followed by some tone or announcment
that does not indicate "ringing," "your call is being forwarded," or
"your call has been queued" in any way.

For your example, I'd say it's pretty obvious that you need to CANCEL
the branch that sent a 183 (and be prepared to BYE it), and switch the
media to the 200.

In general, though, you're right; forking poses an extreme problem
for PSTN interworking, for two reasons: ISUP message consistency 
(when tunneling) and media stream selection.

I'm not going to approach the first one right now. For the second
one, I've toyed around with the concept of defining an ordering for the
1xx status codes; e.g.:

- If you receive a 180 with a media session, the proxy will forward it
  unless it's already passed a 1xx with a media session.

- If you receive a 181-183 with a media session, the proxy will forward it
  unless it's already passed a 181-183 with a media session.

In this way, a user may hear ringtone, followed by an announcement
(from a different branch) that the call has been queued; but never
the other way around (since the ringtone could interrupt a word).

Opinion from the list: would an attempt to codify such behavior for
forking proxies involved in PSTN calls seem useful, or should we 
just come up with a mechanism to prohibit forking for these types of calls?

(***NOTE*** these are just examples, not actually proposed modifications;
 at least, not yet. I don't want to start a debate on the actual
 "rules" I've stated above as much as a discussion on whether this sort
 of work would be useful).

--
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: "Daniel G. Petrie" <[email-masked]>
Date: Thu, 18 Nov 1999 22:24:33 -0500

> just come up with a mechanism to prohibit forking for these types of calls?

How can you know to prevent forking?  You have already forked the call after
which you received 18x response(s) with media.  The user agent does not know
apriori and odds are the proxy does not know either that a 18x response with
media is coming..  Perhaps both desire forking. They do not know until it is
too late
that they are going to get an 183 response.  If anything is to be surpressed
its
the 18x response with media.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Nov 1999 00:13:06 -0500

> the branch that sent a 183 (and be prepared to BYE it), and switch the

You can't CANCEL individual branches. CANCEL is for the whole
transaction.

> the other way around (since the ringtone could interrupt a word).

The problem can also be solved locally at the UA through RTP. The UA
will be able to distinguish one audio stream from the other (we'll
eventually have an end to end provisional acknowledgement which can
contain SDP with an updated port number). Thus, it can simply not play
audio from a 180 on one branch after getting a 183 with audio on
another.

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 19 Nov 1999 14:20:10 +0200

Hi,

The problem is still there.

Why do we have to hear the announcement related to the first 183
received and not the announcement related to the second one? Just
because the first 183 response arrived a few miliseconds before?? It
does not sound very good to me...

Even it is not that clear that an announcement has always higher
preference than a ringback tone (180 vs 183 responses).

If SIP is going to interoperate with the PSTN we have to have a
predictable behaviour... that is, the user knows what's going on when he
listens to the handset (remember that the user may not have a display a
monitor).

The idea of 1xx reponses with media (when it comes to PSTN-SIP
interworking) is to be able to hear the ringback tone generated by the
last PSTN exchange. If we are going to hear this ringback tone from one
branch and then we are going to connect to another branch (because a 200
OK has arrived from the other branch), the ringback makes little sense.
It would change the semantics of the ringback tone for the PSTN user.

The parelell searching sounds like a good idea for reaching a user
saving some time. The problem is how to have the user updated about the
status of the different branches. If we cannot keep the user updated it
is better to perform sequencial search.

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Nov 1999 09:48:26 -0500

> does not sound very good to me...

Do whatever you want. My point is only that the UA will know what
streams are from where, and can decide as it wishes to play one, some,
none, or all.

-Jonathan R.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 19 Nov 1999 10:42:50 -0500

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
To: Adam B. Roach <[email-masked]>
Cc: Gonzalo Camarillo <[email-masked]>;
<[email-masked]>
Sent: Friday, November 19, 1999 12:13 AM
Subject: Re: 183, BCP & forking

> You can't CANCEL individual branches. CANCEL is for the whole

The forking example within the August 1999 SIP Draft uses a CANCEL
message to cancel an individual branch.  Is this no longer valid?
Or are you saying that the CANCEL can not have a TAG in the TO field.

CANCEL appears to be very helpful for services like
CallForwardingNoAnswer in a proxy server.
The CANCEL would end ringing on phone B so that phone C could
be tried next.  This actually causes a forking situation since phone B's
200 response for INVITE could cross on the wire with the CANCEL.
Thus 200 responses for INVITEs could be received from both B and C.

Here are four solutions dealing with forking:

1) Phone A (or SIP end node for phone A) would have to send ACK
and BYE for unwanted or unexpected 200 responses for INVITE.
I think that this solution best fits the current SIP draft.

2) Allow proxy servers to send BYEs.  People have mentioned that
this causes problems concerning the CSeq and encryption.

3) Allow a CANCEL to trigger a BYE from C if C has sent a 200
response for the corresponding INVITE.  This action is not specified
in the SIP draft, but I have not heard a reason against
this solution (although I assume someone could inform me).

4) Allow the proxy server to drop unwanted or unexpected 200 responses
for INVITEs.  I would not like this solution since I assume not receiving
an ACK could still allow it to remain in the call.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 20 Nov 1999 01:19:25 -0500

Brett Tate wrote:

> Or are you saying that the CANCEL can not have a TAG in the TO field.

I'm saying a CANCEL can't have a tag in the To field. In the example you
refer to,
a CANCEL is not sent for the other forked requests as they have already
responded.

> be tried next.

Agreed, but you don't need tags for this to work. Just send the CANCEL
to cancel all phones that might currently be ringing, and then send your
next INVITE.

  This actually causes a forking situation since phone B's
> I think that this solution best fits the current SIP draft.

I expect this to be the behavior in 99% of the cases.

> this causes problems concerning the CSeq and encryption.

Yes, this definitely causes problems.

> this solution (although I assume someone could inform me).

The difficulty is that this fundamentally changes the semantics of
CANCEL. CANCEL does not mean hang up, it means "terminate search".
Consider a typical case. Forking proxy P sends 2 INVITES. It gets a 200
OK to one, and then sends CANCEL to the other. Unfortuantely, this
CANCEL, downstream from the proxy, gets forked again and reaches the UA
which responded with that 200 OK. Now, according to your proposal, this
would cause the call to be hung up. This is not the desired behavior in
this case.

Handling of multiple 200 OK is best left to the UA, since it can hang up
with the additional 200 OKs, as you mention above. Or, it might even
initiate a conference call. However, only the UA can know which to do.

> an ACK could still allow it to remain in the call.

This isn't guaranteed to work, since only a stateful server can do this.
If a proxy, after receiving a 200 OK, goes stateless, and then receives
another 200 OK, it will be forwarded. In any case, I'd rather let the
end systems decide on the right behavior.

-Jonathan R.