Subject: Re: Behavior of SIP Callee user agent

From: John Hearty <[email-masked]>
Date: Wed, 21 Apr 1999 16:47 -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.
>
>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.

 The above confuses me.  I was simply considering a scenario where
the caller originates through an ISUP gateway, and the callee is a
native SIP phone/PC client or whatever.  I don't expect to be transporting
ISUP to the SIP phone, just mapping all the pertinent information where
logical, required and possible.

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

 Normally, it would make alot more sense for the device to be configured
ahead of time or perhaps via a DND button to know that when on calls,
send a busy response right away.  However, this might not be the case
if there were an enhanced call waiting feature in the SIP client.  Then
I could see this comming up.  I don't know if or how this is handled
in the PSTN today.  The closest I can think of is the new call waiting
caller ID services, but don't know if there is an option for the callee
to reject the call.  The designers of such a feature in a SIP client
should probably consider how to handle such a situation, keeping in
mind the types of originations (SIP or PSTN via a gateway).  This all
gets into implementation decisions which probabally should not be discussed
much on this list.  But thanks for bringing up the possibilities.

John Hearty
MCI Worldcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Apr 1999 01:10:45 -0400

John Hearty wrote:
> if there were an enhanced call waiting feature in the SIP client.

In SIP (well, IP telephony in general), call waiting is a "for-free"
service which is really trivial to support in a user agent. In fact, you
can do all kinds of neat things like listing the names of the callers
for all those calls waiting, and some scroll buttons to select who you
talk to right now. So, its a good bet you'll see it.

Its not just call waiting, though. Its perfectly reasonable for my SIP
UAS to ring (and then send 180) when someone calls, and then I can click
"reject" to send a 600 if I don't want to speak to them. The fact that
there is no actual way to reject a call on an analog pots line (I
understand this is possible with ISDN?), is more of an artifact of the
history of the phone network than a feature. In this case, ringing
followed by a busy signal may very well be the right thing to do for
indicating to the caller what happened.

-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