Re: [asterisk-dev] Mailing List Future

[Michael Maier]

Hello!

I can fully agree with what you have written. 100%

Thanks
Michael


On 04.12.23 at 13:52 aster...@phreaknet.org wrote:
I strongly object to not having an asterisk-dev list. Mailing lists are essential 
for FOSS developer discussion. The majority of non-ephemeral development 
discussion happens either on IRC or here on the asterisk-dev list - just check the 
archives to see that it's still active. Most of us are not on the community forums 
and/or couldn't be bothered to use them. You can go and see now that "Development" 
on the community forums is basically dead, because nobody wants to use it, so 
trying to push that on everyone is a terrible idea.


Even for users, I think the loss of asterisk-users will be a major loss. Far more 
*discussion* is happening on the Discourse forum, but far more *quality* 
discussion still happens on asterisk-users. Being on a mailing list seems to be a 
natural weedout for junk questions. More serious questions still seem to come 
through on the mailing list. The community forums is far fuller of useless 
postings from people who can't tell a hard drive from a memory stick. Nobody wants 
to wade through a bunch of low-quality posts to find the few that might have some 
use. Thus, getting rid of asterisk-users would see a significant drop in the 
average quality of user engagement. But at least, even if the -users list is 
dropped, the -dev list should stick around in some form.


I know the forums can have emails enabled that you can receive, and no, that's not 
a proper replacement for a mailing list.


GitHub Discussions aren't a proper mailing list, either, so ultimately I think 
that will run into the same issue. GitHub has a lot of bells and whistles but most 
of them aren't as built out as using the proper tool they try to emulate.


I think #3 is the right choice. It's using the right tool for the right job. If 
you don't want to maintain the lists, have somebody else do it. I do a combination 
of hosted and self-hosted for my own lists. Contrary to the opinions of some, 
people, especially technical people, have not "moved on" from mailing lists; they 
are widely used, and I get hundreds of emails a day from them that I have a good 
workflow for.


Most lists I'm on that used to be elsewhere (e.g. Yahoo Groups, Google Groups, 
mailman, LISTSERV, other custom or independent platforms) have now migrated to 
groups.io and are generally highly satisfied with it compared to other platforms. 
It used to be completely free; it's now free for lists under 100 members, or ones 
that are grandfathered in. As the maintainer of several lists there and a member 
of many more, I've been pretty happy with it.


I'd suggest creating a list there and letting people on this list manually opt 
into it, since there are probably a lot of people on mailman that aren't active 
anymore. If it's under 100 members, it's completely free anyways. If more than 100 
people join, that means people here *really* like mailing lists and find value in 
them, and I'm sure Sangoma can afford $20 a month for it, if it really doesn't 
want to run mailman lists anymore that badly, and $20 is a small price to keep 
developers happy.


NA

On 12/4/2023 7:28 AM, Jaco Kroon wrote:


Hi,

My 5c.  Killing the dev list is a bad idea.

Most developers could not care about having to poll forums.  It also means that 
stuff that would previously get an audience will now get none.


github discussions are better than forums at least.

May I inquire as to the problem you're having with the ML? Perhaps I might be 
able to assist ...


Kind regards,
Jaco

On 2023/12/04 14:00, Joshua C. Colp wrote:


Greetings all,

Over the past few years, the use of the Asterisk mailing lists has diminished, 
with far more conversation happening on the Asterisk community forums[1]. The 
state of email, to ensure reliable delivery, has also gotten more complicated - 
emails get caught by spam filters, etc.. To continue the mailing lists would 
require a huge time and resource investment, for minimal use.


To that end, we’ve decided to discontinue the mailing lists effective February 
1st, 2024.


This means the following:

1. Sending and receiving mailing list emails will no longer be possible.
2. The list archives, however, will remain available.

We need to decide the future of the asterisk-dev mailing list; specifically, 
where to hold discussions in the future. There are a few options:


1. A “Development” category exists on https://community.asterisk.org/ already 
that can be used.

2. We can use GitHub discussions, which keeps things with the GitHub project.
3. We can use a hosted mailing list elsewhere.

We suggest option #2, since it keeps things with the GitHub project, which is 
where everything development-related happens now regardless. This has been set 
up and enabled already.


If you have any input, now is the time to state it.

Cheers,

--
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us 

Re: [asterisk-dev] Gerrit offline? -> What about the future of svn?

[Michael Maier]

Hello George,

On 17.08.23 at 14:09 George Joseph wrote:
On Wed, Aug 16, 2023 at 5:58 PM George Joseph > wrote:


I'll bring it back up in the morning.


Gerrit is back up but will be permanently disabled on Monday at 1200Z.


Another question:
During build (of the (older) rpm src packages only?), svn is necessary. Will 
svn.digium.com still be online?



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[Michael Maier]

On 18.05.23 at 20:29 George Joseph wrote:
On Thu, May 18, 2023 at 11:28 AM Michael Maier <mailto:m1278...@mailbox.org>> wrote:


Hello George,

On 18.05.23 at 19:04 George Joseph wrote:
 > We've sorted the announcement issue and you should have just gotten the
 > ones for the RCs.  Since they didn't go out on time, we'll hold off on
 > the GA releases until next Tuesday.

yes, I got them now. I'll take a look how the new tar files are working
here regarding my existing build process based on a RPM spec file.

I would be glad if there would be URLs to the corresponding git changes.
This would help to find the code changes belonging to each entry faster.


The issue I think is space.  Since the log has to be reasonably readable in plain 
text I'm not sure where we'd place the link without making it very busy.  I'm open 
to options though so could you maybe mock something up and post it back to the 
list so everyone can comment?


After some thought, I came to the conclusion, that your list gives a pretty good 
first impression and a classification of each change. That's enough for most of 
the use cases most probably.


If you need more information, it's best to do a git clone (respectively git pull 
afterwards) to search for the head lines in git log. If someone is interested in 
the patch, he can do a git show [sha1]. That's the way I do it from now on at least.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[Michael Maier]

On 18.05.23 at 20:58 Michael Maier wrote:

Hello George,

On 08.05.23 at 20:22 George Joseph wrote:

This is the first release after the GitHub migration so PLEASE
check all the release artifacts to make sure there are no surprises.


Building has been working fine for me - no surprises! Good job!
Functional test is pending.


So far no problems / "surprises" regarding my functional use cases. Looks good 
to me!


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[Michael Maier]

Hello George,

On 08.05.23 at 20:22 George Joseph wrote:

This is the first release after the GitHub migration so PLEASE
check all the release artifacts to make sure there are no surprises.


Building has been working fine for me - no surprises! Good job!
Functional test is pending.


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[Michael Maier]

Hello George,

On 18.05.23 at 19:04 George Joseph wrote:
We've sorted the announcement issue and you should have just gotten the 
ones for the RCs.  Since they didn't go out on time, we'll hold off on 
the GA releases until next Tuesday.


yes, I got them now. I'll take a look how the new tar files are working 
here regarding my existing build process based on a RPM spec file.


I would be glad if there would be URLs to the corresponding git changes. 
This would help to find the code changes belonging to each entry faster.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[Michael Maier]

On 08.05.23 at 20:22 George Joseph wrote:

This is the first release after the GitHub migration so PLEASE
check all the release artifacts to make sure there are no surprises.


I'm missing the "Asterisk ... now available mails"


Regards
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Using SIP TLS with Mediasec

[Michael Maier]

Hello Karsten,

attached you will find the patch for 18.16. The patch consists of 4 
files, which should be applied behind one another, starting with 1 
(patch -p1 ...). The first of the attached patches removes the new 
Mediasec patch.



Thanks
Michael


On 30.01.23 at 17:58 Karsten Wemheuer wrote:

Hi *,

I am currently testing Asterisk 18.16 with TLS and Mediasec. I am
testing it with Telekom CompanyFlex. The trunk registers and after a
while the request to re-register gets a "403 Forbidden".
I had previously used Asterisk 18.15 with the patch from Michael Maier.
That worked flawlessly.
Why are there two approaches to solving the "Mediasec" problem? What is
the obstacle that prevents to use the working patch from Michael Maier?

Thanks for clarification.

Have a nice day.

Karsten



mediasec-patch-18.16.0.tar.gz
Description: application/gzip
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Using SIP TLS with Mediasec

[Michael Maier]

Hello Karsten,

I can provide a working patch for 18.16 - if you like. Just give me a sign!

Thanks
Michael

On 30.01.23 at 17:58 Karsten Wemheuer wrote:

Hi *,

I am currently testing Asterisk 18.16 with TLS and Mediasec. I am
testing it with Telekom CompanyFlex. The trunk registers and after a
while the request to re-register gets a "403 Forbidden".
I had previously used Asterisk 18.15 with the patch from Michael Maier.
That worked flawlessly.
Why are there two approaches to solving the "Mediasec" problem? What is
the obstacle that prevents to use the working patch from Michael Maier?

Thanks for clarification.

Have a nice day.

Karsten





--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 21.12.22 at 16:53 Michael Maier wrote:

On 21.12.22 at 15:52 Fridrich Maximilian wrote:

I got it working now with [...]


That is excellent news!


I meanwhile sent Max some more information about missing things (like missing 
parameter information in pjsip show endpoint|registration and not working retry 
path (which breaks calls) among others).



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 21.12.22 at 15:52 Fridrich Maximilian wrote:

I got it working now with [...]


That is excellent news!


But the remaining useless headers in Invite should be removed before the 
final release.



I think this should be part of the documentation.


I'm not a maintainer but I think usually the documentation is kept
quite general without describing specific use cases. The docs for the
security_mechanisms parameter say "This is a comma-delimited list of
security mechanisms to use. Each security mechanism must be in the form
defined by RFC 3329 section 2.2." [1]. I think this should suffice.


Sorry - I wasn't able to derive the options string needed *for your 
implementation* based on RFC 3329 section 2.2. For me it wasn't obvious, 
that the ';mediasec' has to be added (I would have expected, that this 
is done automatically if the first parameter is set to mediasec 
(security_negotiation=mediasec))


security_mechanisms=msrp-tls\;mediasec,sdes-srtp\;mediasec,dtls-srtp\;mediasec

Therefore I still think this must be part of the documentation. What's 
wrong to provide an example for a (specific) use case? Why should it be 
secret? This way, users know, how the config option has to be used 
without long try and error to guess the correct syntax.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 21.12.22 at 09:17 Michael Maier wrote:

On 21.12.22 at 08:21 Fridrich Maximilian wrote:

Security-Client: sdes-srtp;mediasec
 ^
The ",mediasec" is missing.


Yes, the security_mechanisms option is a comma separated list of the
literal security_mechanisms that should be used. I.e. you have to
specify security_mechanisms=sdes-srtp\;mediasec,dtls-srtp\;mediasec
(don't forget to escape the semicolon).


I got it working now with (order has been important if I remember correctly)

security_mechanisms=msrp-tls\;mediasec,sdes-srtp\;mediasec,dtls-srtp\;mediasec

I think this should be part of the documentation.


But:
The Invite has to many headers - those are not needed (or is it Telekom 
specific?):

Security-Client: msrp-tls;mediasec
Security-Client: sdes-srtp;mediasec
Security-Client: dtls-srtp;mediasec

Maybe remove them?


Just detected some more eventually unneeded headers in Invite:

Require: mediasec
Proxy-Require: mediasec


Those three headers in Invite seem to be enough (besides the a=3ge2ae:requested in 
SDP) - couldn't see any problem during ~ 3 years until now.


Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 21.12.22 at 08:21 Fridrich Maximilian wrote:

Security-Client: sdes-srtp;mediasec
 ^
The ",mediasec" is missing.


Yes, the security_mechanisms option is a comma separated list of the
literal security_mechanisms that should be used. I.e. you have to
specify security_mechanisms=sdes-srtp\;mediasec,dtls-srtp\;mediasec
(don't forget to escape the semicolon).


I got it working now with (order has been important if I remember correctly)

security_mechanisms=msrp-tls\;mediasec,sdes-srtp\;mediasec,dtls-srtp\;mediasec

I think this should be part of the documentation.


But:
The Invite has to many headers - those are not needed (or is it Telekom 
specific?):

Security-Client: msrp-tls;mediasec
Security-Client: sdes-srtp;mediasec
Security-Client: dtls-srtp;mediasec

Maybe remove them?




always the first entry of the list configured above is dropped in
the following register request. Is this fixed by your mentioned patch
below?


I could not reproduce this behavior. I just tested it with the current
patch and no list entries were dropped.


Yes - the current version including your additional patch doesn't show this 
behavior any more.





I think the different headers are not addressed?


Do you mean the missing ";mediasec" values? That is due to the
configuration, as stated above. Besides that, I'm quite confident it
behaves as intended, we have been running test systems for quite a
while now.

I hope we can resolve your issues, it would certainly be desirable if
this patch worked for more than just very specific Telekom servers.


Yes - that would be very good! Please think about documentation using some 
practical examples to get a working connection!



I tested inbound and outbound calls. I did not test options and reInvite. Did you 
test reInvites?



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 20.12.22 at 17:10 Michael Maier wrote:

Hello Max,

On 20.12.22 at 11:29 Fridrich Maximilian wrote:

Please let me know, if you are still experiencing issues with the new
patch.


I think the different headers are not addressed?


Just tested it - doesn't work.

It is fine for me if you don't want to address the requirements of VoIP 
MagentaZuhause. But it would be good, I think, if you would add the information to 
the documents page, that this implementation is not a generic mediasec 
implementation, but a specific Telekom CompanyFlex one :-), which doesn't work 
with MagentaZuhause (or some others, too).


If I remember correctly, somebody told me my patch would have been working, too, 
with CompanyFlex - but I'm not sure any more. This could be wrong, too. It has 
been quite some time ago 



Thanks
Michael




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

Hello Max,

On 20.12.22 at 11:29 Fridrich Maximilian wrote:

Mr. Maier,


Michael :-)



thank you very much for your feedback! We provided this specifically
for Telekom's "CompanyFlex" trunks which still require mediasec headers
according to their website [1]. Specifically, we have to adhere to
their technical specification 1TR119 [2].


Well, for Telekom MagentaZuhause, the headers must look like this to work (there 
seems to be a difference to the CompanyFlex servers):


Security-Client: sdes-srtp;mediasec
  ^
The ",mediasec" is missing.

Further more, if you configure (id est: a list)
security_mechanisms=sdes-srtp,...
always the first entry of the list configured above is dropped in the following 
register request. Is this fixed by your mentioned patch below?


Example:
Request
Response 401
Request (now without first entry of the list)
Security-Client: ...




Does your patch work, too, if a server doesn't answer the Mediasec
request?


We set the Require: mediasec header, so if a server does not understand
this, it MUST respond with 420 Bad Extension.


The new consumer VoIP server just ignores it ...


Nonetheless, if you have
configured mediasec a server could ignore the mediasec headers and still
send 2XX replies to our requests. Since the mediasec headers are static
and no real security mechanism is negotiated anyways (all we need to do
is satisfy Telekom's requirements), we still allow further transactions
to take place (which is not how RFC 3329 intends it).


Same as I do :-)


However, it does
affect the SDP by setting the 3ge2ae attribute, even if the server never
sent us Security-Server headers.


[...]


I wasn't able to get it working. The headers you are setting
unfortunately doesn't meet the Deutsche Telekom requirements - besides
one additional bug.


Thank you for testing it! We have identified similar issues (see
ASTERISK-30276) and I just uploaded a patch fixing those [3]. I believe
this patch fixes the issues you are seeing. In our setup, it seems to
be working fine - including outgoing calls, re-registrations, and
OPTIONS.

Please let me know, if you are still experiencing issues with the new
patch.


I think the different headers are not addressed?


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 17.12.22 at 18:21 Michael Maier wrote:

On 15.12.22 at 14:39 Asterisk Development Team wrote:


# [ASTERISK-30032 <https://issues.asterisk.org/jira/browse/ASTERISK-30032>] -
    Support of mediasec SIP headers and SDP attributes
(Reported by Maximilian Fridrich)


Hi Maximilian,

today I tried your implementation with Deutsche Telekom (MagentaZuhause).

My configuration:
security_negotiation=mediasec
security_mechanisms=sdes-srtp(,dtls-srtp,msrp-tls)

for endpoint and registration.


I wasn't able to get it working. The headers you are setting unfortunately doesn't 
meet the Deutsche Telekom requirements - besides one additional bug.


If you compare it to my patch, you most probably will see the differences / the 
bug.

Please be careful as Deutsche Telekom not always responds with 494 during 
registration and even authorization during registration isn't always necessary 
(only sometimes)! You should have a close look over ~1 day and each reRegistration 
to be sure to get each possible procedure! Try to force reRegistrations with pjsip 
send register ... and carefully check the headers. Does it still work 1 hour later 
(in- and outbound calls)?


The registration implementation is not necessarily ok if the registration is fine 
(no error is thrown)! You must try to place an outgoing call e.g. - this call must 
work! At the moment, the registration proceeds, but outgoing calls are rejected 
(403 Forbidden). The cause is, that the registration wasn't correct and therefore 
srtp isn't possible - but Deutsche Telekom requires / enforces srtp if tls is active!


Here you can see how it should look like: 
https://www.ip-phone-forum.de/threads/telekom-all-ip-privat-endlich-erfolgreiche-registierung-ssl-tls-m%C3%B6glich.300166/page-3

(Meester Proper is a very good skilled employee of Deutsche Telekom)

Btw:
- Are Options packages working? Did you test this, too?
- I can provide my mediasec patch for 18.16.0-rc1 if you want to have it.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 15.12.22 at 14:39 Asterisk Development Team wrote:


# [ASTERISK-30032 ] -
Support of mediasec SIP headers and SDP attributes
(Reported by Maximilian Fridrich)


Hi Maximilian,
thanks for adding Mediasec support to asterisk! Unfortunately somewhat late - at 
least regarding Deutsche Telekom consumer infrastructure. Telekom started quite 
some time ago dropping the Mediasec requirement for their SIP servers. The new SIP 
servers like


[city]-l01-mav-pc-rt-001.edns.t-ipnet.de

don't need any Mediasec headers any more. Those servers are meanwhile often the 
primary ones provided by the SRV lookup (if they already exist for the location 
you are requesting for).


But the old ones, which are still provided currently with lower priority, still 
need it. Therefore it is necessary to enable Mediasec nevertheless to be able to 
change to them if necessary. Does your patch work, too, if a server doesn't answer 
the Mediasec request?




Another question:
Do you maybe plan to get asterisk ready to cope with 3 completely independent SIP 
servers provided by the SRV lookup? Currently, asterisk can't handle it (it must 
be ensured that all subsequent requests after the register must use the same 
server previously registered to and not any other server of the list. Before 
switching to another server, it's necessary to unregister the current active 
server and afterwards register to the new one).



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] pjsip: SDP port reuse timeout?

[Michael Maier]

Hello all!

I think I encountered a local sdp port problem (no audio after call setup), because the time delta between the previously ended call and the following new call (75 s) was too short to drop the previously used NAT conntrack (in case of a stream per default 120 s / 
nf_conntrack_udp_timeout_stream [1]), because unfortunately, the same local sdp port for the following new call was used (but a different remote sdp port).


If I got it correctly, rtp_allocate_transport() randomly finds new rtp ports 
based on the given port range - but it doesn't respect system based timeouts. 
Therefore, it seems to be possible, that a port is reused though it hasn't been 
timed out in conntrack, e.g.

