Subject: Re: Behavior of SIP Callee user agent

From: John Hearty <[email-masked]>
Date: Wed, 21 Apr 1999 09:51 -0500 (CDT)

>Of course, as has been pointed out, there are other, harder problems. If
>the 180 causes local ringback at the originating gateway, and is then
>followed by a 600, this causes the caller to hear a transition from
>ringing to fast busy. I don't see any solution to this, however. 

 I don't understand when such a scenario would come up in normal session
setups.  A 180 is presumably going to come from a terminating SIP client
that got the Invite and is in the process of alerting the callee.  Why
would a 600 follow that?  In the case of terminating at a PSTN gateway,
I presume it would send a 183 after it received some kind of confirmation
from the PSTN that alerting may be in progress.  I am mainly familiar
with ISUP, and in that case it would mean map an ACM from a PSTN term
to a 183.  In that scenario, I don't see a 600 getting the chance to
be generated back to the SIP network after a 183.  If an ISUP network
encounters a busy condition, it sends back a REL with cause, not an ACM,
unless it is providing in-band busy tones, which is not a problem.
There may be other signalling types where this situation could occur.
If anyone knows how this could happen, please enlighten me.

 I think the original point by Adam where we could have ringing followed
by busy was if we sent ringback when a 100 Trying was received at an
originating gateway.  I think we can scratch that idea.  I had originally
suggested it if a client was implemented that sent a 100 Trying but
not a 180 Ringing while waiting for a human to accept the session.
In such a case and when the session originated from an ISUP gateway,
the ANSI T7 timer would expire, typically in 20 seconds, and the ISUP
network would tear down the call.

 If callee clients behave this way, they will find attempts have short
wait times waiting for a human to accept, with the attempts being aborted.
Many people may be unhappy with this and complain to their client equipment
vendor.  Perhaps a best practices I-D or something is needed advising
clients to not wait around long after sending 100 Trying, but instead
send 180 ringing (or 183) while alerting a callee.

John Hearty
MCI Worldcom

Date: Mon, 19 Apr 1999 21:39 -0500 (CDT)
From: Jonathan Rosenberg <[email-masked]>
Organization: Bell Laboratories
To: Tom-PT Taylor <[email-masked]>
CC: [email-masked]
Sender: [email-masked]
Subject: Re: Behavior of SIP Callee user agent

Tom-PT Taylor wrote:
> 
> What a lot of PSTN interworking problems would be solved if SIP assumed a
> reliable transport end-to-end and we could count on "100 Trying" to carry
> back the ACM and the "180 Ringing" to carry back the SDP to trigger ringing!

There are really two separate problems, and both are solvable:

1. 1XX responses are not reliable
2. 1XX responses are not mandatory

The first of these is solved by an extension Henning and I submitted two
IETF's back, which provides reliable provisional responses. As with
other SIP extensions, the caller (an originating gateway here), would
indicate its need for this extension in a Require header. 

The second problem is addressed in a similar way. We simply define an
extension, say:

org.ietf.send180

and include this in a Require header in the INVITE as well. This
extension, which must always be used with reliable responses, simply
says that you should send a 180 (or 183, as discussed, for remote
generated tones an announcements) when ringback is being provided at the
remote end. Then, the calling gateway sends an ACM when it receives
either 180 or 183.

Of course, as has been pointed out, there are other, harder problems. If
the 180 causes local ringback at the originating gateway, and is then
followed by a 600, this causes the caller to hear a transition from
ringing to fast busy. I don't see any solution to this, however. 

-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: "Adam B. Roach" <[email-masked]>
Date: Wed, 21 Apr 1999 12:24:41 -0500 (CDT)

>If anyone knows how this could happen, please enlighten me.

A native SIP client. You're thinking of SIP as merely an IP transport
for ISUP; there will be native SIP phones, either with embedded processors
or sitting on PCs, which won't derive all their signalling from
ISUP mapping.

For a native SIP client, it may send back a 180, since it really
*is* alerting the user. However, let's say the user is, for
example, in another call. The user "does not wish to take the call
at this time" (phrasing from the SIP spec description of 600),
and clicks on a button to indicate this fact. That'll give you
the 180 followed by 600 I described.

/a