[asterisk-commits] rmudgett: branch 12 r417958 - in /branches/12: ./ channels/ configs/

SVN commits to the Asterisk project asterisk-commits at lists.digium.com
Thu Jul 3 17:06:07 CDT 2014


Author: rmudgett
Date: Thu Jul  3 17:06:02 2014
New Revision: 417958

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=417958
Log:
chan_dahdi: Add inband_on_setup_ack compatibility option.

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

Merged revisions 417957 from http://svn.asterisk.org/svn/asterisk/branches/11

Modified:
    branches/12/   (props changed)
    branches/12/UPGRADE.txt
    branches/12/channels/chan_dahdi.c
    branches/12/channels/sig_pri.c
    branches/12/channels/sig_pri.h
    branches/12/configs/chan_dahdi.conf.sample

Propchange: branches/12/
------------------------------------------------------------------------------
Binary property 'branch-11-merged' - no diff available.

Modified: branches/12/UPGRADE.txt
URL: http://svnview.digium.com/svn/asterisk/branches/12/UPGRADE.txt?view=diff&rev=417958&r1=417957&r2=417958
==============================================================================
--- branches/12/UPGRADE.txt (original)
+++ branches/12/UPGRADE.txt Thu Jul  3 17:06:02 2014
@@ -35,16 +35,26 @@
    - "Exited on signal $EXITSIGNAL" => "Asterisk exited on signal $EXITSIGNAL."
    - "Asterisk Died" => "Asterisk on $MACHINE died (sig $EXITSIGNAL)"
 
- - Added a compatibility option for ari, chan_sip, and chan_pjsip
-   '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 to process the received data, the socket may be disconnected.
-   In such cases, it may be necessary to adjust this value. Default is 100 ms.
-
- - Added support for persistent HTTP connections.  To enable persistent
-   HTTP connections configure the keep alive time between HTTP requests.  The
-   keep alive time between HTTP requests is configured in http.conf with the
-   session_keep_alive parameter.
+ARI:
+ - Added a compatibility option '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 to process the
+   received data, the socket may be disconnected.  In such cases, it may be
+   necessary to adjust this value.
+   Default is 100 ms.
+
+chan_dahdi:
+ - 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.
+
+chan_pjsip:
+ - Added a compatibility option '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 to process the
+   received data, the socket may be disconnected.  In such cases, it may be
+   necessary to adjust this value.
+   Default is 100 ms.
 
  - Added a 'force_avp' option to chan_pjsip which will force the usage of
    'RTP/AVP', 'RTP/AVPF', 'RTP/SAVP', or 'RTP/SAVPF' as the media transport type
@@ -54,6 +64,14 @@
  - Added a 'media_use_received_transport' option to chan_pjsip which will
    cause the SDP answer to use the media transport as received in the SDP
    offer.
+
+chan_sip:
+ - Added a compatibility option '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 to process the
+   received data, the socket may be disconnected.  In such cases, it may be
+   necessary to adjust this value.
+   Default is 100 ms.
 
  - Added a 'force_avp' option for chan_sip. When enabled this option will
    cause the media transport in the offer or answer SDP to be 'RTP/AVP',
@@ -71,6 +89,12 @@
  - A 'dtlsfingerprint' option has been added to chan_sip which allows the
    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.
+
+HTTP:
+ - Added support for persistent HTTP connections.  To enable persistent
+   HTTP connections configure the keep alive time between HTTP requests.  The
+   keep alive time between HTTP requests is configured in http.conf with the
+   session_keep_alive parameter.
 
 From 12.3.0 to 12.3.1:
 

Modified: branches/12/channels/chan_dahdi.c
URL: http://svnview.digium.com/svn/asterisk/branches/12/channels/chan_dahdi.c?view=diff&rev=417958&r1=417957&r2=417958
==============================================================================
--- branches/12/channels/chan_dahdi.c (original)
+++ branches/12/channels/chan_dahdi.c Thu Jul  3 17:06:02 2014
@@ -847,6 +847,7 @@
 			.localdialplan = PRI_NATIONAL_ISDN + 1,
 			.nodetype = PRI_CPE,
 			.qsigchannelmapping = DAHDI_CHAN_MAPPING_PHYSICAL,
+			.inband_on_setup_ack = 1,
 
 #if defined(HAVE_PRI_CCSS)
 			.cc_ptmp_recall_mode = 1,/* specificRecall */
@@ -12148,6 +12149,7 @@
 							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));
@@ -17636,6 +17638,8 @@
 #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)

Modified: branches/12/channels/sig_pri.c
URL: http://svnview.digium.com/svn/asterisk/branches/12/channels/sig_pri.c?view=diff&rev=417958&r1=417957&r2=417958
==============================================================================
--- branches/12/channels/sig_pri.c (original)
+++ branches/12/channels/sig_pri.c Thu Jul  3 17:06:02 2014
@@ -1629,6 +1629,9 @@
 #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;
@@ -1644,6 +1647,9 @@
 #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;
@@ -7489,8 +7495,19 @@
 					 * 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) */
 					) {
 					/*
@@ -8120,7 +8137,12 @@
 	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)

Modified: branches/12/channels/sig_pri.h
URL: http://svnview.digium.com/svn/asterisk/branches/12/channels/sig_pri.h?view=diff&rev=417958&r1=417957&r2=417958
==============================================================================
--- branches/12/channels/sig_pri.h (original)
+++ branches/12/channels/sig_pri.h Thu Jul  3 17:06:02 2014
@@ -345,6 +345,10 @@
 	/*! \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;
 
@@ -483,6 +487,8 @@
 	 * 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)

Modified: branches/12/configs/chan_dahdi.conf.sample
URL: http://svnview.digium.com/svn/asterisk/branches/12/configs/chan_dahdi.conf.sample?view=diff&rev=417958&r1=417957&r2=417958
==============================================================================
--- branches/12/configs/chan_dahdi.conf.sample (original)
+++ branches/12/configs/chan_dahdi.conf.sample Thu Jul  3 17:06:02 2014
@@ -195,6 +195,23 @@
 ; B channels; defaults to 'never'.
 ;
 ;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




More information about the asterisk-commits mailing list