How should this problem be handled to ensure, that a port isn't reused too fast 
(previously used rtp ports should be blocked for 
nf_conntrack_udp_timeout_stream e.g. until being reused)?


Thanks
Michael

[1] https://www.kernel.org/doc/html/latest/networking/nf_conntrack-sysctl.html

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.5.0-rc1 Now Available

[Michael Maier]

On 22.06.21 at 22:27 Joshua C. Colp wrote:
> On Tue, Jun 22, 2021 at 5:22 PM Michael Maier  wrote:
> 
>> Hi,
>>
>> I faced a problem today regarding a conference. One user wasn't able to
>> enter the conference - after / while entering the second digit of the
>> conference PIN, the call always was ended repeatedly by the callers
>> device (Q.850 cause 16). He tried about 5 times. On Asterisk side, I
>> never could see any dtmf logged.
>>
>> The exactly same call from the same device / phone number has been
>> working fine last Thursday w/ Asterisk 18.4.
>>
>> Unfortunately, I can't reproduce it with any other device here.
>>
>> I compared signaling from today with the working one - couldn't see any
>> difference. The RTP stream is not logged at all because of privacy and
>> it's encrypted anyway.
>>
>> I'm not sure if it's really an Asterisk problem - but it's somehow
>> suspicious. Do you by chance have any idea what could have been happened
>> here regarding your changes?
>>
> 
> Based on the list of changes there hasn't been anything in the area of
> DTMF. Without logs and RTP, it's not really possible to say.

Meanwhile I know, that the problem can't be on Asterisk side. The
previous version meanwhile shows the same behavior.

I believe they misconfigured their phones or there is a handling error.
Anyhow, I don't have any possibility to near down the problem as I don't
have any access to those devices.


Sorry for the noise
Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.5.0-rc1 Now Available

[Michael Maier]

Hi,

I faced a problem today regarding a conference. One user wasn't able to
enter the conference - after / while entering the second digit of the
conference PIN, the call always was ended repeatedly by the callers
device (Q.850 cause 16). He tried about 5 times. On Asterisk side, I
never could see any dtmf logged.

The exactly same call from the same device / phone number has been
working fine last Thursday w/ Asterisk 18.4.

Unfortunately, I can't reproduce it with any other device here.

I compared signaling from today with the working one - couldn't see any
difference. The RTP stream is not logged at all because of privacy and
it's encrypted anyway.

I'm not sure if it's really an Asterisk problem - but it's somehow
suspicious. Do you by chance have any idea what could have been happened
here regarding your changes?


Thanks
Michael


On 17.06.21 at 17:15 Asterisk Development Team wrote:
> The Asterisk Development Team would like to announce the first
> release candidate of Asterisk 18.5.0.
> This release candidate is available for immediate download at 
> https://downloads.asterisk.org/pub/telephony/asterisk
> 
> The release of Asterisk 18.5.0-rc1 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 candidate:
> 
> New Features made in this release:
> ---
>  * ASTERISK-29446 - app_confbridge: New ConfKick application
>
>   (Reported by N A)
>  * ASTERISK-29440 - app_confbridge: Allow ConfBridge answer to
>   be suppressed
>   (Reported by N A)
>  * ASTERISK-29431 - Minimum and maximum dialplan functions
>  
>   (Reported by N A)
>  * ASTERISK-29439 - func_volume: Volume function can't be read
>  
>   (Reported by N A)
> 
> Bugs fixed in this release:
> ---
>  * ASTERISK-29475 - SayNumber triggers WARNING if caller hangs
>   up during application execution
>   (Reported by N A)
>  * ASTERISK-29404 - Consolidate res_pjsip_messaging fixes for
>   domain name
>   (Reported by George Joseph)
>  * ASTERISK-29441 - Core reload making TCP endpoints go offline
> 
>   (Reported by Luke Escude)
>  * ASTERISK-28237 - "FRACK!, Failed assertion bad magic number"
>   happens when unsubscribe an application from an event source
>
>   (Reported by Lucas Tardioli Silveira)
>  * ASTERISK-28393 - Multidomain support issue
>   (Reported by
>   Andrea Sannucci)
>  * ASTERISK-29433 - res_rtp_asterisk: Server reflexive
>   candidates use incorrect raddr for RTCP
>   (Reported by
>   Chris)
>  * ASTERISK-29397 - pjsip: Asterisk isn't tolerant of RFC8760
>   UASs
>   (Reported by George Joseph)
>  * ASTERISK-24601 - [patch]Missing RFC4235 tags and attributes
>   in PJSIP NOTIFY event: dialog  XML body
>   (Reported by Marco
>   Paland)
>  * ASTERISK-29370 - chan_sip does not recognize
>   application/hook-flash
>   (Reported by N A)
>  * ASTERISK-29377 - cpool_release_pool "double free or
>   corruption (out)"
>   (Reported by Robert Sutton)
>  * ASTERISK-29372 - file.c switch does not account for flash
>   events
>   (Reported by N A)
>  * ASTERISK-29358 - chan_pjsip: Trace message for progress is
>   output even if frame is not queued
>   (Reported by Michael
>   Maier)
>  * ASTERISK-29407 - chan_local: Filtering audio formats should
>   not occur on removed streams
>   (Reported by Joshua C. Colp)
>  * ASTERISK-29030 - res_rtp_asterisk: Additional RTP-frame (with
>   wrong SSRC) gets inserted when switching from progress to
>   established
>   (Reported by Matthias Hensler)
> 
> Improvements made in this release:
> ---
>  * ASTERISK-29450 - Allow setting channel variables using
>   Originate application
>   (Reported by N A)
>  * ASTERISK-29459 - Missing configuration from PJSIP to SIP
>   conversion script
>   (Reported by N A)
>  * ASTERISK-29460 - Recognize application/hook-flash in PJSIP
>   
>   (Reported by N A)
>  * ASTERISK-29434 - Asterisk reveals pjproject version in STUN
>   packets
>   (Reported by Jeremy Lainé)
>  * ASTERISK-29349 - Silent voicemail option is not completely
>   silent
>   (Reported by N A)
>  * ASTERISK-29380 - Add Flash AMI event to handle flash events
>  
>   (Reported by N A)
> 
> For a full list of changes in this release candidate, please see the 
> ChangeLog:
> https://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-18.5.0-rc1
> 
> Thank you for your continued support of Asterisk!
> 
> 

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Feature request: Allow the use of pjsip client only transports in Asterisk pjsip

[Michael Maier]

Hello!

pjsip provides the ability to create (TCP / TLS) transports without opening any 
listener. This is handy if you don't need any listening transport at all for a 
sip device.

One of the typical use cases is for dial up environments where you just have to register to the VoIP provider on base of TCP or TLS. To register to an ISP using TCP or TLS, no listener is 
necessary at all. Having no listener greatly increases security, because you don't have any port which could be reached from arbitrary scanners in the Internet at all and which therefore 
doesn't need to be secured by other means (portfilter, fail2ban). It's just the correct way to do it like this from a security based view.


This allows, too, for easily separating internal networks and external networks by using two different networks on the Asterisk device, the internal providing the listener for the internal 
devices and the external net providing access to the VoIP ISP w/o any listener.


pjsip provides two CFLAGS which enables this feature to create client 
transports only by using PJSIP_TCP_TRANSPORT_DONT_CREATE_LISTENER and 
PJSIP_TLS_TRANSPORT_DONT_CREATE_LISTENER [1].

I know that it is working perfectly, because I already have a working patch for 
Asterisk which I will post here if you like.


Thanks
Michael


[1] https://pjsip.org/pjsip/docs/html/group__PJSIP__TRANSPORT__TLS.htm

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] supported: timers though deactivated

[Michael Maier]

Hello Joshua,

On 08.06.21 at 21:52 Joshua C. Colp wrote:
> I don't speak spec file but passing NOISY_BUILD=yes to make will generally
> output more information.

Yes, that NOISY_BUILD did the trick so I could find the problems. Now, I
could see, too, why they most probably are "beautifying" things. I think
I will open a bug - from my point of view, this is an systematic bug. I
don't want to know how many strange behaviors are the result of this
kind of "beautifying".


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] supported: timers though deactivated

[Michael Maier]

On 08.06.21 at 10:48 Joshua C. Colp wrote:
> On Mon, Jun 7, 2021 at 10:38 PM Michael Maier  wrote:
> 
>> On 06.06.21 at 22:19 Joshua C. Colp wrote:
>>> On Sun, Jun 6, 2021 at 3:57 PM Michael Maier 
>> wrote:
>>>
>>>> Hello!
>>>>
>>>> Using Asterisk 18.4 / pjisp, timers are advertised as supported though
>>>> disabled in config with timers=no.
>>>>
>>>> This does not happen initially (during the Invite sequence) but later on
>>>> in 200 Ok as answer to a reInvite or as the answer to an Update methode.
>>>>
>>>> Is there any reason why it's suddenly activated later on though it's
>>>> deactivated? From my point of view, this smells like a bug.
>>>>
>>>
>>> It'd be a bug in PJSIP itself, probably in the INVITE session[1] code>>> 
>>> that is what responsible for this.
>>
>> Thanks for your hint!
>>
>> They are using a function to clean up the supported header
>> (cleanup_allow_sup_hdr).
>>
>> Let's take a look at the creation of the 200 Ok answer of the received
>> update - I could find this path (there is no SDP in the received Update):
>>
>> inv_respond_incoming_update
>>  pjsip_dlg_create_response
>>  pjsip_endpt_create_response
>>  pjsip_msg_create
>>  pj_list_init
>>
>>  pjsip_timer_update_resp
>>  pjsip_dlg_send_response
>>
>> If I didn't oversee anything, I couldn't find the usage of
>> cleanup_allow_sup_hdr - but I couldn't find either where the supported
>> header should have been added. Do you have an idea?
>>
> 
> It's added to the global Supported header, which is added elsewhere to
> messages[1].

dlg_beautify_response - I've seen it before but didn't take a closer look 
because of its name "beautify".

My goal is now to add cleanup_allow_sup_hdr to pjsip_dlg_create_response after 
the response has been beautified ... .
I figured out, that cleanup_allow_sup_hdr needs inv->options to know about the 
configuration of an endpoint. Unfortunately, this parameter isn't put to 
pjsip_dlg_create_response.
Using the attached patch, I tried to do this, but I'm getting a compile error 
afterwards:

make --quiet --no-print-directory -C pjproject all
make --quiet --no-print-directory -C jansson all
echo '[jansson] ' Building bundled jansson.
(cd source; make >/dev/null 2>&1)
(cd source; make install DESTDIR= >/dev/null 2>&1)
echo '[pjproject] ' Compiling lib libpj-x86_64-unknown-linux-gnu.a
make -C 
/home/test/rpmbuild-asterisk/BUILD/asterisk-18.4.0/third-party/pjproject/source/pjlib//build
 libpj-x86_64-unknown-linux-gnu.a >/dev/null 2>&1
echo '[pjproject] ' Compiling lib libpjlib-util-x86_64-unknown-linux-gnu.a
make -C 
/home/test/rpmbuild-asterisk/BUILD/asterisk-18.4.0/third-party/pjproject/source/pjlib-util//build
 libpjlib-util-x86_64-unknown-linux-gnu.a >/dev/null 2>&1
make[2]: *** 
[/home/test/rpmbuild-asterisk/BUILD/asterisk-18.4.0/third-party/pjproject/source/pjlib-util/lib/libpjlib-util-x86_64-unknown-linux-gnu.a]
 Error 2
make[1]: *** [pjproject] Error 2
make: *** [third-party] Error 2

Unfortunately, this isn't very verbose. Do you have any idea how to get it more 
verbose or maybe what should I probably additionally do to get it compiling? 
This is based on the
bundled pjsip and the spec file of sangoma.


Thanks
Michael


beautify.tar.gz
Description: application/gzip
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] supported: timers though deactivated

[Michael Maier]

On 06.06.21 at 22:19 Joshua C. Colp wrote:

On Sun, Jun 6, 2021 at 3:57 PM Michael Maier  wrote:


Hello!

Using Asterisk 18.4 / pjisp, timers are advertised as supported though
disabled in config with timers=no.

This does not happen initially (during the Invite sequence) but later on
in 200 Ok as answer to a reInvite or as the answer to an Update methode.

Is there any reason why it's suddenly activated later on though it's
deactivated? From my point of view, this smells like a bug.



It'd be a bug in PJSIP itself, probably in the INVITE session[1] code as
that is what responsible for this.


Thanks for your hint!

They are using a function to clean up the supported header 
(cleanup_allow_sup_hdr).

Let's take a look at the creation of the 200 Ok answer of the received update - 
I could find this path (there is no SDP in the received Update):

inv_respond_incoming_update
pjsip_dlg_create_response
pjsip_endpt_create_response
pjsip_msg_create
pj_list_init

pjsip_timer_update_resp
pjsip_dlg_send_response

If I didn't oversee anything, I couldn't find the usage of 
cleanup_allow_sup_hdr - but I couldn't find either where the supported header 
should have been added. Do you have an idea?



Greetings
Micahel



[1]
https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_inv.c#L1819






--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] supported: timers though deactivated

[Michael Maier]

Hello!

Using Asterisk 18.4 / pjisp, timers are advertised as supported though disabled 
in config with timers=no.

This does not happen initially (during the Invite sequence) but later on in 200 
Ok as answer to a reInvite or as the answer to an Update methode.

Is there any reason why it's suddenly activated later on though it's 
deactivated? From my point of view, this smells like a bug.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk / pjsip: Request and example: increase security of a running asterisk instance

[Michael Maier]

Hi!

On 14.05.21 at 09:35 Michael Maier wrote:
> - f213833-rev-partial-transport-reload.diff
>   This patch reverts ASTERISK-29354 (came with 18.4), because it just doesn't 
> work (for me): After a "core reload", the defined values for 
> external_*_address aren't applied to any
> outgoing package any more.

The above reversal patch isn't needed any more since ASTERISK-29441.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip asterisk 13.24: sips / srtp and Deutsche Telekom doesn't work because of missing mediasec parameters

[Michael Maier]

On 21.10.19 at 17:23 Michael Maier wrote:

New patchset for Asterisk 18.4. As I don't use other versions of Asterisk any 
more, I don't have a patchset for those versions.


How should it all be used now?
If you want to use SIPS and SRTP with Deutsche Telekom AllIP, you have to be 
sure to enable the following features in the pjsip trunk (endpoint):

- transport: tls (TLS 1.2)
- enable SRTP for this trunk
- endpoint: support_mediasec=1
- registration: support_mediasec=1



If you are using FreePBX, you have to add the support_mediasec switches to
pjsip.endpoint_custom_post.conf and
pjsip.registration_custom_post.conf.

This is done like this:

File pjsip.endpoint_custom_post.conf:
[your name of the trunk](+type=endpoint)
support_mediasec=1

File pjsip.registration_custom_post.conf:
[your name of the trunk](+type=registration)
support_mediasec=true



Thanks
Regards
Michael




mediasec-18.4.tar.gz
Description: application/gzip
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Asterisk / pjsip: Request and example: increase security of a running asterisk instance

[Michael Maier]

Hello!

If you're currently running an asterisk instance, you are always forced to create a listener - even if you don't need it all. Therefore you are forced to "secure" this unnecessary listener 
port afterwards by other means. This shouldn't be the way to handle it.


A much better way to do it, is: just don't open listeners at all you don't 
need. Pjsip supports such a behavior.


