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

[Richard Mudgett]

On Fri, Oct 11, 2013 at 12:00 AM, Pavel Troller <patrol at sinus.cz> wrote:

> 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.


In a word: legacy.  The chan_dahdi channel driver was originally written
for analog lines in
early versions of Asterisk.  Later MFC/R2, PRI, and SS7 were forced into
the driver so they
for the most part do things the way the old analog code did it.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131011/87120dd6/attachment.html>