200 SDP from asterisk to extension contains alaw.
Result: no transcoding is necessary. Quality of call isn't harmed
unnecessarily! No unnecessary CPU load.
I would be really glad to have this intelligent codec handling w/
asterisk / pjsip!
Thanks,
kind regards,
Michael Maier
[1]
Michael,
>
> First off, thanks for taking the time to express some of your thoughts
> and concerns to the asterisk-dev list. I'll keep my reply to your
> email inline below.
>
> On Mon, Jan 30, 2017 at 4:13 AM, Michael Maier wrote:
> > Dear developers,
> >
&g
7 at 3:22 PM, Matt Fredrickson
>>> wrote:
>>>
>>>> Hey Michael,
>>>>
>>>> First off, thanks for taking the time to express some of your thoughts
>>>> and concerns to the asterisk-dev list. I'll keep my reply to your
>>>> em
On 01/31/2017 at 01:38 PM Joshua Colp wrote:
> On Tue, Jan 31, 2017, at 04:22 AM, Michael Maier wrote:
>
>
>
>>
>> My first idea was to prevent transcoding already during call setup. But
>> now I understand, that this is not a trivial thing to do.
>>
>&g
On 01/31/2017 at 05:15 PM Joshua Colp wrote:
> On Tue, Jan 31, 2017, at 12:01 PM, Michael Maier wrote:
[...]
>>> We
>>> don't pass the information to the other side, we just adjust our formats
>>> and transcoding.
>>
>> Yes. That's not nece
On 03/01/2017 at 04:37 PM, George Joseph wrote:
> From the blog... http://blogs.asterisk.org/2017/03/01/pjproject-2-6/
>
> This week, we’re pleased to say that we’ve updated the Asterisk 13, 14 and
> master branches’ bundled version of pjproject to 2.6.
I'm testing Asterisk 13 branch since last S
Hello!
I've got one more issue with the auto generated match entry (see
https://issues.asterisk.org/jira/browse/ASTERISK-26735 ).
If during start of asterisk DNS fails, the auto generated match entry
won't be generated any more, even hours later.
Problem: pjsip retries after 60s and establishes
Hello!
After running over a long time stable since having massive problems with
multiple DNS SRV records (see ASTERISK-26738), I got today a new segfault.
I got the attached core (unfortunately I don't have any pcap trace
running any more). But I fear, that this new segfault could be the same
pro
Hello!
Asterisk 13.18.0 contains this change [1], which prevents "+" character
in from_user parameter. This is a bad idea, as I need it (authentication
doesn't work without it). Please allow "+" sign again as before.
Thanks,
Michael
[1] https://gerrit.asterisk.org/#/c/5974/
--
___
On 10/31/2017 at 10:00 PM George Joseph wrote:
> On Tue, Oct 31, 2017 at 2:50 PM, Michael Maier wrote:
>
>> Hello!
>>
>> Asterisk 13.18.0 contains this change [1], which prevents "+" character in
>> from_user parameter. This is a bad idea, as I need it (a
Hello,
since asterisk 13.18.0, I'm facing frequent disconnects like these each day:
[2017-11-04 07:58:42] NOTICE[23289] chan_iax2.c: Peer '98' is now
UNREACHABLE! Time: 2
[2017-11-04 07:58:52] NOTICE[23286] chan_iax2.c: Peer '98' is now
REACHABLE! Time: 1
[2017-11-04 11:21:14] NOTICE[23294] chan
On 11/08/2017 at 06:14 PM Joshua Colp wrote:
> On Wed, Nov 8, 2017, at 12:57 PM, Michael Maier wrote:
>> Hello,
>>
>> since asterisk 13.18.0, I'm facing frequent disconnects like these each
>> day:
>
> What version previously wor
Hello!
Deutsche Telekom introduced sips and srtp. I tested it and it works partly.
Partly means: sips is working - but not srtp. srtp doesn't work, because of
missing additional
headers in the REGISTER and INVITE packages (according an enhancement of RFC
3329).
Example:
UAC
On 15.01.19 at 20:27 Joshua C. Colp wrote:
>
>
> On Tue, Jan 15, 2019, at 3:23 PM, Michael Maier wrote:
>> Hello!
>>
>> Deutsche Telekom introduced sips and srtp. I tested it and it works
>> partly. Partly means: sips is working - but not srtp. srtp doe
Hello!
Given is an outbound call to a callee via asterisk to the ISP. After INVITE,
the ISP sends 100 Trying and some time later 180 Ringing *w/* SDP and the header
"P-Early-Media: sendonly" (no 183 or any other thing until callee responds).
SDP in 180 contains media attribute *sendrecv* (contra
On 24.01.19 at 12:08 Joshua C. Colp wrote:
> On Thu, Jan 24, 2019, at 7:00 AM, Michael Maier wrote:
>> Hello!
>>
>> Given is an outbound call to a callee via asterisk to the ISP. After
>> INVITE, the ISP sends 100 Trying and some time later 180 Ringing *w/*
>&g
On 24.01.19 at 14:31 Joshua C. Colp wrote:
> On Thu, Jan 24, 2019, at 9:23 AM, Michael Maier wrote:
>> On 24.01.19 at 12:08 Joshua C. Colp wrote:
>>> On Thu, Jan 24, 2019, at 7:00 AM, Michael Maier wrote:
>>>> Hello!
>>>>
>>>> Given is an ou
On 24.01.19 at 12:08 Joshua C. Colp wrote:
> On Thu, Jan 24, 2019, at 7:00 AM, Michael Maier wrote:
>> Hello!
>>
>> Given is an outbound call to a callee via asterisk to the ISP. After
>> INVITE, the ISP sends 100 Trying and some time later 180 Ringing *w/*
>&g
On 15.01.19 at 20:27 Joshua C. Colp wrote:
>
>
> On Tue, Jan 15, 2019, at 3:23 PM, Michael Maier wrote:
>> Hello!
>>
>> Deutsche Telekom introduced sips and srtp. I tested it and it works
>> partly. Partly means: sips is working - but not srtp. srtp doe
On 03.02.19 at 12:00 Joshua C. Colp wrote:
> On Sun, Feb 3, 2019, at 6:03 AM, Michael Maier wrote:
>> On 15.01.19 at 20:27 Joshua C. Colp wrote:
>
>
>
>>
>>
>> If I wanted to try it myself - what would be the correct places to
>> implement it?
>>
Hello!
some people are facing a problem regarding forbidden outbound calls to the ISP.
They start an outbound call, which is rejected by the
provider. Debugging revealed the reason: The IP used for the outbound INVITE is
different from the IP used for the REGISTER. That's why the
ISP forbids the
On 24.05.19 at 13:14 Joshua C. Colp wrote:
> On Fri, May 24, 2019, at 6:02 AM, Michael Maier wrote:
>> Hello!
>>
>> some people are facing a problem regarding forbidden outbound calls to
>> the ISP. They start an outbound call, which is rejected by the
>> provid
On 24.05.19 at 14:29 Joshua C. Colp wrote:
> On Fri, May 24, 2019, at 7:24 AM, Michael Maier wrote:
>> On 24.05.19 at 13:14 Joshua C. Colp wrote:
>>> On Fri, May 24, 2019, at 6:02 AM, Michael Maier wrote:
>>>> Hello!
>>>>
>>>> some people are
On 24.05.19 at 14:48 Joshua C. Colp wrote:
> On Fri, May 24, 2019, at 7:46 AM, Michael Maier wrote:
>>
>> Would it be a valid feature request? Do you think it is worth it?
>
> We don't currently accept feature requests on JIRA,
=> What does this mean? Isn'
On 24.05.19 at 15:37 Joshua C. Colp wrote:
> On Fri, May 24, 2019, at 8:24 AM, Michael Maier wrote:
>> On 24.05.19 at 14:48 Joshua C. Colp wrote:
>>> On Fri, May 24, 2019, at 7:46 AM, Michael Maier wrote:
>>>>
>>>> Would it be a valid feature request? Do
On 24.05.19 at 12:45 Joshua C. Colp wrote:
> On Fri, May 24, 2019, at 3:35 AM, Michael Maier wrote:
>> On 03.02.19 at 12:00 Joshua C. Colp wrote:
>>> On Sun, Feb 3, 2019, at 6:03 AM, Michael Maier wrote:
>>>> On 15.01.19 at 20:27 Joshua C. Colp wrote:
[...]
>
On 28.05.19 at 15:12 Joshua C. Colp wrote:
> On Sun, May 26, 2019, at 1:51 PM, Michael Maier wrote:
>> On 24.05.19 at 12:45 Joshua C. Colp wrote:
>>> On Fri, May 24, 2019, at 3:35 AM, Michael Maier wrote:
>> - Is there any possibility in handle_client_registration to ch
Hello!
I wrote some code, which adds basic media encryption support to be used with
Deutsche Telekom. The attached patch is based on Asterisk 16.3
and works for me :-) - not fully tested yet. If you want to use it, you have to
enable media_encryption=sdes for the extension (and
transport tls and
On 30.05.19 at 10:24 Michael Maier wrote:
[...]
Another yet missing point is the qualify OPTIONS package. I'm not sure where to
add the mediasec headers exactly (which function?). At the
moment, the Response after OPTION request is (if already registered):
SIP/2.0 494 Security Agre
On 31.05.19 at 02:25 wrote Learn&Use:
Hi all,
I would need to remove the sdp attribute a=setup from INVITE’s going out to a
SIP trunk ISP. I’m using chan_PJSIP with DTLS media encryption and was
searching through various source files(res_pjsip_sdp_rtp,...) to make a change
in the code to prev
On 31.05.19 at 11:34 Joshua C. Colp wrote:
On Fri, May 31, 2019, at 3:38 AM, Michael Maier wrote:
On 30.05.19 at 10:24 Michael Maier wrote:
[...]
Another yet missing point is the qualify OPTIONS package. I'm not sure where to
add the mediasec headers exactly (which function?). At the
m
On 31.05.19 at 19:25 Joshua C. Colp wrote:
> On Fri, May 31, 2019, at 1:57 PM, Michael Maier wrote:
>
>
>
>>
>> Thanks Joshua!
>>
>> I added the attached changes. Afterwards, I could see one SIGSEGV so
>> far which I can't understand. I would be
Hello!
That's the *complete* patch for Asterisk 16.3 (can be applied to asterisk 16.4,
too). Logging has been changed to ast_debug(3,).
See previous posts for information about usage.
Regards,
Michael
diff -urN asterisk-16.3.0.orig/res/res_pjsip/pjsip_options.c asterisk-16.3.0/res/res_pjsip/pj
Hello!
I'm facing a problem on an outbound call which receives a reInvite w/o SDP
(late / delayed offer technique) from ISP. The ISP won't provide
any SDP in the following received ACK and the call is broken therefore
afterwards because no more media is sent after this reInvite.
Detail:
- ISP
On 17.06.19 at 20:15 Joshua C. Colp wrote:
> On Mon, Jun 17, 2019, at 3:10 PM, Michael Maier wrote:
>> Hello!
>>
>> I'm facing a problem on an outbound call which receives a reInvite w/o
>> SDP (late / delayed offer technique) from ISP. The ISP won't provide
Hello!
On outbound calls, the codecs for the subsequent INVITE to the ISP are derived
from the codecs defined for the trunk and from the received INVITE from the
local device.
The codecs presented by the ISP in 200 OK seem to be ignored unfortunately
later on.
E.g.:
direct_media
On 22.06.19 at 23:59 Joshua C. Colp wrote:
> On Sat, Jun 22, 2019, at 4:40 PM, Michael Maier wrote:
>> Hello!
>>
>> On outbound calls, the codecs for the subsequent INVITE to the ISP are
>> derived from the codecs defined for the trunk and from the received
>
On 17.06.19 at 21:11 Michael Maier wrote:
> On 17.06.19 at 20:15 Joshua C. Colp wrote:
>> On Mon, Jun 17, 2019, at 3:10 PM, Michael Maier wrote:
>>> Hello!
>>>
>>> I'm facing a problem on an outbound call which receives a reInvite w/o
>>> SDP
Am 09.08.19 um 20:09 schrieb Joshua C. Colp:
On Fri, Aug 9, 2019, at 2:58 PM, Michael Maier wrote:
I think I probably realized now the real problem of the wrong SDP
session version: Based on this patch
diff -urN asterisk-16.3.0.orig/res/res_pjsip/pjsip_message_filter.c
asterisk-16.3.0/res
Hello!
In a manufacturing environment it is absolutely necessary to troubleshoot sip connections from asterisk to the ISP using sips / tls. At the
moment, I can't see any way how to do it (CLI "pjsip set logger on" isn't an option).
Firefox and Chrome provide the environment key SSLKEYLOGFILE,
On 19.08.19 at 16:19 George Joseph wrote:
> On Mon, Aug 19, 2019 at 5:37 AM IanG wrote:
>
>> How about configuring Asterisk to forward the decrypted SIP traffic to a
>> local Homer server?
>>
>
> Check out res_hep, res_hep_pjsip, res_hep_rtcp and the hep.conf sample file.
Thanks for all of your
Hello!
If there are headers added to a request using ast_sip_add_header: who is
responsible for the memory management of the added headers? At the moment I
suspect, that there is
a memory leak using ast_sip_add_header because I can see slightly but
constantly more growing memory usage (see medi
Am 31.08.19 um 12:33 schrieb Joshua C. Colp:
On Sat, Aug 31, 2019, at 7:04 AM, Michael Maier wrote:
Hello!
If there are headers added to a request using ast_sip_add_header: who is
responsible for the memory management of the added headers? At the moment I
suspect, that
there is a memory leak
On 30.05.19 at 10:24 Michael Maier wrote:
> Hello!
>
> I wrote some code, which adds basic media encryption support to be used with
> Deutsche Telekom. The attached patch is based on Asterisk 16.3
> and works for me :-) - not fully tested yet. If you want to use it, you ha
Hello!
Since Asterisk 16.5.x (without any additional patch at all), I' m seeing
continuously rising memory consumption each hour even if there where no calls
at all. It's about
792 kbytes (RSS) each hour (3 SIPS / TLS 1.2 trunks, 10 min ReRegistration, 240
s OPTIONS, 1 SIPS trunk, 60 s ReRegist
On 15.09.19 at 21:19 Joshua C. Colp wrote:
> On Sun, Sep 15, 2019, at 2:21 AM, Michael Maier wrote:
>> BTW: I'm not really happy with the fact, that an existing LTS / stable
>> version gets a new pjsip version "on the fly". From my point of view, this
>> shou
On 02.09.19 at 19:03 Michael Maier wrote:
> On 30.05.19 at 10:24 Michael Maier wrote:
>> Hello!
>>
>> I wrote some code, which adds basic media encryption support to be used with
>> Deutsche Telekom. The attached patch is based on Asterisk 16.3
>> and works for
Am 16.09.19 um 20:19 schrieb Kevin Harwell:
Actually can you create a new issue for this on the issue tracker. As well
included the following:
Has anything else changed? For instance was openssl upgraded between then
too? >
Speaking of which, what version of openssl is installed? As well what OS
Hello!
While testing for a memory leak since pjsip 4.9 I detected, that there seems to
be another memory leak concerning core reload with pjsip and 4 TLS trunks / 2
endpoints.
Each core reload rises memory usage about ~ 2 MB (some times more (up to 3 MB),
sometimes less).
That's not a big deal
On 28.09.19 at 12:32 Joshua C. Colp wrote:
> On Sat, Sep 28, 2019, at 6:20 AM, Michael Maier wrote:
>> Hello!
>>
>> While testing for a memory leak since pjsip 4.9 I detected, that there
>> seems to be another memory leak concerning core reload with pjsip and 4
wrote:
On Sat, Sep 28, 2019, at 11:31 AM, Michael Maier wrote:
On 28.09.19 at 12:32 Joshua C. Colp wrote:
On Sat, Sep 28, 2019, at 6:20 AM, Michael Maier wrote:
Hello!
While testing for a memory leak since pjsip 4.9 I detected, that there
seems to be another memory leak concerning core reload
Hello again!
Sorry, but there is one more memory leak even in asterisk 16.6.0-rc2, which
can't be seen with pjsip 4.8 instead of 4.9. It can be seen on inbound calls
(not sure if it's
on outbound calls, too) using SIPS and SRTP.
Examples:
1 Call, duration about 1 h: ~ +1,2 MB
5 short calls (<
On 02.10.19 at 22:45 Sean Bright wrote:
> On 10/2/2019 4:02 PM, Michael Maier wrote:
>> I found one more problem regarding the configuration options, provided by
>> FreePBX, which should be supported by asterisk.
>> I'm referring to the possibility, to add additiona
On 03.10.19 at 15:42 Michael Maier wrote:
> there is one more memory leak even in asterisk 16.6.0-rc2, which can't be
> seen with pjsip 4.8 instead of 4.9. It can be seen on inbound calls (not sure
> if it's
> on outbound calls, too) using SIPS and SRTP.
https://issues.as
On 03.10.19 at 16:08 Jared Smith wrote:
> On Thu, Oct 3, 2019 at 10:01 AM Sean Bright wrote:
>
>> In the future, please feel free to skip the mailing list and submit
>> issues directly to https://issues.asterisk.org/jira for any Asterisk
>> problems.
>>
>> FreePBX issues like this one can go dire
On 03.10.19 at 15:52 Michael Maier wrote:
> On 02.10.19 at 22:45 Sean Bright wrote:
>> On 10/2/2019 4:02 PM, Michael Maier wrote:
>>> I found one more problem regarding the configuration options, provided by
>>> FreePBX, which should be supported by asterisk.
>>&
Hi!
Meanwhile, there is an improved version of the mediasec patch, which adds a
switch to enable mediasec headers for each endpoint individually. This patch is
thankfully
provided by André Valentin (avalen...@marcant.net /
https://www.marcant.net/en/). It's the patch "2-add-mediasec-switches.pa
Hello Kevin,
On 29.01.20 at 20:22 Kevin Harwell wrote:
> Greetings!
>
> Over the years there have been numerous requests to improve the codec
> negotiation process in Asterisk. Specifically, regarding what codecs are
> offered, in what order, how Asterisk chooses which codec(s) to use, and of
> c
On 29.01.20 at 22:44 Kevin Harwell wrote:
> Ugh I used the wrong keyboard shortcuts and the message sent before I was
> done. Below is the rest :-)
>
> On Wed, Jan 29, 2020 at 3:42 PM Kevin Harwell wrote:
>
>> On Wed, Jan 29, 2020 at 3:12 PM Mi
Hello Kevin,
thanks for your clarification. Anyway, I think I don't understand it
completely right now. Please see question below.
Thanks
Michael
On 30.01.20 at 16:49 Kevin Harwell wrote:
> On Thu, Jan 30, 2020 at 4:55 AM Michael Maier wrote:
>
>>
>>
>> Cou
On 30.01.20 at 23:20 Kevin Harwell wrote:
> On Thu, Jan 30, 2020 at 3:01 PM Michael Maier wrote:
>
>> .
>>>> 2. outgoing_sdp_send_prefs
>>>>The list can be created on base of the callees
>>>>allow line and list 1 (option local ...
Hello!
On 05.03.20 at 19:08 Asterisk Development Team wrote:
> * ASTERISK-28746 - res_pjsip_outbound_registration keeps
> retrying the first entry in a SRV record set
> (Reported by
> George Joseph)
I just tested the new version 16.9.0.rc1 and promptly got an error with
this pa
On 09.03.20 at 08:24 Andreas Wehrmann wrote:
>
> Out of interest: What product of theirs do you use? Is it companyflex?
> I'm asking because I need to interface with Deutsche Telekom as well.
I'm using the consumer AllIP product (what you get if you are using
MagentaZuhause [1] e.g.). But they ha
On 09.03.20 at 13:43 George Joseph wrote:
> On Sun, Mar 8, 2020 at 2:48 PM George Joseph wrote:
>
>>
>>
>> On Fri, Mar 6, 2020 at 10:07 PM Michael Maier
>> wrote:
>>
>>> Hello!
>>>
>>> On 05.03.20 at 19:08 Asterisk Development Team
On 09.03.20 at 19:04 George Joseph wrote:
> On Mon, Mar 9, 2020 at 10:59 AM Michael Maier wrote:
>
>> On 09.03.20 at 13:43 George Joseph wrote:
>>> On Sun, Mar 8, 2020 at 2:48 PM George Joseph wrote:
>>>
>>>>
>>>>
>>>> On Fri, M
Hello!
I'm facing a massive problem during sending or receiving of fax (spandsp, pjsip,
asterisk 16.9 bundled pjsip). Affected are always the packages sent by asterisk.
The packages received are pretty perfect.
Tracetool is pcapsipdump.
Problem can't be seen that massive during "normal" (non) fa
ceives
the fax on its own (no other tool involved).
On 04.04.20 at 15:33 Michael Maier wrote:
> Hello!
>
> I'm facing a massive problem during sending or receiving of fax (spandsp,
> pjsip,
> asterisk 16.9 bundled pjsip). Affected are always the packages sent by
> aste
On 04.04.20 at 15:33 Michael Maier wrote:
> Hello!
>
> I'm facing a massive problem during sending or receiving of fax (spandsp,
> pjsip,
> asterisk 16.9 bundled pjsip). Affected are always the packages sent by
> asterisk.
> The packages received are pretty
On June 03, 2020 at 22:17 George Joseph wrote:
> Greetings All,
>
> We've been working hard on new codec negotiation stuff for Asterisk 18 and
> we've got some stuff to run by you. It's a lot so please read carefully.
Thank you very much for your ongoing effort! I really appreciate it!
I additio
On 02.06.20 at 11:10 Asterisk Development Team wrote:
> The Asterisk Development Team would like to announce the second
> release candidate of Asterisk 16.11.0.
> This release candidate is available for immediate download at
> https://downloads.asterisk.org/pub/telephony/asterisk
JFI:
I'm testing
Hello George,
in terms of uses cases? I'm not aware of any use case which would need
asymmetric codecs. The opposite is true: my phones can't handle asymmetric
codecs at all - therefore it's
forbidden.
But I'm not the only one using asterisk - others may have an use case.
On 15.06.20 at 01:56
On Mon, Jun 15, 2020 at 19:56 Joshua Elson wrote:
So I am the one responsible for this situation, if I recall the discussion
a few years back. We actually have had to support several phones - Yealink
being the most distinctly memorable - that support asymmetric codecs on a
single call leg, and fr
Hi George,
On 23.06.20 at 17:55 George Joseph wrote:
> What role should ACN play in Direct Media??
> How do you think codec negotiation should work in this case?
> I'm not going to offer suggestions or explanations until I hear opinions
> from you guys. :)
Direct media means: RTP flows directly f
On 25.06.20 at 15:57 George Joseph wrote:
> On Wed, Jun 24, 2020 at 12:03 PM Stefan Tichy wrote:
>
>> On Sat, Jun 06, 2020 at 08:20:47AM +0200, Michael Maier wrote:
>>
>>> Transcoding only if there is an allowed and supported codec on both sides
>>> which ar
Hello George,
On 08.07.20 at 22:01 George Joseph wrote:
> Today, if you create an endpoint configuration with no codecs, we create an
> empty topology for it but otherwise accept it. I'm not sure what you'd use
> it for though. Is there a situation where an endpoint with no codecs
> _should_ be
On 09.07.20 at 18:28 Asterisk Development Team wrote:
> The Asterisk Development Team would like to announce the first
> release candidate of Asterisk 16.12.0.
> This release candidate is available for immediate download at
> https://downloads.asterisk.org/pub/telephony/asterisk
>
> The release o
Hello!
I was successfully able to patch and compile the actual Asterisk 18 branch.
While building the RPM packages, it turned out, that all devel files
(/usr/include/asterisk.h and
/usr/include/asterisk/*) are missing. Seems, that they aren't installed any
more by make install. Is this the new
On 02.08.20 at 22:15 Joshua C. Colp wrote:
> On Sun, Aug 2, 2020 at 3:20 PM Michael Maier wrote:
>
>> Hello!
>>
>> I was successfully able to patch and compile the actual Asterisk 18
>> branch. While building the RPM packages, it turned out, that all devel
>>
On 03.08.20 at 11:30 Joshua C. Colp wrote:
[...]
> I don't work on FreePBX so don't really have any idea of when it will be
> supported. As it is, 18 hasn't even had a release candidate yet.
Don't hurry - I just took a look to see if there are any changes which involve
my changes.
Regarding FreeP
Hello!
I got the following warning in the asterisk log:
[2020-08-15 16:16:03] WARNING[14367] res_pjsip_outbound_registration.c: No
response received from 'sip:tel.t-online.de' on registration attempt to
'sip:+49...@tel.t-online.de', retrying in '60'
What really happened (according pcap trace)
Hello all!
Is there any official support for the amr codec in Asterisk? I couldn't find
any in asterisk 16.
There is a patch for Asterisk 13:
https://github.com/traud/asterisk-amr
Thanks
Michael
--
_
-- Bandwidth and Colocat
;s
working or if there are any problems with the use of amr and asterisk to get
them addressed and
hopefully fixed.
Thanks
Kind regards
Michael
On 17.08.20 at 20:45 Joshua C. Colp wrote:
> On Mon, Aug 17, 2020 at 3:40 PM Michael Maier wrote:
>
>> Hello all!
>>
>> Is
On 18.08.20 at 10:49 Carsten Bock wrote:
> Hi,
>
> one of the big issues with AMR/AMR-WB and Asterisk is that usually devices
> speaking AMR/AMR-WB do use quite a lot of comfort noise, which is not
> supported by Asterisk as far as I know. Even if you use the patch from the
> above link, you might
On 20.08.20 at 15:12 Alexander Traud wrote:
comfort noise, which is not supported by Asterisk
In case of AMR(-WB), Comfort Noise (CN) is part of the decoder itself already.
Consequently, no additional support in Asterisk is required. My patch can be
changed to enable Voice Activity Detection
Hello!
Alexander Traud provided patches for Asterisk 13 for the EVS codec[1]. Those
patches can be applied to Asterisk 16, too. I attached a tar file, which
contains all patches from
Alexander in one file and a spec file for building the evs codec library from
www.etsi.org (tested on CentOS 7).
On Mon, Aug 24, 2020 at 16:32 George Joseph wrote:
Check your timer_t1 setting in pjsip.conf.
There is no entry - therefore I assume, the default should be used.
That's what would control
pjproject's decision on when to return back to us if there's no response to
a request. It's also unclea
On 20.08.20 at 15:12 Alexander Traud wrote:
> Software bugs love to be talked about. That helps them to hide. Bugs hate to
> be tracked down. That might kill them.
>
>> comfort noise, which is not supported by Asterisk
>
> In case of AMR(-WB), Comfort Noise (CN) is part of the decoder itself
>
On 03.09.20 at 21:41 Alexander Traud wrote:
>> /usr/lib64/asterisk/modules/codec_evs.so
>
> Please,
> 1) do an "ldd" on that. Does it find all dependencies?
Just for info. The expected result would be something like that:
[root@myast ~]# ldd /usr/lib64/asterisk/modules/codec_evs.so
linux
Hello all,
according [1], there are those options in pjsip regarding support of timers:
___
timers
no
yes
required
always
forced - Alias of always
___
I'm
On 05.09.20 at 23:18 Michael Maier wrote:
> Hello all,
>
> according [1], there are those options in pjsip regarding support of timers:
>
> ___
> timers
>
> no
> yes
> required
> alwa
On 08.09.20 at 11:41 Joshua C. Colp wrote:
> On Sat, Sep 5, 2020 at 6:18 PM Michael Maier wrote:
>
>> Hello all,
>>
>> according [1], there are those options in pjsip regarding support of
>> timers:
>>
>>
On 09.09.20 at 19:02 Asterisk Development Team wrote:
> The Asterisk Development Team would like to announce the first
> release candidate of Asterisk 16.14.0.
> This release candidate is available for immediate download at
> https://downloads.asterisk.org/pub/telephony/asterisk
Works for me :-)
Hello!
I'm actually wondering why there isn't any final version yet.
Thanks
Michael
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
Hello!
I'm *sometimes* facing dropped calls after 900s on outbound calls. I analyzed
the traces and could see the following point:
1. Asterisk sends Invite to provider / CSeq 26379 INVITE
2. Provider sends 180 Ringing / require: 100rel RSeq: 2 / CSeq 26379 INVITE
3. Asterisk sends PRACK / CSeq
Hello Joshua,
On 13.10.20 at 13:01 Joshua C. Colp wrote:
> On Tue, Oct 13, 2020 at 7:49 AM Michael Maier wrote:
>
>
>
>
>> My question (because always if a call was dropped, PRACK has been in use):
>> Is it a good idea to use a subsequent CSeq for the PRACK on
Hello!
I'm facing the problem, that *sometimes* the SDP session ID isn't incremented
in the 200 OK, which asterisk sends as answer to a ReInvite it got from the
peer (use case: session
timer handling). This leads to broken calls, because the SDP session ID must be
incremented if the session des
Hello Joshua,
On 27.10.20 at 10:07 Joshua C. Colp wrote:
> On Mon, Oct 26, 2020 at 2:02 PM Michael Maier wrote:
>
>> Hello!
>>
>> I'm facing the problem, that *sometimes* the SDP session ID isn't
>> incremented in the 200 OK, which asterisk sends as answ
On 25.08.20 at 11:13 Michael Maier wrote:
Yes, that's true. While it happens extremely rarely, I wouldn't know how to trace it down. It usually runs for weeks without any problems, suddenly there are one or two entries
(seldom more) and afterwards, it's fine again. Maybe I g
On 19.12.20 at 07:45 Michael Maier wrote:
> Maybe there is a problem with registering 3 numbers to the same
> destination, which are handled by asterisk through the exactly same
> connection (tls/tcp)?
After evaluation lots of faulty retries, I could see, that this problem
only could b
Hello!
I'm not sure if the following finding is a bug or a feature. Given is a trunk
to a registered destination:
virtast*CLI> pjsip show registrations
==
easybellPJSIP/sip:secure.sip.easybell.de
1 - 100 of 148 matches
Mail list logo