What's the use case (one example):
You have a multihomed (or not - that doesn't matter) asterisk system, which on the one hand accepts registrations from devices on an internal network on tcp/5060 (-> listener transport needed) 
and acts as tls trunk for outbound registration (client transport needed - but no listener) on the other hand.


Attached is a working patch example (based on Asterisk 18.4), which shows the 
necessary different parts to achieve the desired behavior (tested).


A few words to the different patches:
- 73433a5-add-correct-port-to-sip-header.diff
  see https://issues.asterisk.org/jira/browse/ASTERISK-29241

- allow-port-0.diff
  This patch allows to use port 0 in the transport bind configuration

- nolistener.diff
  This patch enables Asterisk to use a new transport option "nolistener", which prevents creating a listener on starting the transport. Asterisk must be built using the compile time switch 
PJSIP_TCP_TRANSPORT_DONT_CREATE_LISTENER


- res_pjsip_nat.c.diff, res_pjsip_session.c.diff
  Those two patches are NAT related when using external_media_address= and external_signaling_address= parameters. They fix the problem, that not always the correct IP address is added to SIP 
header or SDP.


- f213833-rev-partial-transport-reload.diff
  This patch reverts ASTERISK-29354 (came with 18.4), because it just doesn't work (for me): After a "core reload", the defined values for external_*_address aren't applied to any outgoing 
package any more.



How to use it? That's an example how it should be used in the transport 
configuration:

[example-nat-tls-transport]
type=transport
protocol=tls
bind=192.168.13.24:0
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
method=tlsv1_2
verify_server=yes
allow_reload=no
external_media_address=external.host.com
external_signaling_address=external.host.com
local_net=192.168.0.0/16
nolistener=1


or an example for a traditional transport including listener:

[192.168.27.28-internal-tcp]
type=transport
protocol=tcp
bind=192.168.27.28
allow_reload=no


How to prove if it's working? Take a look at the pjsip.log. If you see entries 
like this, you see, that it's working:

Example example-nat-tls-transport
[2021-05-14 07:28:05] DEBUG[12836] pjproject:  tlstp:0 SIP TLS 
is ready (client only)

Example 192.168.27.28-internal-tcp
[2021-05-14 07:28:05] DEBUG[12836] pjproject:   tcptp:5060 SIP TCP 
is ready (client only)
[2021-05-14 07:28:05] DEBUG[12836] pjproject:   tcptp:5060 SIP TCP 
listener ready for incoming connections at 192.168.27.28:5060


Thanks
Michael


nolistener.tar.gz
Description: application/gzip
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Wrong IP-address in SDP when on NAT in challenged Invite

[Michael Maier]

On 07.05.21 at 00:12 Michael Maier wrote:

Hello Joshua,

On 06.05.21 at 20:21 Joshua C. Colp wrote:

On Wed, May 5, 2021 at 4:40 PM Michael Maier  wrote:


Hello!

When running asterisk on a system holding WAN and local IP, the IP used
for SDP in an outgoing call in the challenged INVITE is the local one
instead of the WAN IP when using a NATed transport instead of a
transport bound to the WAN IP.

The SDP in the initial INVITE is absolutely correct. But the following
Invite with the Auth header contains the wrong IP in SDP (the IP in the
SIP Contact and Via header are correct).

After digging in the code, I could see, that in
session_outgoing_nat_hook (res_pjsip_session.c) the nat rewrite is
stopped, because of an existing hook (I figured it out by some
additional debug outputs):

 /* SDP produced by us directly will never be multipart */
 if (!transport_state || hook || !tdata->msg->body ||

!ast_sip_is_content_type(>msg->body->content_type, "application",
"sdp") ||
 ast_strlen_zero(transport->external_media_address)) {
 return;
 }



[...]


The only thing that comes to mind is the code in
res/res_pjsip/pjsip_message_filter.c that alters the SDP in some scenario
to update it for the transport the message is going out on.


True - there is a dedicated function checking for multihomed
environments. Maybe this one changes back the IP (not tested though).
Meanwhile I modified the above check for aborting the nat rewrite this
way, that the check for an existing hook follows after the execution of
the NAT rewrite. Now, it's working.

Another question follows now, which is firewall related: At which point
exactly starts asterisk to send outgoing RTP?


Problem disappeared after restarting of asterisk. This happened quite often unfortunately, that restart solved strange behavior after doing reloads in consequence of doing changes in FreePBX - 
even if they are not transport related.


The DNAT rules are needed anyway, but now it's possible to add a established 
INPUT rule, so things are working as expected.

Finally I can say, that I got it working after applying two patches to 
correctly get NAT working on a multihomed server (including WAN IPv4):


res/res_pjsip_nat.c @find_transport_state_in_use

if (transport_state && ((details->transport && details->transport == 
transport_state->transport) ||
(details->factory && details->factory == 
transport_state->factory) ||
((details->type == transport_state->type) && (transport_state->factory) 
&&
!pj_strcmp(_state->factory->addr_name.host, 
>local_address) &&
-   transport_state->factory->addr_name.port == 
details->local_port))) {
+   (transport_state->factory->addr_name.port == 
details->local_port || transport_state->factory->addr_name.port == 0 {
return CMP_MATCH;
}

=> This ensures, that transports used as client can be found, too if they can't 
be directly found.

This patch solves the problem, that the ACK sent by asterisk after a received 
407 during INVITE sequence gets the correct IP in the Via header.


The second patch is needed to ensure, that the INVITE after the 407 containing 
the auth header gets the correct IP (= WAN) in the SDP:

res/res_pjsip_session.c session_outgoing_nat_hook(pj

/* SDP produced by us directly will never be multipart */
-   if (!transport_state || hook || !tdata->msg->body ||
+   if (!transport_state || !tdata->msg->body ||
!ast_sip_is_content_type(>msg->body->content_type, "application", 
"sdp") ||
ast_strlen_zero(transport->external_media_address)) {
return;
}


Move the check for the hook after executing the NAT functionality:

@@ -5492,6 +5512,12 @@ static void session_outgoing_nat_hook(pj
}
}

+   /* There is a hook - don't do it again */
+   if (hook) {
+   ast_debug(5, "stop - hook\n");
+   return;
+   }
+
for (stream = 0; stream < sdp->media_count; ++stream) {
/* See if there are registered handlers for this media stream 
type */
char media[20];


If there are others having problems during NAT they may try those patches. I know of at least one provider which doesn't care about those errors, but there are others which care and therefore 
calls are failing.


Some more information:
It's important to add to *all* transports the following parameters:

external_media_address=external.mydom.org
external_signaling_address=external.mydom.org
local_net=192.168.0.0/16 or whatever you need

I enabled dnsmgr, which should take care of always correct WAN IP via peri

Re: [asterisk-dev] Wrong IP-address in SDP when on NAT in challenged Invite

[Michael Maier]

Hello Joshua,

On 06.05.21 at 20:21 Joshua C. Colp wrote:
> On Wed, May 5, 2021 at 4:40 PM Michael Maier  wrote:
> 
>> Hello!
>>
>> When running asterisk on a system holding WAN and local IP, the IP used
>> for SDP in an outgoing call in the challenged INVITE is the local one
>> instead of the WAN IP when using a NATed transport instead of a
>> transport bound to the WAN IP.
>>
>> The SDP in the initial INVITE is absolutely correct. But the following
>> Invite with the Auth header contains the wrong IP in SDP (the IP in the
>> SIP Contact and Via header are correct).
>>
>> After digging in the code, I could see, that in
>> session_outgoing_nat_hook (res_pjsip_session.c) the nat rewrite is
>> stopped, because of an existing hook (I figured it out by some
>> additional debug outputs):
>>
>> /* SDP produced by us directly will never be multipart */
>> if (!transport_state || hook || !tdata->msg->body ||
>>
>> !ast_sip_is_content_type(>msg->body->content_type, "application",
>> "sdp") ||
>> ast_strlen_zero(transport->external_media_address)) {
>> return;
>> }
>>

[...]

> The only thing that comes to mind is the code in
> res/res_pjsip/pjsip_message_filter.c that alters the SDP in some scenario
> to update it for the transport the message is going out on.

True - there is a dedicated function checking for multihomed
environments. Maybe this one changes back the IP (not tested though).
Meanwhile I modified the above check for aborting the nat rewrite this
way, that the check for an existing hook follows after the execution of
the NAT rewrite. Now, it's working.

Another question follows now, which is firewall related: At which point
exactly starts asterisk to send outgoing RTP?

Why am I asking? Given is an outbound call e.g. Portfilter opens
incoming port as soon as it has seen an outgoing packet. If there is no
outgoing RTP, the incoming RTP packages will be dropped because
portfilter doesn't know what to do with them (no conntrack information
there).

After applying a DNAT-rule, things are working fine - but that's not a
good solution.

Now I'm wondering why asterisk doesn't always start sending RTP after a
200 OK sdp (or an any other arbitrary SDP) containing a=sendrecv and
correct media and dest port.

Sometimes asterisk begins to send RTP not until it receives RTP from
Callee - though the Caller already sends RTP - therefore there is no
reason to not send anything. I'm quite puzzled.

This behavior is 100% reproducible for certain numbers.


Do you by chance have any idea?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk / pjsip: control the SRV DNS response set with an option

[Michael Maier]

Hello George,

On 05.04.21 at 17:11 George Joseph wrote:

On Mon, Apr 5, 2021 at 7:38 AM George Joseph  wrote:




On Sat, Apr 3, 2021 at 12:09 AM Michael Maier 
wrote:



Hello!

As Asterisk doesn't care about destinations used for each request if
there is a
DNS SRV set given by the DNS resolution (more than one server in the
response) I
would like to shrink the used destinations received from DNS SRV query to
one
server (as the SRV list is unchanged since years now regarding German
Telekom).

I can do this like in the attached patch - but I didn't find any way so
far to
bring in a (new) option of transport configuration e.g. to this callback.
Isn't
there any way?



I think this would take a lot of investigation and a lot of work.  There
are several subsystems involved in the DNS resolution process...  the core
DNS stuff (main/dns*), the pjsip resolver callback, the
individual res_pjsip modules that want to do lookups, and pjproject
itself.  You'd have to find a way to pass the specific endpoint involved
through all of those subsystems.


Thanks for your estimation.


 However, I'm not sure that patch you
attached will actually do what you want, although I guess it depends on
what you wanted :) 


This patch just prevents adding more than one of the possible 3 SRV entries received from the lookup to be used by asterisk. This way, asterisk always has to use the same server, because there is only one (and always the same). I know - that's a workaround and not the final 
solution you described above. I would be already happy if it would be possible to add a configuration option to define which entry should be used (first, second or third). But I don't see any way to achieve it w/o massive changes.



By the time sip_resolve_callback is called, I _think_
all of the lookups have already been done and sip_resolve_callback is just
iterating over the results.  If your intention was to not do all the
lookups you may have even more work to do.


That's the result if you change the patch to always use the *second* entry:

[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:485 sip_resolve: 
Performing SIP DNS resolution of target 'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:512 sip_resolve: 
Transport type for target 'tel.t-online.de' is 'TLS transport'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:555 sip_resolve: 
[0x7fe32838d188] Created resolution tracking for target 'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:177 
sip_resolve_add: [0x7fe32838d188] Added target 'tel.t-online.de' with record 
type '35', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:177 
sip_resolve_add: [0x7fe32838d188] Added target '_sips._tcp.tel.t-online.de' 
with record type '33', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:177 
sip_resolve_add: [0x7fe32838d188] Added target 'tel.t-online.de' with record 
type '1', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:626 sip_resolve: 
[0x7fe32838d188] Starting initial resolution using parallel queries for target 
'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:278 
sip_resolve_callback: [0x7fe32838d188] All parallel queries completed
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:379 
sip_resolve_callback: [0x7fe32838d188] NAPTR record received on target 
'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:177 
sip_resolve_add: [0x7fe32838d188] Added target '_sips._tcp.tel.t-online.de' 
with record type '33', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:379 
sip_resolve_callback: [0x7fe32838d188] NAPTR record received on target 
'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:383 
sip_resolve_callback: [0x7fe32838d188] NAPTR record skipped because order '20' 
does not match strict order '10'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:379 
sip_resolve_callback: [0x7fe32838d188] NAPTR record received on target 
'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:383 
sip_resolve_callback: [0x7fe32838d188] NAPTR record skipped because order '30' 
does not match strict order '10'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:345 
sip_resolve_callback: [0x7fe32838d188] SRV record being skipped on target 
'_sips._tcp.tel.t-online.de' because NAPTR record exists
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:345 
sip_resolve_callback: [0x7fe32838d188] SRV record being skipped on target 
'_sips._tcp.tel.t-online.de' because NAPTR record exists
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:345 
sip_resolve_callback: [0x7fe32838d188] SRV record being skipped on target 
'_sips

Re: [asterisk-dev] Asterisk Community Services Coming Back Up

[Michael Maier]

On 09.04.21 at 00:37 Joshua Elson wrote:

Thank you all for all the work on this! Sounds like quite the effort and we
appreciate the investment in the community.


Yes. That's definitely true! I must emphasize this!



Not the biggest deal in the world, but does anyone else have interest in
moving get_mp3_source.sh off of svn.digium.com? This being down has caused
all my automated builds to fail since it went offline yesterday. Not
life-altering, but caused a little bit of a scramble.


It would be good to have it on github e.g. or on some other mirror. I am 
struggling, too, because I coudln't find any other source.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk Community Services Move

[Michael Maier]

On 07.04.21 at 15:57 Joshua C. Colp wrote:
> Greetings,
> 
> The Asterisk Community Services infrastructure (issues.asterisk.org,
> wiki.asterisk.org, gerrit.asterisk.org, crowd.asterisk.org, git.asterisk.org,
> downloads.asterisk.org, downloads.digium.com, signup.asterisk.org) is
> undergoing a physical move today which will result in them being down.

http://svn.digium.com seems to be down, too.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Asterisk / pjsip: control the SRV DNS response set with an option

[Michael Maier]

Hello!

As Asterisk doesn't care about destinations used for each request if there is a 
DNS SRV set given by the DNS resolution (more than one server in the response) I 
would like to shrink the used destinations received from DNS SRV query to one 
server (as the SRV list is unchanged since years now regarding German Telekom).


I can do this like in the attached patch - but I didn't find any way so far to 
bring in a (new) option of transport configuration e.g. to this callback. Isn't 
there any way?



Thanks for any hint.
Michael
--- 1/res/res_pjsip/pjsip_resolver.c	2021-03-11 18:23:06.0 +0100
+++ 2/res/res_pjsip/pjsip_resolver.c	2021-04-02 10:32:35.541203000 +0200
@@ -273,6 +273,7 @@ static void sip_resolve_callback(const s
 	int idx, address_count = 0, have_naptr = 0, have_srv = 0;
 	unsigned short order = 0;
 	int strict_order = 0;
+	unsigned short enoughSrvRecords = 0;
 
 	ast_debug(2, "[%p] All parallel queries completed\n", resolve);
 
@@ -347,6 +348,11 @@ static void sip_resolve_callback(const s
 
 /* SRV records just create new queries for +A, nothing fancy */
 ast_debug(2, "[%p] SRV record received on target '%s'\n", resolve, ast_dns_query_get_name(query));
+if (enoughSrvRecords) {
+	/* we prefer to have only one SRV record */
+	continue;
+	}
+enoughSrvRecords++;
 
 /* If an explicit IPv6 target transport has been requested look for only  records */
 if ((target->transport & PJSIP_TRANSPORT_IPV6) &&
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.3.0-rc1 Now Available

[Michael Maier]

On 11.03.21 at 20:04 Asterisk Development Team wrote:

The Asterisk Development Team would like to announce the first
release candidate of Asterisk 18.3.0.


I'm running this version based on pjsip (tls/udp/tcp) since it has been released 
w/o any problems so far (using a lot of additional patches as usual) - means: 
works for me.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Security Patches for third-party/patches: How to force a fresh build?

[Michael Maier]

On 18.03.21 at 17:09 Alexander Traud wrote:

Some folks might not download the whole Asterisk, apply their patches, and
build Asterisk but download just the last diff/patch, apply that, and re-build
Asterisk.

Those diffs/patches are available via 
 which is terrible

handy when you have many custom patches.

Now comes my concern. The last security fix included a patch for the bundled
PJ-Project (ASTERISK-29196). With that applied, the PJ-Project does not
re-build automatically. One has to touch
third-party/pjproject/patches/config_site.h for example, to trigger a fresh
build of the PJ-Project.

I am not sure everyone knows that. Those users have the latest version of
Asterisk but not of the PJ-Project. That is a headache for support. In this
case, they even face a security concern. I am thinking about changing one file
permission twice within the patch file. Any other idea?


You're probably right. But people seriously operating a phone environment 
(especially if they have (a lot of) own patches), should be very careful about 
their version management and how to easily revert to a known working version 
without loosing any data.


That's why I'm always building asterisk from scratch based on a carefully 
documented spec file. This ensures / provides:

- proper versioning
- documentation about changes and added (own) patches
- easy deployment
- easy fall back if problems occur with the new version
- reproducibility


Building asterisk nowadays each time from scratch in a clean environment shouldn't 
be any headache. I'm doing this on a VM in < 1 minute including rpm debuginfo package.


As a starting point, you can use the sangoma srpm e.g. and modify this one 
according your own requirements.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip advanced codec negotiation

[Michael Maier]

Hello Trevor,

unfortunately it's not yet implemented ... .

On 15.03.21 at 19:57 Trevor Peirce wrote:
> Hi All,
> 
> Trying to wrap my head around codec negotiation with Asterisk 18 when
> using PJSIP.  I'm not seeing the results that I expect.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip - retry handling - faulty warning message?

[Michael Maier]

Hello!

On 13.01.21 at 13:44 Michael Maier wrote:
> 
> On 19.12.20 at 21:10 Michael Maier wrote:
>> 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 be seen as long as there are all 3 numbers (re)-registered at
>> the same time (maybe chance).
>>
>> I could even find an example, where suddenly all numbers are registered
>> at the same time though they have been reregistered before serially (the
>> third number was 1:20 minutes before the other two numbers).
>> But suddenly, the third number was reregistered at the same time as the
>> other 2 numbers. Exactly at this moment, the faulty retries are
>> beginning. I think, there could be a problem to distinguish registration
>> more than two numbers to the same destination.
>>
>> At the moment now, they are registering at different times (ok, 2 at the
>> same time, but the 3. number is registered 3 seconds later). I couldn't
>> see any problem right now. I'll wait and see if this assumption can be
>> verified.
> 
> 
> After long time of debugging and testing, things seem to be clear now:

Meanwhile I could proof (on base of four transports to the same
destination), that the following configuration of an individual
transport for each used trunk ensures, that there are no more
(re)Registering problems - even if they are done at the same time:

[trunk1]
type=transport
protocol=tls
bind=0.0.0.0:0
 ^
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
method=tlsv1_2
verify_server=yes
allow_reload=no
tos=0xb8
cos=3

[trunkn]
type=transport
protocol=tls
bind=0.0.0.0:0
 ^
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
method=tlsv1_2
verify_server=yes
allow_reload=no
tos=0xb8
cos=3

=> That's a configuration for an encrypted SIP connection.

You can verify if it works correctly, by checking
netstat -n | grep 5061

If you get the same amount of connections as registered trunks,
configuration works as expected.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.2.0-rc1 Now Available

[Michael Maier]

On 14.01.21 at 18:48 Asterisk Development Team wrote:

The Asterisk Development Team would like to announce the first
release candidate of Asterisk 18.2.0.
This release candidate is available for immediate download at
https://downloads.asterisk.org/pub/telephony/asterisk

The release of Asterisk 18.2.0-rc1 resolves several issues reported by the
community and would have not been possible without your participation.


Works for me since 2021-01-14 22:57:40 CET w/o any problems.


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Michael Maier]

On 11.01.21 at 17:46 Michael Maier wrote:
> 
> On 11.01.21 at 15:27 Joshua C. Colp wrote:
>> On Mon, Jan 11, 2021 at 10:21 AM Michael Maier  wrote:
>>> It is possible to tcpkill the first connection without being restarted:
>>>
>>> # tcpkill -i eth0 tcp port 54761
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:    tlsc0x7fa1d82efae8 TLS
>>> connection closed
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:DISCONNECTED
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:   sip_transport.c
>>> Transport tlsc0x7fa1d82efae8 shutting down, force=0
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:SHUTDOWN
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:DESTROY
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:    tlsc0x7fa1d82efae8 TLS
>>> transport destroyed with reason 120104: Connection reset by peer
>>>
>>> If you're doing the same against Telekom, they drop the first connect
>>> after 10 s (therefore no tcpkill is necessary)
>>>
>>> Any idea why there are 2 connections started though only one is necessary?
>>> This is really odd.
>>>
>>
>> Nope. The code itself wasn't explicitly designed or written for this usage,
>> so there may be issues with it.
> 
> Sounds like a bug to me. Anyway, I found another solution to add n standard 
> transports listening all to no port (tested with Asterisk 18.0.1):

Some further investigation showed, that the first connection was killed by the 
provider if the Register fails. The ISP doesn't allow connections w/o a valid 
Register. They
are closed after 10s. This happens exactly just as with the old transports.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip asterisk 13.24: sips / srtp and Deutsche Telekom doesn't work because of missing mediasec parameters

[Michael Maier]

On 21.10.19 at 17:23 Michael Maier wrote:

Attached are actual patches for Asterisk 16.16.0-rc1, 18.0.1 and 18.2.0-rc1 (one 
patch for each version). Version 16.16.0-rc1 is only compile tested (16.14.x was 
the last asterisk 16 version I used myself). 18.2.0-rc1 is used here (as 18.1 and 
18.0.x, too).


All three patches contain a fix for the handling of 183 Session Progress w/o SDP, 
which is handled as 180 Ringing. Another fix handles 180 Ringing w/ SDP as 183 
Session Progress. You may remove them if you don't like them. They are not 
mediasec related. But they reflect "features" of Deutsche Telekom to be sure to 
get ring back and early media for my C610IP.



How should it all be used now?
If you want to use SIPS and SRTP with Deutsche Telekom AllIP, you have to be 
sure to enable the following features in the pjsip trunk (endpoint):

- transport: tls (TLS 1.2)
- enable SRTP for this trunk
- endpoint: support_mediasec=1
- registration: support_mediasec=1



If you are using FreePBX, you have to add the support_mediasec switches to
pjsip.endpoint_custom_post.conf and
pjsip.registration_custom_post.conf.

This is done like this:

File pjsip.endpoint_custom_post.conf:
[your name of the trunk](+type=endpoint)
support_mediasec=1

File pjsip.registration_custom_post.conf:
[your name of the trunk](+type=registration)
support_mediasec=true




Thanks
Michael


mediasec.tar.xz
Description: application/xz
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip - retry handling - faulty warning message?

[Michael Maier]

On 19.12.20 at 21:10 Michael Maier wrote:

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 be seen as long as there are all 3 numbers (re)-registered at
the same time (maybe chance).

I could even find an example, where suddenly all numbers are registered
at the same time though they have been reregistered before serially (the
third number was 1:20 minutes before the other two numbers).
But suddenly, the third number was reregistered at the same time as the
other 2 numbers. Exactly at this moment, the faulty retries are
beginning. I think, there could be a problem to distinguish registration
more than two numbers to the same destination.

At the moment now, they are registering at different times (ok, 2 at the
same time, but the 3. number is registered 3 seconds later). I couldn't
see any problem right now. I'll wait and see if this assumption can be
verified.



After long time of debugging and testing, things seem to be clear now:

Asterisk / pjsip doesn't like to process more than one Register in the same 
connection to the ISP. If they are not at the same time trying to reRegister, it 
*seems* to work - as long as there aren't any (network) problems coming up.


But this still isn't a good idea, because it turned out, that the ISP cancels a 
TCP connection after 10 seconds, if one of the numbers is unregistered (and 
therefore the remaining numbers handled on this connection are broken, too).



The solution is, to use for each registered number (= trunk / endpoint) an own 
transport. This seems to ensure, that each number is handled through an *own* TCP 
connection. You can add several "equal" transports, which only differ in their 
name (the listener port is always the same or even 0 instead of 5061, e.g. - but 
the configured listener port is never used, because you don't need any listener 
port as such for tcp registering to a trunk, because the complete signaling for in 
and outbound calls is handled through this "dedicated line" using a random local 
port from the beginning (= first Register) of the connection).



This night, by chance, there was a network problem reaching the ISP's server - and 
first time, I saw a correct retry handling! The 3 sent reRegisters for the 3 
numbers timed out (after ~30s) and were correctly retried 60s after the 
corresponding "No response received" warning. That's how it is supposed to work I 
think.


Hope that this is really the solution now.


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Michael Maier]

On 11.01.21 at 15:27 Joshua C. Colp wrote:

On Mon, Jan 11, 2021 at 10:21 AM Michael Maier  wrote:

It is possible to tcpkill the first connection without being restarted:

# tcpkill -i eth0 tcp port 54761
[2021-01-11 14:42:15] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8 TLS
connection closed
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
Reliable transport 'tlsc0x7fa1d82efae8' state:DISCONNECTED
[2021-01-11 14:42:15] DEBUG[8569] pjproject:   sip_transport.c
Transport tlsc0x7fa1d82efae8 shutting down, force=0
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
Reliable transport 'tlsc0x7fa1d82efae8' state:SHUTDOWN
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
Reliable transport 'tlsc0x7fa1d82efae8' state:DESTROY
[2021-01-11 14:42:15] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8 TLS
transport destroyed with reason 120104: Connection reset by peer

If you're doing the same against Telekom, they drop the first connect
after 10 s (therefore no tcpkill is necessary)

Any idea why there are 2 connections started though only one is necessary?
This is really odd.



Nope. The code itself wasn't explicitly designed or written for this usage,
so there may be issues with it.


Sounds like a bug to me. Anyway, I found another solution to add n standard 
transports listening all to no port (tested with Asterisk 18.0.1):

[estandard]
type=transport
protocol=tls
bind=0.0.0.0:0
 ^
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
method=tlsv1_2
verify_server=yes
allow_reload=no
tos=cs3
cos=3

[telekom1]
...

# netstat -tulpn | grep 5061
tcp0  0 0.0.0.0:50610.0.0.0:*   LISTEN  
11329/asterisk


CLI> pjsip show transports

Transport:  

==

Transport:  0.0.0.0-tls   tls  3184  0.0.0.0:5061
Transport:  0.0.0.0-udp   udp  3184  0.0.0.0:5060
Transport:  estandard tls  3 96  0.0.0.0:5061
Transport:  telekom1  tls  3 96  0.0.0.0:5061
Transport:  telekom2  tls  3 96  0.0.0.0:5061
Transport:  telekom3  tls  3 96  0.0.0.0:5061

Using the estandard transport for easybell works fine and doesn't start two 
connections to the ISP at startup.

Hope that works for my other trunks as expected.


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Michael Maier]

Hello!

I'm analyzing the transports opened by or for a Registration to an ISPs trunk. 
Here: transport type flow.

I can reproducibly see, that on Asterisk start up are always two connections 
created to register a trunk. The first one looks like this:

# grep "tlsc0x7fa1d82efae8" /var/log/asterisk/full
[2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d82efae8 TLS 
client transport created
[2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d82efae8 TLS 
transport 192.168.122.174:54761 is connecting to secure.sip.easybell.de:5061...
[2021-01-11 13:21:24] DEBUG[8569] res_pjsip/pjsip_transport_events.c: Reliable 
transport 'tlsc0x7fa1d82efae8' state:CONNECTED
[2021-01-11 13:21:24] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8 TLS 
transport 192.168.122.174:54761 is connected to secure.sip.easybell.de:5061

=> this one gets never used - you can see there only tls keep alives.

The second one is the one used:
# grep "tlsc0x7fa1d8324ec8" /var/log/asterisk/full
[2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d8324ec8 .TLS 
client transport created
[2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d8324ec8 .TLS 
transport 192.168.122.174:48650 is connecting to secure.sip.easybell.de:5061...
[2021-01-11 13:21:24] DEBUG[8569] res_pjsip/pjsip_transport_events.c: Reliable 
transport 'tlsc0x7fa1d8324ec8' state:CONNECTED
[2021-01-11 13:21:24] DEBUG[8569] pjproject:tlsc0x7fa1d8324ec8 TLS 
transport 192.168.122.174:48650 is connected to secure.sip.easybell.de:5061
[2021-01-11 13:21:24] DEBUG[8570] res_pjsip/pjsip_transport_events.c: 
Registered monitor 0x7fa219fca1cb(0x7fa1d8008fe8) to transport 
tlsc0x7fa1d8324ec8
[2021-01-11 13:22:44] DEBUG[8621] res_pjsip/pjsip_transport_events.c: 
Registered monitor 0x7fa219fca1cb(0x7fa1df08) to transport 
tlsc0x7fa1d8324ec8
[2021-01-11 13:24:04] DEBUG[8646] res_pjsip/pjsip_transport_events.c: 
Registered monitor 0x7fa219fca1cb(0x7fa1de78) to transport 
tlsc0x7fa1d8324ec8
[2021-01-11 13:25:24] DEBUG[8654] res_pjsip/pjsip_transport_events.c: 
Registered monitor 0x7fa219fca1cb(0x7fa1d0003558) to transport 
tlsc0x7fa1d8324ec8
[2021-01-11 13:26:44] DEBUG[8667] res_pjsip/pjsip_transport_events.c: 
Registered monitor 0x7fa219fca1cb(0x7fa1ded8) to transport 
tlsc0x7fa1d8324ec8
[2021-01-11 13:28:04] DEBUG[8674] res_pjsip/pjsip_transport_events.c: 
Registered monitor 0x7fa219fca1cb(0x7fa1d0001a28) to transport 
tlsc0x7fa1d8324ec8
[2021-01-11 13:29:24] DEBUG[8685] res_pjsip/pjsip_transport_events.c: 
Registered monitor 0x7fa219fca1cb(0x7fa1d0003498) to transport 
tlsc0x7fa1d8324ec8
[2021-01-11 13:30:44] DEBUG[8695] res_pjsip/pjsip_transport_events.c: 
Registered monitor 0x7fa219fca1cb(0x7fa1d0003228) to transport 
tlsc0x7fa1d8324ec8

It differs in the log output already at the beginning:
[2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d82efae8 TLS 
client transport created
vs
[2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d8324ec8 .TLS 
client transport created
   ^
What does this dot mean? Where is it coming from?

It is possible to tcpkill the first connection without being restarted:

# tcpkill -i eth0 tcp port 54761
[2021-01-11 14:42:15] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8 TLS 
connection closed
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c: Reliable 
transport 'tlsc0x7fa1d82efae8' state:DISCONNECTED
[2021-01-11 14:42:15] DEBUG[8569] pjproject:   sip_transport.c 
Transport tlsc0x7fa1d82efae8 shutting down, force=0
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c: Reliable 
transport 'tlsc0x7fa1d82efae8' state:SHUTDOWN
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c: Reliable 
transport 'tlsc0x7fa1d82efae8' state:DESTROY
[2021-01-11 14:42:15] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8 TLS 
transport destroyed with reason 120104: Connection reset by peer

If you're doing the same against Telekom, they drop the first connect after 10 
s (therefore no tcpkill is necessary)

Any idea why there are 2 connections started though only one is necessary? This 
is really odd.

Putting it all together of what can be seen in the logfile:
[2021-01-11 13:21:24] DEBUG[8570] res_pjsip_outbound_registration.c: Outbound 
REGISTER attempt 1 to 'sips:secure.sip.easybell.de' with client
'sips:004912345678...@secure.sip.easybell.de'
[2021-01-11 13:21:24] DEBUG[8570] res_pjsip/pjsip_resolver.c: Performing SIP 
DNS resolution of target 'secure.sip.easybell.de'
[2021-01-11 13:21:24] DEBUG[8570] res_pjsip/pjsip_resolver.c: Transport type 
for target 'secure.sip.easybell.de' is 'TLS transport'
[2021-01-11 13:21:24] DEBUG[8570] res_pjsip/pjsip_resolver.c: [0x7fa1d800cbb8] 
Created resolution tracking for target 'secure.sip.easybell.de'
[2021-01-11 13:21:24] DEBUG[8570] res_pjsip/pjsip_resolver.c: [0x7fa1d800cbb8] 
Added target 'secure.sip.easybell.de' with 

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Michael Maier]

On 10.01.21 at 22:18 Michael Maier wrote:

Aha, I remembered at the PJSIP level a feature[1] got added when the
Google Voice patch was done. It hasn't been exposed to be explicitly
configurable in Asterisk though.

[1]
https://www.pjsip.org/pjsip/docs/html/structpjsip__tpselector.htm#a1622f416d48eb173aed22b750aa28dfa



In fact the flow functionality[1] may get you closer to how you need
things. There was a bug though with it, so either 18 branch needs to be
used or this change[2] included.

[1]
https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L161
[2] https://gerrit.asterisk.org/c/asterisk/+/15256


The patch was vital!


Great! I'm testing it! I'll be back.


Yeah! That's cool.

myfw*CLI> pjsip show transports

Transport:  

==

Transport:  0.0.0.0-tls   tls  3184  0.0.0.0:5061
Transport:  0.0.0.0-udp   udp  3184  0.0.0.0:5060
Transport:  tflow-001 udp  3184  0.0.0.0:0
Transport:  tflow-002 udp  3184  0.0.0.0:0
Transport:  tflow-003 udp  3184  0.0.0.0:0

Besides the point that the type is not shown correctly - maybe use * or something else neutral, it's working as expected: no more useless listener ports and each trunk / number for 
ISP gets its own port and therefore connection. That was the goal.


But: as long as there where those other normal tls transports, the port in the VIA and CONTACT has been always 5062 - even if the flow transports have been used. That's odd. Now it's 
5061 (after those additional tls transports have been deleted) - not sure, where the 5061 is actually coming from :-). But most probably not from the correct source :-) - I think 
it's derived from 0.0.0.0-tls.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Michael Maier]

>> Aha, I remembered at the PJSIP level a feature[1] got added when the
>> Google Voice patch was done. It hasn't been exposed to be explicitly
>> configurable in Asterisk though.
>>
>> [1]
>> https://www.pjsip.org/pjsip/docs/html/structpjsip__tpselector.htm#a1622f416d48eb173aed22b750aa28dfa
>>
> 
> In fact the flow functionality[1] may get you closer to how you need
> things. There was a bug though with it, so either 18 branch needs to be
> used or this change[2] included.
> 
> [1]
> https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L161
> [2] https://gerrit.asterisk.org/c/asterisk/+/15256

Great! I'm testing it! I'll be back.

Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Michael Maier]

On 10.01.21 at 19:56 Joshua C. Colp wrote:
> On Sun, Jan 10, 2021 at 2:46 PM Michael Maier  wrote:
> 
>>
>> That's a pretty problematic behavior. ISPs (especially Deutsche Telekom
>> e.g.) want to tear down a tls connection if it isn't used any more (why
>> should a connection be hold active if
>> nobody uses it?). Therefore, after each unregister of a number, the
>> connection is teared down after 10s by ISP. Now, asterisk or probably
>> pjsip, reopens this connection again after
>> about 12s. Therefore, the ISP disconnects the connection automatically
>> after 30s again. And Asterisk reopens it again after 1 minute - and so on.
>> That's pretty broken.
>>
> 
> Without specific information or debug I can't really say why it would be
> doing that. The PJSIP layer should only open a new connection when a
> request is actually made. For example, if qualify is enabled then that
> would trigger a new connection as it establishes a connection to test
> viability. There is no ability to state "only ever attempt a connection
> when an outbound registration is being performed".

There is no other reason (the trunk was unregistered and the pcap trace
doesn't show any packet). And no asterisk log. The only log is from pjsip:

# netstat -n | grep 506
tcp0  0 3.2.1.5:42961   217.0.20.195:5061   ESTABLISHED
tcp0  0 3.2.1.5:54487   217.0.20.195:5061   ESTABLISHED
tcp0  0 3.2.1.5:41067   217.0.20.195:5061   ESTABLISHED
tcp0  0 3.2.1.5:60297   212.172.58.207:5061 ESTABLISHED


myfw*CLI> pjsip show registrations

 

==

 easybellPJSIP/sip:secure.sip.easybell.deeasybellPJSIP 
Registered
 telekomPJSIP-002/sip:tel.t-online.detelekomPJSIP-002  
Registered
 telekomPJSIP-003/sip:tel.t-online.detelekomPJSIP-003  
Registered
 telekomPJSIP-001/sip:tel.t-online.detelekomPJSIP-001  
Registered

Objects found: 4

myfw*CLI> pjsip send unregister telekomPJSIP-003
[2021-01-10 12:06:46] DEBUG[26143]: pjproject: :  sip_auth_client.c 
...Unable to set auth for tdta0x3761e18: can not find credential for 
tel.t-online.de/Digest

-- Connection is dropped by ISP
[2021-01-10 12:06:56] DEBUG[26142]: pjproject: :SSL 
6 [SSL_ERROR_ZERO_RETURN] (Read) ret: 0 len: 65535
[2021-01-10 12:06:56] DEBUG[26142]: pjproject: :  tlsc0x37d54e8 
TLS connection closed
[2021-01-10 12:06:56] DEBUG[26142]: pjproject: :sip_transport.c 
Transport tlsc0x37d54e8 shutting down, force=0
myfw*CLI> quit

[root@myfw mnt]# netstat -n | grep 506
tcp0  0 3.2.1.5:54487   217.0.20.195:5061   ESTABLISHED
tcp0  0 3.2.1.5:41067   217.0.20.195:5061   ESTABLISHED
tcp0  0 3.2.1.5:60297   212.172.58.207:5061 ESTABLISHED


# rasterisk
Asterisk 18.0.1, Copyright (C) 1999 - 2018, Digium, Inc. and others.
Created by Mark Spencer 
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for 
details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=
Connected to Asterisk 18.0.1 currently running on myfw (pid = 26097)

-> Connection is restarted by Asterisk or pjsip
[2021-01-10 12:07:08] DEBUG[26143]: pjproject: :tlsc0x3769578 
TLS client transport created
[2021-01-10 12:07:08] DEBUG[26143]: pjproject: :tlsc0x3769578 
TLS transport 3.2.1.5:52817 is connecting to tel.t-online.de:5061...
[2021-01-10 12:07:08] DEBUG[26142]: pjproject: :tlsc0x3769578 
TLS transport 3.2.1.5:52817 is connected to tel.t-online.de:5061

-> Connection is dropped again by ISP
[2021-01-10 12:07:38] DEBUG[26142]: pjproject: :SSL 
6 [SSL_ERROR_ZERO_RETURN] (Read) ret: 0 len: 65535
[2021-01-10 12:07:38] DEBUG[26142]: pjproject: :  tlsc0x3769578 
TLS connection closed
[2021-01-10 12:07:38] DEBUG[26142]: pjproject: :sip_transport.c 
Transport tlsc0x3769578 shutting down, force=0
[2021-01-10 12:07:38] DEBUG[26142]: pjproject: :  tlsc0x3769578 
TLS transport destroyed with reason 470006: EVP lib
myfw*CLI> pjsip show registrations

 

==

 easybellPJSIP/sip:secure.sip.easybell.deeasybellPJSIP 
Registered
 telekomPJSIP-002/sip:tel.t-online.detelekomPJSIP-002  
Registered
 telekomPJSIP-003/sip:tel.t-online.detelekomPJSIP-003  
Unregistered
 telekomPJSIP-

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Michael Maier]

On 09.01.21 at 11:37 Joshua C. Colp wrote:

On Sat, Jan 9, 2021 at 1:38 AM Michael Maier  wrote:



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

Objects found: 1


The related connection:
# netstat -n | grep 5061
tcp0  0 192.168.122.174:58709   212.172.58.207:5061
  ESTABLISHED

=> That's expected.


Now doing an unregister

pjsip send unregister *all

gives:

virtast*CLI> pjsip show registrations

   
  

==

   easybellPJSIP/sip:secure.sip.easybell.deeasybellPJSIP
Unregistered

Objects found: 1

So far so good.


But (even after hours - pjsip sends per default tcp/tls keep alives each
90 s):
# netstat -n | grep 5061
tcp0  0 192.168.122.174:58709   212.172.58.207:5061
  ESTABLISHED

=> That's not what I expect.

Shouldn't the connection been closed after the last trunk to a destination
has been closed (there could be more than one numbers / trunks use the same
destination / connection -
therefore this would have to be checked before).

What could be the use case to hold the connection forever even if it is
unused?


This behavior can be found with Asterisk 18.x (not tested with 16.x).



I believe PJSIP doesn't care or know whether there's anything currently
"active" over the connection, and thus it is kept open for when it may be
used again. To do otherwise and try to be intelligent is likely a ton of
work, which is probably why it was never done. From an Asterisk level we
don't really manage the connections and let PJSIP do it.


That's a pretty problematic behavior. ISPs (especially Deutsche Telekom e.g.) want to tear down a tls connection if it isn't used any more (why should a connection be hold active if 
nobody uses it?). Therefore, after each unregister of a number, the connection is teared down after 10s by ISP. Now, asterisk or probably pjsip, reopens this connection again after 
about 12s. Therefore, the ISP disconnects the connection automatically after 30s again. And Asterisk reopens it again after 1 minute - and so on. That's pretty broken.



Register multiple numbers to one destination (Asterisk 18.0.1)
--
If you register more than one number to the same destination, asterisk handles all registers through the same connection. This doesn't work (well) with all ISPs. Deutsche Telekom / 
AllIP e.g. supports it partly - means, you can register more than one number - but if you deregister one of it, the complete connection is dropped (because normally, they want to 
have for each register an own connection). Besides that, there are problems during reRegistration, if they are reRegistered all at the same time (if they are reRegistered serially, 
it's working - maybe Asterisk can't properly handle mutliple Registers to the same destination via same connection).


To work around this problem, that asterisk handles all Registers to one destination through the same connection, I added dedicated transports - for each trunk an own transport (each 
getting an own listener port). Therefore my transports now looks like:


myfw*CLI> pjsip show transports

Transport:  

==

Transport:  0.0.0.0-tls   tls  3184  0.0.0.0:5061
Transport:  0.0.0.0-tls2  tls  3184  0.0.0.0:5062
Transport:  0.0.0.0-tls3  tls  3184  0.0.0.0:5063
Transport:  0.0.0.0-udp   udp  3184  0.0.0.0:5060

I'm running 4 trunks - the following 2 as example for the next problem:

myfw*CLI> pjsip show registration telekomPJSIP-001

 

==

 telekomPJSIP-001/sip:tel.t-online.detelekomPJSIP-001  
Registered

 ParameterName: ParameterValue
 
 auth_rejection_permanent : true
 client_uri   : sip:+49...@tel.t-online.de
 contact_header_params:
 contact_user : +49...
 endpoint : telekomPJSIP-001
 expiration   : 660
 fatal_retry_interval : 0
 forbidden_retry_interval : 10
 line : true
 max_retries  : 1
 outbound_auth: telekomPJSIP-001
 outbound_proxy   :
 retry_interval   : 60
 server_uri   : sip:tel.t-online.de
 support_mediasec : true
 support_outbound : no
 support_path : false
 transport: 0.0.0.0-tls


myfw*

[asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Michael Maier]

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

Objects found: 1


The related connection:
# netstat -n | grep 5061
tcp0  0 192.168.122.174:58709   212.172.58.207:5061 ESTABLISHED

=> That's expected.


Now doing an unregister

pjsip send unregister *all

gives:

virtast*CLI> pjsip show registrations

 

==

 easybellPJSIP/sip:secure.sip.easybell.deeasybellPJSIP 
Unregistered

Objects found: 1

So far so good.


But (even after hours - pjsip sends per default tcp/tls keep alives each 90 s):
# netstat -n | grep 5061
tcp0  0 192.168.122.174:58709   212.172.58.207:5061 ESTABLISHED

=> That's not what I expect.

Shouldn't the connection been closed after the last trunk to a destination has been closed (there could be more than one numbers / trunks use the same destination / connection - 
therefore this would have to be checked before).


What could be the use case to hold the connection forever even if it is unused?


This behavior can be found with Asterisk 18.x (not tested with 16.x).


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip - retry handling - faulty warning message?

[Michael Maier]

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 be seen as long as there are all 3 numbers (re)-registered at
the same time (maybe chance).

I could even find an example, where suddenly all numbers are registered
at the same time though they have been reregistered before serially (the
third number was 1:20 minutes before the other two numbers).
But suddenly, the third number was reregistered at the same time as the
other 2 numbers. Exactly at this moment, the faulty retries are
beginning. I think, there could be a problem to distinguish registration
more than two numbers to the same destination.

At the moment now, they are registering at different times (ok, 2 at the
same time, but the 3. number is registered 3 seconds later). I couldn't
see any problem right now. I'll wait and see if this assumption can be
verified.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip - retry handling - faulty warning message?

[Michael Maier]

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 get sometime the opportunity to trace it down.




Ok, the last few days now, it happened quite often. I could see pretty often (5 or  more times a day) retries(!) even after 0.02 seconds. But not always. Sometimes, they don't occur 
even after 0.1s!



Therefore, I switched on debugging and verbose output now (each level 5). What happened? No more problem now since one day ... - though there were really enough cases where the delta 
of the answer has been slow enough to trigger a faulty resend.


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)?

Strange.


Regards
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Problem with SDP session id in 200 OK during ReInvite

[Michael Maier]

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 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 description has changed (the session
>> description has changed).
>>
>> Modifying the SDP session ID is possible in
>> res/res_pjsip/pjsip_message_filter.c / filter_on_tx_message() for SDPs
>> contained in an Invite, which is created and sent by asterisk.
>> At the moment, I'm already modifying the SDP session ID at this place,
>> because of another problem:
>>
> 
> 
> 
> 
>> Maybe it's too late and the processing of the 200 OK doesn't hit this part
>> at all?
>>
>> Or is there any other possibility to modify the SDP session ID contained
>> in the 200 OK, that is sent by asterisk as an answer to a ReInvite?
>>
> 
> It should be modifiable there, it injects itself at the transaction layer
> to be called for both requests and responses. I'm not sure under what
> scenarios (if any) it would not be called.

thanks for your estimation! Meanwhile, I hope I have found the problem now. I 
changed my workaround to always statically modify the SDP session id (the 
condition seemed to be the
problem). But tests are going on.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Problem with SDP session id in 200 OK during ReInvite

[Michael Maier]

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 description has changed (the session description has 
changed).

Modifying the SDP session ID is possible in 
res/res_pjsip/pjsip_message_filter.c / filter_on_tx_message() for SDPs 
contained in an Invite, which is created and sent by asterisk.
At the moment, I'm already modifying the SDP session ID at this place, because 
of another problem:

--- asterisk-16.5.0/res/res_pjsip/pjsip_message_filter.c2019-04-04 
16:49:57.0 +0200
+++ asterisk-16.5.0/res/res_pjsip/pjsip_message_filter.c2019-06-18 
14:46:57.78400 +0200
@@ -340,6 +340,23 @@
}
}

