[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-dev
Subject:    [asterisk-dev] DAHDI/MFCR2: handling remote clearing for outgoing calls ?
From:       Pavel Troller <patrol () sinus ! cz>
Date:       2013-10-11 5:00:14
Message-ID: 20131011050014.GA32509 () tangens ! sinus ! cz
[Download RAW message or body]

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

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev


[prev in list] [next in list] [prev in thread] [next in thread]