Subject: Re: Behavior of SIP Callee user agent

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

Well, never mind.  I found reference that the user agent SHOULD respond
with a 1xx as soon as possible if it can't give a final response within
200 ms.  This begs the question of what message(s) should map back to
an ACM on ISUP.  Any 1XX?  Just 180?  Based on the fact that the RFC
says a 1xx should be sent back without specifying a particular 1xx,
it seems any 1xx could come back and should map to an ACM to prevent
the ANSI T7 timer from expiring thus tearing down the call.

 That brings up the issue of what a PSTN originator will hear.  If
a 100 Trying maps to an ACM, it would seem the originator would hear
dead air unless some requirements were defined for gateways to send
ringback when 100 Trying was received and mapped to an ACM.

 This also gets into the question of audio cut through before a final
response, which I am waiting for feedback on and so will not discuss
further here (don't want to confuse things too much).

 Comments?

John Hearty
MCI Worldcom

Date: Mon, 12 Apr 1999 15:11 -0500 (CDT)
From: John Hearty <[email-masked]>
To: [email-masked]
Subject: Behavior of SIP Callee user agent

 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: [email-masked] (Adam B. Roach)
Date: Mon, 19 Apr 1999 15:47:57 -0500 (CDT)

>an ACM on ISUP.  

But you probably don't want the call to fall down in the case that it
doesn't. This is a tricky issue. As I understand it, the ACM is meant
to indicate that a full set of digits has been entered; this is 
different from the purpose of the 1xx messages. You may want to consider
sending back an ACM as soon as your gateway has determined that a complete
number has been sent. This has some complicated implications for gateways
which have to support overlapped dialing (unless you just perform a
simple timeout) -- but I'm digressing too far into implementation issues.

My point is that, since they mean different things, you probably shouldn't
wait for a 1xx to send an ACM.  By doing so, you gain nothing and risk 
interoperability problems.

>ringback when 100 Trying was received and mapped to an ACM.

And, even then, you may leave the caller in the unexpected situation
where he hears a few ring tones, followed by a busy signal (in the
situation where the 100 is followed by a 486 or 600). It may be better
to, as Arjun suggests, send some sort of call progressing tone until
you get an actual 180 or final response.

--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
[email-masked]    |                  <*> | USA