+   /* set new sdp version */
+   ast_debug(5, "increment SDP version, starting from 
%x\n",sdp->origin.version);
+   time_t sec;
+   time_t cseqt=1;
+   sec = time(NULL);
+   cseq = pjsip_msg_find_hdr(tdata->msg, PJSIP_H_CSEQ, NULL);
+   if (cseq) {
+   cseqt=cseq->cseq;
+   }
+   if (sec + cseqt <= sdp->origin.version) {
+   /* actual time can be same if sdp is generated more often 
than once a second */
+   sdp->origin.version = sec + cseqt + (sdp->origin.version - 
(sec + cseqt)) + 1;
+   }
+   else {
+   sdp->origin.version=sec + cseqt;
+   }
+
pjsip_tx_data_invalidate_msg(tdata);
}

Maybe it's too late and the processing of the 200 OK doesn't hit this part at 
all?

Or is there any other possibility to modify the SDP session ID contained in the 
200 OK, that is sent by asterisk as an answer to a ReInvite?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip / asterisk 16: Question regarding 100rel / PRACK

[Michael Maier]

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 Asterisk side,
>> which is reused later on by the provider for the update (in this example)?
>> Probably it shouldn't harm - but
>> could this for some devices be nevertheless a problem? For now, I disabled
>> 100rel support on Asterisk trunk side (it was on by default). Let's wait
>> and see what happens ... .
>>
> 
> Purely from a sequence number perspective there is a local sequence number
> and remote sequence number, they are independent and could conceivably
> match up at times but that by itself should not cause an issue within the
> specification itself. I can't speak towards any issues or assumptions
> within the SIP implementation of the remote side though.

