Subject: RE: Behavior of SIP Callee user agent

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 20 Apr 1999 11:03:43 -0400

But intermediate SIP servers won't send back ACMs.

> -----Original Message-----
> From:	Christian Huitema [SMTP:[email-masked]]
> Sent:	Tuesday, April 20, 1999 10:57 AM
> To:	Taylor, Tom-PT [CAR:5V00-I:EXCH]; Christian Huitema;
> [email-masked]
> Subject:	Re: Behavior of SIP Callee user agent
> 
> On Apr 20,  9:02am, Tom-PT Taylor wrote:
> > Subject: RE: Behavior of SIP Callee user agent
> > Obviously one would return "484 Address Incomplete" rather than "100
> Trying"
> > in the case of overlap dialling, and would not return the ACM until the
> > requisite SAM in the forward direction justified it.
> 
> Except when dealing with relays.  It may well be that only the final step
> in the signalling chain knows that the address is incomplete.  The
> intermediate SIP servers could well send a Trying response...
> 
> -- 
> Christian Huitema
> ------------------------------
> Please note my new address: [email-masked]
> http://www.telcordia.com/

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 21 Apr 1999 11:28:39 -0500 (CDT)

I beleive the problem situation here is where you have a proxy server
between two gateways. A valid sequence of messages would be:

gw1          proxy          gw2
 ----INVITE---->
 <-----100------
               ----INVITE---->
               <-----484------
 <-----484------

If you map 1xx messages to an ACM *and* have no further method of
digit collection, this may cause something of a problem.

Taking up the issue of ACM messages in the ISUP world: It is my
understanding that ACM is used in a variety of cases to set up
an end-to-end audio channel; not just in the case of ringing.

For example, the operator-assisted portion of operator-assited
calls *can* occur after an ACM, but before an ANM. It's not clear
how sending an ACM before a clear indication of ringing or
error would necessarily break the SS7 side of things.

The problem of overlapped dialing can be solved in a variety of
ways:

1) As you suggest, wait for a 180, a 183, or a final response 
   before sending an ACM. This requires the addition of provisional 
   ACKs (hence special clients) to work reliably.

2) An inter-digit timeout on the ingress gateway; in this case, a 484
   would indicate user error (similar to giving a "short" number
   from a native SIP client).

3) Collection of additional digits by the gateway itself if it receives
   a 484 message. Of course, this breaks down for pulse dialing (unless
   you try to get *really* smart and count the audible "clicks" on the
   line).

Each solution has its caveats; however, only the first is broken by a 
pre-ringing ACM message.

-- 
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
EUS/XT/N                   | Fax: +1 972 669 0154 | Richardson, TX 75081
[email-masked]    | ECN: 800 37594   <*> | USA