]> git.ipfire.org Git - thirdparty/asterisk.git/commitdiff
chan_dahdi: Add inband_on_setup_ack compatibility option.
authorRichard Mudgett <rmudgett@digium.com>
Thu, 3 Jul 2014 21:48:03 +0000 (21:48 +0000)
committerRichard Mudgett <rmudgett@digium.com>
Thu, 3 Jul 2014 21:48:03 +0000 (21:48 +0000)
The new inband_on_setup_ack option causes Asterisk to assume inband audio
may be present when a SETUP_ACKNOWLEDGE message is received.

Q.931 Section 5.1.3 says that in scenarios with overlap dialing, when a
dialtone is sent from the network side, progress indicator 8 "Inband info
now available" MAY be sent to the CPE if no digits were received with the
SETUP.  It is thus implied that the ie is mandatory if digits came with
the SETUP and dialtone is needed.  This option should be enabled, when the
network sends dialtone and you want to hear it, but the network doesn't
send the progress indicator when needed.

NOTE: For Q.SIG setups this option should be enabled when outgoing overlap
dialing is also enabled because Q.SIG does not send the progress indicator
with the SETUP ACK.

The commit -r413714 (AST-1338) which causes this issue was dealing with a
SIP-to-ISDN interoperability issue.

This commit is a merge of the two patches indicated below.