You're right - it happened again meanwhile w/o PRACK being enabled.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] pjsip / asterisk 16: Question regarding 100rel / PRACK

[Michael Maier]

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 26380 PRACK / RAck 2 26379
4. Provider sends 200 OK / CSeq 26380 PRACK

5. Provider sends 200 OK / CSeq 26379 INVITE
6. Asterisk sends ACK / CSeq 26379 ACK


900s later

7. Provider sends Update / CSeq 26380 UPDATE
8. Asterisk sends 200 OK / CSeq 26380 UPDATE

9. Provider sends ReInvite / CSeq 26381 INVITE
10. Asterisk sends 200 OK / CSeq 26381 INVITE
11. Provider sends ACK / CSeq 26381 ACK (without any *supported* headers)

12. Provider sends BYE
=> call is unexpectedly ended by the provider.


If it's working as expected, all steps are the same as above, but step 11 
contains the supported headers and call proceeds.

Strange: There are two outgoing calls to exactly the same destination. The 
first call drops after 900s - the second call (restarted directly after the 
first call has been dropped)
works as expected.


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 Asterisk side, 
which is reused later on by the provider for the update (in this example)? 
Probably it shouldn't harm - but
could this for some devices be nevertheless a problem? For now, I disabled 
100rel support on Asterisk trunk side (it was on by default). Let's wait and 
see what happens ... .


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16.14.0-rc1 Now Available

[Michael Maier]

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:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16.14.0-rc1 Now Available

[Michael Maier]

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 :-)

Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip and timers configuration

[Michael Maier]

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:
>>
>> ___
>> timers
>>
>> no
>> yes
>> required
>> always
>> forced - Alias of always
>> ___
>>
>>
> Timers support is 100% PJSIP[1][2], so my own experience with it and the
> implementation is extremely limited - as will likely be the rest of people.
> 
> 
>>
>> I'm wondering about their meanings.
>>
>> - "No" seems to be clear. No timers support at all.
>>
>> - "Always"? I have no idea. Therefore I tested it. I couldn't find any
>> timers support mentioned in INVITE or 200 OK at all.
>>
>> - "Required"? Same as "yes" - the only difference was the timer:require in
>> asterisk's outbound Invite.
>>
>>
>> Is this the expected behavior, especially regarding "always"?
>>
> 
> Looking at the code the use of "always" means that even if the remote side
> has not accepted it or negotiated it, it is still enabled on the session
> from the perspective of PJSIP so it is supposed to generate session
> refreshes.

I couldn't see any advertised timer support regarding the option "always" in an 
Invite or elsewhere. According your explanation, this would mean, that asterisk 
would just do an
Update each Min-SE seconds e.g.? I did not test this obviously.

> The use of "required" means that if the remote side does not support the
> timer extension it is supposed to reject the call as a result of extension
> negotiation.
> 
> 
>>
>>
>>
>> Another question:
>> I can see here the following (with timer=yes):
>> On *outbound* calls, the provider says in 200 ok: refresher is uas (means:
>> provider). The first refresh coming in as update, the provider says:
>> refresher is uac (that would be
>> asterisk) and asterisk acks it in the 200 ok. But the provider does send
>> all following updates (always with uac as refresher). Asterisk itself
>> doesn't send any update (I would expect
>> it - or is asterisk just not fast enough and provider is always faster?
>> Min-SE is 900 and Session-Expires is 1800 - updates from provider are
>> coming exactly each 900 s).
>>
> 
> Looking at the RFC[3] it appears as though this is fine. Within the scope
> of a session refresh initiated by the provider it is the UAC and Asterisk
> is the UAS:
> 
>The UAC MAY include the refresher parameter with value 'uac' if it
>wants to perform the refreshes.  However, it is RECOMMENDED that the
>parameter be omitted so that it can be selected by the negotiation
>mechanisms described below.
> 
> 
> 
>> Is this the expected behavior?
>> I can't see this behavior on inbound calls. Here, refresher in 200 ok and
>> following updates doesn't differ.
>>
> 
>  According to things this is expected. For an inbound call without further
> detail I can't really say.

According your description above, it is ok, because: on an inbound call (as 
seen by asterisk), the providor is uac (and asterisk uas). As the provider 
anounces itself as refresher,
it is at the same time uac for the sip call and the device starting the 
refreshs. On an outbound call (as seen by asterisk), the provider is uas for 
the SIP call and uac as performer
of the refreshes. That's why it "differs" here.


Thanks
Michael


> 
> [1]
> https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_inv.c
> [2]
> https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_timer.c
> [3] https://tools.ietf.org/html/rfc4028

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip and timers configuration

[Michael Maier]

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
> always
> forced - Alias of always
> ___
> 

I tested with asterisk 16.13.0 and bundled pjsip.

> 
> I'm wondering about their meanings.
> 
> - "No" seems to be clear. No timers support at all.
> 
> - "Always"? I have no idea. Therefore I tested it. I couldn't find any timers 
> support mentioned in INVITE or 200 OK at all.

- "Always" behaves like "no"

> 
> - "Required"? Same as "yes" - the only difference was the timer:require in 
> asterisk's outbound Invite.

All given options are reflected in pjsip show endpoint endpointname

> 
> 
> Is this the expected behavior, especially regarding "always"?
> 
> 
> 
> Another question:
> I can see here the following (with timer=yes):
> On *outbound* calls, the provider says in 200 ok: refresher is uas (means: 
> provider). The first refresh coming in as update, the provider says: 
> refresher is uac (that would be
> asterisk) and asterisk acks it in the 200 ok. But the provider does send all 
> following updates (always with uac as refresher). Asterisk itself doesn't 
> send any update (I would expect
> it - or is asterisk just not fast enough and provider is always faster? 
> Min-SE is 900 and Session-Expires is 1800 - updates from provider are coming 
> exactly each 900 s).
> 
> Is this the expected behavior?
> I can't see this behavior on inbound calls. Here, refresher in 200 ok and 
> following updates doesn't differ.

Sorry, one more question:
If set to yes (=default) asterisk always gives the refresher to the caller in 
inbound call. Is there any possibility to say asterisk to do the refreshing by 
its own?

> 
> 
> Thanks
> Michael
> 
> 
> 
> [1] 
> https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+Configuration_res_pjsip#Asterisk17Configuration_res_pjsip-endpoint_timers

Documentation is the same for asterisk 16.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] pjsip and timers configuration

[Michael Maier]

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 wondering about their meanings.

- "No" seems to be clear. No timers support at all.

- "Always"? I have no idea. Therefore I tested it. I couldn't find any timers 
support mentioned in INVITE or 200 OK at all.

- "Required"? Same as "yes" - the only difference was the timer:require in 
asterisk's outbound Invite.


Is this the expected behavior, especially regarding "always"?



Another question:
I can see here the following (with timer=yes):
On *outbound* calls, the provider says in 200 ok: refresher is uas (means: 
provider). The first refresh coming in as update, the provider says: refresher 
is uac (that would be
asterisk) and asterisk acks it in the 200 ok. But the provider does send all 
following updates (always with uac as refresher). Asterisk itself doesn't send 
any update (I would expect
it - or is asterisk just not fast enough and provider is always faster? Min-SE 
is 900 and Session-Expires is 1800 - updates from provider are coming exactly 
each 900 s).

Is this the expected behavior?
I can't see this behavior on inbound calls. Here, refresher in 200 ok and 
following updates doesn't differ.


Thanks
Michael



[1] 
https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+Configuration_res_pjsip#Asterisk17Configuration_res_pjsip-endpoint_timers

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] EVS codec for Asterisk 16

[Michael Maier]

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-vdso.so.1 =>  (0x7ffc4034e000)
lib3gpp-evs.so => /lib64/lib3gpp-evs.so (0x7fedadb2)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7fedad904000)
libc.so.6 => /lib64/libc.so.6 (0x7fedad536000)
/lib64/ld-linux-x86-64.so.2 (0x7fedae118000)

[root@myast ~]# ldd /usr/lib64/asterisk/modules/codec_amr.so
linux-vdso.so.1 =>  (0x7fff96bc9000)
libopencore-amrnb.so.0 => /lib64/libopencore-amrnb.so.0 
(0x7fa96835a000)
libopencore-amrwb.so.0 => /lib64/libopencore-amrwb.so.0 
(0x7fa968146000)
libvo-amrwbenc.so.0 => /lib64/libvo-amrwbenc.so.0 (0x7fa967f2c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7fa967d1)
libc.so.6 => /lib64/libc.so.6 (0x7fa967942000)
libm.so.6 => /lib64/libm.so.6 (0x7fa96764)
/lib64/ld-linux-x86-64.so.2 (0x7fa968789000)


> 2) Which version/variant of Asterisk do you use?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Support for amr codec?

[Michael Maier]

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 
> already. Consequently, no additional support in Asterisk is required. My 
> patch can be changed to enable Voice Activity Detection (VAD) in the encoder. 
> Then, the patch does Discontinuous Transmission (DTX) automatically: 
> /res/res_format_attr_amr.c:amr_clone set attr->vad = 1.
> Although optional, VAD/DTX/CN are tested scenarios since Nov. 2016.
> 
>> Samsung S20
> 
> Puh. Are you using my patch? There is a software bug in Comfort Noise, when 
> you use an *old* version of the OpenCORE-AMR library [1]. Only AMR-WB. Only 
> decoding. This gets solved by patching your library or by using version 0.1.5 
> of OpenCORE-AMR. That version is included in Ubuntu 20.04 LTS already. For 
> Debian, you have to go wait for Debian 11 (Bullseye).
> 
> If you use my patch, the latest library, and still face any issue with 
> Comfort Noise, please, please, please, create an issue report on my GitHub 
> (or talk to me privately). For example, which firmware variant you use on 
> your Samsung S20. Software bugs hate to be tracked down and I hate software 
> bugs.

After reviewing the sip (only!) traces, I found an inbound call, which was 
answered by my wife. The caller was on Vodafone IMS and we are on Deutsche 
Telekom / landline (SVDSL). The
call leg from Telekom to asterisk was AMR-WB and from asterisk to C610IP 
(Gigaset) was G722 (-> transcoding).
I asked her, if she noticed anything during this 45 min call. She stated, that 
this call would have been brilliant regarding call quality - especially taking 
into account, that it's
been a mobile call :-). She didn't realize any distortions. (There have been no 
codec changes during the call.)

Just to say, that things seem to work pretty good! There is a high WAF :-)


One more thing: There was an interesting codec negotiation at the startup of 
the call.
At the moment, I adjusted G722/G711/AMR-WB/AMR (which was the answer in 200 OK 
to Telekom and which would have meant G722).
Promptly I got a reInvite to use AMR-WB (which was acked by asterisk).

The Invite from Telekom was:
AMR-WB/16000 fmtp:96 mode-set=0,1,2; mode-change-period=2; 
mode-change-neighbor=1; max-red=0
AMR-WB/16000 fmtp:97 mode-change-capability=2; max-red=0
G722
G711

The acked codec after reInvite:
AMR-WB/16000 fmtp:96 
mode-set=0,1,2;mode-change-period=2;mode-change-neighbor=1;max-red=0

Well, I'm thinking about reordering codecs to AMR-WB,AMR,G722,G711 ... .


BTW: this call (as each call here) was encrypted using the mediasec patch.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip - retry handling - faulty warning message?

[Michael Maier]

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 unclear who's doing the retry, us or pjproject.


BTW: I'm using TCP - not UDP.


 It's
odd that either one of us would wait only 27ms before retrying a request
though.   As Josh says below, the debug stuff would be needed for further
analysis.


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 get 
sometime the opportunity to trace it down.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] EVS codec for Asterisk 16

[Michael Maier]

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

At first, you have to build the lib3gpp-evs library with
rpmbuild -ba lib3gpp-evs.spec

This creates 4 packages: a src, a devel and the library package itself and the 
corresponding debuginfo package.
On the machine, you are building Asterisk at next, you have to install the 
library and the devel package. On the machine Asterisk runs, you only need the 
library package.

To build Asterisk, you have to apply the evs-asterisk.16.patch (which contains 
all changes necessary in one patch file as described at [1] - the patch here 
wants to have this
patch[2] already applied before). Any further information how to build Asterisk 
after the patch file has been applied can be found here[1].

If all went fine, there are at the end two more modules in 
/usr/lib64/asterisk/modules:
codec_evs.so
res_format_attr_evs.so

After restarting of Asterisk, you can check if everything went fine by:

asterisk -r
core show codecs
(-> evs must be part of the list)

core show translation
(evs must be part of the list)

After adding the codec to be allowed for a trunk, you may test it - I couldn't 
test it so far, because I didn't have any device using the evs codec.


Thanks
Michael


[1] https://github.com/traud/asterisk-evs
[2] https://www.mail-archive.com/asterisk-dev@lists.digium.com/msg45213.html


evs-asterisk-16.tar.gz
Description: application/gzip
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Support for amr codec?

[Michael Maier]

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 (VAD) in the encoder.


I can hear the distortions on the other side (on the G711 side), therefore I think it's a problem of the decoder during 
transcoding amr -> g711.


[...]


few small changes to get the patches applied


Same here. If you have an issue, report it.


That wasn't a problem of the code by itself. The patch just has to be adjusted to Asterisk 16.x additional code lines - 
no trouble at all.





Is there a must have to support amr (with Deutsche Telekom)?


