[asterisk-dev] DAHDI/MFCR2: handling remote clearing for outgoing calls ?

[Pavel Troller]

Hi!
  I'm preparing an Asterisk installation serving as a gateway to the legacy
CAS/MFCR2 exchange. All seems to work well, except that almost any clear cause
occuring during outgoing connection setup to the remote exchange is presented
as Congestion (Clear Cause 34) to the originator.
  I was searching through the code of chan_dahdi.c and found this part, in the
dahdi_r2_on_call_disconnect() function:
...
        } else if (openr2_chan_get_direction(r2chan) == OR2_DIR_FORWARD) {
                /* being the forward side we must report what happened to the call to whoever requested it */
                switch (cause) {
                case OR2_CAUSE_BUSY_NUMBER:
                        p->subs[SUB_REAL].needbusy = 1;
                        break;
                case OR2_CAUSE_NETWORK_CONGESTION:
                case OR2_CAUSE_OUT_OF_ORDER:
                case OR2_CAUSE_UNALLOCATED_NUMBER:
                case OR2_CAUSE_NO_ANSWER:
                case OR2_CAUSE_UNSPECIFIED:
                case OR2_CAUSE_NORMAL_CLEARING:
                        p->subs[SUB_REAL].needcongestion = 1;
                        break;
                default:
                        ast_channel_softhangup_internal_flag_add(p->owner, AST_SOFTHANGUP_DEV);
                }
                ast_mutex_unlock(&p->lock);
        } else {
                ast_mutex_unlock(&p->lock);
                /* being the backward side and not UP yet, we only need to request hangup */
                /* TODO: what about doing this same thing when were AST_STATE_UP? */
                ast_queue_hangup_with_cause(p->owner, dahdi_r2_cause_to_ast_cause(cause));
        }
...
  Setting needcongestion causes that dahdi_read() sends the
AST_CONTROL_CONGESTION frame towards the originator, causing it to initiate
hangup with obvious Congestion clear cause (34).
  But what I don't understand, is, WHY we are sending the congestion frame
instead of simply initiating the hangup by ourself with a proper cause ?
  Because I didn't find a trick how to propagate a proper cause code to the
originator, I've changed the code to the following:

        } else if (openr2_chan_get_direction(r2chan) == OR2_DIR_FORWARD) {
                /* being the forward side we must report what happened to the call to whoever requested it */
                switch (cause) {
                case OR2_CAUSE_BUSY_NUMBER:
                        p->subs[SUB_REAL].needbusy = 1;
                        break;
                case OR2_CAUSE_NETWORK_CONGESTION:
                case OR2_CAUSE_OUT_OF_ORDER:
                case OR2_CAUSE_UNSPECIFIED:
                        p->subs[SUB_REAL].needcongestion = 1;
                        break;
                case OR2_CAUSE_UNALLOCATED_NUMBER:
                case OR2_CAUSE_NO_ANSWER:
                case OR2_CAUSE_NORMAL_CLEARING:
                        ast_mutex_unlock(&p->lock);
                        ast_queue_hangup_with_cause(p->owner, dahdi_r2_cause_to_ast_cause(cause));
                        return;
                        break;
                default:
                        ast_channel_softhangup_internal_flag_add(p->owner, AST_SOFTHANGUP_DEV);
                }
                ast_mutex_unlock(&p->lock);
        } else {

  In this case, it is chan_dahdi, who initiates the hangup, and it can set the
clear cause using the standard set of cause values (for selected clear cases).
>From the user's point of view, I can't find anything wrong with this solution.
Now the connection attempt is cleared as before, but with the proper cause code
(tested on UNALLOCATED).

  By the way, there is probably a bug in the mapping function, dahdi_r2_cause_to_ast_cause().
OR2_CAUSE_UNALLOCATED_NUMBER is mapped to AST_CAUSE_UNREGISTERED, while it must be mapped to
AST_CAUSE_UNALLOCATED.


  I would like to hear, why the hangup handling was written in such a strange
way, and whether we need a different handling for forward and backward 
connections at all - for me it seems superfluous.

With regards,
  Pavel