ASTERISK-23897 #close
Reported by: Pavel Troller
Patches:
      pri-4.diff (license #6302) patch uploaded by Pavel Troller
      jira_asterisk_23897_v11.patch (license #5621) patch uploaded by rmudgett

Review: https://reviewboard.asterisk.org/r/3633/
........

Merged revisions 417956 from http://svn.asterisk.org/svn/asterisk/branches/1.8

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@417957 65c4cc65-6c06-0410-ace0-fbb531ad65f3

UPGRADE.txt
channels/chan_dahdi.c
channels/sig_pri.c
channels/sig_pri.h
configs/chan_dahdi.conf.sample

index 2a4c1ded4475e126191d283d2132ec1e5220a26c..f79f048b34e2592a80a99e3926680ed79780b8d3 100644 (file)
@@ -20,7 +20,7 @@
 ===
 ===========================================================
 
-from 11.10.0 to 11.11.0
+from 11.10.2 to 11.11.0
  - Added a compatibility option for chan_sip, 'websocket_write_timeout'.
    When a websocket connection exists where Asterisk writes a substantial
    amount of data to the connected client, and the connected client is slow
@@ -41,6 +41,10 @@ from 11.10.0 to 11.11.0
    hash to be specified for the DTLS fingerprint placed in SDP. Supported
    values are 'sha-1' and 'sha-256' with 'sha-256' being the default.
 
+ - Added the inband_on_setup_ack compatibility option to chan_dahdi.conf to
+   deal with switches that don't send an inband progress indication in the
+   SETUP ACKNOWLEDGE message.
+
 from 11.10.0 to 11.10.1
  - MixMonitor AMI actions now require users to have authorization classes.
    * MixMonitor - system
index 3a37087d9d193e5b159b62bb65a1c8aeaf095442..5610b004434ba15c3e860beefa0c4e47eeb72262 100644 (file)
@@ -1409,6 +1409,7 @@ static struct dahdi_chan_conf dahdi_chan_conf_default(void)
                        .localdialplan = PRI_NATIONAL_ISDN + 1,
                        .nodetype = PRI_CPE,
                        .qsigchannelmapping = DAHDI_CHAN_MAPPING_PHYSICAL,
+                       .inband_on_setup_ack = 1,
                        .inband_on_proceeding = 1,
 
 #if defined(HAVE_PRI_CCSS)
@@ -12960,6 +12961,7 @@ static struct dahdi_pvt *mkintf(int channel, const struct dahdi_chan_conf *conf,
                                                        pris[span].pri.layer1_ignored = 0;
                                                }
                                                pris[span].pri.append_msn_to_user_tag = conf->pri.pri.append_msn_to_user_tag;
+                                               pris[span].pri.inband_on_setup_ack = conf->pri.pri.inband_on_setup_ack;
                                                pris[span].pri.inband_on_proceeding = conf->pri.pri.inband_on_proceeding;
                                                ast_copy_string(pris[span].pri.initial_user_tag, conf->chan.cid_tag, sizeof(pris[span].pri.initial_user_tag));
                                                ast_copy_string(pris[span].pri.msn_list, conf->pri.pri.msn_list, sizeof(pris[span].pri.msn_list));
@@ -18334,6 +18336,8 @@ static int process_dahdi(struct dahdi_chan_conf *confp, const char *cat, struct
 #endif /* defined(HAVE_PRI_MWI) */
                        } else if (!strcasecmp(v->name, "append_msn_to_cid_tag")) {
                                confp->pri.pri.append_msn_to_user_tag = ast_true(v->value);
+                       } else if (!strcasecmp(v->name, "inband_on_setup_ack")) {
+                               confp->pri.pri.inband_on_setup_ack = ast_true(v->value);
                        } else if (!strcasecmp(v->name, "inband_on_proceeding")) {
                                confp->pri.pri.inband_on_proceeding = ast_true(v->value);
 #if defined(HAVE_PRI_DISPLAY_TEXT)
index 1d9067adf860894d83965a0e320ecdbb7a6483ee..3e231f6249aeb7d13c152b28267e27748626d7c9 100644 (file)
@@ -1516,6 +1516,9 @@ static int pri_fixup_principle(struct sig_pri_span *pri, int principle, q931_cal
 #if defined(HAVE_PRI_CALL_WAITING)
                new_chan->is_call_waiting = old_chan->is_call_waiting;
 #endif /* defined(HAVE_PRI_CALL_WAITING) */
+#if defined(HAVE_PRI_SETUP_ACK_INBAND)
+               new_chan->no_dialed_digits = old_chan->no_dialed_digits;
+#endif /* defined(HAVE_PRI_SETUP_ACK_INBAND) */
 
 #if defined(HAVE_PRI_AOC_EVENTS)
                old_chan->aoc_s_request_invoke_id_valid = 0;
@@ -1531,6 +1534,9 @@ static int pri_fixup_principle(struct sig_pri_span *pri, int principle, q931_cal
 #if defined(HAVE_PRI_CALL_WAITING)
                old_chan->is_call_waiting = 0;
 #endif /* defined(HAVE_PRI_CALL_WAITING) */
+#if defined(HAVE_PRI_SETUP_ACK_INBAND)
+               old_chan->no_dialed_digits = 0;
+#endif /* defined(HAVE_PRI_SETUP_ACK_INBAND) */
 
                /* More stuff to transfer to the new channel. */
                new_chan->call_level = old_chan->call_level;
@@ -7363,8 +7369,19 @@ static void *pri_dchannel(void *vpri)
                                         * We explicitly DO NOT want to check PRI_PROG_CALL_NOT_E2E_ISDN
                                         * because it will mess up ISDN to SIP interoperability for
                                         * the ALERTING message.
+                                        *
+                                        * Q.931 Section 5.1.3 says that in scenarios with overlap
+                                        * dialing where no called digits are received and the tone
+                                        * option requires dialtone, the switch MAY send an inband
+                                        * progress indication ie to indicate dialtone presence in
+                                        * the SETUP ACKNOWLEDGE.  Therefore, if we did not send any
+                                        * digits with the SETUP then we must assume that dialtone
+                                        * is present and open the voice path.  Fortunately when
+                                        * interoperating with SIP, we should be sending digits.
                                         */
-                                       && (e->setup_ack.progressmask & PRI_PROG_INBAND_AVAILABLE)
+                                       && ((e->setup_ack.progressmask & PRI_PROG_INBAND_AVAILABLE)
+                                               || pri->inband_on_setup_ack
+                                               || pri->pvts[chanpos]->no_dialed_digits)
 #endif /* defined(HAVE_PRI_SETUP_ACK_INBAND) */
                                        ) {
                                        /*
@@ -7977,7 +7994,12 @@ int sig_pri_call(struct sig_pri_chan *p, struct ast_channel *ast, const char *rd
        if (!keypad || !ast_strlen_zero(c + p->stripmsd + dp_strip))
 #endif /* defined(HAVE_PRI_SETUP_KEYPAD) */
        {
-               pri_sr_set_called(sr, c + p->stripmsd + dp_strip, pridialplan, s ? 1 : 0);
+               char *called = c + p->stripmsd + dp_strip;
+
+               pri_sr_set_called(sr, called, pridialplan, s ? 1 : 0);
+#if defined(HAVE_PRI_SETUP_ACK_INBAND)
+               p->no_dialed_digits = !called[0];
+#endif /* defined(HAVE_PRI_SETUP_ACK_INBAND) */
        }
 
 #if defined(HAVE_PRI_SUBADDR)
index 43acb12697de1e3a4f7d3933148b354cf9283238..e9a699ffff6b49c85b61f6d767d170b7cf25a141 100644 (file)
@@ -343,6 +343,10 @@ struct sig_pri_chan {
        /*! \brief TRUE if this is a call waiting call */
        unsigned int is_call_waiting:1;
 #endif /* defined(HAVE_PRI_CALL_WAITING) */
+#if defined(HAVE_PRI_SETUP_ACK_INBAND)
+       /*! TRUE if outgoing SETUP had no called digits */
+       unsigned int no_dialed_digits:1;
+#endif /* defined(HAVE_PRI_SETUP_ACK_INBAND) */
 
        struct ast_channel *owner;
 
@@ -470,6 +474,8 @@ struct sig_pri_span {
         * appended to the initial_user_tag[].
         */
        unsigned int append_msn_to_user_tag:1;
+       /*! TRUE if a SETUP ACK message needs to open the audio path. */
+       unsigned int inband_on_setup_ack:1;
        /*! TRUE if a PROCEEDING message needs to unsquelch the received audio. */
        unsigned int inband_on_proceeding:1;
 #if defined(HAVE_PRI_MCID)
index be9381624a5f6c2666a36cd579636a1746162629..dfd6e5280dd4376473296330288e59c88a6bfb8c 100644 (file)
@@ -196,6 +196,23 @@ context=public
 ;
 ;resetinterval = 3600
 ;
+; Assume inband audio may be present when a SETUP ACK message is received.
+; Q.931 Section 5.1.3 says that in scenarios with overlap dialing, when a
+; dialtone is sent from the network side, progress indicator 8 "Inband info
+; now available" MAY be sent to the CPE if no digits were received with
+; the SETUP.  It is thus implied that the ie is mandatory if digits came
+; with the SETUP and dialtone is needed.
+; This option should be enabled, when the network sends dialtone and you
+; want to hear it, but the network doesn't send the progress indicator when
+; needed.
+;
+; NOTE: For Q.SIG setups this option should be enabled when outgoing overlap
+; dialing is also enabled because Q.SIG does not send the progress indicator
+; with the SETUP ACK.
+; Default yes in current release branches for backward compatibility.
+;
+;inband_on_setup_ack=yes
+;
 ; Assume inband audio may be present when a PROCEEDING message is received.
 ; Q.931 Section 5.1.2 says the network cannot assume that the CPE side has
 ; attached to the B channel at this time without explicitly sending the