Deutsche Telekom does the transcoding for you. Chapter 4.2.4.1 in



There are people out there, fearing that Deutsche Telekom could just drop the transcoding w/o any regard to their own 
defined interfaces. Therefore I tested your patches from idle curiosity.



any problems with the use of amr and asterisk


AMR, AMR-WB and 3GPP-EVS are yet another example to unveil the limitations of 
the SDP media negotiations in Asterisk. This is discussed in GitHub issue #10 
and at the remainder of issue #8. I have yet to understand issue #5 in 3GPP-EVS 
whether the bug is mine. Anyway, I am happy that I reached that far as I had to 
patch a lot within Asterisk already. But it looks like it is time to leave.


I think it wouldn't be a good idea to leave. Asterisk 18 most probably will have an exciting big change in handling of 
SDP negotiations. One goal is to reduce unnecessary transcodings. But only for pjsip.
See the subjects "Asterisk 18 Planning: Codec Negotiation" and subjects containing "Advanced Codec Negotiation" here in 
the mailing list.


Here you can find some initial documentation [1]


Thanks
Michael

[1] https://wiki.asterisk.org/wiki/display/AST/Codec+Negotiation

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Support for amr codec?

[Michael Maier]

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 end up with some distorted noise.

Well, during my tests I in fact noticed some more or less silent distortions 
which may be caused by comfort noise generated by the mobile(?) (it's only from 
mobile -> local phone -
not vice versa). For me it sounds like a pretty silent steam engine.

I tested with amr and amr-wb in conjunction with transcoding (as I'm having no 
local phone supporting amr. Transcoding was between g722 or g711). Therefore I 
can't say for sure if
this distortion is a result of transcoding or not. I could here it with two 
different mobiles (iPhone and Huawei). After muting of the iPhone, the 
distortion mostly went away (no
change with the Huawei mobile).


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Support for amr codec?

[Michael Maier]

Hello!

Thanks Joshua for your replay.

I tried to apply this patch here https://github.com/traud/asterisk-amr to 
asterisk 16. It's working fine for me after a few small changes to get the 
patches applied. For convenience,
I built one single patch file (I attached it), which can be applied with

patch -p1 amr-asterisk-16.12.patch

to asterisk 16.12.



To get it compile and working, you need (for CentOS 7) the following additional 
RPM packages:

vo-amrwbenc-0.1.3-1.el7.x86_64.rpm
vo-amrwbenc-devel-0.1.3-1.el7.x86_64 (only for compile)

opencore-amr-0.1.5-6.el7.x86_64.rpm
opencore-amr-devel-0.1.5-6.el7.x86_64.rpm (only for compile)

You can find them here: https://centos.pkgs.org/7/rpmfusion-free-updates-x86_64/


Additionally, you have to follow the build instructions given on 
https://github.com/traud/asterisk-amr , especially you have to run

./bootstrap.sh

before ./configure

of asterisk. As I'm building my asterisk binary on base of a self maintained 
Schmooze spec file, I can say, that it is not necessary to run this command 
with the option
--enable-category MENUSELECT_CORE_SOUNDS - Schmooze uses the opposite:

./menuselect/menuselect --disable-category MENUSELECT_CORE_SOUNDS



How to proof build success?
You should get after compile 2 new modules in /usr/lib64/asterisk/modules:

codec_amr.so
res_format_attr_amr.so

After restarting of asterisk, you can check with "core show codecs audio", if 
those 2 codecs are displayed:

1 audio amr  amr  (AMR)
2 audio amrwbamrwb(AMR-WB)

Further more, you can check, if transcoding basically works with "core show 
translation". If you can find amr and amrwb in the output, transcoding is 
expected to work.



How to test it in the wild?
With Deutsche Telekom e.g, there are mobile calls using amr codec (if you 
accept it). You can see it in the SDP of the INVITE. After enabling it for the 
trunk, Telekom will use it,
especially on outgoing calls (from what I've seen here).

You can check it for an active call in the asterisk CLI, too:
pjsip show channelstats



The final question: Is there a must have to support amr (with Deutsche 
Telekom)? I don't think so - I've never had any problem so far w/o support of 
amr. Therefore, at the time
being, it's nice to have from my point of view. But it's good to see, if it'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 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
> 
> 
> There is no official support for it.


amr-asterisk-16.12.patch.gz
Description: application/gzip
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Support for amr codec?

[Michael Maier]

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 Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] pjsip - retry handling - faulty warning message?

[Michael Maier]

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):

RegisterAug 15, 2020 16:16:03.946677000 CEST
RegisterAug 15, 2020 16:16:03.97371 CEST~ 27 ms 
(Retry)
Security agreement required Aug 15, 2020 16:16:04.066745000 CEST~ 92 ms
...
Ok  Aug 15, 2020 16:16:04.081487000 CEST~ 14 ms 
(finish)


(Usual duration of a Register is ~ 22.8 ms)

Okay, provider was a bit lazy to answer, but Register has been working fine 
after one retry 27 ms later. Therefore, I don't understand the warning, 
especially because the registration timeout is 660s and asterisk starts 
reregistration 10s before the expiry of the registration - so there wasn't any 
problem with the Registration de facto. Especially as there couldn't be seen 
any Retry after 60 s as stated in the log. Maybe the log entry is somewhat 
hasty?


Thanks
Michael


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Compiling Asterisk 18 with Telekom AllIP mediasec patches seems to work fine / Building RPM package failed

[Michael Maier]

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 FreePBX: as you are meanwhile the same company (Sangoma), I hoped 
that you could know it :-).


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Compiling Asterisk 18 with Telekom AllIP mediasec patches seems to work fine / Building RPM package failed

[Michael Maier]

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
>> 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 intended behavior?
>>
> 
> Yes, as headers are not used by most people they were moved to a separate
> target. This is documented in the UPGRADE.txt document:
> 
> Build
> --
>  * Asterisk headers are no longer installed and uninstalled automatically when
>performing a "make install" or a "make uninstall".  To install/uninstall 
> the
>headers, use "make install-headers" and "make uninstall-headers".  The 
> headers
>also continue to be uninstalled when performing a "make uninstall-all".
> 
> It was actually done for Asterisk 17.

Thanks - now I've got my first Asterisk 18 packages and I know, that mediasec 
most probably will work, too, with Asterisk 18. But I have to finally test it. 
Do you know by chance
when FreePBX will officially support Asterisk 18?

I don't think it would be a good idea to just change the Asterisk version 
without any regard of an actual FreePBX (surely, I would have to add manually 
new options to the additional
config files).


Thanks
Kind regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Compiling Asterisk 18 with Telekom AllIP mediasec patches seems to work fine / Building RPM package failed

[Michael Maier]

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 intended behavior?


Thanks
Kind regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Advanced Codec Negotiation: Need info and uses cases

[Michael Maier]

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 are not common. If there is one common codec on both sides - use
>>> this codec and do not transcode.
>>
>> If Alice (OpenStage20, Local Net) offers G.722, alaw and ulaw and
>> Bob (Remote Localtion) supports Opus, alaw and ulaw, then
>> transcoding between G.722 and Opus results in better audio quality.
>> Transcoding causes some CPU Load, but this might be acceptable.
>>
>>
> Hmmm.  I'll have to think if we can support this generically.
> It'd need an option like
> "use_the_highest_bitrate_codec_even_if_it_means_transcoding" :)

I doubt that this is a good thing. Why should adding additional delay raise 
quality? opus is lossy. Each transcode step adds errors. It can't be better.

Please think about cascades, too! The first one transcodes opus -> g722, the 
next step g722 -> opus, ... . Great.

But it would explain, why some fax calls are horribly broken if you think a 
mechanism like this further.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Advanced Codec Negotiation: Direct Media

[Michael Maier]

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 from peer to peer without asterisk being 
involved besides codec negotiation. This means, asterisk doesn't / can't do any 
transcoding.

In terms of use cases - it's all the same: It's asterisk's job to enforce 
allowed codecs to ensure that lines aren't overloaded to guarantee the quality 
of a voice call.

Therefore the only job of asterisk is to enforce the allowed codecs on both 
sides. If there isn't any match between two sides (or maybe already on the 
incoming side) -> asterisk has
to drop the call. If there are matches, asterisk can proceed. If a phone isn't 
happy with the offer, it will drop the call. That's what I would expect. But 
that's most probably
nothing new ...


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Advanced Codec Negotiation: Asymmetric Codecs

[Michael Maier]

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 from our reading, it's legal in the RFC. In some very
high throughput cases, it was preferable to reduce overall transcoding use
in our infrastructure when you did the math on having a few thousand of
these phones in the same situation.

That being said, it's conceivable we could live without that option now,
and some phone vendors do still not properly implement the RFC standard
around this, but we do still run in production with asymmetric codecs on a
single call leg for a slight majority of our devices.


Sorry, I couldn't find any absolutely necessary reason why there must be asymmetric codecs. For me it sounds more like 
it's just happening at the moment, but it could work all the same using symmetric codecs.
At the moment, I can't see any reason why the 2 legs from a phone must use different codecs. I would be happy to learn 
such a use case which implies necessarily asymmetric codecs.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Advanced Codec Negotiation: Asymmetric Codecs

[Michael Maier]

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 George Joseph wrote:
> Given the earlier discussions, under what conditions is it desirable to use
> a different codec in one direction than the other on the same call leg?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16.11.0-rc2 Now Available

[Michael Maier]

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 this version for quite some time now and couldn't realize any 
problems so far (not especially related to rc2 but 16.11 as a whole).


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Advanced Codec Negotiation: Need info and uses cases

[Michael Maier]

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 additionally read this documentation here [1].
During writing down those lines I got the feeling how complicated could be ... .


Therefore there must be some basic principals on how to handle things. I tried 
to write them down as follows:

0. Asterisk is the only one which decides the codecs to be used on base of the 
allow list on each leg phone <-> Asterisk because I want to be sure about the 
codecs used on each leg
(because of existing network bandwidth restrictions e.g.)
1. The phone must support at least one of the codecs of the allow list. If not: 
drop the call
2. Bringing together the legs: the actually used codec list on each leg only 
contains the codecs supported by the respective device and which are allowed on 
the allow list on the
other hand.
3. At this point Asterisk decides: if there are common codecs on both legs -> 
use these / this. If there are no common codecs between two legs: transcode 
(Use case: don't prevent a
call as long as the codecs on each leg itself are allowed).
4. Each phone on each call leg may define its own codec order. But Asterisk 
finally has to decide, which side to prefer (-> switchable).
5. Basically, a phone mustn't advertise codecs it can't handle - if this can't 
be prevented, the codec has to be removed on the respective allow list of the 
line on Asterisk side.

[...]

> Simple use case, Alice to Bob, no direct media.
> 
> 1.  Under what conditions would we accept a format on an incoming offer
> from a UAC (Alice) that *wasn't* in the UAC's endpoint allow= parameter?

The use case of this consideration seems to me: How to handle broken 
configurations.

>   Does whether we accept formats not on the endpoint need to be
> configurable?   Don't just say "yes". :)

No. From my point of view it never ever is Asterisk's job to handle broken 
configurations. Simple example: Phone sends SDP offer codec a) and b) which are 
both not on the allow list
for this endpoint -> drop the call.

>   We need use cases.

Use case: It's not Asterisk's job to repair broken configurations. I must be 
sure that only allowed codecs are used on a defined port because of bandwidth 
restrictions e.g.

>   We could
> use the offer's list exclusively, use the endpoint's list exclusively,
> merge the two together, or use only those in common.

Asterisk finally defines which codec to use. Therefore all codecs of the phones 
offer have to be dropped which are not part of the allow list. Furthermore all 
codecs of the allow
list have to be dropped, which are not contained in the SDP offer of the device.

>  What happens if after
> applying that operation, there are no formats in common?  Drop the call?

Exactly. Because it's a result of misconfiguration. It's not Asterisk's job to 
repair broken configurations.

> Transocde? 

Transcoding only if there is an allowed and supported codec on both sides which 
are not common. If there is one common codec on both sides - use this codec and 
do not transcode.

> Using what format? It'd have to be one Alice accepts.  We'll
> save the process of transcoding for a follow-on discussion.
> 
> 2.  Under what conditions would we send a codec in an offer to a UAS (Bob)
> that *wasn't* in the UAS's endpoint allow= parameter.

Never! I must be sure about the codecs to be used on a line (bandwidth).

>   Similarly, under
> what conditions would we send a format to Bob that *was* in his endpoint
> allow= parameter but *wasn't* in the reconciled list we got from Alice via
> the core?  Same possible options and questions as above.

Asterisk just should send the codecs to Bob which are part of the allow list - 
nothing more. The order could be defined by the reconciled list we got from 
Alice. Always the same use
case: Asterisk defines which codec to use just to be sure that bandwidth 
requirements can be enforced (or other requirements)

> 
> 3.  OK now whatever we've decided to send to Bob, according to RFC3264 para
> 6.1, Bob MUST send back an answer that contains a common format OR reject
> the stream if there are no formats in common.  It doesn't say whether it's
> valid for Bob to send back formats we didn't request *in addition *to ones
> we did request.  It wouldn't make sense for him to do that because that
> same RFC and paragraph only says we MUST accept media in a format we sent.
> It doesn't mention what should happen if we get media in a format we
> *didn't* request.  Based on this, unless someone can give us a valid use
> case for this, and rules governing when it's acceptable and when it's not,
> we do NOT plan on supporting receiving media in a format we didn't
> request.

Yes.

>  We'd just drop the frames.

Correctly.

>   If Bob wants to use a format 

Re: [asterisk-dev] Problems with massively (continously) growing skew

[Michael Maier]

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 perfect.
> 
> Tracetool is pcapsipdump.
> 
> Problem can't be seen that massive during "normal" (non) fax calls (maybe 
> just a
> little bit).
> 
> 
> What can be seen?
> 
> Inbound fax:
> - Fax passthrough (alaw)
> - Fax received by asterisk
> - no Jitterbuffer
> - after about 1 minute of duration (> 6100 packages):
>   skew rises from +-0 to -30 (from one package to the
>   other) and all following packages afterwards have -19.9
>   ms (one package seems to be just dropped without any
>   sequence error (sequence counter is ok))
> - Another 4000 packages later one more dropped package
>   (without sequence error) from -19.9 to -52 and
>   afterwards all following packages -39.9 ms (sampling
>   rate: 20 ms) -> exactly the same as before but from -19
>   to - 40 ms.
> - Duration: ~ 2 minutes
> - always reproducible

After I could resolve the problem for outgoing faxes (see below), I'm wondering
how skewing is done when asterisk / spandsp does the fax handling.

Asterisk itself uses res_timing_timerfd.so. But if I understand [1] correctly,
asterisk doesn't do any timing for fax handling (and therefore no skew related
jobs at all). This would mean, spandsp has to do it. But spandsp doesn't seem to
use timerfd.

At the moment I'm struggling at this point. How can I improve skewing for 
asterisk
/ spandsp? Where is it done in general?

> 
> Outbound fax
> - Fax passthrough (alaw)
> - sent via iaxmodem through asterisk (iaxmodem connected
>   to asterisk via iax). No jitterbuffer!
> - skew is rising continuously (+362 ms after 363 s
>   duration -> every second +1 ms)
> - always reproducible

I could find the problem for outbound faxes via iaxmodem.

Version 1.2.0 introduced improved skew behavior, which unfortunately breaks 
things
here. After reverting this new feature, sending outgoing faxes via iaxmodem 
works
as expected again.

Attached you can find the patch to remove the improved skewing feature again 
based
on iaxmodem 1.3.1


Thanks
Michael


[1] https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces
--- 1/iaxmodem.c	2016-02-07 02:24:28.0 +0100
+++ 2/iaxmodem.c	2020-04-10 10:38:55.48400 +0200
@@ -140,8 +140,6 @@
 static int dspdebug = 0;
 static int nodaemon = 0;
 static int commalen = 2;
-static int defskew = 0;
-static int skew;
 
 struct modem {
 struct modem *next;
@@ -420,12 +418,6 @@
 	nodaemon = 1;
 	printlog(LOG_INFO, "This modem is exempt from daemon use.\n");
 }
-if (strncasecmp(line, "skew", 4) == 0) {
-	line += 4;
-	while (*line == '\t' || *line == ' ') line++;
-	defskew = atoi(line);
-	printlog(LOG_INFO, "Setting skew = %d\n", defskew);
-}
 }
 
 void
@@ -544,7 +536,7 @@
 	if (!info) t31_call_event(s, AT_CALL_EVENT_ANSWERED);
 	modemstate = MODEM_CONNECTED;
 	gettimeofday(, NULL);
-	nextaudio.tv_usec += (VOIP_PACKET_LENGTH + skew);
+	nextaudio.tv_usec += VOIP_PACKET_LENGTH;
 	if (nextaudio.tv_usec >= 100) {
 		nextaudio.tv_sec += 1;
 		nextaudio.tv_usec -= 100;
@@ -932,8 +924,7 @@
 	t31_state.audio.modems.fast_modems.v27ter_rx.logging.level = loglevel;
 }
 
-int selectfd, selectretval, selectblock, avail, audiobalance = 0;
-skew = defskew;
+int selectfd, selectretval, selectblock, avail, audiobalance = 0, skew = 0;
 struct timeval tv;
 fd_set select_rfds;
 for (;;) {
@@ -970,7 +961,7 @@
 	}
 	if (modemstate == MODEM_CONNECTED) {
 	tv.tv_sec = 0;
-	tv.tv_usec = timediff(nextaudio, now) - window;
+	tv.tv_usec = timediff(nextaudio, now) - (window + skew);
 	} else if (modemstate == MODEM_RINGING) {
 	tv.tv_sec = 5; tv.tv_usec = 0;	/* ring every 5 seconds */
 	timeradd(, , );
@@ -1067,8 +1058,8 @@
 	/*
 	 * Is it time to send more audio?  (This comes first for a reason, as it's our priority.)
 	 */
-	if (modemstate == MODEM_CONNECTED && timediff(nextaudio, now) <= window) {
-	nextaudio.tv_usec += (VOIP_PACKET_LENGTH + skew);
+	if (modemstate == MODEM_CONNECTED && timediff(nextaudio, now) <= (window + skew)) {
+	nextaudio.tv_usec += VOIP_PACKET_LENGTH;
 	if (nextaudio.tv_usec >= 100) {
 		nextaudio.tv_sec += 1;
 		nextaudio.tv_usec -= 100;
@@ -1093,14 +1084,11 @@
 		if (audiobalance > 5) {
 		/*
 		 * We seem to be getting ahead in our audio transmissions, relative
-		 * to the audio receptions.  So we lengthen the time between transmissions
-		 * (by increasing our perception of VOIP_PACKET_LENGTH), hoping to improve the ratio.
-		 *
-		 * We are deliberately less-sensitive to get

Re: [asterisk-dev] Problems with massively (continously) growing skew

[Michael Maier]

Hello!

Meanwhile, I tested several different versions of spandsp - but always the same
problem. I tested another platform (for iaxmodem) - same behavior, too.

All tests are done with Asterisk 16.9.0 / pjsip.


At first, let's concentrate on the inbound faxes. It's asterisk, which receives
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 
> asterisk.
> The packages received are pretty perfect.
> 
> Tracetool is pcapsipdump.
> 
> Problem can't be seen that massive during "normal" (non) fax calls (maybe 
> just a
> little bit).
> 
> 
> What can be seen?
> 
> Inbound fax:
> - Fax passthrough (alaw)
> - Fax received by asterisk
> - no Jitterbuffer
> - after about 1 minute of duration (> 6100 packages):
>   skew rises from +-0 to -30 (from one package to the
>   other) and all following packages afterwards have -19.9
>   ms (one package seems to be just dropped without any
>   sequence error (sequence counter is ok))
> - Another 4000 packages later one more dropped package
>   (without sequence error) from -19.9 to -52 and
>   afterwards all following packages -39.9 ms (sampling
>   rate: 20 ms) -> exactly the same as before but from -19
>   to - 40 ms.
> - Duration: ~ 2 minutes
> - always reproducible

I found another way to demonstrate the problem: using Wiresharks I/O Graph in
statistics (packets/second). Here you can see very well the problem: there are
missing packets - but without any sequence error - they are just not created.
Testcase here is a pretty short fax. The exactly same behavior can be found with
longer faxes, too.

You can find find two screenshots (2 examples) here:

Example 1 [1]
The red line represents the outbound packets/s. The green line are the incoming
packet/s.

Example 2 [2]
The green line represents the outbound packets/s. The red line are the incoming
packet/s.


Thanks
Kind regards
Michael


[1] https://www.bilder-upload.eu/bild-898820-1586108183.png.html

[2] https://www.bilder-upload.eu/bild-eaf123-1586109449.png.html

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Problems with massively (continously) growing skew

[Michael Maier]

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) fax calls (maybe just a
little bit).


What can be seen?

Inbound fax:
- Fax passthrough (alaw)
- Fax received by asterisk
- no Jitterbuffer
- after about 1 minute of duration (> 6100 packages):
  skew rises from +-0 to -30 (from one package to the
  other) and all following packages afterwards have -19.9
  ms (one package seems to be just dropped without any
  sequence error (sequence counter is ok))
- Another 4000 packages later one more dropped package
  (without sequence error) from -19.9 to -52 and
  afterwards all following packages -39.9 ms (sampling
  rate: 20 ms) -> exactly the same as before but from -19
  to - 40 ms.
- Duration: ~ 2 minutes
- always reproducible


Outbound fax
- Fax passthrough (alaw)
- sent via iaxmodem through asterisk (iaxmodem connected
  to asterisk via iax). No jitterbuffer!
- skew is rising continuously (+362 ms after 363 s
  duration -> every second +1 ms)
- always reproducible


Does anybody has any idea?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16.9.0-rc1 Now Available - unusable with Deutsche Telekom

[Michael Maier]

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, Mar 6, 2020 at 10:07 PM Michael Maier 
>>>> wrote:
>>>>
>>>>> 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 patch. With Deutsche Telekom, you always get a SRV record set. On
>>>>> the other hand, you mostly have to register 3 numbers - each must be
>>>>> registered on its own - to the same destination. Therefore, on startup,
>>>>> there are 3 registers done to the same destination. Often, one of the
>>>>> three numbers fails to register on the first attempt and therefore, it
>>>>> is done twice.
>>>>>
>>>>> With this patch, you're now using the second of usually 3 SRV entries
>>>>> and registration is done successfully (which would have worked too, if
>>>>> you would have used the first entry again, because it's just a very
>>>>> temporary problem) - but all succeeding calls (outgoing INVITEs) are
>> now
>>>>> rejected (403 Forbidden), because they are going to the first entry of
>>>>> the SRV record set - which fails on Deutsche Telekom, because they
>> await
>>>>> all subsequent actions to be done at the same server as the
>> registration
>>>>> was done.
>>>>>
>>>>>
>>> I'm thinking more about this...   Basically, the only reason this worked
>> in
>>> the past is that the SRV processing was broken. :)
>>
>> Yes - that's definitely true. Sometime, "broken" isn't always that bad
>> but can be pretty good at the same time on the other hand :-)
>>
>> BTW:
>> While you're at it: it would be a great oportunity to get it sorted out
>> completely by globaly adding session stability (one trunk always uses
>> same IP destination for all actions. If the destionation can't be
>> reached any more (or misbehaves), you have to reregister to another IP
>> of the list and remember the new IP for all following actions).
>>
> 
> Yeah, we're thinking that's the only real solution but it's not a quick fix
> and will need some serious thought.  For instance, if on registration the
> first server in the set was successful but when Asterisk attempted to send
> a call, the first server failed, would you expect Asterisk to automatically
> try to re-register and then use the new server?

Exactly.

>  That would be a lot of
> work just to support DT.  Now if they could point to an RFC that codifies
> their required behavior it would be a different matter.  We checked around
> and couldn't find anything however.

The complete interface documentation and the related RFCs can be found
here (there system is based on IMS and 3GPP):

https://www.telekom.de/hilfe/geraete-zubehoer/telefone-und-anlagen/informationen-zu-telefonanlagen/schnittstellenbeschreibungen-fuer-hersteller?wt_mc=alias_1254_schnittstellenbeschreibungen=true

Or direct link (in english language):
https://www.telekom.de/hilfe/downloads/1tr114.pdf

> 
> 
>>
>>> Anyway, What do the 3 numbers represent?  3 different DIDs and therefore
>> it
>>> could be any number, or 3 numbers for each DID, etc.?  How do you use
>> the 3
>>> numbers?
>>
>> The 3 numbers are 3 completely different numbers and DIDs at the same
>> time. They are used for in- and outbound calls and each number
>> represents an own trunk (as seen by FreePBX e.g.). You have to register
>> each number on its own to be able to place outbound calls and to get
>> inbound calls for this number. If you don't register a number and
>> someone calls this number, the caller gets a "the number you dialed is
>> currently not available - please try again later".
>>
> 
> OK I understand now.
> 
> I think the bottom line is that this isn't a regression and creating an
> option to disable a bug fix isn't a real solution.  While we figure out a
> long term solution I believe your only short term one is to use IP
> addresses or specific A/ recor

Re: [asterisk-dev] Asterisk 16.9.0-rc1 Now Available - unusable with Deutsche Telekom

[Michael Maier]

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 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 patch. With Deutsche Telekom, you always get a SRV record set. On
>>> the other hand, you mostly have to register 3 numbers - each must be
>>> registered on its own - to the same destination. Therefore, on startup,
>>> there are 3 registers done to the same destination. Often, one of the
>>> three numbers fails to register on the first attempt and therefore, it
>>> is done twice.
>>>
>>> With this patch, you're now using the second of usually 3 SRV entries
>>> and registration is done successfully (which would have worked too, if
>>> you would have used the first entry again, because it's just a very
>>> temporary problem) - but all succeeding calls (outgoing INVITEs) are now
>>> rejected (403 Forbidden), because they are going to the first entry of
>>> the SRV record set - which fails on Deutsche Telekom, because they await
>>> all subsequent actions to be done at the same server as the registration
>>> was done.
>>>
>>>
> I'm thinking more about this...   Basically, the only reason this worked in
> the past is that the SRV processing was broken. :)

Yes - that's definitely true. Sometime, "broken" isn't always that bad
but can be pretty good at the same time on the other hand :-)

BTW:
While you're at it: it would be a great oportunity to get it sorted out
completely by globaly adding session stability (one trunk always uses
same IP destination for all actions. If the destionation can't be
reached any more (or misbehaves), you have to reregister to another IP
of the list and remember the new IP for all following actions).

> Anyway, What do the 3 numbers represent?  3 different DIDs and therefore it
> could be any number, or 3 numbers for each DID, etc.?  How do you use the 3
> numbers?

The 3 numbers are 3 completely different numbers and DIDs at the same
time. They are used for in- and outbound calls and each number
represents an own trunk (as seen by FreePBX e.g.). You have to register
each number on its own to be able to place outbound calls and to get
inbound calls for this number. If you don't register a number and
someone calls this number, the caller gets a "the number you dialed is
currently not available - please try again later".


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16.9.0-rc1 Now Available - unusable with Deutsche Telekom

[Michael Maier]

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 have some other products, too,
especially for business like DeutschlandLAN SIP Trunk [2], which all do
behave more or less slightly different.

I remember, there is a product, which relies on different (TCP) ports if
you want to register more than one number (asterisk registers all
numbers to one destination using the same local port and dest. IP -
which isn't a problem with the AllIP solution).


Regards,
Michael

[1] https://www.telekom.de/zuhause/tarife-und-optionen/internet

[2]
https://geschaeftskunden.telekom.de/internet-dsl/tarife/festnetz-internet-dsl/deutschlandlan-sip-trunk#tarife

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16.9.0-rc1 Now Available - unusable with Deutsche Telekom

[Michael Maier]

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 patch. With Deutsche Telekom, you always get a SRV record set. On
the other hand, you mostly have to register 3 numbers - each must be
registered on its own - to the same destination. Therefore, on startup,
there are 3 registers done to the same destination. Often, one of the
three numbers fails to register on the first attempt and therefore, it
is done twice.

With this patch, you're now using the second of usually 3 SRV entries
and registration is done successfully (which would have worked too, if
you would have used the first entry again, because it's just a very
temporary problem) - but all succeeding calls (outgoing INVITEs) are now
rejected (403 Forbidden), because they are going to the first entry of
the SRV record set - which fails on Deutsche Telekom, because they await
all subsequent actions to be done at the same server as the registration
was done.

Therefore, this patch is a no go for all users of Deutsche Telekom or
any other provider relying on all actions to be done to always the same
destination IP.

Therefore, please make this new feature switchable or add another
feature, which takes care to always use the same destination IP as
initially used for the registration. You have to take care, too, that
there is more than one number at the same time - but all of them using
the same destination SRV hostname, but they could have different IP
addresses - but each number must use its own IP which was initially used
for the register.

For convenience, I attached the reverse patch to remove the offending
patch which makes asterisk mainly unusable for users of Deutsche Telekom.


Thanks
Michael
--- b/res/res_pjsip_outbound_registration.c
+++ a/res/res_pjsip_outbound_registration.c
@@ -334,14 +334,6 @@
 	 * module unload.
 	 */
 	pjsip_regc *client;
-	/*!
-	 * \brief Last tdata sent
-	 * We need the original tdata to resend a request on auth failure
-	 * or timeout.  On an auth failure, we use the original tdata
-	 * to initialize the new tdata for the authorized response.  On a timeout
-	 * we need it to skip failed SRV entries if any.
-	 */
-	pjsip_tx_data *last_tdata;
 	/*! \brief Timer entry for retrying on temporal responses */
 	pj_timer_entry timer;
 	/*! \brief Optional line parameter placed into Contact */
@@ -552,13 +544,6 @@
 	/* Due to the message going out the callback may now be invoked, so bump the count */
 	ao2_ref(client_state, +1);
 	/*
-	 * We also bump tdata in expectation of saving it to client_state->last_tdata.
-	 * We have to do it BEFORE pjsip_regc_send because if it succeeds, it decrements
-	 * the ref count on its own.
-	 */
-	pjsip_tx_data_add_ref(tdata);
-
-	/*
 	 * Set the transport in case transports were reloaded.
 	 * When pjproject removes the extraneous error messages produced,
 	 * we can check status and only set the transport and resend if there was an error
@@ -567,26 +552,13 @@
 	pjsip_regc_set_transport(client_state->client, );
 	status = pjsip_regc_send(client_state->client, tdata);
 
+	/* If the attempt to send the message failed and the callback was not invoked we need to
+	 * drop the reference we just added
-	/*
-	 * If the attempt to send the message failed and the callback was not invoked we need to
-	 * drop the references we just added
 	 */
 	if ((status != PJ_SUCCESS) && !(*callback_invoked)) {
-		pjsip_tx_data_dec_ref(tdata);
 		ao2_ref(client_state, -1);
-		return status;
 	}
 
-	/*
-	 * Decref the old last_data before replacing it.
-	 * BTW, it's quite possible that last_data == tdata
-	 * if we're trying successive servers in an SRV set.
-	 */
-	if (client_state->last_tdata) {
-		pjsip_tx_data_dec_ref(client_state->last_tdata);
-	}
-	client_state->last_tdata = tdata;
-
 	return status;
 }
 
@@ -1105,25 +1077,11 @@
 		retry_after = pjsip_msg_find_hdr(param->rdata->msg_info.msg, PJSIP_H_RETRY_AFTER,
 			NULL);
 		response->retry_after = retry_after ? retry_after->ivalue : 0;
-
-		/*
-		 * If we got a response from the server, we have to use the tdata
-		 * from the transaction, not the tdata saved when we sent the
-		 * request.  If we use the saved tdata, we won't process responses
-		 * like 423 Interval Too Brief correctly and we'll wind up sending
-		 * the bad Expires value again.
-		 */
-		pjsip_tx_data_dec_ref(client_state->last_tdata);
-
 		tsx = pjsip_rdata_get_tsx(param->rdata);
 		response->old_request = tsx->last_tx;
 		pjsip_tx_data_add_ref(response->old_request);
 		pjsip_rx_data_clone(param->rdata, 0, >rdata);
-	} else {
-		/* old_request steals the reference */
-		response->old_request = client_state->last_tdata;
 	}
-	client_state->last_tdata = NULL;
 
 	/*
 	 * Transfer response reference to serializer task so the
@@ -1169,9 +1127,6 @@
 	

Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation

[Michael Maier]

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 ...).
>>>>
>>>>Or:
>>>>
>>>>The list can be created on base of list 1
>>>>(option remote ...) and the callees allow line.
>>>>
>>>>Both lists may have a different codec order or
>>>>different codecs (if *_single is provided).
>>>>
>>>>Codecs not given in the callees allow line or
>>>>list 1 are dropped (*_limit).
>>>>
>>>>
>>> This is mostly correct, but for clarification selecting the "remote" or
>>> "local" value will always only contain those codecs from the endpoint
>>> configuration allow line. Or another way to say it is the resulting list
>> is
>>> the intersection of the two lists (list 1 and allow=) plus the codecs in
>>> the allow line that are not in list 1. The order will change depending on
>>> which value is used.
>>>
>>> This means that if list 1 contains a codec not found in the endpoints
>>> allow= line then that codec will not be included in the resulting list.
>> For
>>> example;
>>>
>>> list 1 = opus,ulaw,alaw
>>> allow= ulaw, alaw, g722
>>>
>>> Then if "remote" or "local" is chosen then the resulting list will never
>>> have opus in it.
>>
>> Sorry, I don't understand at the moment, how it is possible to *not*
>> choose "remote" or "local". According to your documentation, "remote" is
>> the default if you don't provide any option to outgoing_sdp_send_prefs.
>> Maybe I missunderstood some more ... .
>>
> 
> No worries it's my bad. I can see how what I wrote was ambiguous. What I
> meant was "if *either* remote *or* local is chosen". As in it doesn't
> matter which option value you choose. Either one would result (in this
> example) in opus not being included in list 2.

Hmm, that's how I understood it - but I still can't see any possibility
to not provide either remote or local value. Therefore I can't see any
possibility to ever get opus in your given example above to the
resulting list 2. But that would be ok anyway, because I don't ever want
to have opus in the list in this specific case.

Could you please tell me, how outgoing_sdp_send_prefs can be used
*without* any active "value" (like local, local_limit, local_single,
remote, remote_limit, remote_single) as long as *remote* is
automatically used ("default") according documentation if no other value
is provided? This would be the same for all other lists, too.


From documentation:
--
remote - Order by what is optionally given by a "caller". Note, the
resulting list will contain those codecs specified by Bob's
configuration, which are not found also in the given remote list, as
least preferred. Meaning they will be at the end, or bottom of the list
(*default*)
--


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation

[Michael Maier]

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:
> 
>> 
>>
>> Could the planned codec handling globally described like this:
>>
>>
> Overall I think you have the gist of it. See below, though, for a couple of
> clarifications.
> 
> 
>>
>> The codec handling is based on 4 lists.
>>
>> 1. incoming_sdp_receive_prefs
>>This list is created based on the allow line
>>of the callers extension and the SDP offer of
>>the phone (local ...).
>>
>>Or:
>>
>>This list is created based on the SDP offer of
>>the caller and the allow line of the extension
>>(remote).
>>
>>Codecs not given in the callers allow line are
>>dropped. Both list variants may have a
>>different codec order.
>>
>>
>> 2. outgoing_sdp_send_prefs
>>The list can be created on base of the callees
>>allow line and list 1 (option local ...).
>>
>>Or:
>>
>>The list can be created on base of list 1
>>(option remote ...) and the callees allow line.
>>
>>Both lists may have a different codec order or
>>different codecs (if *_single is provided).
>>
>>Codecs not given in the callees allow line or
>>list 1 are dropped (*_limit).
>>
>>
> This is mostly correct, but for clarification selecting the "remote" or
> "local" value will always only contain those codecs from the endpoint
> configuration allow line. Or another way to say it is the resulting list is
> the intersection of the two lists (list 1 and allow=) plus the codecs in
> the allow line that are not in list 1. The order will change depending on
> which value is used.
> 
> This means that if list 1 contains a codec not found in the endpoints
> allow= line then that codec will not be included in the resulting list. For
> example;
> 
> list 1 = opus,ulaw,alaw
> allow= ulaw, alaw, g722
> 
> Then if "remote" or "local" is chosen then the resulting list will never
> have opus in it.

Sorry, I don't understand at the moment, how it is possible to *not*
choose "remote" or "local". According to your documentation, "remote" is
the default if you don't provide any option to outgoing_sdp_send_prefs.
Maybe I missunderstood some more ... .

> Unless for some reason folks think it would make sense to
> make an offer to a device containing codec(s) that were not part of its
> Asterisk endpoint configuration definition.
> 
> 
>>
>> 3. outgoing_sdp_receive_prefs
>>The list is created based on the received SDP
>>and list 2 (remote ...).
>>
>>Or:
>>
>>The list is based on list 2 and the received
>>SDP.
>>
>>These list variants may provide different codec
>>orders or different codecs (if *_single is
>>provided).
>>
>>This list only contains codecs which can be
>>found in the received SDP and in list 2 at the
>>same time.
>>
>>
>> 4. incoming_sdp_send_prefs
>>This list is created based on list 3 and 1
>>(remote ...)
>>
>>Or
>>
>>the list is based on 1 and 3 (local ...).
>>
>>The Codec order may differ between those
>>variants.
>>
>>This list only contains codecs which can be
>>found in list 3 and 1 at the same time
>>(*_limit).
>>
>>
> Again this is mostly the case, but pretty much the same description from
> above applies here too, i.e. the resulting list will never have codecs in
> it that were not part of list 1.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation

[Michael Maier]

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 Michael Maier 
>> wrote:
>>
>>>
>>>
>>
>>> 
>>>
>>> From my point of view, it should always be possible to prevent
>>> transcoding as long as there is one codec which can be used on both
>>> sides. If there is more than one codec equal on both sides, it's good to
>>> have the possibility by your planned options if the local or the remote
>>> most preferred codec should be used.
>>>
>>> Default configuration for me would be like that:
>>> incoming_sdp_receive_prefs=local
>>> outgoing_sdp_send_prefs=remote
>>> outgoing_sdp_receive_prefs=local
>>> incoming_sdp_send_prefs=local
>>> transcode=avoid
>>>
>>> From my understanding, this should avoid any unnecessary transcoding as
>>> long as there's just one common codec on both sides and should always
>>> prefer the codecs desired by the caller.
>>>
>>> Did I got this correctly?
>>>
>>
>> We're still working through the idea of the "transcode" option, and how it
>> might work in practice. But what you have is the general idea. To better
>> avoid it, in the setup you have above I'd probably modify the following:
>>
> 
> incoming_sdp_send_prefs=remote
> 
> This would send in the answer to Alice the exact order preferred by Bob. If
> Alice accepts then Asterisk should never transcode.

Thanks! That's true. Probably even better remote_limit (even for
outgoing_sdp_send_prefs).


Could the planned codec handling globally described like this:


The codec handling is based on 4 lists.

1. incoming_sdp_receive_prefs
   This list is created based on the allow line
   of the callers extension and the SDP offer of
   the phone (local ...).

   Or:

   This list is created based on the SDP offer of
   the caller and the allow line of the extension
   (remote).

   Codecs not given in the callers allow line are
   dropped. Both list variants may have a
   different codec order.


2. outgoing_sdp_send_prefs
   The list can be created on base of the callees
   allow line and list 1 (option local ...).

   Or:

   The list can be created on base of list 1
   (option remote ...) and the callees allow line.

   Both lists may have a different codec order or
   different codecs (if *_single is provided).

   Codecs not given in the callees allow line or
   list 1 are dropped (*_limit).


3. outgoing_sdp_receive_prefs
   The list is created based on the received SDP
   and list 2 (remote ...).

   Or:

   The list is based on list 2 and the received
   SDP.

   These list variants may provide different codec
   orders or different codecs (if *_single is
   provided).

   This list only contains codecs which can be
   found in the received SDP and in list 2 at the
   same time.


4. incoming_sdp_send_prefs
   This list is created based on list 3 and 1
   (remote ...)

   Or

   the list is based on 1 and 3 (local ...).

   The Codec order may differ between those
   variants.

   This list only contains codecs which can be
   found in list 3 and 1 at the same time
   (*_limit).


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation

[Michael Maier]

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
> course how transcoding is affected by that.

I'm really happy to hear that you are going to improve the codec
handling! Thanks for that!

> Well hopefully that wait will soon be over. Currently we have plans to work
> on this for Asterisk 18.

Will Asterisk 18 be a LTS version?

> The bulk of that work will be around the addition
> of new chan_pjsip options that will allow a user to better control codec
> offerings, and order.
> 
> I've added a page to the wiki [1] beneath the Asterisk 18 roadmap page that
> explains what those options are (along with a couple current codec related
> ones), and how they will work. Please, if you have any interest in this
> topic read through that page and let us know what you think, or how things
> can be improved.
> 
> [1] https://wiki.asterisk.org/wiki/display/AST/Codec+Negotiation

From my point of view, it should always be possible to prevent
transcoding as long as there is one codec which can be used on both
sides. If there is more than one codec equal on both sides, it's good to
have the possibility by your planned options if the local or the remote
most preferred codec should be used.

Default configuration for me would be like that:
incoming_sdp_receive_prefs=local
outgoing_sdp_send_prefs=remote
outgoing_sdp_receive_prefs=local
incoming_sdp_send_prefs=local
transcode=avoid

From my understanding, this should avoid any unnecessary transcoding as
long as there's just one common codec on both sides and should always
prefer the codecs desired by the caller.

Did I got this correctly?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip asterisk 13.24: sips / srtp and Deutsche Telekom doesn't work because of missing mediasec parameters

[Michael Maier]

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.patch" 
contained in the patchset.tar.gz container.
The "3-reduced-mediasec-switches.patch" mainly removed an unnecessary switch 
(aor) introduced by "2-add-mediasec-switches.patch".

This is how the patches in the container should be used (tested against 
asterisk 16.6.x):
You may apply the patches 1-mediasec-no-initial-reInvite.patch, 
2-add-mediasec-switches.patch and 3-reduced-mediasec-switches.patch in the 
given order or you may only apply
the last patch (mediasec-all-in-one.patch), which combines the first 3 patches 
in one patch.


How should it all be used now?
If you want to use SIPS and SRTP with Deutsche Telekom AllIP, you have to be 
sure to enable the following features in the pjsip trunk (endpoint):

- transport: tls (TLS 1.2)
- enable SRTP for this trunk
- endpoint: support_mediasec=1
- registration: support_mediasec=1



If you are using FreePBX, you have to add the support_mediasec switches to
pjsip.endpoint_custom_post.conf and
pjsip.registration_custom_post.conf.

This is done like this:

File pjsip.endpoint_custom_post.conf:
[your name of the trunk](+type=endpoint)
support_mediasec=1

File pjsip.registration_custom_post.conf:
[your name of the trunk](+type=registration)
support_mediasec=true



Thanks
Regards
Michael


mediasec-patchset.tar.gz
Description: application/gzip
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Asterisk 16.x / pjsip TLS] Memory leak with core reload

[Michael Maier]

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.
>>> I'm referring to the possibility, to add additional options not supported 
>>> by FreePBX using special config files like
>>> pjsip.registration_custom_post.conf or pjsip.aor_custom_post.conf and 
>>> pjsip.endpoint_custom_post.conf or pjsip.transports_custom_post.conf.
>>> The last two files are working pretty fine as expected, but the first two 
>>> just don't work.
>>>
>>> I'm configuring in pjsip.registration_custom_post.conf for example:
>>>
>>> [extName](+)
>>> key=value
>>>
>>> Asterisk reads it (asterisk complains if it doesn't know the key), but 
>>> asterisk doesn't apply the provided value for a known key - it's always the 
>>> default value. That's
>>> strange, too. 
>>
>> Please file an issue[1] with a configuration that exhibits this.
> 
> https://issues.asterisk.org/jira/browse/ASTERISK-28563

Thanks to all clarifying the correct way to configure it with FreePBX:

[extName](+type=registration)
key=value

eg.

This really works as expected!

I'm now wondering if I missed some documentation about this feature, because I 
searched the whole web and only found others having the same problem but never 
a solution!

I'm sorry for the noise!


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Asterisk 16.x / pjsip TLS] Memory leak with core reload

[Michael Maier]

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 directly to their issue tracking
>> system (I don't know the URL for that off-hand).
>>
> 
> The FreePBX issue tracker is at https://issues.freepbx.org

This is not a FreePBX issue as the feature

[extName](+)

is provided by asterisk (take a look at the source code) and not FreePBX - 
FreePBX e.g. is just using it.


Regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16.5.x / SIPS / SRTP / pjsip 4.9 - one more memory leak

[Michael Maier]

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.asterisk.org/jira/browse/ASTERISK-28564


Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Asterisk 16.x / pjsip TLS] Memory leak with core reload

[Michael Maier]

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 additional options not supported by 
>> FreePBX using special config files like
>> pjsip.registration_custom_post.conf or pjsip.aor_custom_post.conf and 
>> pjsip.endpoint_custom_post.conf or pjsip.transports_custom_post.conf.
>> The last two files are working pretty fine as expected, but the first two 
>> just don't work.
>>
>> I'm configuring in pjsip.registration_custom_post.conf for example:
>>
>> [extName](+)
>> key=value
>>
>> Asterisk reads it (asterisk complains if it doesn't know the key), but 
>> asterisk doesn't apply the provided value for a known key - it's always the 
>> default value. That's
>> strange, too. 
> 
> Please file an issue[1] with a configuration that exhibits this.

https://issues.asterisk.org/jira/browse/ASTERISK-28563

I think this should be enough - just install FreePBX and you will see it. You 
don't need any special configuration - it's the default configuration provided 
by FreePBX.



Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Asterisk 16.5.x / SIPS / SRTP / pjsip 4.9 - one more memory leak

[Michael Maier]

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 (< 1 minute): ~ +1 MB


Example for the inbound INVITE and OK package:

<--- Received SIP request (2276 bytes) from TLS:217.0.20.195:5061 --->
INVITE sip:+491234567890@12.13.14.15:5061;transport=tcp;line=abcdefg SIP/2.0
Max-Forwards: 49
Via: SIP/2.0/TLS 
217.0.20.195:5061;branch=z9hG4bKg3Zqkv7ivdsp3wo1jhdbdvgy5dwsq6jye
To: 
From: 
;tag=h7g4Esbg_p65540t1570108521m378032c299263169s1_1621954413-1461120854
Call-ID: p65540t1570108521m378032c299263169s2
CSeq: 1 INVITE
Contact: 
;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Record-Route: 
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
History-Info: 
;index=1
Min-Se: 900
P-Asserted-Identity: 
P-Asserted-Identity: 
Session-Expires: 1800
Supported: timer
Supported: 100rel
Supported: histinfo
Supported: 199
Supported: uui
Supported: norefersub
Content-Type: application/sdp
Content-Length: 1061
Session-ID: 253f41678c65f936805ef6b071943e64
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, UPDATE, PRACK, INFO, INVITE, ACK, 
OPTIONS, CANCEL, BYE

v=0
o=- 1011696818 1621954173 IN IP4 217.0.20.195
s=-
c=IN IP4 217.0.135.5
t=0 0
m=audio 27888 RTP/SAVP 96 97 9 98 99 100 101 8 102 103
b=AS:84
a=rtpmap:96 AMR-WB/16000
a=fmtp:96 mode-set=0,1,2; mode-change-period=2; mode-change-neighbor=1; 
max-red=0
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-change-capability=2; max-red=0
a=rtpmap:9 G722/8000
a=rtpmap:98 AMR/8000
a=fmtp:98 mode-set=0,2,4,7; mode-change-period=2; mode-change-neighbor=1; 
max-red=0
a=rtpmap:99 AMR/8000
a=fmtp:99 mode-set=0,2,4; mode-change-period=2; mode-change-neighbor=1; 
max-red=0
a=rtpmap:100 AMR/8000
a=fmtp:100 mode-set=0,1,2,3,4,5,6,7; mode-change-period=2; 
mode-change-neighbor=1; max-red=0
a=rtpmap:101 AMR/8000
a=fmtp:101 mode-set=0,1,2,3,4,5,6,7; max-red=0
a=rtpmap:8 PCMA/8000
a=rtpmap:102 telephone-event/8000
a=rtpmap:103 telephone-event/16000
a=ptime:20
a=maxptime:30
a=3ge2ae:applied
a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:HTNhK8lOYS+/1ORuNEbEhnsisXj4PEVIh8FBKmTR
a=crypto:2 AES_CM_128_HMAC_SHA1_32 
inline:6qBJEfKKXxbpJTepS298yUmUl/891GwnlURC3tdn




<--- Transmitting SIP response (1178 bytes) to TLS:217.0.20.195:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 
217.0.20.195:5061;rport=5061;received=217.0.20.195;branch=z9hG4bKg3Zqkv7ivdsp3wo1jhdbdvgy5dwsq6jye
Record-Route: 
Call-ID: p65540t1570108521m378032c299263169s2
From: 
;tag=h7g4Esbg_p65540t1570108521m378032c299263169s1_1621954413-1461120854
To: 
;tag=94f22858-9c32-44c5-8a45-76964f62684a
CSeq: 1 INVITE
Server: FPBX-14.0.11(16.5.1)
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, 
UPDATE, PRACK, MESSAGE, REFER
Contact: 
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:   368

v=0
o=- 1011696818 1621954176 IN IP4 12.13.14.15
s=Asterisk
c=IN IP4 12.13.14.15
t=0 0
m=audio 10032 RTP/SAVP 9 8 102
a=3ge2ae:requested
a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:OnkHAdHasSl83UnyFNuDSrBx+OsRF8DRZ6c5PnmJ
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-16
a=ptime:20
a=maxptime:150
a=sendrecv


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Asterisk 16.x / pjsip TLS] Memory leak with core reload

[Michael Maier]

Hello Joshua!

Many thanks for your continuous effort supporting the community!

Unfortunately, I'm very busy currently and therefore I can't do the necessary 
investigations to narrow down the issue or just anonymise my asterisk config.

On Mon, Sep 30, 2019, at 17:48 Joshua C. Colp 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 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 for me as my configuration is mostly statically -
but for others having more endpoints / trunks and often change the
config this could be a serious
problem.


Please file an issue[1] with a configuration that exhibits this (for example 
does your transport have allow_reload set to yes, as that would alter things).


No - allow_reload is set to no.


I tried to reproduce this this morning and was unable to. I also asked Kevin to 
try to reproduce it who triaged the original memory leak issues and he was also 
unable to. Can you please file an issue like I mentioned with the specific 
configuration/scenario so we can see if something is up?


A few global words about my config at the moment:
- It's FreePBX 14 based
- There are 4 pjsip SIPS / SRTP trunks
- 2 pjsip SIP trunks
- 1 IAX2 device (for fax)
- several FreePBX features activated, like follow me, e.g.
- 15 outbound routes
- 7 inbound routes
- 3 custom contexts
- a small blacklist

I'm not sure if I'm really able to create a reliable anonymised config with 
justifiable expenditure.


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 additional options not supported by 
FreePBX using special config files like
pjsip.registration_custom_post.conf or pjsip.aor_custom_post.conf and 
pjsip.endpoint_custom_post.conf or pjsip.transports_custom_post.conf.
The last two files are working pretty fine as expected, but the first two just 
don't work.

I'm configuring in pjsip.registration_custom_post.conf for example:

[extName](+)
key=value

Asterisk reads it (asterisk complains if it doesn't know the key), but asterisk doesn't apply the provided value for a known key - it's always the default value. That's 
strange, too.




Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Asterisk 16.x / pjsip TLS] Memory leak with core reload

[Michael Maier]

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 
>> 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 for me as my configuration is mostly statically - 
>> but for others having more endpoints / trunks and often change the 
>> config this could be a serious
>> problem.
> 
> Please file an issue[1] with a configuration that exhibits this (for example 
> does your transport have allow_reload set to yes, as that would alter things).

No - allow_reload is set to no.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] [Asterisk 16.x / pjsip TLS] Memory leak with core reload

[Michael Maier]

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 for me as my configuration is mostly statically - but for 
others having more endpoints / trunks and often change the config this could be 
a serious
problem.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Memory leak since Asterisk 16.5.x / pjsip

[Michael Maier]

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,
and version?


CentOS 7, openssl didn't change. It's openssl-1.0.2k-16.el7_6.1.x86_64



I assume before downgrading you were using the bundled version of Asterisk?


I'm normally using *always* the bundled version - I'm working on base of the 
rpm source package from Schmooze Com, Inc.
I've just changed the third party directory in 16.5.1 from pjsip 4.9 to 4.8 
including all patches. I can provide you with the complete source package if 
you like.


When you downgraded to pjproject 2.8 did you also install the patches that
had been included with Asterisk for 2.8 that were under the
"third-party/pjproject/patches/" directory?


Yes



Lastly, can you attach the config_site.h you used and the ./configure
command you used when configuring/building pjproject 2.8.


It should be the same as in the source file of Schmooze Com, Inc. I can provide the complete rpm source file if you want to have it. Both "versions", the one using 4.8 and 
the one using 4.9.



Regards,
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip asterisk 13.24: sips / srtp and Deutsche Telekom doesn't work because of missing mediasec parameters

[Michael Maier]

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 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 tls1.2). Use at your own risk!
>>
>>
>> The current patch lacks a basic mediasec option, which prevents adding the 
>> mediasec headers to each *initial* REGISTER or to each INVITE (if
>> sdes is activated). As of today, I don't know how to solve this problem 
>> without too much changes.
>> Anyway: It looks like the additional HEADERs seem not to disrupt other ISPs 
>> (tested with one other ISP). This option should be accessible in
>> rtp, session and register environment. Maybe there is a possibility to 
>> exchange data between register, session and rtp environment. This way, it
>> would be possible to dynamically set mediasec in session and rtp based on 
>> the result of the initial register. It would be necessary at the
>> same time, to dynamically disable sdes encryption if activation of mediasec 
>> didn't succeed.
>>
>> One more open point is the check for the 3 headers using the same name 
>> (Security-Server and Security-Verify). How can they be checked
>> regarding order? Is there a function to get each value of the same header? 
>> Maybe based on an array index? This way it would be possible to
>> create the Security-Verify headers dynamically based on the 494 or 401 
>> response.
>>
>> The UPDATE package (used as a watchdog circuit during a call each 15 
>> minutes) seems not to be affected - I couldn't find any problem at this
>> point.
> 
> 
Attached is a new version of the mediasec patch. The following items changed:

The patch now contains too mediasec on ReINVITES initiated by our selves.



Regards
Michael
diff -urN asterisk-16.5.0/res/res_pjsip/pjsip_options.c asterisk-16.5.0.new/res/res_pjsip/pjsip_options.c
--- a/res/res_pjsip/pjsip_options.c	2019-07-25 11:38:14.0 +0200
+++ b/res/res_pjsip/pjsip_options.c	2019-08-31 12:59:33.39900 +0200
@@ -212,6 +212,8 @@
  */
 static struct ast_taskprocessor *management_serializer;
 
+static int sip_options_qualify_contact(void *obj, void *arg, int flags);
+
 static pj_status_t send_options_response(pjsip_rx_data *rdata, int code)
 {
 	pjsip_endpoint *endpt = ast_sip_get_pjsip_endpoint();
@@ -801,6 +803,15 @@
 		break;
 	}
 
+	/* check for 494 */
+	if (status == AVAILABLE && e->body.tsx_state.src.rdata->msg_info.msg->line.status.code == 494) {
+		/* need to resend the options request with mediasec headers */
+		ast_debug(3,"detected 494 - call sip_options_qualify_contact again with mediasec header\n");
+		sip_options_qualify_contact(contact_callback_data->contact, contact_callback_data->aor_options, 494);
+		ao2_ref(contact_callback_data, -1);
+		return;
+	}
+
 	/* Update the callback data with the new status, this will get handled in the AOR serializer */
 	contact_callback_data->status = status;
 
@@ -905,6 +916,14 @@
 		return 0;
 	}
 
+	if (flags && flags == 494) {
+		/* add mediasec header */
+		ast_debug(3,"OPTIONS: adding MEDIASEC headers\n");
+		ast_sip_add_header(tdata,"Security-Verify","msrp-tls;mediasec");
+		ast_sip_add_header(tdata,"Security-Verify","sdes-srtp;mediasec");
+		ast_sip_add_header(tdata,"Security-Verify","dtls-srtp;mediasec");
+	}
+
 	if (ast_sip_send_out_of_dialog_request(tdata, endpoint,
 		(int)(aor_options->qualify_timeout * 1000), contact_callback_data,
 		qualify_contact_cb)) {
diff -urN a/res/res_pjsip_outbound_registration.c b/res/res_pjsip_outbound_registration.c
--- a/res/res_pjsip_outbound_registration.c	2019-07-25 11:38:14.0 +0200
+++ b/res/res_pjsip_outbound_registration.c	2019-09-02 15:07:27.38300 +0200
@@ -361,6 +361,8 @@
 	char *transport_name;
 	/*! \brief The name of the registration sorcery object */
 	char *registration_name;
+	/*! \brief Indicator, if there was a 494 response before */
+	unsigned int is494;
 };
 
 /*! \brief Outbound registration state information (persists for lifetime that registration should exist) */
@@ -597,6 +599,19 @@
 		pj_strassign(>values[hdr->count++], _NAME);
 	}
 
+	/* Add some header for mediasec */
+	if (client_state->is494) {
+		/* answer for 494 */
+		ast_sip_add_header(tdata,"Security-Verify","msrp-tls;mediasec");
+		ast_sip_add_header(tdata,"Security-Verify","sdes-srtp;mediasec");
+		ast_sip_add_header(tdata,"Security-Verify","dtls-srtp;mediasec");
+	}
+	else {
+