Subject: [Sipping] (sip-isup-03) Mapping to ACM message with cause value

From: "Hiroshi Waki" <[email-masked]>
Date: Thu, 6 Sep 2001 17:52:18 +0900

Dear all,

This is Hiroshi Waki of NTT, Japan.

I have a question concerning the interworking method described in 
draft-ietf-sip-isup-03. The question is what SIP-response should be 
mapped to an ACM message which has a cause indicators parameter.

Please suppose that a call is unsuccessful because of the callee's status 
and that the caller hears an announcement about the information concerning 
the callee, which can be provided not in the caller's end system but in the 
callee's end system.

For SIP to ISUP mapping, there is a specification in the section 6.1.6 
of draft-sip-isup-03. But for ISUP to SIP mapping, there is 
no specification in the draft. The detail of this question is 
described below.

Supposed scenarios and call flows are shown below. These flows 
are about the case of the unsuccessful setup with a tone or announcement.

        [PSTN]-----[MGC] -----[SIP outbound proxy(Note)]-----[SIP UAS]
           | --IAM-->|                    |
           |         | ---INVITE--------> |
           |         |                    |
           |         | <--*ResponseA*---- |
           | <-ACM---|                    |
           | <======Tone/Announcement=====|
           |         |                    |
               Note: The proxy controls a tone/announcement generator, which
                       may or may not be deployed in the proxy.

There are three requirements for sending the ACM. 
(Req1) The MGC sends to the caller not REL message but ACM message.
(Req2) Second is that the ACM has a cause indicators parameter, which 
consists of not only a cause value but also a diagnostic description.
(Req3) Third is that the ACM has an indicator which shows that in-band 
information is available.

   There may be some approaches to send the information from the proxy 
   to the MGC in the *responseA*. Here are three approaches to send the 
   information in the *responseA*. (There is no approach with 3xx because 
   the case is not for the redirection.)
   - Approach A: Sending 18x response.
   In this approach, Req2 and Req3 are not satisfied. The problems are followed. 
   (A1) There is no parameter/header to convey the information for the 
   cause indicators parameter in the ACM.
   (A2) There is no specification to set an indicator which shows that 
   in-band information is available (according to the draft, 183 is mapped 
   to an ACM without cause indicators parameter).
   - Approach B: Sending 4xx, 5xx, or 6xx response.
   In this approach, Req1 and Req3 are not satisfied. The problems are followed.
   (B1) The responses are mapped not to ACM message but to REL message 
   according to the draft.
   (B2) There is no specification of such the mapping.
   - Approach C: Sending a response not yet specified in the draft bis04.

Which approach should be taken or is there any other approach?
And how should the problems be solved?

Best regards,
Hiroshi Waki

---
Hiroshi Waki
NTT Network Service Systems Laboratories
tel +81 422 59 3404  fax +81 422 59 3494
e-mail [email-masked]

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP