[asterisk-bugs] asterisk-bugs Digest, Vol 41, Issue 42
Bhrugu Mehta
bhrugumehta at gmail.com
Wed Mar 3 00:38:08 CST 2010
realtime oracle engine is available here,
https://issues.asterisk.org/view.php?id=16735
On Wed, Mar 3, 2010 at 11:58 AM,
<asterisk-bugs-request at lists.digium.com> wrote:
> Send asterisk-bugs mailing list submissions to
> asterisk-bugs at lists.digium.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.digium.com/mailman/listinfo/asterisk-bugs
> or, via email, send a message with subject or body 'help' to
> asterisk-bugs-request at lists.digium.com
>
> You can reach the person managing the list at
> asterisk-bugs-owner at lists.digium.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of asterisk-bugs digest..."
>
>
> Today's Topics:
>
> 1. [Asterisk 0016664]: [patch] Random DTMF duplicate emulation
> on bridged OOH323 channel on outgoing calls (Asterisk Bug Tracker)
> 2. [Asterisk 0016661]: DISA doesn't honor caller ID on the
> channel (Asterisk Bug Tracker)
> 3. [DAHDI-linux 0016752]: Dahdi-2.2.1 isn't compile on
> kernel-2.6.33 (Asterisk Bug Tracker)
> 4. [Asterisk 0016664]: [patch] Random DTMF duplicate emulation
> on bridged OOH323 channel on outgoing calls (Asterisk Bug Tracker)
> 5. [Asterisk 0016949]: sip reinvite broken (Asterisk Bug Tracker)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 2 Mar 2010 22:09:25 -0600
> From: Asterisk Bug Tracker <noreply at bugs.digium.com>
> Subject: [asterisk-bugs] [Asterisk 0016664]: [patch] Random DTMF
> duplicate emulation on bridged OOH323 channel on outgoing calls
> To: asterisk-bugs at lists.digium.com
> Message-ID: <612375041be6da6fa62fe69a62c2d9b4 at issues.asterisk.org>
> Keywords: [Asterisk] Addons/chan_ooh323
> Content-Type: text/plain; charset="utf-8"
>
>
> A NOTE has been added to this issue.
> ======================================================================
> https://issues.asterisk.org/view.php?id=16664
> ======================================================================
> Reported By: vmikhelson
> Assigned To: may213
> ======================================================================
> Project: Asterisk
> Issue ID: 16664
> Category: Addons/chan_ooh323
> Reproducibility: random
> Severity: major
> Priority: normal
> Status: ready for testing
> Asterisk Version: SVN
> JIRA:
> Regression: No
> Reviewboard Link:
> SVN Branch (only for SVN checkouts, not tarball releases): N/A
> SVN Revision (number only!):
> Request Review:
> ======================================================================
> Date Submitted: 2010-01-21 00:44 CST
> Last Modified: 2010-03-02 22:09 CST
> ======================================================================
> Summary: [patch] Random DTMF duplicate emulation on bridged
> OOH323 channel on outgoing calls
> Description:
> In majority of cases DTMF tones are duplicated by Asterisk when bridging a
> SIP or DAHDI channel with OOH323 channel on outgoing calls.
>
> In case of a normal DTMF processing the following sequence is observed:
>
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2855 __ast_read: DTMF begin '9'
> received on SIP/464-00000012
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2865 __ast_read: DTMF begin
> passthrough '9' on SIP/464-00000012
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2783 __ast_read: DTMF end '9'
> received on SIP/464-00000012, duration 120 ms
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2823 __ast_read: DTMF end
> accepted with begin '9' on SIP/464-00000012
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2839 __ast_read: DTMF end
> passthrough '9' on SIP/464-00000012
>
> In case of a problematic DTMF processing it looks like that:
>
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2855 __ast_read: DTMF begin '9'
> received on SIP/464-00000011
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2865 __ast_read: DTMF begin
> passthrough '9' on SIP/464-00000011
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2783 __ast_read: DTMF end '9'
> received on OOH323/172.17.135.2:1720-9915, duration 0 ms
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2809 __ast_read: DTMF begin
> emulation of '9' with duration 100 queued on OOH323/172.17.135.2:1720-9915
> [Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
> Don't know how to indicate condition 20 on ooh323c_o_21
> [Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
> Don't know how to indicate condition 20 on ooh323c_o_21
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2932 __ast_read: DTMF end
> emulation of '9' queued on OOH323/172.17.135.2:1720-9915
> [Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
> Don't know how to indicate condition 20 on ooh323c_o_21
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2783 __ast_read: DTMF end '9'
> received on SIP/464-00000011, duration 120 ms
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2823 __ast_read: DTMF end
> accepted with begin '9' on SIP/464-00000011
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2839 __ast_read: DTMF end
> passthrough '9' on SIP/464-00000011
> [Jan 20 19:18:55] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
> Don't know how to indicate condition 20 on ooh323c_o_21
>
> ======================================================================
>
> ----------------------------------------------------------------------
> (0118808) vmikhelson (reporter) - 2010-03-02 22:09
> https://issues.asterisk.org/view.php?id=16664#c118808
> ----------------------------------------------------------------------
> Re: 0118798
>
> May213,
>
> Thank you for the disconnect issue analysis. I have captured several
> packet traces which definitely showed the H.245 Round TripDelayRequest
> messages being ignored by Asterisk's H323 channel.
>
> I do not think fixing this falls into a "new feature request" category. It
> is a major oversight in the channel design. See
> http://www.packetizer.com/in/q43.html
>
> The inner workings of the underlying H323 protocol are mostly not
> configurable on Avaya IPOffice 403. And even if they were I would not
> suggest to disable the required portion of the protocol.
>
> In some implementations, like for example Cisco ATA 188, the feature is
> not enabled by default but is easily settable.
>
> If you still think that IRC is a better place to discuss fixing this issue
> please let me know how I can reach you there.
>
> Thank you,
> Vladimir
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2010-03-02 22:09 vmikhelson Note Added: 0118808
> ======================================================================
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 2 Mar 2010 22:39:45 -0600
> From: Asterisk Bug Tracker <noreply at bugs.digium.com>
> Subject: [asterisk-bugs] [Asterisk 0016661]: DISA doesn't honor caller
> ID on the channel
> To: asterisk-bugs at lists.digium.com
> Message-ID: <cc2625f7d77a666ced0f81ba901ae3d4 at issues.asterisk.org>
> Keywords: [Asterisk] Applications/app_disa
> Content-Type: text/plain; charset="utf-8"
>
>
> A NOTE has been added to this issue.
> ======================================================================
> https://issues.asterisk.org/view.php?id=16661
> ======================================================================
> Reported By: jstapleton
> Assigned To:
> ======================================================================
> Project: Asterisk
> Issue ID: 16661
> Category: Applications/app_disa
> Reproducibility: always
> Severity: minor
> Priority: normal
> Status: feedback
> Asterisk Version: 1.4.28
> JIRA: SWP-773
> Regression: No
> Reviewboard Link:
> SVN Branch (only for SVN checkouts, not tarball releases): N/A
> SVN Revision (number only!):
> Request Review:
> ======================================================================
> Date Submitted: 2010-01-20 15:42 CST
> Last Modified: 2010-03-02 22:39 CST
> ======================================================================
> Summary: DISA doesn't honor caller ID on the channel
> Description:
> DISA doesn't honor caller ID on the channel that may have been changed with
> the caller ID dialplan function. Instead, it defaults to using the caller
> ID of the original incoming call.
> ======================================================================
>
> ----------------------------------------------------------------------
> (0118809) jstapleton (reporter) - 2010-03-02 22:39
> https://issues.asterisk.org/view.php?id=16661#c118809
> ----------------------------------------------------------------------
> This doesn't work:
> exten=>XXXX,1,Set(CALLERID(num)=1601)
> exten=>XXXX,n,DISA(no-password,features)
>
> This does:
> exten=>XXXX,1,Set(CALLERID(num)=1601)
> exten=>XXXX,n,DISA(no-password,features,${CALLERID(all)})
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2010-03-02 22:39 jstapleton Note Added: 0118809
> ======================================================================
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 2 Mar 2010 23:19:30 -0600
> From: Asterisk Bug Tracker <noreply at bugs.digium.com>
> Subject: [asterisk-bugs] [DAHDI-linux 0016752]: Dahdi-2.2.1 isn't
> compile on kernel-2.6.33
> To: asterisk-bugs at lists.digium.com
> Message-ID: <61d842206ab2141071b0a78bb0ad9307 at issues.asterisk.org>
> Keywords: [DAHDI-linux] General
> Content-Type: text/plain; charset="utf-8"
>
>
> A NOTE has been added to this issue.
> ======================================================================
> https://issues.asterisk.org/view.php?id=16752
> ======================================================================
> Reported By: alephlg
> Assigned To:
> ======================================================================
> Project: DAHDI-linux
> Issue ID: 16752
> Category: General
> Reproducibility: always
> Severity: minor
> Priority: normal
> Status: acknowledged
> JIRA:
> Reviewboard Link:
> ======================================================================
> Date Submitted: 2010-02-02 05:10 CST
> Last Modified: 2010-03-02 23:19 CST
> ======================================================================
> Summary: Dahdi-2.2.1 isn't compile on kernel-2.6.33
> Description:
> aleph at noder dahdi-linux-2.2.1 $ make
> make -C drivers/dahdi/firmware firmware-loaders
> make[1]: Entering directory
> `/home/aleph/mandriva/dahdi-linux-2.2.1/drivers/dahdi/firmware'
> Attempting to download dahdi-fwload-vpmadt032-1.20.0.tar.gz
> --2010-02-02 12:07:46--
> http://downloads.digium.com/pub/telephony/firmware/releases/dahdi-fwload-vpmadt032-1.20.0.tar.gz
> downloads.digium.com (downloads.digium.com) felold?sa? 76.164.171.232
> Csatlakoz?s a k?vetkez?h?z: downloads.digium.com
> (downloads.digium.com)[76.164.171.232]:80? kapcsol?dva.
> HTTP k?r?s elk?ldve, v?rakoz?s v?laszra? 200 OK
> Hossz: 146556 (143K) [application/x-gzip]
> Ment?s ide: ?dahdi-fwload-vpmadt032-1.20.0.tar.gz?
>
> 100%[=========================================================>] 146.556
> 159K/s id? 0,9s
>
> 2010-02-02 12:07:47 (159 KB/s) --
> ?dahdi-fwload-vpmadt032-1.20.0.tar.gz? mentve [146556/146556]
>
> make[1]: Leaving directory
> `/home/aleph/mandriva/dahdi-linux-2.2.1/drivers/dahdi/firmware'
> make -C /lib/modules/2.6.33-desktop-0.rc6.1mnb/build
> SUBDIRS=/home/aleph/mandriva/dahdi-linux-2.2.1/drivers/dahdi
> DAHDI_INCLUDE=/home/aleph/mandriva/dahdi-linux-2.2.1/include
> DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
> make[1]: Entering directory `/usr/src/linux-2.6.33-desktop-0.rc6.1mnb'
> CC [M]
> /home/aleph/mandriva/dahdi-linux-2.2.1/drivers/dahdi/dahdi-base.o
> In file included from
> /home/aleph/mandriva/dahdi-linux-2.2.1/include/dahdi/kernel.h:39,
> from
> /home/aleph/mandriva/dahdi-linux-2.2.1/drivers/dahdi/dahdi-base.c:62:
> /home/aleph/mandriva/dahdi-linux-2.2.1/include/dahdi/dahdi_config.h:27:28:
> error: linux/autoconf.h: Nincs ilyen f?jl vagy k?nyvt?r
> make[2]: ***
> [/home/aleph/mandriva/dahdi-linux-2.2.1/drivers/dahdi/dahdi-base.o] Error
> 1
> make[1]: ***
> [_module_/home/aleph/mandriva/dahdi-linux-2.2.1/drivers/dahdi] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.6.33-desktop-0.rc6.1mnb'
> make: *** [modules] Error 2
>
>
> ======================================================================
>
> ----------------------------------------------------------------------
> (0118810) WaxyMouthfeel (reporter) - 2010-03-02 23:19
> https://issues.asterisk.org/view.php?id=16752#c118810
> ----------------------------------------------------------------------
> If you change instances of <linux/autoconf.h> to <generated/autoconf.h> to
> reflect the new kernel layout, it compiles cleanly.
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2010-03-02 23:19 WaxyMouthfeel Note Added: 0118810
> ======================================================================
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 2 Mar 2010 23:32:50 -0600
> From: Asterisk Bug Tracker <noreply at bugs.digium.com>
> Subject: [asterisk-bugs] [Asterisk 0016664]: [patch] Random DTMF
> duplicate emulation on bridged OOH323 channel on outgoing calls
> To: asterisk-bugs at lists.digium.com
> Message-ID: <186a6505c3625828e1c45c9d85acafdc at issues.asterisk.org>
> Keywords: [Asterisk] Addons/chan_ooh323
> Content-Type: text/plain; charset="utf-8"
>
>
> A NOTE has been added to this issue.
> ======================================================================
> https://issues.asterisk.org/view.php?id=16664
> ======================================================================
> Reported By: vmikhelson
> Assigned To: may213
> ======================================================================
> Project: Asterisk
> Issue ID: 16664
> Category: Addons/chan_ooh323
> Reproducibility: random
> Severity: major
> Priority: normal
> Status: ready for testing
> Asterisk Version: SVN
> JIRA:
> Regression: No
> Reviewboard Link:
> SVN Branch (only for SVN checkouts, not tarball releases): N/A
> SVN Revision (number only!):
> Request Review:
> ======================================================================
> Date Submitted: 2010-01-21 00:44 CST
> Last Modified: 2010-03-02 23:32 CST
> ======================================================================
> Summary: [patch] Random DTMF duplicate emulation on bridged
> OOH323 channel on outgoing calls
> Description:
> In majority of cases DTMF tones are duplicated by Asterisk when bridging a
> SIP or DAHDI channel with OOH323 channel on outgoing calls.
>
> In case of a normal DTMF processing the following sequence is observed:
>
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2855 __ast_read: DTMF begin '9'
> received on SIP/464-00000012
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2865 __ast_read: DTMF begin
> passthrough '9' on SIP/464-00000012
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2783 __ast_read: DTMF end '9'
> received on SIP/464-00000012, duration 120 ms
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2823 __ast_read: DTMF end
> accepted with begin '9' on SIP/464-00000012
> [Jan 20 19:59:56] DTMF[21084]: channel.c:2839 __ast_read: DTMF end
> passthrough '9' on SIP/464-00000012
>
> In case of a problematic DTMF processing it looks like that:
>
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2855 __ast_read: DTMF begin '9'
> received on SIP/464-00000011
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2865 __ast_read: DTMF begin
> passthrough '9' on SIP/464-00000011
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2783 __ast_read: DTMF end '9'
> received on OOH323/172.17.135.2:1720-9915, duration 0 ms
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2809 __ast_read: DTMF begin
> emulation of '9' with duration 100 queued on OOH323/172.17.135.2:1720-9915
> [Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
> Don't know how to indicate condition 20 on ooh323c_o_21
> [Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
> Don't know how to indicate condition 20 on ooh323c_o_21
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2932 __ast_read: DTMF end
> emulation of '9' queued on OOH323/172.17.135.2:1720-9915
> [Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
> Don't know how to indicate condition 20 on ooh323c_o_21
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2783 __ast_read: DTMF end '9'
> received on SIP/464-00000011, duration 120 ms
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2823 __ast_read: DTMF end
> accepted with begin '9' on SIP/464-00000011
> [Jan 20 19:18:54] DTMF[20916]: channel.c:2839 __ast_read: DTMF end
> passthrough '9' on SIP/464-00000011
> [Jan 20 19:18:55] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
> Don't know how to indicate condition 20 on ooh323c_o_21
>
> ======================================================================
>
> ----------------------------------------------------------------------
> (0118811) vmikhelson (reporter) - 2010-03-02 23:32
> https://issues.asterisk.org/view.php?id=16664#c118811
> ----------------------------------------------------------------------
> Re: 118799
>
> May213,
>
> It works better with patch.
>
> Specifically, I do not see "WARNING[10429]: chan_ooh323.c:1054
> ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10"
> in the middle of DTMF dialing. That allows to dial faster without loosing
> digits.
>
> It seems like calls originated on DAHDI lines work as they should with no
> missing digits or repetitions.
>
> Calls originated on SIP lines repeat almost every digit 2 times except "*"
> which is passed correctly.
>
> Please take a look at the Avaya IPOffice log. The string dialed was
> "*7352#"
>
> 18975mS CMLineRx: v=9
> CMCapabilityAck
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Product Unknown
> 19002mS PRN: Unhandled Facility
> 21136mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[*]
> Product Unknown
> Display [ThinkPad T60p]
> 22789mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[7]
> Product Unknown
> Display [ThinkPad T60p]
> 31836mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[3]
> Product Unknown
> Display [ThinkPad T60p]
> 32111mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[3]
> Product Unknown
> Display [ThinkPad T60p]
> 32673mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[5]
> Product Unknown
> Display [ThinkPad T60p]
> 32946mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[5]
> Product Unknown
> Display [ThinkPad T60p]
> 33882mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[2]
> Product Unknown
> Display [ThinkPad T60p]
> 34154mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[2]
> Product Unknown
> Display [ThinkPad T60p]
> 35616mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[#]
> Product Unknown
> Display [ThinkPad T60p]
> 35884mS CMLineRx: v=9
> CMInformation
> Line: type=IPLine 9
> Call: lid=9 id=1 in=2
> Keypad[#]
> Product Unknown
> Display [ThinkPad T60p]
>
> Thank you,
> Vladimir
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2010-03-02 23:32 vmikhelson Note Added: 0118811
> ======================================================================
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 3 Mar 2010 00:28:10 -0600
> From: Asterisk Bug Tracker <noreply at bugs.digium.com>
> Subject: [asterisk-bugs] [Asterisk 0016949]: sip reinvite broken
> To: asterisk-bugs at lists.digium.com
> Message-ID: <6c8d23f47d36a9b8e46beb8d49c6f3fb at issues.asterisk.org>
> Keywords: [Asterisk] Channels/chan_sip/Interoperability
> Content-Type: text/plain; charset="utf-8"
>
>
> The following issue has been SUBMITTED.
> ======================================================================
> https://issues.asterisk.org/view.php?id=16949
> ======================================================================
> Reported By: drookie
> Assigned To:
> ======================================================================
> Project: Asterisk
> Issue ID: 16949
> Category: Channels/chan_sip/Interoperability
> Reproducibility: always
> Severity: major
> Priority: normal
> Status: new
> Asterisk Version: 1.6.0.24
> JIRA:
> Regression: No
> Reviewboard Link:
> SVN Branch (only for SVN checkouts, not tarball releases): N/A
> SVN Revision (number only!):
> Request Review:
> ======================================================================
> Date Submitted: 2010-03-03 00:28 CST
> Last Modified: 2010-03-03 00:28 CST
> ======================================================================
> Summary: sip reinvite broken
> Description:
> Actually I have asterisk 1.6.0.25, but this interface doesn't allow to
> report it.
> OS: FreeBSD.
>
> Sample scheme:
> PSTN <--E1---> cisco <---SIP---> asterisk <---SIP---> linksys ata
>
> In the supplied wireshark cap file:
> Cisco: 192.168.3.40
> Asterisk: 192.168.3.20 (main), 192.168.3.28(carp)
> Linksys: 192.168.3.197
>
> Cisco has only g711 codec enabled on its voip dial-peer leg.
> Linksys has g723 and g729 as preferred codecs, but other codecs _aren't_
> restricted.
> Asterisk settings:
>
> Cisco:
> [kosm65-gw1]
> type=peer
> insecure=invite,port
> host=192.168.3.40
> context=kosm65-gw1-incoming
> dtmfmode=rfc2833
> disallow=all
> allow=alaw
> canreinvite=yes
>
> Linksys:
> [rybalko81-voip3]
> username=rybalko81-voip3
> secret=somesecret
> type=friend
> host=dynamic
> insecure=invite,port
> context=ordinary
> disallow=all
> allow=g729
> allow=g723
> dtmfmode=auto
> canreinvite=yes
>
> Problem description:
> I place call from Linksys to PSTN (number 92931575). If other than
> g729/g723 codecs aren't restricted in the Linksys config (it has also g726
> and g711), it sends them in the initial SDP. And then asterisk sends
> reinvites: to cisco for Linksys address and with g711 codec, and to Linksys
> for Cisco address _but_ with codecs g729/g723 (I could understand if it
> sends reinvite with g711 codec which is present in Linksys's SDP and which
> can be understood by Cisco, but it definitely reinvites with codecs from
> asterisk config). All of this results in one-way audio (PSTN cannot hear
> Linksys), as Linksys can understand g711 and Cisco cannot understand g72x.
>
> Workaround:
> If other than g723/g729 codecs are restricted on the Linksys side,
> matching the asterisk config, no reinvite occurs. Same effect when
> canreinvite is set to 'no'.
> ======================================================================
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2010-03-03 00:28 drookie New Issue
> 2010-03-03 00:28 drookie Asterisk Version => 1.6.0.24
> 2010-03-03 00:28 drookie Regression => No
> 2010-03-03 00:28 drookie SVN Branch (only for SVN checkouts, not tarball
> releases) => N/A
> ======================================================================
>
>
>
>
> ------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-bugs mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-bugs
>
> End of asterisk-bugs Digest, Vol 41, Issue 42
> *********************************************
>
--
Bhrugu Mehta
Sr. S/W Engineer (D&D)
VOIP,Telephony Team (Asterisk,zaptel etc.)
India
More information about the asterisk-bugs
mailing list