Subject: RE: 183, BCP & forking

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 19 Nov 1999 09:55:53 -0600

There is a PSTN feature called MADN (Multiple Appearance Directory Number).
At the terminating end, this rings multiple sets.  It may be possible to dig
up the feature description and see how this is supposed to appear to the
originating user.  I'll see if there is anything helpful here.  There may
not be because there may be restrictions on the terminating numbers which
prevent cases where one would get ringback (ringing tone) from one
appearance and something else from another.  

> -----Original Message-----
> From:	Gonzalo Camarillo [SMTP:[email-masked]]
> Sent:	Friday, November 19, 1999 7:20 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: 183, BCP & forking
> 
> 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
> 
> 
> [email-masked] wrote:
> > 
> > "Adam B. Roach" wrote:
> > >
> > > 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.
> > 
> > You can't CANCEL individual branches. CANCEL is for the whole
> > transaction.
> > 
> > > 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).
> > 
> > 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.
> > 
> > --
> > 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
> 
> -- 
> 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: Larry Cox <[email-masked]>
Date: Fri, 19 Nov 1999 11:53:58 -0700

Some common Centrex type behavior patterns are also significant problems.
Example:

1) a call to site A rings at stations 1 and 2.
2) after 10 seconds un-answered,
   station 3 is added to the ring list.
   1 and 2 are still ringing.
3) after 10 more seconds station 4 is added to the ring list.
   four stations are now ringing.
4) after 10 more seconds ring is canceled on all four stations.
   the call is forwarded to station 1 at site B

This is an example of the type of call features that people want to add to
simple systems. The problem that we are facing is the requirement that
responses at the origin of the call have to make sense even though we do
not have easy access to the information required to keep the decisions
simple at the destination end of the call. It has mostly been assumed that
intelligence at the destination end was required to achieve rational
behavior on a complex call. Even though I sometimes wonder if it is safe to
remove that assumption, our objective is to enable complex calling
capability across multiple switching systems. If we send an INVITE to a
node that starts ringing on multiple stations and concurrently to a second
node that produces multiple responses, it is easy to describe an
environment that will produce several irrelevant media responses and also
result in the call being answered in multiple locations. At present PBX and
Centrex systems can respond quick enough to cancel ring a few milliseconds
after the call is answered on one ringing station. In a distributed
environment, latency will result in much more unpredictable behavior.
Instead of picking up a ringing phone and hearing dial tone (resulting in
the conclusion that the calling party had already disconnected), there
could easily be 2 or more seconds of silence resulting in the conclusion
that the calling party waited to identify who answered and then
disconnected. On a cell phone, this could also result in the answering
party being billed for the wasted air time.

Larry

At 02:20 PM 11/19/99 +0200, you wrote:
>> > one, I've toyed around with the concept of defining an ordering for the
>> > 1xx status codes; e.g.:
>> >
>> > - If you receive a 181-183 with a media session, the proxy will forward it

======================================

Larry Cox
Senior Software Engineer

Hypercom Network Systems Inc.      Phone: (602) 504-4657
2851 West Kathleen Road            Fax: (602) 504-4711
Phoenix, AZ 85053                  Web: www.hypercom.com
USA

---

From: "Schroeder, Tim" <[email-masked]>
Date: Mon, 22 Nov 1999 17:09:21 -0600

Gonzalo Camarillo wrote:
> 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 response and we begin hearing a ringback
> tone or an announce... in the meantime, we receive a 200 from another
> location... what should we do??

Jonathan Rosenberg wrote:
> 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.

That seems OK.

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

Isn't this effectively a call defect?  Someone answered a ringing phone
(causing the 200 OK to be sent) and the caller immediately hangs up on them?
I don't think I like that.  Especially when they get dropped in the hope
that someone might answer the phone that isn't even ringing yet?  (Do I have
that right?)

Gonzalo Camarillo wrote:
> 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) installed in the server.

Jonathan Rosenberg wrote:
> Doing this is probably the best bet.

I think we ought to be very leery of letting the caller determine the
behavior of the callee's service/equipment.  In this case the parallel
search is being done by a proxy server, presumably because the called party
has signed up for some "Find Me" sort of service that has that behavior.
Should someone then be able to call and over-ride that behavior?  It seems
if I have a whole set of phones that I expect to ring in unison (and that I
can answer any of them) it could be pretty annoying if someone could usurp
control of them and ring them serially and make me wait for the one nearest
me to ring before I could answer it, or deny me the ability to answer the
'first' one, even though a later one was still ringing.

Since SIP has the capability of doing these parallel searches, I think we
ought to figure out how not-very-smart terminals (black phones) can deal
with that, rather than letting them forcibly alter the behavior of SIP for
someone who has a fully capable terminal.

Tim Schroeder

This e-mail and any files transmitted with it are the property of SBC,
are confidential, and are intended solely for the use of the individual
or entity to whom this e-mail is addressed. If you are not one of the
named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender at
[email-masked] and delete this message immediately from your
computer. Any other use, retention, dissemination, forwarding, printing,
or copying of this e-mail is strictly prohibited.

---

From: "Schroeder, Tim" <[email-masked]>
Date: Mon, 22 Nov 1999 17:50:28 -0600

Adam B. Roach [mailto:[email-masked]] writes
> 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?

I believe this has to be handled by the PSTN gateways, whether codified or
whether the decision is made on a gateway-by-gateway basis.  In general, I
think nothing else will know whether the party is on the PSTN or not, or
what the exact behavior of signaling on that PSTN ought to be.  I also don't
think prohibiting forking is correct, unless forking is completely removed
from SIP.  The server doing the forking may not be able to determine whether
a PSTN party is involved (although that may be worked around); more
importantly signaling behavior should not be different for one party because
the other is on (or across) a PSTN.

Tim Schroeder

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 23 Nov 1999 15:35:46 +0200

Tom,

I haven't heard about this PSTN feature (MADN) that you are referring
to, but it is probably because in Europe has a different name than in
the States.

I can tell you how the "Personal number" worked in the nordic countries
though.

This was an IN (Intelligent network) service. The user had a personal
number where he could be reached.

Tipically the user had three kinds of phones.

1) GSM phone.
2) NMT phone (a mobile network in north Europe).
3) Fixed phone.

When the personal number was dialed, the IN node tried first the GSM
phone. It sent the GSM number to the GW-MSC with a parameter indicating
that announcements were not allowed.
Therefore, if the user was not reachable in the GSM network, instead of
playing "The mobile cannot be reached", a REL was sent back. 
Then, the IN node tried the next number (NMT phone), and so on. Thus,
the search was always sequencial.

This way, the caller did not hear "The mobile cannot be reached" before
the call was actually answered. Do we want this to happen in SIP? :o)

Best regards,

Gonzalo

> [email-masked] wrote:
> 
>     ---------------------------------------------------------------
> 
> There is a PSTN feature called MADN (Multiple Appearance Directory
> Number).  At the terminating end, this rings multiple sets.  It may be
> possible to dig up the feature description and see how this is
> supposed to appear to the originating user.  I'll see if there is
> anything helpful here.  There may not be because there may be
> restrictions on the terminating numbers which prevent cases where one
> would get ringback (ringing tone) from one appearance and something
> else from another.
>