Subject: Re: 183,BCP & forking

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 18 Nov 1999 09:34:16 +0200

[email-masked] wrote:
> 
> Gonzalo Camarillo wrote:
> >
> > 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...
> 
> 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

> >
> > 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.
> 
> 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.
> 
> >
> > 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
> 
> --
> Anders Kristensen <[email-masked]>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK

-- 
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