similar to: switching from simple_bridge technology to native_rtp issue

Hey guys, have issues with reinvite, no matter what endpoint is calling asterisk always tries switch simple_bridge to native_rtp Bridge 0422bfa0-9d22-4bba-9108-a3f14d7d1cab: switching from simple_bridge technology to native_rtp in endpoints table ?direct_media? sets to ?no? on all endpoints but it doesn?t help. if native_rtp not work for some reason I have oneway audio. how can I fix this?

On Wed, Mar 18, 2015 at 7:41 AM, Nick Awesome <jleed at me.com> wrote: > Hey guys, > > have issues with reinvite, no matter what endpoint is calling asterisk > always tries switch simple_bridge to native_rtp > > Bridge 0422bfa0-9d22-4bba-9108-a3f14d7d1cab: switching from simple_bridge > technology to native_rtp > > in endpoints table ?direct_media? sets to ?no? on

On Thu, Mar 19, 2015 at 1:47 AM, Nick Awesome <jleed at me.com> wrote: > NAT endpoint calling local endpount - switching to native_rtp then no audio, > both of them have direct_media=no, Verbose log: > > -- Executing [99 at dialmap:1] AGI("PJSIP/304-00000022", "/pbx/agi.php") in > new stack > -- Launched AGI Script /pbx/agi.php > -- AGI

Well, it breaks audio for all NAT endpoints, how can I fix this? > On 18 Mar 2015, at 15:48, Matthew Jordan <mjordan at digium.com> wrote: > > On Wed, Mar 18, 2015 at 7:41 AM, Nick Awesome <jleed at me.com <mailto:jleed at me.com>> wrote: >> Hey guys, >> >> have issues with reinvite, no matter what endpoint is calling asterisk >> always tries

NAT endpoint calling local endpount - switching to native_rtp then no audio, both of them have direct_media=no, Verbose log: -- Executing [99 at dialmap:1] AGI("PJSIP/304-00000022", "/pbx/agi.php") in new stack -- Launched AGI Script /pbx/agi.php -- AGI Script Executing Application: (Dial) Options: (PJSIP/99/sip:99 at 192.168.1.73:5060,20) -- Called

On Wed, Mar 18, 2015 at 9:53 AM, Nick Awesome <jleed at me.com> wrote: > Well, it breaks audio for all NAT endpoints, how can I fix this? > Local (packet to packet) bridging should not do that. Remote (direct media) can do that. Can you confirm - by looking at a verbose level 4 log - how Asterisk is bridging the two channels? -- Matthew Jordan Digium, Inc. | Director of Technology

    Some users have complained that their calls drop after about 30 seconds.  Not all, just some.  After looking at the log files the only difference I can find from the dropped calls is the following line: [2020-09-07 11:29:59] VERBOSE[21666][C-00000055] bridge.c: Bridge 14410400-5e04-4358-af0c-45fd71f6f5cd: switching from simple_bridge technology to native_rtp     Most calls just do:

Le 2017-07-05 18:51, Joshua Colp a ?crit : > On Wed, Jul 5, 2017, at 01:45 PM, Jean Aunis wrote: > >> Hello, I am struggling with a problem which I thought would be an easy one : bridging several channels together in a *smart* bridge. I emphasize *smart* : I want my bridge to be a native_rtp one when only two channels are involved, and switch to softmix technology when a third

Hello, I am struggling with a problem which I thought would be an easy one : bridging several channels together in a *smart* bridge. I emphasize *smart* : I want my bridge to be a native_rtp one when only two channels are involved, and switch to softmix technology when a third channel comes in. I thought I could use ConfBridge for that, but it creates a bridge that is not smart (it is of

Hi friends, I am just starting use asterisk for our VoIP server. It works fine in LAN. But when it is deployed in public network(with a public IP), the SIP clients in different NAT fails to communicate with each other. I have set 'icesupport' to 'yes' in sip.conf and set STURN and TURN server in rtp.conf. It still fails! Hope someone to help me out! Thanks in advance:) This

On Mon, Sep 7, 2020 at 9:35 PM Carlos Chavez <cursor at telecomab.mx> wrote: > Some users have complained that their calls drop after about 30 > seconds. Not all, just some. After looking at the log files the only > difference I can find from the dropped calls is the following line: > > [2020-09-07 11:29:59] VERBOSE[21666][C-00000055] bridge.c: Bridge >

On 21-11-16 15:17, Matthew Jordan wrote: > > On Mon, Nov 21, 2016 at 7:05 AM, Jonas Kellens > <jonas.kellens at telenet.be <mailto:jonas.kellens at telenet.be>> wrote: > > Hello > > when using Asterisk version 13.12.2 I notice that it takes up to > 30 seconds (sometimes even longer) for a call queue to call its > members. > >

Hello, I think there is an issue when DTMF are handled with SIP INFO and direct media is enabled. When I receive a SIP INFO, the logs tell me that a "DTMF begin" is generated, but no related "DTMF end" is generated, unless the call is ended. Here is an excerpt of the logs : *--- SIP INFO received **on **SIP/xxx-00000004:* [Dec 13 11:56:16] DTMF[18193][C-00000005]

I have a hosted server. I have TWO different locations what have phones. Chicago and Indiana If I send audio direct from server to Chicago I hear it - same with indiana. But if indiana calls chicago - NO AUDIO. I see this in the CLI -- Channel SIP/63009-00000013 joined 'simple_bridge' basic-bridge <475050e7-9d99-43f0-a9bf-7aa581a97fd9> -- Channel SIP/63000-00000012 joined

Hello when using Asterisk version 13.12.2 I notice that it takes up to 30 seconds (sometimes even longer) for a call queue to call its members. Example 1 : [Nov 21 08:17:57] pbx.c: Executing [queue at pbx-routing:15] Queue("SIP/incoming-00000246", "myqueue1,,,,300,,,") in new stack [Nov 21 08:17:57] res_musiconhold.c: Started music on hold, class 'default', on

Hi I'm trying to get the rebuilt parking functionality to work in Asterisk 12.0.0. In Asterisk 11.6.0 I managed to get a call to get parked by adding a dynamic feature in features.conf for the DMTF sequence *# which called a macro in extensions.conf, which then runned the ParkAndAnnounce application, and the call got parked. The syntax for ParkAndAnnounce I used was this (I don't

On 06/14/2017 at 10:17 PM, Joshua Colp wrote: > On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote: > > <snip> > >> >> I can now say, that asterisk / pjsip seams to work *mostly* as expected. >> Just one exception - and that's the package in question, which can't be >> seen in tcpdump. >> >> I extended the above patch by adding

The Asterisk Development Team would like to announce the release of Asterisk 13.33.0. This release is available for immediate download at https://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 13.33.0 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following issues are resolved in this release:

The Asterisk Development Team would like to announce the release of Asterisk 13.33.0. This release is available for immediate download at https://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 13.33.0 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following issues are resolved in this release:

I'm trying to implement direct_media between multiple peers and an uplink provider, all of whom have direct_media=yes configures. For originating calls to the uplink provider direct_media=yes works like expected. SIP flows through asterisk, rtp doesn't SIP: enduser <-> SBC <-> asterisk 13 <-> uplink RTP: enduser <-> SBC <-----------------> uplink SBC