Subject: Behavior of SIP Callee user agent

From: John Hearty <[email-masked]>
Date: Mon, 12 Apr 1999 15:11 -0500 (CDT)

I was reviewing the RFC to try and determine if there are any time
constraints imposed on a User Agent which receives an Invite that it
must respond by, but was unable to find anything.  Is there something
defined that I missed?  Or could we consider that the callee's User
Agent could be just waiting for a human to pick up the phone, for example,
assuming the device is not configured to automatically send a 180 Ringing.

 The reson I am looking at this is in an interworking scenario on an
ANSI ISUP gateway.  I want to decide if such a gateway should start the
T11 timer and send back an ACM on it's own when it expires, or wait
for the ISUP side's T7 timer (ACM timeout) to expire and send a release
to the gateway.  ANSI T1.113.4 in section 2.1.4.7 says "If in normal
operation, a delay in the receipt of an address complete signal from
the succeeding exchange is expected [i.e. a SIP 1xx or 200], the last
common channel signalling exchange shall originate and send an Address
Complete Message 15 to 20 seconds (T11) after receiving the Initial
Address Message."

 The call scenario I am considering looks like this:

ISUP User A         PSTN Gateway            SIP User B
-----------         ------------            ----------

IAM --------------->
                    Invite ---------------->
                                            User does not respond
                                            within Gateway's T11 time.
    <-------------- ACM

 Not shown in the messaging above is the retransmitted Invites by the
gateway to User B based on exponential backoff of SIP timer T1.  This
scenario would give User B time until 7 Invites were transmitted before
the session is torn down by the gateway.

 The alternative in this scenario is that the session would get torn
down when the ANSI ISUP T7 timer expired (20-30 seconds per ANSI):

ISUP User A     PSTN Gateway        SIP User B
-----------     ------------        ----------

IAM --------------->
                    Invite -------------->
                                           User does not respond
                                           within User A's T7 time.
REL --------------->
                    BYE ----------------->
                    <--------------------- OK

 So bottom line, did I miss something in the RFC, or are callee time
constraints missing but needed in the RFC, or do we add time constraints
to a best practices companion RFC?  I realize the best thing for the
callee to do would be send back a 180 Ringing when taking the human
interaction time into account, but didn't see that required anywhere,
and in fact examples abound where 200 is the only response sent.  

John Hearty
MCI Worldcom

---

From: Arjun RC <[email-masked]>
Date: Tue, 13 Apr 1999 09:26:30 +0530 (IST)

Hi John,

John> 200 ms.  This begs the question of what message(s) should map back to
John> an ACM on ISUP.  Any 1XX?  Just 180?  Based on the fact that the RFC
John> says a 1xx should be sent back without specifying a particular 1xx,

I dont know much about the exact PSTN side signalling, but once the INVITE
message reaches the other side, If my callee cannot currently process the
invite message right away, Id used the 182 - Queued Call. In the case that
the proxy SIP server is trying to reach the callee, it returns 100 Trying
to the caller and subsequently, 180 -- Ringing. What this would translate
to is that while its Trying, the caller gets a "beep beep" sound which is
usually heard when the call is trying to reach the destination (at least
that is what we hear in the PSTN here -- sorry if it sounds so naive, but
thats my knowleldge of PSTN :-p). Once the called destination is reached
and a 180--Ringing is returned, the PSTN user hears the usual ring.

John> dead air unless some requirements were defined for gateways to send

The dead air that the PSTN user might hear is probably whwn the call is
Queued to begin processing, which should not be long.

I might be totally worong, but this is my understanding.

Cheers
ARC

We are Pentium of Borg. Division is futile. You will be
approximated.
------------------------------+----------------------------------+
(O): Hughes Software Systems  |(R): 68/G, 2nd Narayanappa Block, |
146, Prestige Opal Bldng,     |R.T. Nagar,                       |
Infantry Rd, Bangalore-560001 |Bangalore-560032                  |
Ph:+91-80-2286390/91/92       |Ph:+91-80-3430565                 |
------------------------------+----------------------------------+
http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS)

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Apr 1999 21:41:45 -0400

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

This is what the SIP extensions for reliable 1xx responses are supposed
to address (see the Internet draft on the topic). They need to be
finalized; comments are most appreciated.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs